From exim@www1.ietf.org Mon May 3 17:30:11 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 RAA03312 for ; Mon, 3 May 2004 17:30:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkT1-0007oH-B3 for nsis-archive@odin.ietf.org; Mon, 03 May 2004 16:55:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43KtBWS030021 for nsis-archive@odin.ietf.org; Mon, 3 May 2004 16:55:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjbE-00066U-8l; Mon, 03 May 2004 15:59:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjWk-0004ur-0Q for nsis@optimus.ietf.org; Mon, 03 May 2004 15:54:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25719; Mon, 3 May 2004 15:54:55 -0400 (EDT) Message-Id: <200405031954.PAA25719@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 03 May 2004 15:54:55 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-04.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Analysis of Existing Quality of Service Signaling Protocols Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-signalling-analysis-04.txt Pages : 39 Date : 2004-5-3 This document reviews some of the existing QoS signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid the mistakes during the design and the implementation of any new protocol in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-signalling-analysis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-3161546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-signalling-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-3161546.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue May 4 06:55:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22239 for ; Tue, 4 May 2004 06:55: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 1BKxPR-0001ra-8j for nsis-archive@odin.ietf.org; Tue, 04 May 2004 06:44:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44AiLo3007147 for nsis-archive@odin.ietf.org; Tue, 4 May 2004 06:44:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIO-0000Fz-F8; Tue, 04 May 2004 06:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKvUY-0000f8-0K for nsis@optimus.ietf.org; Tue, 04 May 2004 04:41: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 EAA17403 for ; Tue, 4 May 2004 04:41: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 1BKvUV-0004iz-1H for nsis@ietf.org; Tue, 04 May 2004 04:41:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKvTq-0004YL-00 for nsis@ietf.org; Tue, 04 May 2004 04:40:47 -0400 Received: from smtp3.libero.it ([193.70.192.127]) by ietf-mx with esmtp (Exim 4.12) id 1BKvT8-0004GT-00 for nsis@ietf.org; Tue, 04 May 2004 04:40:02 -0400 Received: from libero.it (172.16.1.107) by smtp3.libero.it (7.0.027-DD01) id 404F14900071065A for nsis@ietf.org; Tue, 4 May 2004 10:39:30 +0200 Date: Tue, 4 May 2004 10:39:30 +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.168 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PLING_PLING autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] about CASP!!! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 some questions about CASP. 1) Is GIMPS the latest upd= ate of CASP? 2) Which are main differences between CASP and GIMPS? =0D = 3) There are many implementations of CASP. Are there papers about it? Are= there proactive solutions (reservation on new link before the handoff)= with CASP for mobility support? Thanks in advance for your replie= s, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 5 04:13:44 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 EAA29045 for ; Wed, 5 May 2004 04:13:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHSE-0006lB-7n for nsis-archive@odin.ietf.org; Wed, 05 May 2004 04:08:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4588Y8o025970 for nsis-archive@odin.ietf.org; Wed, 5 May 2004 04:08:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHKE-0004Bf-JK; Wed, 05 May 2004 04:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHGV-0002z8-UX for nsis@optimus.ietf.org; Wed, 05 May 2004 03:56: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 DAA28164 for ; Wed, 5 May 2004 03:56: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 1BLHGT-0000oF-Dh for nsis@ietf.org; Wed, 05 May 2004 03:56:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLHFe-0000dc-00 for nsis@ietf.org; Wed, 05 May 2004 03:55:34 -0400 Received: from smtp2.libero.it ([193.70.192.52]) by ietf-mx with esmtp (Exim 4.12) id 1BLHEy-0000QB-00 for nsis@ietf.org; Wed, 05 May 2004 03:54:52 -0400 Received: from libero.it (172.16.1.107) by smtp2.libero.it (7.0.027-DD01) id 404F13FC0073499B for nsis@ietf.org; Wed, 5 May 2004 09:54:55 +0200 Date: Wed, 5 May 2004 09:54:21 +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.168 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] mobility support in NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I have read many draft about mobility support for NSIS. I'd l= ike to know if there are specific solutions or papers about this argument= like MRSVP, HMRSVP for RSVP. Thanks in advance, Elena _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu May 6 04:00:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25580 for ; Thu, 6 May 2004 04:00: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 1BLdlb-0003zp-Bb for nsis-archive@odin.ietf.org; Thu, 06 May 2004 03:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i467w3e0015346 for nsis-archive@odin.ietf.org; Thu, 6 May 2004 03:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdii-0002MK-Tr; Thu, 06 May 2004 03:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdaX-0006Vy-DM for nsis@optimus.ietf.org; Thu, 06 May 2004 03:46:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24751 for ; Thu, 6 May 2004 03:46:35 -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 1BLdaU-0003nG-LQ for nsis@ietf.org; Thu, 06 May 2004 03:46:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdZg-0003QN-00 for nsis@ietf.org; Thu, 06 May 2004 03:45:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLdZ5-00033b-00 for nsis@ietf.org; Thu, 06 May 2004 03:45:08 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i467j8B01736 for ; Thu, 6 May 2004 10:45:08 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 10:44:59 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i467ix9t009470 for ; Thu, 6 May 2004 10:44:59 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 003Slxw3; Thu, 06 May 2004 10:44:56 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 i467iuH23104 for ; Thu, 6 May 2004 10:44:56 +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, 6 May 2004 10:44:52 +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, 6 May 2004 10:44:53 +0300 Message-ID: Thread-Topic: IETF 60 Thread-Index: AcQzPgSW6QxTNgZ6QHqdYgS/gzs2lw== To: X-OriginalArrivalTime: 06 May 2004 07:44:53.0081 (UTC) FILETIME=[0490E490:01C4333E] 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, UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] IETF 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: , Content-Transfer-Encoding: quoted-printable Hi all, I have requested two slots for IETF 60. I imagine that the NSIS agenda = will not look dramatically different than what was discussed at IETF 59, but hopefully we will have make more = progress on the current documents. I have requested the agenda to avoid the following conflicts: MUST AVOID: MIDCOM, IPv6, TSVWG, AAA (I co-chair AAA), SIP, SIPPING =20 SHOULD AVOID:=20 MIP4, MIPv6, CCAMP, TEWG, DCCP, DHC WG, HIP, EAP WG Comments are welcomed. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue May 11 08:11: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 IAA21770 for ; Tue, 11 May 2004 08:11: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 1BNW2o-0005vZ-1g for nsis-archive@odin.ietf.org; Tue, 11 May 2004 08:07:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BC7Xlq022774 for nsis-archive@odin.ietf.org; Tue, 11 May 2004 08:07:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNVxR-00052J-NS; Tue, 11 May 2004 08:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNVsW-0003fB-2s for nsis@optimus.ietf.org; Tue, 11 May 2004 07:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21190 for ; Tue, 11 May 2004 07:56:54 -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 1BNVsV-00079D-A6 for nsis@ietf.org; Tue, 11 May 2004 07:56:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNVrW-0006la-00 for nsis@ietf.org; Tue, 11 May 2004 07:55:55 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BNVqs-0006OL-00 for nsis@ietf.org; Tue, 11 May 2004 07:55:14 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4BBt70O013921; Tue, 11 May 2004 13:55:08 +0200 To: nsis@ietf.org Cc: john.loughney@nokia.com, "McDonald, Andrew" , "Georgios Karagiannis" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 11 May 2004 13:55:04 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/11/2004 13:55:08 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] Submission of draft-ietf-nsis-qos-nslp-03.txt + early review comments update Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, We have submitted draft-ietf-nsis-qos-nslp-03.txt. While it is working its way through the repositories you can find it at: http://nsis.srmr.co.uk/~adm/draft-ietf-nsis-qos-nslp-03.txt Please find below a point-by-point discussion of how the early review comments were addressed. Best regards, Sven Comments on NSLP - in general this doc is not as well written as NTLP and needs some editorial work. Parts are pretty hard to understand. Sven>> We tried to clarify the document. Section 5 (message formats and processing) is restructured. - 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? Sven>> We updated section 1.2 to The 'local application case' includes not only user applications (e.g. multimedia applications) but also network management (e.g. initiating a tunnel to handle an aggregate, or interworking with some other reservation protocol - such as RSVP) and the policy control module (e.g. for explicit teardown triggered by AAA). - How is receiver selection based on ADSPEC done if resources are reserved in the forward direction with RESERVE? Sven>> The draft describes receiver-initiated reservations in section 3.5.3. It basically uses QUERY as PATH. The QUERY message (sender->receiver) contains a QSPEC to can be used to provide ADSPEC to receiver. - some talk about 2-phase operation for RSVP. Any thought of the same for NSLP? Sven>> Section 8.2 states that we assume reserve/commit functionality to be implemented by the QoS model. - Didn't see any way to do resource sharing across flows. Sven>> Section 4.2.4 discusses state handling. It states that resource sharing between flows within a session and between sessions (with BOUND_SESSION_ID) is assumed to be the responsability of the QoS model. This is captured in section 8.1. - Ditto for fate-sharing across flows (if you tear one down you tear the fate-shared ones down) Sven>> Section 4.2.6 discusses session binding. It introduces a NO_FATE_SHARING flag that enables/disables fate sharing between flows within a session and between sessions (with BOUND_SESSION_ID) - Reservation priority is declared out of scope but is critically important. We can't just punt this. One thought is to have it be part of a set of "common facilities" that go across all the GIMPS applications. I bet there are a number of such common things which are not part of the transport but aren't specific to a particular signaling appication. Sven>> This was raised as a question to the mailing list. We received 3 views, mainly stating that reservation priority (preemption) was not a QoS NSLP function. This is captured in section 4.5. Message priority is in scope for the QoS NSLP but relies on GIMPS. This is captured in a GIMPS requirement (section 7.7). We will seek to confirm this position at the interim meeting. - Is there any capability for make-before-break so that reservations can be installed on multiple paths at the same time to deal with graceful mobility? It seems that the notion of flow/session separation captures part of this, but I don't see how it solves the double-booking problems on the common links. Sven>> This issue was raised on the mailing list. The answers were not conclusive although the main stream seems to be that this would require a charter extension. The proposal is to summarize pros and cons at the interim and decide on a way forward there. - how does bi-dir reservation enforce symmetric routing? Sven>> It doesn't. Bidirectional reservations are explained in section 3.5.4. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 12 12:29:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23422 for ; Wed, 12 May 2004 12:29: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 1BNwId-0004q2-Rc for nsis-archive@odin.ietf.org; Wed, 12 May 2004 12:09:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CG9dOg018598 for nsis-archive@odin.ietf.org; Wed, 12 May 2004 12:09:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvZv-0008T5-I9; Wed, 12 May 2004 11:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvNo-0002H3-03 for nsis@optimus.ietf.org; Wed, 12 May 2004 11:10: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 LAA15120 for ; Wed, 12 May 2004 11:10:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNvNl-00070g-99 for nsis@ietf.org; Wed, 12 May 2004 11:10:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNvKw-0005gh-00 for nsis@ietf.org; Wed, 12 May 2004 11:07:59 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BNvHR-0004PO-00 for nsis@ietf.org; Wed, 12 May 2004 11:04:21 -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 i4CF4LAh026866 for ; Wed, 12 May 2004 17:04:21 +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); Wed, 12 May 2004 17:04:21 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 17:04:26 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org, "McDonald, Andrew" , Georgios Karagiannis Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early review comments update Date: Wed, 12 May 2004 17:03:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 12 May 2004 15:04:21.0172 (UTC) FILETIME=[67A6C740:01C43832] 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 Sven, Andrew and Georgios, I went through the QoS-NSLP doc. and I have two main comments: The first one is editorial: There are a lot of information that are repeated more times in the document: first in the Overview part then in the Design Decision and also in the Func. Spec. part, sometimes with very similar details. I know that there are a lot of aspects that should be described and it is difficult to handle it but I think the doc. would be much easier to read if this fractal-like structure could be eliminated. The second is related to bi-directional and receiver-initiated reservation. In both case it can happen that the receiver does not have the resource info for the reverse reservation but the sender has this info. There is a discussion in the open issues mentioning that this info may should be provided by a different application. However, QoS-NSLP provides two natural mechanisms to transmit this info: a) stacking two QSpec like in case of local QoS model example and b) sending a separate reserve message with a QSpec for the reverse path directly to the receiver (like in case of aggregation or reduced state examples). So I would suggest that QoS-NSLP support this function. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > sven.van_den_bosch@alcatel.be > Sent: Tuesday, May 11, 2004 1:55 PM > To: nsis@ietf.org > Cc: john.loughney@nokia.com; McDonald, Andrew; Georgios Karagiannis > Subject: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early > review comments update > > > Hi all, > > We have submitted draft-ietf-nsis-qos-nslp-03.txt. While it > is working its > way through the repositories you can find it at: > http://nsis.srmr.co.uk/~adm/draft-ietf-nsis-qos-nslp-03.txt > > Please find below a point-by-point discussion of how the early review > comments were addressed. > > Best regards, > Sven > > Comments on NSLP > > - in general this doc is not as well written as NTLP and needs some > editorial work. Parts are pretty hard to understand. > > Sven>> We tried to clarify the document. Section 5 (message > formats and > processing) is restructured. > > - 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? > > Sven>> We updated section 1.2 to The 'local application case' > includes not > only user applications (e.g. multimedia applications) but also network > management (e.g. initiating a tunnel to handle an aggregate, or > interworking with some other reservation protocol - such as > RSVP) and the > policy control module (e.g. for explicit teardown triggered by AAA). > > - How is receiver selection based on ADSPEC done if resources > are reserved > in the forward direction with RESERVE? > > Sven>> The draft describes receiver-initiated reservations in section > 3.5.3. It basically uses QUERY as PATH. The QUERY message > (sender->receiver) contains a QSPEC to can be used to provide > ADSPEC to > receiver. > > - some talk about 2-phase operation for RSVP. Any thought of > the same for > NSLP? > > Sven>> Section 8.2 states that we assume reserve/commit > functionality to be > implemented by the QoS model. > > - Didn't see any way to do resource sharing across flows. > > Sven>> Section 4.2.4 discusses state handling. It states that resource > sharing between flows within a session and between sessions (with > BOUND_SESSION_ID) is assumed to be the responsability of the > QoS model. > This is captured in section 8.1. > > - Ditto for fate-sharing across flows (if you tear one down > you tear the > fate-shared ones down) > > Sven>> Section 4.2.6 discusses session binding. It introduces a > NO_FATE_SHARING flag that enables/disables fate sharing between flows > within a session and between sessions (with BOUND_SESSION_ID) > > - Reservation priority is declared out of scope but is critically > important. We can't just punt this. One thought is to have it > be part of a > set of "common facilities" that go across all the GIMPS > applications. I bet > there are a number of such common things which are not part of the > transport but aren't specific to a particular signaling appication. > > Sven>> This was raised as a question to the mailing list. We > received 3 > views, mainly stating that reservation priority (preemption) > was not a QoS > NSLP function. This is captured in section 4.5. Message priority is in > scope for the QoS NSLP but relies on GIMPS. This is captured > in a GIMPS > requirement (section 7.7). We will seek to confirm this > position at the > interim meeting. > > - Is there any capability for make-before-break so that > reservations can be > installed on multiple paths at the same time to deal with graceful > mobility? It seems that the notion of flow/session separation > captures part > of this, but I don't see how it solves the double-booking > problems on the > common links. > > Sven>> This issue was raised on the mailing list. The answers were not > conclusive although the main stream seems to be that this > would require a > charter extension. The proposal is to summarize pros and cons at the > interim and decide on a way forward there. > > - how does bi-dir reservation enforce symmetric routing? > > Sven>> It doesn't. Bidirectional reservations are explained in section > 3.5.4. > > > > _______________________________________________ > nsis mailing 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 May 12 12:46:23 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25660 for ; Wed, 12 May 2004 12:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwil-00018B-R7 for nsis-archive@odin.ietf.org; Wed, 12 May 2004 12:36:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CGadQm004346 for nsis-archive@odin.ietf.org; Wed, 12 May 2004 12:36:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwU4-0003OD-Rm; Wed, 12 May 2004 12:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNw2c-0005zi-Nr for nsis@optimus.ietf.org; Wed, 12 May 2004 11:53: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 LAA19807 for ; Wed, 12 May 2004 11:53: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 1BNw2b-0002rl-JD for nsis@ietf.org; Wed, 12 May 2004 11:53:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNvzp-0001Xf-00 for nsis@ietf.org; Wed, 12 May 2004 11:50:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNvy4-0000Qe-00 for nsis@ietf.org; Wed, 12 May 2004 11:48:25 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BNvxq-0003fE-4Q for nsis@ietf.org; Wed, 12 May 2004 11:48:11 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 16:47:13 +0100 Message-ID: From: "McDonald, Andrew" To: =?iso-8859-1?Q?=27Attila_B=E1der_=28IJ/ETH=29=27?= , "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org, Georgios Karagiannis Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early Date: Wed, 12 May 2004 16:47:18 +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=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 Attila, Attila B=E1der (IJ/ETH) wrote: > The first one is editorial: There are a lot of information that are > repeated more times in the document: first in the Overview part then > in the Design Decision and also in the Func. Spec. part, sometimes > with very similar details. I know that there are a lot of aspects > that should be described and it is difficult to handle it but I think > the doc. would be much easier to read if this fractal-like structure > could be eliminated. =20 I think with all the changes in technical content, it has been = difficult to keep everything in balance. It's probably heading in the = right direction, but as things settle down it might be useful to have a = purely editorial pass at some point. Do you think a different overall structure is needed, or is it just a = rebalancing of what text goes where? > The second is related to bi-directional and receiver-initiated > reservation. In both case it can happen that the receiver does not > have the resource info for the reverse reservation but the sender has > this info. There is a discussion in the open issues mentioning that > this info may should be provided by a different application. However, > QoS-NSLP provides two natural mechanisms to transmit this info: a) > stacking two QSpec like in case of local QoS model example and b) > sending a separate reserve message with a QSpec for the reverse path > directly to the receiver (like in case of aggregation or reduced > state examples). So I would suggest that QoS-NSLP support this > function. =20 Just because we can doesn't necessarily mean we should. I think this is an architectural question. Should the QoS NSLP be = involved in transporting end-to-end data of this sort, or is that = outside our scope, and so something that should be done by some other = mechanism? (this is a question of carrying something unchanged = end-to-end, not AdSpec-like things) [please read section 9.7 of the -03 draft to get the full question] best regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 12 12:57:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26238 for ; Wed, 12 May 2004 12:57:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwrS-0005NW-F2 for nsis-archive@odin.ietf.org; Wed, 12 May 2004 12:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CGjcSs020675 for nsis-archive@odin.ietf.org; Wed, 12 May 2004 12:45:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwfT-0000Kg-5A; Wed, 12 May 2004 12:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwSa-0001du-0b for nsis@optimus.ietf.org; Wed, 12 May 2004 12:19: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 MAA22851 for ; Wed, 12 May 2004 12:19:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwSX-0007de-Vq for nsis@ietf.org; Wed, 12 May 2004 12:19:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwRR-00076V-00 for nsis@ietf.org; Wed, 12 May 2004 12:18:46 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BNwQI-0006FX-00 for nsis@ietf.org; Wed, 12 May 2004 12:17:34 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4CGHXPA010055 for ; Wed, 12 May 2004 18:17:33 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 May 2004 18:17:33 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 18:17:39 +0200 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "'McDonald, Andrew'" , "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org, Georgios Karagiannis Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early Date: Wed, 12 May 2004 18:17:05 +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: 12 May 2004 16:17:33.0866 (UTC) FILETIME=[A1E6B0A0:01C4383C] 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 Andrew, see my comments inline, Best regards, Attila > -----Original Message----- > From: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > Sent: Wednesday, May 12, 2004 5:47 PM > To: Attila B=E1der (IJ/ETH); 'sven.van_den_bosch@alcatel.be'; > nsis@ietf.org; Georgios Karagiannis > Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + > early >=20 >=20 > Hi Attila, >=20 > Attila B=E1der (IJ/ETH) wrote: > > The first one is editorial: There are a lot of information that are > > repeated more times in the document: first in the Overview part = then > > in the Design Decision and also in the Func. Spec. part, sometimes > > with very similar details. I know that there are a lot of aspects > > that should be described and it is difficult to handle it=20 > but I think > > the doc. would be much easier to read if this fractal-like = structure > > could be eliminated. =20 >=20 > I think with all the changes in technical content, it has=20 > been difficult to keep everything in balance. It's probably=20 > heading in the right direction, but as things settle down it=20 > might be useful to have a purely editorial pass at some point. >=20 > Do you think a different overall structure is needed, or is=20 > it just a rebalancing of what text goes where? This latter one. If the number of subsection could be decreased, I = think, would help.=20 >=20 > > The second is related to bi-directional and receiver-initiated > > reservation. In both case it can happen that the receiver does not > > have the resource info for the reverse reservation but the=20 > sender has > > this info. There is a discussion in the open issues mentioning that > > this info may should be provided by a different=20 > application. However, > > QoS-NSLP provides two natural mechanisms to transmit this info: a) > > stacking two QSpec like in case of local QoS model example and b) > > sending a separate reserve message with a QSpec for the reverse = path > > directly to the receiver (like in case of aggregation or reduced > > state examples). So I would suggest that QoS-NSLP support this > > function. =20 >=20 > Just because we can doesn't necessarily mean we should. >=20 > I think this is an architectural question. Should the QoS=20 > NSLP be involved in transporting end-to-end data of this=20 > sort, or is that outside our scope, and so something that=20 > should be done by some other mechanism? (this is a question=20 > of carrying something unchanged end-to-end, not AdSpec-like things) > [please read section 9.7 of the -03 draft to get the full question] >=20 I think, if you want to use NSIS for real applications carrying such = info cannot be avoided. I think NSIS should carry all info related to = resource reservation. It can be included also into QSpec but I think it = would be more natural to use stacking or send it in a separate QoS-NSLP = message.=20 >=20 > best regards, > Andrew >=20 > --=20 >=20 > Visit our website at www.roke.co.uk >=20 > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, > Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to > Roke Manor Research Ltd and must not be passed to any third=20 > party without > permission. This communication is for information only and=20 > shall not create or > change any contractual relationship. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu May 13 02:48:01 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 CAA22334 for ; Thu, 13 May 2004 02:48:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO9xV-0000ra-Nl for nsis-archive@odin.ietf.org; Thu, 13 May 2004 02:44:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D6ijrF003315 for nsis-archive@odin.ietf.org; Thu, 13 May 2004 02:44:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO9p3-0007fx-6l; Thu, 13 May 2004 02:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO9k3-0006fK-5L for nsis@optimus.ietf.org; Thu, 13 May 2004 02:30: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 CAA21627 for ; Thu, 13 May 2004 02:30:48 -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 1BO9jz-0006z5-G5 for nsis@ietf.org; Thu, 13 May 2004 02:30:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO9j5-0006Lm-00 for nsis@ietf.org; Thu, 13 May 2004 02:29:52 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BO9iJ-0005r9-00 for nsis@ietf.org; Thu, 13 May 2004 02:29:03 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4D6Sv0O007955; Thu, 13 May 2004 08:28:57 +0200 Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early To: Attila =?iso-8859-1?Q?B=E1der?= (IJ/ETH) Cc: "'McDonald, Andrew'" , nsis@ietf.org, Georgios Karagiannis X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 13 May 2004 08:28:54 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/13/2004 08:28:56 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 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.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 Attila, Thanks for your comments. Please see inline ... Sven Attila B=E1der (IJ/ETH) @ietf.org on 12/0= 5/2004 18:17:05 Sent by: nsis-admin@ietf.org To: "'McDonald, Andrew'" , Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org, Georgios Karagiannis cc: Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early Hi Andrew, see my comments inline, Best regards, Attila > -----Original Message----- > From: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > Sent: Wednesday, May 12, 2004 5:47 PM > To: Attila B=E1der (IJ/ETH); 'sven.van_den_bosch@alcatel.be'; > nsis@ietf.org; Georgios Karagiannis > Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + > early > > > Hi Attila, > > Attila B=E1der (IJ/ETH) wrote: > > The first one is editorial: There are a lot of information that are= > > repeated more times in the document: first in the Overview part the= n > > in the Design Decision and also in the Func. Spec. part, sometimes > > with very similar details. I know that there are a lot of aspects > > that should be described and it is difficult to handle it > but I think > > the doc. would be much easier to read if this fractal-like structur= e > > could be eliminated. > > I think with all the changes in technical content, it has > been difficult to keep everything in balance. It's probably > heading in the right direction, but as things settle down it > might be useful to have a purely editorial pass at some point. > > Do you think a different overall structure is needed, or is > it just a rebalancing of what text goes where? This latter one. If the number of subsection could be decreased, I thin= k, would help. Sven>> OK. We organised the document the way it is such that readers th= at are not interested in implementation but want to get a view on what QoS= NSLP does and what mechanisms it uses only have to read the first secti= ons. We look at the rebalance like you suggest next time. > > > The second is related to bi-directional and receiver-initiated > > reservation. In both case it can happen that the receiver does not > > have the resource info for the reverse reservation but the > sender has > > this info. There is a discussion in the open issues mentioning that= > > this info may should be provided by a different > application. However, > > QoS-NSLP provides two natural mechanisms to transmit this info: a) > > stacking two QSpec like in case of local QoS model example and b) > > sending a separate reserve message with a QSpec for the reverse pat= h > > directly to the receiver (like in case of aggregation or reduced > > state examples). So I would suggest that QoS-NSLP support this > > function. > > Just because we can doesn't necessarily mean we should. > > I think this is an architectural question. Should the QoS > NSLP be involved in transporting end-to-end data of this > sort, or is that outside our scope, and so something that > should be done by some other mechanism? (this is a question > of carrying something unchanged end-to-end, not AdSpec-like things) > [please read section 9.7 of the -03 draft to get the full question] > I think, if you want to use NSIS for real applications carrying such in= fo cannot be avoided. I think NSIS should carry all info related to resour= ce reservation. It can be included also into QSpec but I think it would be= more natural to use stacking or send it in a separate QoS-NSLP message.= Sven>> I think this is a question for the working group that we should discuss at the interim. I agree with you that the mechanisms you propos= e can be used. However, we started with a more basic scenario and added t= he open issue to see if there is consensus to go further. > > best regards, > Andrew > > -- > > 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 Thu May 13 03:13: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 DAA23534 for ; Thu, 13 May 2004 03:13: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 1BOABu-0003i3-6n for nsis-archive@odin.ietf.org; Thu, 13 May 2004 02:59:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D6xcuX014244 for nsis-archive@odin.ietf.org; Thu, 13 May 2004 02:59:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOA9N-0003D5-0t; Thu, 13 May 2004 02:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOA7E-0002pv-PD for nsis@optimus.ietf.org; Thu, 13 May 2004 02:54: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 CAA22788 for ; Thu, 13 May 2004 02:54:45 -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 1BOA7A-0003FW-T1 for nsis@ietf.org; Thu, 13 May 2004 02:54:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOA6H-0002kH-00 for nsis@ietf.org; Thu, 13 May 2004 02:53:50 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BOA5L-0002Fy-00 for nsis@ietf.org; Thu, 13 May 2004 02:52:51 -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 i4D6qev09204; Thu, 13 May 2004 09:52:40 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 09:52:37 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4D6qbqC007588; Thu, 13 May 2004 09:52:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Xv2fow; Thu, 13 May 2004 09:52:35 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4D6qYH22718; Thu, 13 May 2004 09:52:34 +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); Thu, 13 May 2004 09:52:31 +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] Submission of draft-ietf-nsis-qos-nslp-03.txt + early Date: Thu, 13 May 2004 09:52:31 +0300 Message-ID: Thread-Topic: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early Thread-Index: AcQ4tWmlIRSGnHKYSRq4eWKiEJfhlwAAVRNw To: , Cc: , , X-OriginalArrivalTime: 13 May 2004 06:52:32.0031 (UTC) FILETIME=[DD3EF2F0:01C438B6] 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, > Sven>> OK. We organised the document the way it is such that readers = that > are not interested in implementation but want to get a view on what = QoS > NSLP does and what mechanisms it uses only have to read the first = sections. > We look at the rebalance like you suggest next time. I would think that having a protocol overview before delving into the protocol details is a good thing, probably what is needed is just some rebalancing of the text. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu May 13 04:15:32 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 EAA27088 for ; Thu, 13 May 2004 04:15: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 1BOB9p-0006to-Di for nsis-archive@odin.ietf.org; Thu, 13 May 2004 04:01:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D81XTw026509 for nsis-archive@odin.ietf.org; Thu, 13 May 2004 04:01:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOB7P-0006IP-TC; Thu, 13 May 2004 03:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOB3B-0005bV-Lr for nsis@optimus.ietf.org; Thu, 13 May 2004 03:54: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 DAA26295 for ; Thu, 13 May 2004 03:54: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 1BOB39-0003Qo-0y for nsis@ietf.org; Thu, 13 May 2004 03:54:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOB2A-0002u0-00 for nsis@ietf.org; Thu, 13 May 2004 03:53:39 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BOB16-00028b-00 for nsis@ietf.org; Thu, 13 May 2004 03:52:32 -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 i4D7qLVH003255; Thu, 13 May 2004 09:52:21 +0200 (MET DST) Message-ID: <001901c438bf$3bf83dd0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "=?iso-8859-1?Q?Attila_B=E1der_\=28IJ/ETH\=29?=" , Cc: "'McDonald, Andrew'" , References: Subject: Re: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early Date: Thu, 13 May 2004 09:52:26 +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.1409 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.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 Attila, Sven, Andrew > > I think, if you want to use NSIS for real applications carrying such info > cannot be avoided. I think NSIS should carry all info related to resource > reservation. It can be included also into QSpec but I think it would be > more natural to use stacking or send it in a separate QoS-NSLP message. > > Sven>> I think this is a question for the working group that we should > discuss at the interim. I agree with you that the mechanisms you propose > can be used. However, we started with a more basic scenario and added the > open issue to see if there is consensus to go further. > Georgios: I agree with Attila when saying that if we want to use NSIS for real applications carrying such info is necessary. Therefore, it is important to discuss this issue at the interim meeting. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri May 14 13:20:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06370 for ; Fri, 14 May 2004 13: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 1BOgFb-0005bf-HN for nsis-archive@odin.ietf.org; Fri, 14 May 2004 13:13:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EHDZka021551 for nsis-archive@odin.ietf.org; Fri, 14 May 2004 13:13:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOg5P-0003Q0-Qx; Fri, 14 May 2004 13:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOg2e-0002gK-84 for nsis@optimus.ietf.org; Fri, 14 May 2004 13:00: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 NAA05225 for ; Fri, 14 May 2004 13:00: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 1BOg2c-0006c9-8L for nsis@ietf.org; Fri, 14 May 2004 13:00:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOg1R-0005iR-00 for nsis@ietf.org; Fri, 14 May 2004 12:58:58 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1BOg0J-000561-00 for nsis@ietf.org; Fri, 14 May 2004 12:57:48 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i4EGviU21237; Fri, 14 May 2004 18:57:44 +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 i4EGviD09056; Fri, 14 May 2004 18:57:44 +0200 (MEST) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id SAA16698; Fri, 14 May 2004 18:57:43 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 14 May 2004 18:57:43 +0200 Message-ID: <4D486782CA36D4118A530000D11EA42A022C7E4F@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: sven.van_den_bosch@alcatel.be, MCDONALD ANDREW , karagian@cs.utwente.nl Cc: nsis@ietf.org Date: Fri, 14 May 2004 18:57:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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] QoS NSLP receiver-initiated reservation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Sven, Andrew and Georgios, I have some questions relating to the receiver-ini scenario (Sec 3.5.3 of the new -03 draft). - Regarding the QUERY message alerting the receiver to issue a RESERVE it says "This QUERY message is instructing the QoS-NSLP process running on each QNE located on the path followed by this QUERY message to install a QoS-NSLP reverse path state" I assume you are referring to NTLP state (referring to a specific NSLP) here, because QUERY is defined to NOT install any QoS-NSLP state. May be the wording should be clarified. - You mention the information whether OPWA (One-Path-with-Advertising) is used would be carried in the QSpec. However, I think this is Control Information is similar to the RESPONSE-REQUEST Object: It will be processed in the common QoS-NSLP processing to determine what type of message should be sent as a reaction to the incoming message. OPWA is not related to QoS-Model specific processing. It does not need resource information nor are they QSM specific. Therefore OPWA to me is Common Control Information (CCI) not carried in the QSpec. - Regarding refreshing state, you mention refreshing reverse-path state (and hence GIMPS message associations) sending a QUERY, in addition to refreshing reservation state by sending the RESERVE. Actually I dont understand GIMPS refreshing mechanisms sufficiently. But shouldnt GIMPS notice a message association is still active when in one direction or the other messages come by in QoS NSLP? So it would suffice that RESERVEs are sent (which need to be sent anyways for refreshing the reservation state). Thanks for your clarifications, Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 17 04:15:06 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 EAA06528 for ; Mon, 17 May 2004 04:15: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 1BPdCS-0003nH-EA for nsis-archive@odin.ietf.org; Mon, 17 May 2004 04:10:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H8AGk8014583 for nsis-archive@odin.ietf.org; Mon, 17 May 2004 04:10:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPd2j-000294-34; Mon, 17 May 2004 04:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPd0J-0001nh-Cx for nsis@optimus.ietf.org; Mon, 17 May 2004 03:57: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 DAA05420 for ; Mon, 17 May 2004 03:57:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPd0G-0004K8-P1 for nsis@ietf.org; Mon, 17 May 2004 03:57:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcyo-0003qa-00 for nsis@ietf.org; Mon, 17 May 2004 03:56:11 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BPcxn-0003AZ-00 for nsis@ietf.org; Mon, 17 May 2004 03:55:08 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 17 May 2004 08:54:30 +0100 Message-ID: From: "McDonald, Andrew" To: "'Kappler Cornelia'" , sven.van_den_bosch@alcatel.be, karagian@cs.utwente.nl Cc: nsis@ietf.org Date: Mon, 17 May 2004 08:54:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 Subject: [NSIS] RE: QoS NSLP receiver-initiated reservation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Cornelia, On Fri, May 14, 2004 at 06:57:40PM +0200, Kappler Cornelia wrote: > - Regarding the QUERY message alerting the receiver to issue a RESERVE it > says "This QUERY message is instructing the QoS-NSLP process running on each > QNE located on the path followed by this QUERY message to install a QoS-NSLP > reverse path state" I assume you are referring to NTLP state (referring to a > specific NSLP) here, because QUERY is defined to NOT install any QoS-NSLP > state. May be the wording should be clarified. Yes, it should be "NTLP reverse path state". I thought I'd caught that one, but it must have slipped through. > - You mention the information whether OPWA (One-Path-with-Advertising) is > used would be carried in the QSpec. However, I think this is Control > Information is similar to the RESPONSE-REQUEST Object: It will be processed > in the common QoS-NSLP processing to determine what type of message should > be sent as a reaction to the incoming message. OPWA is not related to > QoS-Model specific processing. It does not need resource information nor are > they QSM specific. Therefore OPWA to me is Common Control Information (CCI) > not carried in the QSpec. As I understand it, OPWA is about gathering information along the path to allow the receiver to determine what reservation can be supported (supported in RSVP using the Adspec). I think that although there may be QoS-Model-independent parts of this, there are also QoS-Model-specific parts (e.g. to me, the fact that Guaranteed Service and Controlled Load have different requirements for contents of the ADSPEC in RFC2210 would hint at this). It's probably an area where some more thinking about details would be useful. > - Regarding refreshing state, you mention refreshing reverse-path state (and > hence GIMPS message associations) sending a QUERY, in addition to refreshing > reservation state by sending the RESERVE. Actually I dont understand GIMPS > refreshing mechanisms sufficiently. But shouldnt GIMPS notice a message > association is still active when in one direction or the other messages come > by in QoS NSLP? So it would suffice that RESERVEs are sent (which need to be > sent anyways for refreshing the reservation state). Yes, this is a good question. GIMPS does not say anything about this at the moment, and so it is currently identified as an open issue in section 9.6 of the QoS NSLP draft. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 03:16:47 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 DAA17705 for ; Wed, 19 May 2004 03:16: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 1BQLGx-0001LF-Nl for nsis-archive@odin.ietf.org; Wed, 19 May 2004 03:13:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J7DpdO005137 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 03:13:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQLDJ-0000bF-Le; Wed, 19 May 2004 03:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQL2A-00074N-5j for nsis@optimus.ietf.org; Wed, 19 May 2004 02:58: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 CAA16668 for ; Wed, 19 May 2004 02:58:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQL26-0004yG-51 for nsis@ietf.org; Wed, 19 May 2004 02:58:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQL1C-0004rO-00 for nsis@ietf.org; Wed, 19 May 2004 02:57:35 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1BQL0V-0004dl-00 for nsis@ietf.org; Wed, 19 May 2004 02:56:51 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for nsis@ietf.org; Wed, 19 May 2004 08:56:19 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 08:54:49 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6DF@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: nsis@ietf.org Date: Wed, 19 May 2004 08:54:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 Subject: [NSIS] qos-nslp: query and response request Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 qos-nslp authors, the response_request mainly serves to transport an RII. It further distinguishes a Query from a PATH(Query) message in the case of a receiver initiated reservation. The RII must be created and maintained locally. If there's just a single dialogue at a time requiring a response, the RII could be omitted and a local timer could control the response process. This would reduce the number of parameters to be signaled (a flag bit will do) and further reduce the state to be maintained (the timer is foreseen anyway, but no RII must be created, stored or processed). Do you expect multiple simultaneous message dialogues requiring response messages? If so, could you describe one? Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 06:06: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 GAA27182 for ; Wed, 19 May 2004 06:06: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 1BQNro-0002I4-5X for nsis-archive@odin.ietf.org; Wed, 19 May 2004 06:00:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JA033q008739 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 06:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNiI-0007rm-5y; Wed, 19 May 2004 05:50:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNKR-0001R0-PL for nsis@optimus.ietf.org; Wed, 19 May 2004 05: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 FAA23677 for ; Wed, 19 May 2004 05:25: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 1BQNKO-0001tg-ES for nsis@ietf.org; Wed, 19 May 2004 05:25:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNJP-0001k8-00 for nsis@ietf.org; Wed, 19 May 2004 05:24:32 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BQNIX-0001Zc-00 for nsis@ietf.org; Wed, 19 May 2004 05:23:38 -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 i4J9NbVH003130 for ; Wed, 19 May 2004 11:23:37 +0200 (MET DST) Message-ID: <009b01c43d82$fcff5050$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Nsis \(E-mail\)" Subject: RE: [NSIS] qos-nslp: query and response request Date: Wed, 19 May 2004 11:23:47 +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.1409 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.2 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 Rudiger Thank you for your comments, please see inline: > Dear qos-nslp authors, > the response_request mainly serves to transport > an RII. It further distinguishes a Query from a > PATH(Query) message in the case of a receiver > initiated reservation. > The RII must be created and maintained locally. > If there's just a single dialogue at a time > requiring a response, the RII could be omitted > and a local timer could control the response > process. This would reduce the number of > parameters to be signaled (a flag bit will do) > and further reduce the state to be maintained > (the timer is foreseen anyway, but no RII must > be created, stored or processed). Georgios: I am not sure what you mean by "created and maintained locally." The RII is not created and maintained locally. It can be used to send RESPONSE messages back to a node that initiated a QUERY/RESERVE message and required to receive a RESPONSE message from the last node in the downstream path. A downstream node that desires responses may keep track of this RII to identify the RESPONSE when it passes back through it. In particular, regarding the QUERY message, see Section 5.4.2 of the QOS-NSLP draft, a RESPONSE message is sent back to the node that required the RESPONSE, only by the last downstream node that has to process the QUERY message, see some text from the draft: "If this is last node to process this QUERY message (either because it is the last node on the path, or because of scoping), and a RESPONSE_REQUEST object is present, then a RESPONSE message MUST be generated and passed back along the reverse of the path used by the QUERY." > Do you expect multiple simultaneous message > dialogues requiring response messages? > If so, could you describe one? Georgios: No, I don't think so Best Regards, georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 06: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 GAA28777 for ; Wed, 19 May 2004 06:30: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 1BQOGu-0007W4-EX for nsis-archive@odin.ietf.org; Wed, 19 May 2004 06:26:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JAQ0uV028877 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 06:26:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOAP-0006GX-5R; Wed, 19 May 2004 06:19:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQO1G-0004JQ-9f for nsis@optimus.ietf.org; Wed, 19 May 2004 06:09: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 GAA27596 for ; Wed, 19 May 2004 06:09: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 1BQO1C-0002UL-Eu for nsis@ietf.org; Wed, 19 May 2004 06:09:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQO0N-0002Jm-00 for nsis@ietf.org; Wed, 19 May 2004 06:08:56 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BQNzm-00023y-00 for nsis@ietf.org; Wed, 19 May 2004 06:08:18 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 19 May 2004 11:07:47 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Wed, 19 May 2004 11:07:51 +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 update Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, I have updated the interim meeting page at http://nsis.srmr.co.uk/interim.html with a (current) list of attendees and various other bits. It would be a big help to us if people who are coming but haven't registered could do so sooner rather than later, if only so we know how much coffee to order. Also, we'd like to finalise transport/hotel arrangements (for those we are helping with this) - some of our administrative support will be on holiday next week. We have a possibility to organise an "event" of a social sort (involving food, drink and possibly some other traditional English activities) on June 2nd evening. We're assuming that most people would be interested to come to such a thing (if there are opinions on the subject please let me know directly). Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 07:02:29 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 HAA01048 for ; Wed, 19 May 2004 07:02: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 1BQOhn-0003IW-6R for nsis-archive@odin.ietf.org; Wed, 19 May 2004 06:53:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JArljK012676 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 06:53:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOXd-0001yk-A4; Wed, 19 May 2004 06:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOPK-0000Uq-Km for nsis@optimus.ietf.org; Wed, 19 May 2004 06:34: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 GAA29238 for ; Wed, 19 May 2004 06:34:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQOPG-0006VE-J0 for nsis@ietf.org; Wed, 19 May 2004 06:34:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQOON-0006JL-00 for nsis@ietf.org; Wed, 19 May 2004 06:33:44 -0400 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1BQONQ-0005z2-00 for nsis@ietf.org; Wed, 19 May 2004 06:32:45 -0400 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Wed, 19 May 2004 12:32:13 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 12:32:13 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E2@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: karagian@cs.utwente.nl Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp: query and response request Date: Wed, 19 May 2004 12:32:12 +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 Hi Georgios, thanks for your response, R> the response_request mainly serves to transport R> an RII. It further distinguishes a Query from a R> PATH(Query) message in the case of a receiver R> initiated reservation. | R> The RII must be created and maintained locally. R> If there's just a single dialogue at a time R> requiring a response, the RII could be omitted R> and a local timer could control the response R> process. This would reduce the number of R> parameters to be signaled (a flag bit will do) R> and further reduce the state to be maintained R> (the timer is foreseen anyway, but no RII must R> be created, stored or processed). | |Georgios: I am not sure what you mean by "created and=20 |maintained locally." Rudi: Sorry, by locally I mean the original creator=20 of the message with response request |Georgios: The RII is not created and maintained=20 |locally. It can be used to send RESPONSE messages |back to a node that initiated a QUERY/RESERVE message=20 |and required to receive a RESPONSE message from the=20 |last node in the downstream path. A downstream |node that desires responses may keep track of this=20 |RII to identify the RESPONSE when it passes back=20 |through it. Rudi: Fine, as you say the downstream node which created the message requiring a response doesn't=20 need the RII to be aware of that (...may keep=20 track of this RII...). |Georgios: In particular, regarding the QUERY message,=20 |see Section 5.4.2 of the QOS-NSLP draft, |a RESPONSE message is sent back to the node that=20 |required the RESPONSE, only by the last downstream |node that has to process the QUERY message [snipped] Rudi: But the last downstream node doesn't need the=20 RII to know that he's the last downstream node.=20 And a set flag would be sufficient to tell him that=20 a response is required. I still don't understand why the RII is required. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 10:35:37 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 KAA15668 for ; Wed, 19 May 2004 10:35: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 1BQRxU-0001W4-4V for nsis-archive@odin.ietf.org; Wed, 19 May 2004 10:22:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JEMC5b005828 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 10:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRfT-0002ad-CX; Wed, 19 May 2004 10:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQR0y-0004xz-UZ for nsis@optimus.ietf.org; Wed, 19 May 2004 09:21:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10017 for ; Wed, 19 May 2004 09:21:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQR0x-0004Lw-AH for nsis@ietf.org; Wed, 19 May 2004 09:21:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQR08-0004If-00 for nsis@ietf.org; Wed, 19 May 2004 09:20:53 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BQQzb-0004DO-00 for nsis@ietf.org; Wed, 19 May 2004 09:20:19 -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 i4JDKHVH013057 for ; Wed, 19 May 2004 15:20:17 +0200 (MET DST) Message-ID: <011501c43da4$0cf748c0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: Subject: Re: [NSIS] qos-nslp: query and response request Date: Wed, 19 May 2004 15:20:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01C43DB4.D0684B00" 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0112_01C43DB4.D0684B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rudiger In addition to what I have mentioned before, maybe I misunderstood your = below question: "Do you expect multiple simultaneous message=20 dialogues requiring response messages?=20 If so, could you describe one?" If your question is: Is it possible to send QUERY/RESERVE messages within one session, where = each of them might request a RESPONSE message. Then the answer is yes. Please note that any RESERVE messages used to = initiate/refresh/release a reservation state and any QUERY messages that = are sent by any downstream nodes within one session may request a = RESPONSE message. Best Regards, Georgios ------=_NextPart_000_0112_01C43DB4.D0684B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Rudiger
 
In addition to what I have mentioned = before, maybe=20 I misunderstood your below = question:
 
"Do you expect multiple simultaneous message
dialogues = requiring=20 response messages?
If so, could you describe one?"
 
If your question is:
Is it possible to send QUERY/RESERVE = messages=20 within one session, where each of them might request a RESPONSE=20 message.
Then the answer is yes. Please note = that any=20 RESERVE messages used to initiate/refresh/release a reservation state = and any=20 QUERY messages that are sent by any downstream nodes within one session = may=20 request a RESPONSE message.
 
Best Regards,
Georgios
 
 
 

 
------=_NextPart_000_0112_01C43DB4.D0684B00-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 15:29:49 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 PAA05723 for ; Wed, 19 May 2004 15:29: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 1BQVxG-00007y-D1 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:38:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JIcEg0000486 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:38:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVln-0005yt-B1; Wed, 19 May 2004 14:26:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQS1x-0002V6-OU for nsis@optimus.ietf.org; Wed, 19 May 2004 10:26: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 KAA14862 for ; Wed, 19 May 2004 10:26: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 1BQS1v-0000oO-GG for nsis@ietf.org; Wed, 19 May 2004 10:26:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQS12-0000kd-00 for nsis@ietf.org; Wed, 19 May 2004 10:25:52 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1BQS0F-0000dT-00 for nsis@ietf.org; Wed, 19 May 2004 10:25:03 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 19 May 2004 16:24:31 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 16:22:54 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E5@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: karagian@cs.utwente.nl Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp: query and response request Date: Wed, 19 May 2004 16:22:53 +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.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 Georgios, my comments in line. Note that I won't reply before=20 Monday (holiday & vacations). Regards, R=FCdiger |Georgios: Yes, you are right, but if the=20 |RESPONSE message will not carry the |RII, then this node (the node that=20 |initiated the QUERY message) will not be=20 |able to associate the sent (original) |QUERY message with the received RESPONSE=20 |message. |Consider the following scenario: Omitted, the figure had some line breaks.=20 |Consider that: |* NodeC is a last downstream node in the path=20 | (Note that the definition of the last downstream | node is given in the QoS-NSLP draft). |* Node A sends a QUERY that carries a=20 | REQUEST_RESPONSE object (with a RII inside). | At the same time this RII is stored by NodeA. Would the downstream message carry A's origin IP=20 address to C?=20 |* NodeB receives, via NTLP, the QUERY message,=20 | but since this node is not the last downstream | node it will process it and via NTLP it will forarded=20 | further downstream. |* NodeC is the last downstream node. Therefore, this message=20 | will check the RESPONSE_REQUEST object | and will generate a RESPONSE message that have to be sent=20 | back to NodeA. | Note however, that this RESPONSE message is sent using=20 | the Connection mode of NTLP. Thus this message will | be sent peer-to-peer upstream, using the NTLP reverse state.=20 | This message, however, has to be scoped up to NodeA. The=20 | only way of doing that is by using the RII that | was carried by the RESPONSE_REQUEST object. In this way=20 | each (upstream) node that receives the RESPONSE message=20 | will have to check the RII in the RESPONSE message and | the stored (if there is any) RII. | |The matching of this two RII's (the one carried by the=20 |RESPONSE message and the stored one) occurs only in NodeA.=20 |Therefore, NodeA can deduce that the received RESPONSE |message is associated to the QUERY message that was=20 |initiatedd by NodeA. If I got you right, C isn't aware of (or using) A's IP=20 address (there's no IP adress carried at NSLP level in a=20 response message, I see). Instead, it uses the session ID=20 to identify the signaling relation and uses the RII to=20 allow A to figure out that this is the reply to A's=20 response request. Would this be the idea? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 15:29:50 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 PAA05740 for ; Wed, 19 May 2004 15:29:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVyl-0000YE-1G for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:39:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JIdk1w002113 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:39:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVls-0005zu-6i; Wed, 19 May 2004 14:26:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQS5O-0003ZX-Ug for nsis@optimus.ietf.org; Wed, 19 May 2004 10:30: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 KAA15115 for ; Wed, 19 May 2004 10:30:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQS5M-0001Ac-IA for nsis@ietf.org; Wed, 19 May 2004 10:30:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQS4G-00013d-00 for nsis@ietf.org; Wed, 19 May 2004 10:29:13 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1BQS3H-0000rZ-00 for nsis@ietf.org; Wed, 19 May 2004 10:28:11 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 19 May 2004 16:27:40 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 16:26:14 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E6@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: karagian@cs.utwente.nl, nsis@ietf.org Subject: RE: [NSIS] qos-nslp: query and response request Date: Wed, 19 May 2004 16:26:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43DAC.DF7E66AE" 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,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C43DAC.DF7E66AE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Georgios, =20 the meaning is "multiple simultaneous message dialogues=20 referring to one session requiring response messages by=20 one originatior". =20 Regards, R=FCdiger -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of = Georgios Karagiannis Sent: Wednesday, May 19, 2004 3:20 PM To: nsis@ietf.org Subject: Re: [NSIS] qos-nslp: query and response request Hi Rudiger =20 In addition to what I have mentioned before, maybe I misunderstood your = below question: =20 "Do you expect multiple simultaneous message=20 dialogues requiring response messages?=20 If so, could you describe one?" =20 If your question is: Is it possible to send QUERY/RESERVE messages within one session, where = each of them might request a RESPONSE message. Then the answer is yes. Please note that any RESERVE messages used to = initiate/refresh/release a reservation state and any QUERY messages = that are sent by any downstream nodes within one session may request a = RESPONSE message. =20 Best Regards, Georgios =20 =20 =20 =20 ------_=_NextPart_001_01C43DAC.DF7E66AE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Georgios,
 
the=20 meaning is "multiple simultaneous message dialogues =
referring to one session requiring response messages = by=20
one=20 originatior".
 
Regards, R=FCdiger
-----Original Message-----
From: = nsis-admin@ietf.org=20 [mailto:nsis-admin@ietf.org]On Behalf Of Georgios=20 Karagiannis
Sent: Wednesday, May 19, 2004 3:20 = PM
To:=20 nsis@ietf.org
Subject: Re: [NSIS] qos-nslp: query and = response=20 request

Hi Rudiger
 
In addition to what I have mentioned = before,=20 maybe I misunderstood your below=20 question:
 
"Do you expect multiple simultaneous message
dialogues = requiring=20 response messages?
If so, could you describe one?"
 
If your question is:
Is it possible to send QUERY/RESERVE = messages=20 within one session, where each of them might request a RESPONSE=20 message.
Then the answer is yes. Please note = that any=20 RESERVE messages used to initiate/refresh/release a reservation state = and any=20 QUERY messages that are sent by any downstream nodes within one = session may=20 request a RESPONSE message.
 
Best Regards,
Georgios
 
 
 

 
------_=_NextPart_001_01C43DAC.DF7E66AE-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 15: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 PAA05756 for ; Wed, 19 May 2004 15: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 1BQVzt-0000jd-I8 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:40:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JIevcn002818 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:40:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVm3-00063K-Ny; Wed, 19 May 2004 14:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSCj-00067Q-7d for nsis@optimus.ietf.org; Wed, 19 May 2004 10:37:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15872 for ; Wed, 19 May 2004 10:37: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 1BQSCg-0001vD-Sm for nsis@ietf.org; Wed, 19 May 2004 10:37:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQSBt-0001qr-00 for nsis@ietf.org; Wed, 19 May 2004 10:37:05 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BQSBB-0001mi-00 for nsis@ietf.org; Wed, 19 May 2004 10:36:21 -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 i4JEaJVH026744; Wed, 19 May 2004 16:36:19 +0200 (MET DST) Message-ID: <017a01c43dae$ac4c1e50$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Geib, Ruediger" Cc: References: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E5@G8PQD.blf01.telekom.de> Subject: Re: [NSIS] qos-nslp: query and response request Date: Wed, 19 May 2004 16:36:29 +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 i4JEaJVH026744 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 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 Rudiger Please see inline: ----- Original Message -----=20 From: "Geib, Ruediger" To: Cc: Sent: Wednesday, May 19, 2004 4:22 PM Subject: RE: [NSIS] qos-nslp: query and response request > Hi Georgios, > > my comments in line. Note that I won't reply before > Monday (holiday & vacations). > > Regards, R=FCdiger > > |Georgios: Yes, you are right, but if the > |RESPONSE message will not carry the > |RII, then this node (the node that > |initiated the QUERY message) will not be > |able to associate the sent (original) > |QUERY message with the received RESPONSE > |message. > |Consider the following scenario: > > Omitted, the figure had some line breaks. Georgios: Sorry about that, please see below: NodeE----NodeA ---------NodeB ----------NodeC QUERY | |------------>| QUERY | | | |--------------->| | | | = | | | RESPONSE | | | | <------------- | | | RESPONSE | |<----------- | > > |Consider that: > |* NodeC is a last downstream node in the path > | (Note that the definition of the last downstream > | node is given in the QoS-NSLP draft). > |* Node A sends a QUERY that carries a > | REQUEST_RESPONSE object (with a RII inside). > | At the same time this RII is stored by NodeA. > > Would the downstream message carry A's origin IP > address to C? Georgios: No, the downstream message does not carry NodeA's origin IP address to NodeC. That is why the RII has to be carried by the REQUEST_RESPONSE object. > |* NodeB receives, via NTLP, the QUERY message, > | but since this node is not the last downstream > | node it will process it and via NTLP it will forarded > | further downstream. > |* NodeC is the last downstream node. Therefore, this message > | will check the RESPONSE_REQUEST object > | and will generate a RESPONSE message that have to be sent > | back to NodeA. > | Note however, that this RESPONSE message is sent using > | the Connection mode of NTLP. Thus this message will > | be sent peer-to-peer upstream, using the NTLP reverse state. > | This message, however, has to be scoped up to NodeA. The > | only way of doing that is by using the RII that > | was carried by the RESPONSE_REQUEST object. In this way > | each (upstream) node that receives the RESPONSE message > | will have to check the RII in the RESPONSE message and > | the stored (if there is any) RII. > | > |The matching of this two RII's (the one carried by the > |RESPONSE message and the stored one) occurs only in NodeA. > |Therefore, NodeA can deduce that the received RESPONSE > |message is associated to the QUERY message that was > |initiatedd by NodeA. > > If I got you right, C isn't aware of (or using) A's IP > address (there's no IP adress carried at NSLP level in a > response message, I see). Instead, it uses the session ID > to identify the signaling relation and uses the RII to > allow A to figure out that this is the reply to A's > response request. Would this be the idea? Georgios: Yes, that is right. Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 15:30:04 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 PAA05820 for ; Wed, 19 May 2004 15:30: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 1BQW4l-0001qe-9m for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:45:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JIjxlM007089 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVmc-0006E4-AM; Wed, 19 May 2004 14:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSNT-0000HV-IN for nsis@optimus.ietf.org; Wed, 19 May 2004 10:49: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 KAA16805 for ; Wed, 19 May 2004 10:48: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 1BQSNR-0002lp-1p for nsis@ietf.org; Wed, 19 May 2004 10:49:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQSMO-0002fx-00 for nsis@ietf.org; Wed, 19 May 2004 10:47:56 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1BQSLj-0002aR-00 for nsis@ietf.org; Wed, 19 May 2004 10:47:15 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 19 May 2004 16:46:44 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 16:44:58 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E8@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: karagian@cs.utwente.nl Cc: nsis@ietf.org Subject: [NSIS] qos-nslp: scoped response request Date: Wed, 19 May 2004 16:44:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Georgios, thanks for claryfying. The RII is only required=20 to correctly return a scoped response_request=20 then. Why isn't this RII part of the scoping=20 parameter? Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 15:30:09 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 PAA05838 for ; Wed, 19 May 2004 15:30:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQW6L-0002OI-NC for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:47:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JIlbl1009148 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:47:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVmz-0006NI-Pv; Wed, 19 May 2004 14:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSW7-0001LE-1f for nsis@optimus.ietf.org; Wed, 19 May 2004 10:57: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 KAA17603 for ; Wed, 19 May 2004 10:57: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 1BQSW4-0003er-DC for nsis@ietf.org; Wed, 19 May 2004 10:57:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQSVD-0003WL-00 for nsis@ietf.org; Wed, 19 May 2004 10:57:04 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BQSTr-0003HM-00 for nsis@ietf.org; Wed, 19 May 2004 10:55:39 -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 i4JEtbVH000143; Wed, 19 May 2004 16:55:37 +0200 (MET DST) Message-ID: <018e01c43db1$5e8ed060$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Geib, Ruediger" Cc: References: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E8@G8PQD.blf01.telekom.de> Subject: Re: [NSIS] qos-nslp: scoped response request Date: Wed, 19 May 2004 16:55:47 +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 i4JEtbVH000143 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 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 Rudiger But the RESPONSE message that is sent back to the node that requested this response, it must contain a SCOPING object of type RII. Thus the RII is part of the SCOPING object. Pleaase see section 5.4.3 of the QoS-NSLP draft. Best Regards, Georgios ----- Original Message -----=20 From: "Geib, Ruediger" To: Cc: Sent: Wednesday, May 19, 2004 4:44 PM Subject: [NSIS] qos-nslp: scoped response request > Hi Georgios, > > thanks for claryfying. The RII is only required > to correctly return a scoped response_request > then. Why isn't this RII part of the scoping > parameter? > > Regards, R=FCdiger > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 15:30:37 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 PAA05874 for ; Wed, 19 May 2004 15:30: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 1BQWCE-000401-Fz for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:53:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JIrgGp015374 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 14:53:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVnE-0006R2-8t; Wed, 19 May 2004 14:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQT3m-0006NE-A5 for nsis@optimus.ietf.org; Wed, 19 May 2004 11:32: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 LAA18945 for ; Wed, 19 May 2004 11:32:43 -0400 (EDT) From: mbarek@enst.fr Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQT3l-00063P-0a for nsis@ietf.org; Wed, 19 May 2004 11:32:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQT2m-0005zt-00 for nsis@ietf.org; Wed, 19 May 2004 11:31:45 -0400 Received: from reloaded.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx with esmtp (Exim 4.12) id 1BQT1o-0005vW-00 for nsis@ietf.org; Wed, 19 May 2004 11:30:44 -0400 Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by smtp2.enst.fr (Postfix) with ESMTP id 9B26B3B6; Wed, 19 May 2004 17:30:42 +0200 (CEST) Received: from webmail.rezel.enst.fr (phoenix.rezel.enst.fr [137.194.14.1]) by email.enst.fr (8.9.3/8.9.3) with SMTP id RAA26839; Wed, 19 May 2004 17:30:42 +0200 (CEST) Received: from 194.254.163.24 (SquirrelMail authenticated user mbarek) by webmail.rezel.net with HTTP; Wed, 19 May 2004 17:30:43 +0200 (CEST) Message-ID: <33223.194.254.163.24.1084980643.squirrel@webmail.rezel.net> In-Reply-To: <00c801c43d9d$9716a520$4c0d5982@dynamic.ewi.utwente.nl> References: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E2@G8PQD.blf01.telekom.de> <00c801c43d9d$9716a520$4c0d5982@dynamic.ewi.utwente.nl> Date: Wed, 19 May 2004 17:30:43 +0200 (CEST) Subject: Re: [NSIS] qos-nslp: query and response request To: "Georgios Karagiannis" Cc: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal 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=1.1 required=5.0 tests=AWL,NO_REAL_NAME, PRIORITY_NO_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 Rudiger > > Please see my comments in line! > > ----- Original Message ----- > From: "Geib, Ruediger" > To: > Cc: > Sent: Wednesday, May 19, 2004 12:32 PM > Subject: RE: [NSIS] qos-nslp: query and response request > > >> Hi Georgios, >> >> thanks for your response, >> >> R> the response_request mainly serves to transport >> R> an RII. It further distinguishes a Query from a >> R> PATH(Query) message in the case of a receiver >> R> initiated reservation. >> | >> R> The RII must be created and maintained locally. >> R> If there's just a single dialogue at a time >> R> requiring a response, the RII could be omitted >> R> and a local timer could control the response >> R> process. This would reduce the number of >> R> parameters to be signaled (a flag bit will do) >> R> and further reduce the state to be maintained >> R> (the timer is foreseen anyway, but no RII must >> R> be created, stored or processed). >> | >> |Georgios: I am not sure what you mean by "created and >> |maintained locally." >> >> Rudi: Sorry, by locally I mean the original creator >> of the message with response request >> >> |Georgios: The RII is not created and maintained >> |locally. It can be used to send RESPONSE messages >> |back to a node that initiated a QUERY/RESERVE message >> |and required to receive a RESPONSE message from the >> |last node in the downstream path. A downstream >> |node that desires responses may keep track of this >> |RII to identify the RESPONSE when it passes back >> |through it. >> >> Rudi: Fine, as you say the downstream node which >> created the message requiring a response doesn't >> need the RII to be aware of that (...may keep >> track of this RII...). > > Georgios: Yes, you are right, but if the RESPONSE message will not carr= y > the > RII, then this > node (the node that initiated the QUERY message) will not be able to > associate the sent (original) > QUERY message with the received RESPONSE message. > Consider the following scenario: > > NodeE-------NodeA --------------------NodeB -----------------------Node= C > QUERY > | |----------------------------->| QUERY > | > | | > |---------------------------->| > | | = | > RESPONSE | > | | RESPONSE > |<----------------------------| > | | <--------------------------- | > | > > > Consider that: > * NodeC is a last downstream node in the path (Note that the definition= of > the last downstream > node is given in the QoS-NSLP draft). > * Node A sends a QUERY that carries a REQUEST_RESPONSE object (with a R= II > inside). > At the same time this RII is stored by NodeA. > * NodeB receives, via NTLP, the QUERY message, but since this node is n= ot > the last downstream > node it will process it and via NTLP it will forarded further > downstream. > * NodeC is the last downstream node. Therefore, this message will check > the > RESPONSE_REQUEST object > and will generate a RESPONSE message that have to be sent back to Nod= eA. > Note however, that > this RESPONSE message is sent using the Connection mode of NTLP. Thus > this > message will > be sent peer-to-peer upstream, using the NTLP reverse state. This > message, > however, has to be > scoped up to NodeA. The only way of doing that is by using the RII t= hat > was carried by the > RESPONSE_REQUEST object. In this way each (upstream) node that receiv= es > the > RESPONSE message will have to check the RII in the RESPONSE message a= nd > the stored (if there is any) RII. > > The matching of this two RII's (the one carried by the RESPONSE message > and > the stored one) > occurs only in NodeA. Therefore, NodeA can deduce that the received > RESPONSE > message > is associated to the QUERY message that was initiatedd by NodeA. > >> >> |Georgios: In particular, regarding the QUERY message, >> |see Section 5.4.2 of the QOS-NSLP draft, >> |a RESPONSE message is sent back to the node that >> |required the RESPONSE, only by the last downstream >> |node that has to process the QUERY message >> [snipped] >> >> Rudi: But the last downstream node doesn't need the >> RII to know that he's the last downstream node. >> And a set flag would be sufficient to tell him that >> a response is required. >> >> I still don't understand why the RII is required. > Georgios: I hope that the explanation above made it more clear! > > Best Regards, > Georgios > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > Hi Georgios I just want to extend the example you've given by adding the fact that node B stores the RII because it is interested in the result of th Query (it is said in the draft that it is possible to do that). In that case, Node B will check the RII of the response and the one it has stored wich are the same so not only node A could match thr two RII that's why I woul= d like that you explain to me how we could make the difference between a node wich stores the RII because it is interested in the response and the one wich initiates the Query. Best Regards Nader _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 15:38:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06349 for ; Wed, 19 May 2004 15:38: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 1BQWRg-0005V7-0z for nsis-archive@odin.ietf.org; Wed, 19 May 2004 15:09:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJ9d5Y021145 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 15:09:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVp4-0006sm-D5; Wed, 19 May 2004 14:29:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQUBg-0000w6-Uj for nsis@optimus.ietf.org; Wed, 19 May 2004 12:45: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 MAA22883 for ; Wed, 19 May 2004 12:44: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 1BQUBf-00040S-69 for nsis@ietf.org; Wed, 19 May 2004 12:44:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQUAn-0003vO-00 for nsis@ietf.org; Wed, 19 May 2004 12:44:06 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1BQUA2-0003nX-00 for nsis@ietf.org; Wed, 19 May 2004 12:43:18 -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 i4JGf4VH017874; Wed, 19 May 2004 18:41:04 +0200 (MET DST) Message-ID: <01d001c43dc0$19bd5470$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: Cc: References: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E2@G8PQD.blf01.telekom.de> <00c801c43d9d$9716a520$4c0d5982@dynamic.ewi.utwente.nl> <33223.194.254.163.24.1084980643.squirrel@webmail.rezel.net> Subject: Re: [NSIS] qos-nslp: query and response request Date: Wed, 19 May 2004 18:41:14 +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.1409 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.2 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 Nader In normal operation, NodeB will not store the RII that was generated by NodeA. If NodeB needs to request a RESPONSE message, than this node will have to initiate another QUERY or RESERVE message and include another RII in an REQUEST_RESPONSE object. Please note that RII is an identifier which must be (probabilistically) unique within the context of a SESSION_ID, and SHOULD be different for each response request (generated by a node). Thus an RII that is generated by NodeA will certainly be different than an RII that is generated by NodeB. Best Regards, Georgios PS. Please note that I will be out of office and that the next time that I will read my e-mail is next Monday! ----- Original Message ----- From: To: "Georgios Karagiannis" Cc: Sent: Wednesday, May 19, 2004 5:30 PM Subject: Re: [NSIS] qos-nslp: query and response request > > Hi Rudiger > > > > Please see my comments in line! > > > > ----- Original Message ----- > > From: "Geib, Ruediger" > > To: > > Cc: > > Sent: Wednesday, May 19, 2004 12:32 PM > > Subject: RE: [NSIS] qos-nslp: query and response request > > > > > >> Hi Georgios, > >> > >> thanks for your response, > >> > >> R> the response_request mainly serves to transport > >> R> an RII. It further distinguishes a Query from a > >> R> PATH(Query) message in the case of a receiver > >> R> initiated reservation. > >> | > >> R> The RII must be created and maintained locally. > >> R> If there's just a single dialogue at a time > >> R> requiring a response, the RII could be omitted > >> R> and a local timer could control the response > >> R> process. This would reduce the number of > >> R> parameters to be signaled (a flag bit will do) > >> R> and further reduce the state to be maintained > >> R> (the timer is foreseen anyway, but no RII must > >> R> be created, stored or processed). > >> | > >> |Georgios: I am not sure what you mean by "created and > >> |maintained locally." > >> > >> Rudi: Sorry, by locally I mean the original creator > >> of the message with response request > >> > >> |Georgios: The RII is not created and maintained > >> |locally. It can be used to send RESPONSE messages > >> |back to a node that initiated a QUERY/RESERVE message > >> |and required to receive a RESPONSE message from the > >> |last node in the downstream path. A downstream > >> |node that desires responses may keep track of this > >> |RII to identify the RESPONSE when it passes back > >> |through it. > >> > >> Rudi: Fine, as you say the downstream node which > >> created the message requiring a response doesn't > >> need the RII to be aware of that (...may keep > >> track of this RII...). > > > > Georgios: Yes, you are right, but if the RESPONSE message will not carry > > the > > RII, then this > > node (the node that initiated the QUERY message) will not be able to > > associate the sent (original) > > QUERY message with the received RESPONSE message. > > Consider the following scenario: > > > > NodeE-------NodeA --------------------NodeB -----------------------NodeC > > QUERY > > | |----------------------------->| QUERY > > | > > | | > > |---------------------------->| > > | | | > > RESPONSE | > > | | RESPONSE > > |<----------------------------| > > | | <--------------------------- | > > | > > > > > > Consider that: > > * NodeC is a last downstream node in the path (Note that the definition of > > the last downstream > > node is given in the QoS-NSLP draft). > > * Node A sends a QUERY that carries a REQUEST_RESPONSE object (with a RII > > inside). > > At the same time this RII is stored by NodeA. > > * NodeB receives, via NTLP, the QUERY message, but since this node is not > > the last downstream > > node it will process it and via NTLP it will forarded further > > downstream. > > * NodeC is the last downstream node. Therefore, this message will check > > the > > RESPONSE_REQUEST object > > and will generate a RESPONSE message that have to be sent back to NodeA. > > Note however, that > > this RESPONSE message is sent using the Connection mode of NTLP. Thus > > this > > message will > > be sent peer-to-peer upstream, using the NTLP reverse state. This > > message, > > however, has to be > > scoped up to NodeA. The only way of doing that is by using the RII that > > was carried by the > > RESPONSE_REQUEST object. In this way each (upstream) node that receives > > the > > RESPONSE message will have to check the RII in the RESPONSE message and > > the stored (if there is any) RII. > > > > The matching of this two RII's (the one carried by the RESPONSE message > > and > > the stored one) > > occurs only in NodeA. Therefore, NodeA can deduce that the received > > RESPONSE > > message > > is associated to the QUERY message that was initiatedd by NodeA. > > > >> > >> |Georgios: In particular, regarding the QUERY message, > >> |see Section 5.4.2 of the QOS-NSLP draft, > >> |a RESPONSE message is sent back to the node that > >> |required the RESPONSE, only by the last downstream > >> |node that has to process the QUERY message > >> [snipped] > >> > >> Rudi: But the last downstream node doesn't need the > >> RII to know that he's the last downstream node. > >> And a set flag would be sufficient to tell him that > >> a response is required. > >> > >> I still don't understand why the RII is required. > > Georgios: I hope that the explanation above made it more clear! > > > > Best Regards, > > Georgios > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > Hi Georgios > > I just want to extend the example you've given by adding the fact that > node B stores the RII because it is interested in the result of th Query > (it is said in the draft that it is possible to do that). In that case, > Node B will check the RII of the response and the one it has stored wich > are the same so not only node A could match thr two RII that's why I would > like that you explain to me how we could make the difference between a > node wich stores the RII because it is interested in the response and the > one wich initiates the Query. > > Best Regards > Nader > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 23:34: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 XAA10070 for ; Wed, 19 May 2004 23:34: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 1BQeGh-0007a2-0w for nsis-archive@odin.ietf.org; Wed, 19 May 2004 23:30:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K3Uo2f029125 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 23:30:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeC1-0006UZ-0o; Wed, 19 May 2004 23:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQe9m-0005uv-IA for nsis@optimus.ietf.org; Wed, 19 May 2004 23:23: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 XAA09549 for ; Wed, 19 May 2004 23:23: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 1BQe9k-0003Jm-Gy for nsis@ietf.org; Wed, 19 May 2004 23:23:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQe8o-0003AB-00 for nsis@ietf.org; Wed, 19 May 2004 23:22:42 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQe8B-0002xD-00 for nsis@ietf.org; Wed, 19 May 2004 23:22:03 -0400 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4K3CS2B023616; Thu, 20 May 2004 11:12:38 +0800 (SGT) From: "Cheng Hong" To: Cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" , Subject: RE: [NSIS] qos-nslp: session binding Date: Thu, 20 May 2004 11:21:04 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <00a101c43e19$7fef4bf0$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.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: 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, Regarding the section 4.2.6 session binding, I have a question about the first example given. In the second to last paragraph on Page 33, it = states:=20 "For this purpose, the end-to-end session contains a BOUND_SESSION_ID carrying the SESSION_ID of the aggregate session",=20 It is further stated in the first paragraph on page 34,: "By default, a session that is bound to another session with the BOUND_SESSION_ID object shares fate with it. This means that if a bound session is torn down, every binding session should be torn down as = well". Shouldn't this be the other way around? Obviously, the tearing down of = the aggregate session doesn't mean that every end-to-end session should be = also torn down. But if there is an end-to-end session torn down, the = aggregated session should be torn down as well.=20 cheers Cheng Hong=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed May 19 23:53: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 XAA10562 for ; Wed, 19 May 2004 23:53: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 1BQeTP-0001CR-OD for nsis-archive@odin.ietf.org; Wed, 19 May 2004 23:43:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K3hx5j004596 for nsis-archive@odin.ietf.org; Wed, 19 May 2004 23:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeKm-0008O7-CF; Wed, 19 May 2004 23:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeI9-0007iH-RR for nsis@optimus.ietf.org; Wed, 19 May 2004 23:32: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 XAA09921 for ; Wed, 19 May 2004 23:32:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQeI7-0004jy-Pu for nsis@ietf.org; Wed, 19 May 2004 23:32:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQeHG-0004as-00 for nsis@ietf.org; Wed, 19 May 2004 23:31:27 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQeGM-0004He-00 for nsis@ietf.org; Wed, 19 May 2004 23:30:31 -0400 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4K3L2ZP023907; Thu, 20 May 2004 11:21:10 +0800 (SGT) From: "Cheng Hong" To: "'Cheng Hong'" , Cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" , Subject: RE: [NSIS] qos-nslp: Requesting response Date: Thu, 20 May 2004 11:29:38 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <00a201c43e1a$b13d4170$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.1409 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=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 all, In section 4.2.2, the third paragraph states that "A message contains at most one RESPONSE_REQUEST object". I would like to know if this is also = true for the stacking Qspec case and the Layering case (section 4.3), where responses from different nodes may be necessary? cheers Cheng Hong=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu May 20 03:31:06 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 DAA02637 for ; Thu, 20 May 2004 03:31: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 1BQhzr-0008Pm-OB for nsis-archive@odin.ietf.org; Thu, 20 May 2004 03:29:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K7Thsc032331 for nsis-archive@odin.ietf.org; Thu, 20 May 2004 03:29:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQhwK-0007mG-Bq; Thu, 20 May 2004 03:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQhuq-0007Rk-2G for nsis@optimus.ietf.org; Thu, 20 May 2004 03:24: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 DAA02346 for ; Thu, 20 May 2004 03:24:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQhun-0001w6-FP for nsis@ietf.org; Thu, 20 May 2004 03:24:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQhtk-0001mv-00 for nsis@ietf.org; Thu, 20 May 2004 03:23:24 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQhsy-0001UK-00 for nsis@ietf.org; Thu, 20 May 2004 03:22:36 -0400 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4K7CmA3001387; Thu, 20 May 2004 15:13:01 +0800 (SGT) From: "Cheng Hong" To: Cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" , Subject: RE: [NSIS] qos-nslp: NR definition Date: Thu, 20 May 2004 15:21:24 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <00a701c43e3b$15351750$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.1409 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=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 all, In the terminology definition, the QNI is defined as=20 "The first node in the sequence of QNEs that issues a reservation = request for a session" ; the QNR is defind as "The last node in the sequence of QNEs that = receives a reservation request for a session" Also in section 5.4.1 RESERVE Message, paragraph 3 on page 49, it states "RESERVE messge MUST only be sent towards the NR" But in the section 3.5.3 Basic Receiver Initiated Reservation, it is = obvious that the RESERVE message is sent from the NR, as shown in figure 5. To have a consistant definition, maybe the QNI should be defined as the = QNE that initiates the QoS NSLP message signaling (instead of referring to RESERVE message) and QNR should be the QNE that response to the QoS NSLP message from the QNI. cheers Cheng Hong=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu May 20 05:40: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 FAA08086 for ; Thu, 20 May 2004 05:40:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQk1K-0004vD-3B for nsis-archive@odin.ietf.org; Thu, 20 May 2004 05:39:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K9dMwv018904 for nsis-archive@odin.ietf.org; Thu, 20 May 2004 05:39:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQjvC-0003m9-3u; Thu, 20 May 2004 05:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQjsz-0003RR-AR for nsis@optimus.ietf.org; Thu, 20 May 2004 05:30: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 FAA07628 for ; Thu, 20 May 2004 05:30:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQjsv-0000yb-Ob for nsis@ietf.org; Thu, 20 May 2004 05:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQjrs-0000o9-00 for nsis@ietf.org; Thu, 20 May 2004 05:29:37 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BQjr8-0000S7-00 for nsis@ietf.org; Thu, 20 May 2004 05:28:50 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 20 May 2004 10:28:20 +0100 Message-ID: From: "McDonald, Andrew" To: "'Geib, Ruediger'" , karagian@cs.utwente.nl, nsis@ietf.org Subject: RE: [NSIS] qos-nslp: query and response request Date: Thu, 20 May 2004 10:28:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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: , Geib, Ruediger wrote: > the meaning is "multiple simultaneous message dialogues > referring to one session requiring response messages by > one originatior". I think it is impossible to exclude this. As one example, what happens if a RESPONSE message is lost on route (e.g. dropped because of overload/congestion)? In this case we could send another QUERY/RESERVE (which might contain different parameters), and subsequently get a RESPONSE. Is this for the original QUERY/RESERVE or the second one? Without a unique identifier (the RII), you can't tell them apart. regards, Andrew > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Georgios Karagiannis > Sent: Wednesday, May 19, 2004 3:20 PM > To: nsis@ietf.org > Subject: Re: [NSIS] qos-nslp: query and response request > > > Hi Rudiger > > In addition to what I have mentioned before, maybe I misunderstood > your below question: > > "Do you expect multiple simultaneous message > dialogues requiring response messages? > If so, could you describe one?" > > If your question is: > Is it possible to send QUERY/RESERVE messages within one session, > where each of them might request a RESPONSE message. > Then the answer is yes. Please note that any RESERVE messages used to > initiate/refresh/release a reservation state and any QUERY messages > that are sent by any downstream nodes within one session may request > a RESPONSE message. > > Best Regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu May 20 07:16:40 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 HAA11880 for ; Thu, 20 May 2004 07: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 1BQlOT-0003BL-Cx for nsis-archive@odin.ietf.org; Thu, 20 May 2004 07:07:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KB7LkU012225 for nsis-archive@odin.ietf.org; Thu, 20 May 2004 07:07:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQlKI-0002Pz-FP; Thu, 20 May 2004 07:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQkHG-0007J9-IV for nsis@optimus.ietf.org; Thu, 20 May 2004 05:55: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 FAA08588 for ; Thu, 20 May 2004 05:55: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 1BQkHC-0005cU-QT for nsis@ietf.org; Thu, 20 May 2004 05:55:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQkGX-0005Q3-00 for nsis@ietf.org; Thu, 20 May 2004 05:55:06 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BQkFg-0005Dk-00 for nsis@ietf.org; Thu, 20 May 2004 05:54:12 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 20 May 2004 10:53:43 +0100 Message-ID: From: "McDonald, Andrew" To: "'Cheng Hong'" , nsis@ietf.org Cc: "'Georgios Karagiannis'" , sven.van_den_bosch@alcatel.be Subject: RE: [NSIS] qos-nslp: NR definition Date: Thu, 20 May 2004 10:53:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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: , Cheng Hong wrote: > In the terminology definition, the QNI is defined as > "The first node in the sequence of QNEs that issues a reservation > request for a session" ; > the QNR is defind as "The last node in the sequence of QNEs that > receives a reservation request for a session" > > Also in section 5.4.1 RESERVE Message, paragraph 3 on page 49, it > states "RESERVE messge MUST only be sent towards the NR" > > But in the section 3.5.3 Basic Receiver Initiated Reservation, it is > obvious that the RESERVE message is sent from the NR, as shown in > figure 5. > > To have a consistant definition, maybe the QNI should be defined as > the QNE that initiates the QoS NSLP message signaling (instead of > referring to RESERVE message) and QNR should be the QNE that response > to the QoS NSLP message from the QNI. I think the error is in figure 5. A corrected version might look like: NR NF NF NI sender receiver | | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | | | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | | | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | In this case it is the receiver who initiates the _reservation_, by sending the first RESERVE message. Does that solve the question? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu May 20 07:17:17 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 HAA11918 for ; Thu, 20 May 2004 07:17: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 1BQlU7-0004ds-EU for nsis-archive@odin.ietf.org; Thu, 20 May 2004 07:13:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KBDBYJ017837 for nsis-archive@odin.ietf.org; Thu, 20 May 2004 07:13:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQlKa-0002T7-Fa; Thu, 20 May 2004 07:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQkqn-00069h-FZ for nsis@optimus.ietf.org; Thu, 20 May 2004 06:32: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 GAA10122 for ; Thu, 20 May 2004 06:32: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 1BQkqj-0004sb-Fy for nsis@ietf.org; Thu, 20 May 2004 06:32:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQkpl-0004gF-00 for nsis@ietf.org; Thu, 20 May 2004 06:31:30 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQkon-0004KJ-00 for nsis@ietf.org; Thu, 20 May 2004 06:30:29 -0400 Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4KAKr4N006728; Thu, 20 May 2004 18:20:57 +0800 (SGT) From: "Cheng Hong" To: "'McDonald, Andrew'" , Cc: "'Georgios Karagiannis'" , Subject: RE: [NSIS] qos-nslp: NR definition Date: Thu, 20 May 2004 18:29:29 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <00b701c43e55$55ae3900$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.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: 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 Andrew, Yes. That could solve the problem, although it would make the NR initate = the signalling. cheers Cheng=20 > -----Original Message----- > From: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Thursday, May 20, 2004 5:54 PM > To: 'Cheng Hong'; nsis@ietf.org > Cc: 'Georgios Karagiannis'; sven.van_den_bosch@alcatel.be > Subject: RE: [NSIS] qos-nslp: NR definition >=20 >=20 > Cheng Hong wrote: > > In the terminology definition, the QNI is defined as > > "The first node in the sequence of QNEs that issues a reservation=20 > > request for a session" ; the QNR is defind as "The last node in the=20 > > sequence of QNEs that receives a reservation request for a session" > >=20 > > Also in section 5.4.1 RESERVE Message, paragraph 3 on page 49, it=20 > > states "RESERVE messge MUST only be sent towards the NR" > >=20 > > But in the section 3.5.3 Basic Receiver Initiated=20 > Reservation, it is=20 > > obvious that the RESERVE message is sent from the NR, as shown in=20 > > figure 5. > >=20 > > To have a consistant definition, maybe the QNI should be defined as=20 > > the QNE that initiates the QoS NSLP message signaling (instead of=20 > > referring to RESERVE message) and QNR should be the QNE=20 > that response=20 > > to the QoS NSLP message from the QNI. >=20 > I think the error is in figure 5. A corrected version might look like: >=20 > NR NF NF NI > sender receiver > | | | | > | QUERY | | | > +--------->| | | > | | QUERY | | > | +--------->| | > | | | QUERY | > | | +--------->| > | | | | > | | | RESERVE | > | | |<---------+ > | | RESERVE | | > | |<---------+ | > | RESERVE | | | > |<---------+ | | > | | | | > | RESPONSE | | | > +--------->| | | > | | RESPONSE | | > | +--------->| | > | | | RESPONSE | > | | +--------->| > | | | | >=20 > In this case it is the receiver who initiates the=20 > _reservation_, by sending the first RESERVE message. >=20 > Does that solve the question? >=20 > regards, > Andrew >=20 > --=20 >=20 > Visit our website at www.roke.co.uk >=20 > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to Roke Manor Research Ltd and must not be=20 > passed to any third party without permission. This=20 > communication is for information only and shall not create or=20 > change any contractual relationship. >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri May 21 10:22:46 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 KAA03905 for ; Fri, 21 May 2004 10:22: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 1BRAiv-0003Eu-GT for nsis-archive@odin.ietf.org; Fri, 21 May 2004 10:10:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LEA9Uo012437 for nsis-archive@odin.ietf.org; Fri, 21 May 2004 10:10:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAZM-0006BB-AX; Fri, 21 May 2004 10:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRANF-0002wv-4i for nsis@optimus.ietf.org; Fri, 21 May 2004 09:47: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 JAA01349 for ; Fri, 21 May 2004 09:47:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRAND-0007nq-3D for nsis@ietf.org; Fri, 21 May 2004 09:47:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRAMD-0007c8-00 for nsis@ietf.org; Fri, 21 May 2004 09:46:41 -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 1BRALZ-0007QP-00 for nsis@ietf.org; Fri, 21 May 2004 09:46:01 -0400 Received: from [10.1.1.109] (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 88D8FF674 for ; Fri, 21 May 2004 15:51:09 +0200 (CEST) Date: Fri, 21 May 2004 15:45:47 +0200 From: Martin Stiemerling To: nsis@ietf.org Message-ID: <2147483647.1085154347@[10.1.1.109]> 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [NSIS] New NATFW NSLP I-D: draft-ieft-nsis-nslp-natfw-02.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, The latest version of the NATFW NSLP Internet draft has been posted to the I-D repository. You will find the draft here as well: ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp-natfw-02.t xt A html version is available here: http://www.stiemerling.org/nsis The major changes: - Document has been completely restructured, so that it is now more a protocol specification - Added bit definition of messages/objects - Added text parts on multiplexing, policy rules - Changed text to fit to new structure. I'll be away from email for the next week and being reachable by email beginning with the interim meeting. Regards, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 03:07:33 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 DAA15981 for ; Mon, 24 May 2004 03:07: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 1BS9WL-00075k-T4 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 03:05:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O75D8W027245 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 03:05:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Hf-0005Kl-2w; Mon, 24 May 2004 02: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 1BS9Ey-0004mk-5l for nsis@optimus.ietf.org; Mon, 24 May 2004 02: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 CAA15347 for ; Mon, 24 May 2004 02:47:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9Eu-0007ZT-BC for nsis@ietf.org; Mon, 24 May 2004 02:47:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9Dy-0007IN-00 for nsis@ietf.org; Mon, 24 May 2004 02:46:14 -0400 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1BS9DH-0006vP-00 for nsis@ietf.org; Mon, 24 May 2004 02:45:32 -0400 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Mon, 24 May 2004 08:44:59 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 08:45:00 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6E9@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: andrew.mcdonald@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp: query and response request Date: Mon, 24 May 2004 08:44:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , Hi Andrew, |Geib, Ruediger wrote: |> the meaning is "multiple simultaneous message dialogues |> referring to one session requiring response messages by |> one originatior". | |I think it is impossible to exclude this. | |As one example, what happens if a RESPONSE message is lost on |route (e.g. dropped because of overload/congestion)? In this |case we could send another QUERY/RESERVE (which might contain |different parameters), and subsequently get a RESPONSE. Is |this for the original QUERY/RESERVE or the second one? Without |a unique identifier (the RII), you can't tell them apart. The above holds if the session ID remains unchanged, meaning you refer to an active session. The RESPONSE message carries a QSPEC object which should be interpreted by the originator of the QUERY/RESERVE. Which other QoS NSLP contents could be changed without being identifiable by a RESPONSE without RII? Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 03:12:58 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 DAA16228 for ; Mon, 24 May 2004 03:12: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 1BS9aq-00089U-Uv for nsis-archive@odin.ietf.org; Mon, 24 May 2004 03:09:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O79qdK031321 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 03:09:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Y6-0007OH-VK; Mon, 24 May 2004 03:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9PY-0006GO-73 for nsis@optimus.ietf.org; Mon, 24 May 2004 02:58: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 CAA15764 for ; Mon, 24 May 2004 02:58:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9PU-0002tm-Aa for nsis@ietf.org; Mon, 24 May 2004 02:58:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9OY-0002dG-00 for nsis@ietf.org; Mon, 24 May 2004 02:57:10 -0400 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1BS9Nn-00026Q-00 for nsis@ietf.org; Mon, 24 May 2004 02:56:23 -0400 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Mon, 24 May 2004 08:55:53 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 08:55:54 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE09DAF6EA@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: karagian@cs.utwente.nl Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp: scoped response request Date: Mon, 24 May 2004 08:55:53 +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 Hi Georgios, |But the RESPONSE message that is sent back to |the node that requested this response, it must contain |a SCOPING object of type RII. Thus the RII is part of the=20 |SCOPING object. |Pleaase see section 5.4.3 of the QoS-NSLP draft. Yes but only in upstream direction. My question is, why=20 the RII isn't part of the SCOPING object when it is=20 signaled in a downstream message.=20 Regards, R=FCdiger |----- Original Message -----=20 |From: "Geib, Ruediger"=20 |> Hi Georgios, |> thanks for claryfying. The RII is only required |> to correctly return a scoped response_request |> then. Why isn't this RII part of the scoping |> parameter? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 05:44:45 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 FAA22975 for ; Mon, 24 May 2004 05:44:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBpt-0008P2-Jl for nsis-archive@odin.ietf.org; Mon, 24 May 2004 05:33:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O9XXov032296 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 05:33:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBjg-0007gM-O4; Mon, 24 May 2004 05:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBa9-0006WU-0J for nsis@optimus.ietf.org; Mon, 24 May 2004 05:17: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 FAA21926 for ; Mon, 24 May 2004 05:17: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 1BSBa5-0004sN-AH for nsis@ietf.org; Mon, 24 May 2004 05:17:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBZ4-0004a0-00 for nsis@ietf.org; Mon, 24 May 2004 05:16:11 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BSBY5-0004G8-00 for nsis@ietf.org; Mon, 24 May 2004 05:15:09 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4O9F22T019364; Mon, 24 May 2004 11:15:06 +0200 Subject: RE: [NSIS] qos-nslp: session binding To: "Cheng Hong" Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 May 2004 11:14:51 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/24/2004 11:15:05 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 Cheng Hong, Sorry for the delayed reply (holiday). Please see my response inline. Cheers, Sven "Cheng Hong" on 20/05/2004 05:21:04 To: cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" , Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL Subject: RE: [NSIS] qos-nslp: session binding Hi all, Regarding the section 4.2.6 session binding, I have a question about the first example given. In the second to last paragraph on Page 33, it states: "For this purpose, the end-to-end session contains a BOUND_SESSION_ID carrying the SESSION_ID of the aggregate session", It is further stated in the first paragraph on page 34,: "By default, a session that is bound to another session with the BOUND_SESSION_ID object shares fate with it. This means that if a bound session is torn down, every binding session should be torn down as well". Shouldn't this be the other way around? Obviously, the tearing down of the aggregate session doesn't mean that every end-to-end session should be also torn down. But if there is an end-to-end session torn down, the aggregated session should be torn down as well. Sven>> I think it is OK. See the definition of binding session and bound session in the paragraph above. The binding session is the one with SID_A (=the end-to-end one) in the example. The bound session (=the aggregate) is the one with SID_B. So it is only if the bound session is torn down that all the binding sessions are torn down as well, just as you say. cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 05:49:00 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 FAA23130 for ; Mon, 24 May 2004 05:49:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBww-0001P5-5P for nsis-archive@odin.ietf.org; Mon, 24 May 2004 05:40:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O9enBH005377 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 05:40:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBkY-00086C-Mc; Mon, 24 May 2004 05:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBd5-0006tt-29 for nsis@optimus.ietf.org; Mon, 24 May 2004 05:20: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 FAA22051 for ; Mon, 24 May 2004 05:20:15 -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 1BSBd1-0005mT-JU for nsis@ietf.org; Mon, 24 May 2004 05:20:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBcA-0005UX-00 for nsis@ietf.org; Mon, 24 May 2004 05:19:22 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BSBbU-0005Cd-00 for nsis@ietf.org; Mon, 24 May 2004 05:18:40 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4O9Id2S022023; Mon, 24 May 2004 11:18:39 +0200 Subject: RE: [NSIS] qos-nslp: Requesting response To: "Cheng Hong" Cc: "'Cheng Hong'" , , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 May 2004 11:18:37 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/24/2004 11:18:39 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 Cheng Hong, Thanks for your comment. We discussed about this and yes, even in this case we think a single RESPONSE_REQUEST object is sufficient. The RESPONSE_REQUEST then applies to each QSPEC. As is specified, a QNE that is interested in the RESPONSE may watch out for it when it passes through it on the way to the original requestor. Any information specific for a QNE can be put in the QSPEC. Hope this clarifies things, Sven "Cheng Hong" on 20/05/2004 05:29:38 To: "'Cheng Hong'" , cc: "'McDonald, Andrew'" , "'Georgios Karagiannis'" , Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL Subject: RE: [NSIS] qos-nslp: Requesting response Hi all, In section 4.2.2, the third paragraph states that "A message contains at most one RESPONSE_REQUEST object". I would like to know if this is also true for the stacking Qspec case and the Layering case (section 4.3), where responses from different nodes may be necessary? cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 06:25:59 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 GAA24764 for ; Mon, 24 May 2004 06:25: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 1BSCcd-0007Yw-6J for nsis-archive@odin.ietf.org; Mon, 24 May 2004 06:23:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OANtVY029070 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 06:23:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCIO-0004OG-Re; Mon, 24 May 2004 06: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 1BSCCw-0003Zw-IU for nsis@optimus.ietf.org; Mon, 24 May 2004 05:57:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23490 for ; Mon, 24 May 2004 05:57:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCCs-0001UE-U9 for nsis@ietf.org; Mon, 24 May 2004 05:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCC3-0001B8-00 for nsis@ietf.org; Mon, 24 May 2004 05:56:28 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BSCBQ-0000nM-00 for nsis@ietf.org; Mon, 24 May 2004 05:55:48 -0400 Received: from Palpatine ([10.81.113.74]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4O9k2vQ016682; Mon, 24 May 2004 17:46:10 +0800 (SGT) From: "Cheng Hong" To: Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] qos-nslp: session binding Date: Mon, 24 May 2004 17:54:33 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <001901c44175$210521a0$4a71510a@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.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: 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, Thanks for the reply, regarding the issue: > Sven>> I think it is OK. See the definition of binding=20 > session and bound > session in the paragraph above. The binding session is the=20 > one with SID_A (=3Dthe end-to-end one) in the example. The=20 > bound session (=3Dthe aggregate) is the one with SID_B. So it=20 > is only if the bound session is torn down that all the=20 > binding sessions are torn down as well, just as you say. That is my question. Should all the end-to-end (binding) be torn down = when the aggregate (bound) session is torn down? I think there would be cases when one of the end-to-end (binding) session needs to be torn down, and = thus requires the aggregate (bound) session to be also torn down (since the member has changed). But this does not mean all the other end-to-end (binding) session should also be torn down. =20 Also, there are cases where the network cannot afford to sustain the aggregate session, and it has to be torn down, but some member of the aggregation, e.g. some high priority end-to-end session, could be = allowed to remain. In this case, not all the end-to-end (binding) sessions have to = be torn down. Or, the scenario you intent to deal with is different from the above? cheers Cheng Hong=20 > -----Original Message----- > From: sven.van_den_bosch@alcatel.be=20 > [mailto:sven.van_den_bosch@alcatel.be]=20 > Sent: Monday, May 24, 2004 5:15 PM > To: Cheng Hong > Cc: nsis@ietf.org; 'McDonald, Andrew'; 'Georgios Karagiannis' > Subject: RE: [NSIS] qos-nslp: session binding >=20 >=20 > Hi Cheng Hong, >=20 > Sorry for the delayed reply (holiday). Please see my response inline. >=20 > Cheers, > Sven >=20 >=20 >=20 >=20 >=20 > "Cheng Hong" on 20/05/2004 05:21:04 >=20 > To: > cc: "'McDonald, Andrew'" , "'Georgios > Karagiannis'" , Sven VAN DEN > BOSCH/BE/ALCATEL@ALCATEL > Subject: RE: [NSIS] qos-nslp: session binding >=20 >=20 > Hi all, >=20 > Regarding the section 4.2.6 session binding, I have a=20 > question about the first example given. In the second to last=20 > paragraph on Page 33, it states: >=20 > "For this purpose, the end-to-end session contains a=20 > BOUND_SESSION_ID carrying the SESSION_ID of the aggregate session", >=20 > It is further stated in the first paragraph on page 34,: >=20 > "By default, a session that is bound to another session with=20 > the BOUND_SESSION_ID object shares fate with it. This means=20 > that if a bound session is torn down, every binding session=20 > should be torn down as well". >=20 > Shouldn't this be the other way around? Obviously, the=20 > tearing down of the aggregate session doesn't mean that every=20 > end-to-end session should be also torn down. But if there is=20 > an end-to-end session torn down, the aggregated session=20 > should be torn down as well. >=20 > Sven>> I think it is OK. See the definition of binding=20 > session and bound > session in the paragraph above. The binding session is the=20 > one with SID_A (=3Dthe end-to-end one) in the example. The=20 > bound session (=3Dthe aggregate) is the one with SID_B. So it=20 > is only if the bound session is torn down that all the=20 > binding sessions are torn down as well, just as you say. >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 06:40:47 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 GAA25567 for ; Mon, 24 May 2004 06:40:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCpl-0000oK-Uw for nsis-archive@odin.ietf.org; Mon, 24 May 2004 06:37:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OAbTG1003109 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 06:37:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCdi-0007vW-JP; Mon, 24 May 2004 06:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCKb-0004hn-C7 for nsis@optimus.ietf.org; Mon, 24 May 2004 06:05:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23974 for ; Mon, 24 May 2004 06:05:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCKX-00045Z-LJ for nsis@ietf.org; Mon, 24 May 2004 06:05:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCJb-0003ng-00 for nsis@ietf.org; Mon, 24 May 2004 06:04:16 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BSCIi-0003Cz-00 for nsis@ietf.org; Mon, 24 May 2004 06:03:20 -0400 Received: from Palpatine ([10.81.113.74]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4O9rxiS016953; Mon, 24 May 2004 17:54:07 +0800 (SGT) From: "Cheng Hong" To: Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] qos-nslp: Requesting response Date: Mon, 24 May 2004 18:02:29 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <001c01c44176$3d48bce0$4a71510a@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.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: 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, Thanks for the reply. Now I am clear about the issue.=20 But the content of the RESPONSE_REQUEST is the RII. Would there be = scenarios where the RII for different QSPEC be different too? E.g. a end-to-end response is requested by an QNI, and a local response is requested by an edge QNE in the layering case? Or this is also possible to be placed in QSPEC? cheers Cheng Hong=20 > -----Original Message----- > From: sven.van_den_bosch@alcatel.be=20 > [mailto:sven.van_den_bosch@alcatel.be]=20 > Sent: Monday, May 24, 2004 5:19 PM > To: Cheng Hong > Cc: 'Cheng Hong'; nsis@ietf.org; 'McDonald, Andrew';=20 > 'Georgios Karagiannis' > Subject: RE: [NSIS] qos-nslp: Requesting response >=20 >=20 > Hi Cheng Hong, >=20 > Thanks for your comment. We discussed about this and yes,=20 > even in this case we think a single RESPONSE_REQUEST object=20 > is sufficient. The RESPONSE_REQUEST then applies to each=20 > QSPEC. As is specified, a QNE that is interested in the=20 > RESPONSE may watch out for it when it passes through it on=20 > the way to the original requestor. Any information specific=20 > for a QNE can be put in the QSPEC. >=20 > Hope this clarifies things, > Sven >=20 >=20 >=20 >=20 >=20 >=20 > "Cheng Hong" on 20/05/2004 05:29:38 >=20 > To: "'Cheng Hong'" , > cc: "'McDonald, Andrew'" , "'Georgios > Karagiannis'" , Sven VAN DEN > BOSCH/BE/ALCATEL@ALCATEL > Subject: RE: [NSIS] qos-nslp: Requesting response >=20 >=20 > Hi all, >=20 > In section 4.2.2, the third paragraph states that "A message=20 > contains at most one RESPONSE_REQUEST object". I would like=20 > to know if this is also true for the stacking Qspec case and=20 > the Layering case (section 4.3), where responses from=20 > different nodes may be necessary? >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 07:30:45 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 HAA28173 for ; Mon, 24 May 2004 07:30:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDYQ-0006oB-A0 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:23:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OBNcq6026166 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:23:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDIL-00050O-2O; Mon, 24 May 2004 07:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDDp-0004NK-Ax for nsis@optimus.ietf.org; Mon, 24 May 2004 07:02: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 HAA26393 for ; Mon, 24 May 2004 07:02:16 -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 1BSDDl-0006T3-3K for nsis@ietf.org; Mon, 24 May 2004 07:02:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDCz-0006Ar-00 for nsis@ietf.org; Mon, 24 May 2004 07:01:30 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BSDCV-0005s6-00 for nsis@ietf.org; Mon, 24 May 2004 07:00:59 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4OB0w2S014475; Mon, 24 May 2004 13:00:58 +0200 Subject: RE: [NSIS] qos-nslp: session binding To: "Cheng Hong" Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 May 2004 13:00:55 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/24/2004 13:00:58 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 Cheng Hong, Please see inline for further comments. Cheers, Sven "Cheng Hong" on 24/05/2004 11:54:33 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] qos-nslp: session binding Hi Sven, Thanks for the reply, regarding the issue: > Sven>> I think it is OK. See the definition of binding > session and bound > session in the paragraph above. The binding session is the > one with SID_A (=the end-to-end one) in the example. The > bound session (=the aggregate) is the one with SID_B. So it > is only if the bound session is torn down that all the > binding sessions are torn down as well, just as you say. That is my question. Should all the end-to-end (binding) be torn down when the aggregate (bound) session is torn down? I think there would be cases when one of the end-to-end (binding) session needs to be torn down, and thus requires the aggregate (bound) session to be also torn down (since the member has changed). But this does not mean all the other end-to-end (binding) session should also be torn down. Sven>> We had imagined it would work as follows: the aggregate session is torn down, by the ingress/egress or a QNE in the domain. If it is the ingress or the egress, the binding information is available. The ingress/egress can then decide to either tear down the end-to-end session or to set up a new aggregate session to tie the end-to-end one to or to signal each of the end-to-end ones separately. All these cases are supported by the draft since the use of the session binding information is still the responsability of ingress/egress. If it is a QNE (inside) that initiates the teardown, the TEAR will eventually reach ingress or egress and we fall back in the previous case. Also, there are cases where the network cannot afford to sustain the aggregate session, and it has to be torn down, but some member of the aggregation, e.g. some high priority end-to-end session, could be allowed to remain. In this case, not all the end-to-end (binding) sessions have to be torn down. Sven>> See above. The ingress/egress of the domain would know this and decide to re-signal separate end-to-end session (with the risk of failure of course). Or, the scenario you intent to deal with is different from the above? cheers Cheng Hong > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Monday, May 24, 2004 5:15 PM > To: Cheng Hong > Cc: nsis@ietf.org; 'McDonald, Andrew'; 'Georgios Karagiannis' > Subject: RE: [NSIS] qos-nslp: session binding > > > Hi Cheng Hong, > > Sorry for the delayed reply (holiday). Please see my response inline. > > Cheers, > Sven > > > > > > "Cheng Hong" on 20/05/2004 05:21:04 > > To: > cc: "'McDonald, Andrew'" , "'Georgios > Karagiannis'" , Sven VAN DEN > BOSCH/BE/ALCATEL@ALCATEL > Subject: RE: [NSIS] qos-nslp: session binding > > > Hi all, > > Regarding the section 4.2.6 session binding, I have a > question about the first example given. In the second to last > paragraph on Page 33, it states: > > "For this purpose, the end-to-end session contains a > BOUND_SESSION_ID carrying the SESSION_ID of the aggregate session", > > It is further stated in the first paragraph on page 34,: > > "By default, a session that is bound to another session with > the BOUND_SESSION_ID object shares fate with it. This means > that if a bound session is torn down, every binding session > should be torn down as well". > > Shouldn't this be the other way around? Obviously, the > tearing down of the aggregate session doesn't mean that every > end-to-end session should be also torn down. But if there is > an end-to-end session torn down, the aggregated session > should be torn down as well. > > Sven>> I think it is OK. See the definition of binding > session and bound > session in the paragraph above. The binding session is the > one with SID_A (=the end-to-end one) in the example. The > bound session (=the aggregate) is the one with SID_B. So it > is only if the bound session is torn down that all the > binding sessions are torn down as well, just as you say. > > cheers > > Cheng Hong > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 07:31:01 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 HAA28190 for ; Mon, 24 May 2004 07:31:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDYf-0006uK-NV for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:23:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OBNrbt026525 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:23:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDKG-0005Xg-EZ; Mon, 24 May 2004 07:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDGk-0004iF-11 for nsis@optimus.ietf.org; Mon, 24 May 2004 07:05: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 HAA26485 for ; Mon, 24 May 2004 07:05:17 -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 1BSDGf-0007Sz-NH for nsis@ietf.org; Mon, 24 May 2004 07:05:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDFf-00076n-00 for nsis@ietf.org; Mon, 24 May 2004 07:04:16 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BSDEf-0006iO-00 for nsis@ietf.org; Mon, 24 May 2004 07:03:13 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4OB3C2S015581; Mon, 24 May 2004 13:03:12 +0200 Subject: RE: [NSIS] qos-nslp: Requesting response To: "Cheng Hong" Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 May 2004 13:03:10 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/24/2004 13:03:12 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 Cheng Hong, The idea is that the RII is chosen by the first QNE that wants to receive a response. Subsequent QNEs that are also interested to get a RESPONSE (potentially to their QSPEC) will just keep track of the RII chosen by the first QNE to identify the RESPONSEs. They will find their particular answer in their QSPEC. The RII is chosen such that collision are very unlikely. Hope this helps, Sven "Cheng Hong" on 24/05/2004 12:02:29 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] qos-nslp: Requesting response Hi Sven, Thanks for the reply. Now I am clear about the issue. But the content of the RESPONSE_REQUEST is the RII. Would there be scenarios where the RII for different QSPEC be different too? E.g. a end-to-end response is requested by an QNI, and a local response is requested by an edge QNE in the layering case? Or this is also possible to be placed in QSPEC? cheers Cheng Hong > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Monday, May 24, 2004 5:19 PM > To: Cheng Hong > Cc: 'Cheng Hong'; nsis@ietf.org; 'McDonald, Andrew'; > 'Georgios Karagiannis' > Subject: RE: [NSIS] qos-nslp: Requesting response > > > Hi Cheng Hong, > > Thanks for your comment. We discussed about this and yes, > even in this case we think a single RESPONSE_REQUEST object > is sufficient. The RESPONSE_REQUEST then applies to each > QSPEC. As is specified, a QNE that is interested in the > RESPONSE may watch out for it when it passes through it on > the way to the original requestor. Any information specific > for a QNE can be put in the QSPEC. > > Hope this clarifies things, > Sven > > > > > > > "Cheng Hong" on 20/05/2004 05:29:38 > > To: "'Cheng Hong'" , > cc: "'McDonald, Andrew'" , "'Georgios > Karagiannis'" , Sven VAN DEN > BOSCH/BE/ALCATEL@ALCATEL > Subject: RE: [NSIS] qos-nslp: Requesting response > > > Hi all, > > In section 4.2.2, the third paragraph states that "A message > contains at most one RESPONSE_REQUEST object". I would like > to know if this is also true for the stacking Qspec case and > the Layering case (section 4.3), where responses from > different nodes may be necessary? > > cheers > > Cheng Hong > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 08:00:09 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 IAA29686 for ; Mon, 24 May 2004 08:00:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDzM-0001wj-06 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:51:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OBpRRh007482 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:51:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDhU-0008DD-Vj; Mon, 24 May 2004 07:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDZ6-000727-Ml for nsis@optimus.ietf.org; Mon, 24 May 2004 07:24: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 HAA27902 for ; Mon, 24 May 2004 07:24:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDZ6-000698-11 for nsis@ietf.org; Mon, 24 May 2004 07:24:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDY8-0005oF-00 for nsis@ietf.org; Mon, 24 May 2004 07:23:21 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BSDX5-0005Ck-00 for nsis@ietf.org; Mon, 24 May 2004 07:22:15 -0400 Received: from Palpatine ([10.81.113.74]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i4OBCeSb018356; Mon, 24 May 2004 19:12:49 +0800 (SGT) From: "Cheng Hong" To: Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] qos-nslp: session binding Date: Mon, 24 May 2004 19:21:12 +0800 Organization: Panasonic Singapore Laboratories Message-ID: <003001c44181$3b875cd0$4a71510a@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, Thanks a lot for the reply. Now, it is clear. Just one more question: > available. The ingress/egress can then decide to either tear > down the end-to-end session or to set up a new aggregate > session to tie the end-to-end one to or to signal each of the > end-to-end ones separately. All these cases are supported by Does this also require that the new aggregate session to reuse the same Session ID, so that it could remain to be the bound session? cheers Cheng Hong > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Monday, May 24, 2004 7:01 PM > To: Cheng Hong > Cc: nsis@ietf.org; 'McDonald, Andrew'; 'Georgios Karagiannis' > Subject: RE: [NSIS] qos-nslp: session binding > > > Hi Cheng Hong, > > Please see inline for further comments. > > Cheers, > Sven > > > > > > "Cheng Hong" on 24/05/2004 11:54:33 > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > cc: , "'McDonald, Andrew'" > , > "'Georgios Karagiannis'" > Subject: RE: [NSIS] qos-nslp: session binding > > > Hi Sven, > > Thanks for the reply, regarding the issue: > > > Sven>> I think it is OK. See the definition of binding > > session and bound > > session in the paragraph above. The binding session is the one with > > SID_A (=the end-to-end one) in the example. The bound session (=the > > aggregate) is the one with SID_B. So it is only if the > bound session > > is torn down that all the binding sessions are torn down as > well, just > > as you say. > > That is my question. Should all the end-to-end (binding) be > torn down when the aggregate (bound) session is torn down? I > think there would be cases when one of the end-to-end > (binding) session needs to be torn down, and thus requires > the aggregate (bound) session to be also torn down (since the > member has changed). But this does not mean all the other end-to-end > (binding) session should also be torn down. > > Sven>> We had imagined it would work as follows: the > aggregate session > Sven>> is > torn down, by the ingress/egress or a QNE in the domain. If > it is the ingress or the egress, the binding information is > available. The ingress/egress can then decide to either tear > down the end-to-end session or to set up a new aggregate > session to tie the end-to-end one to or to signal each of the > end-to-end ones separately. All these cases are supported by > the draft since the use of the session binding information is > still the responsability of ingress/egress. If it is a QNE > (inside) that initiates the teardown, the TEAR will > eventually reach ingress or egress and we fall back in the > previous case. > > Also, there are cases where the network cannot afford to > sustain the aggregate session, and it has to be torn down, > but some member of the aggregation, e.g. some high priority > end-to-end session, could be allowed to remain. In this case, > not all the end-to-end (binding) sessions have to be torn down. > > Sven>> See above. The ingress/egress of the domain would know this and > decide to re-signal separate end-to-end session (with the > risk of failure of course). > > Or, the scenario you intent to deal with is different from the above? > > cheers > > Cheng Hong > > > > > > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: Monday, May 24, 2004 5:15 PM > > To: Cheng Hong > > Cc: nsis@ietf.org; 'McDonald, Andrew'; 'Georgios Karagiannis' > > Subject: RE: [NSIS] qos-nslp: session binding > > > > > > Hi Cheng Hong, > > > > Sorry for the delayed reply (holiday). Please see my > response inline. > > > > Cheers, > > Sven > > > > > > > > > > > > "Cheng Hong" on 20/05/2004 05:21:04 > > > > To: > > cc: "'McDonald, Andrew'" , "'Georgios > > Karagiannis'" , Sven VAN DEN > > BOSCH/BE/ALCATEL@ALCATEL > > Subject: RE: [NSIS] qos-nslp: session binding > > > > > > Hi all, > > > > Regarding the section 4.2.6 session binding, I have a > question about > > the first example given. In the second to last paragraph on > Page 33, > > it states: > > > > "For this purpose, the end-to-end session contains a > BOUND_SESSION_ID > > carrying the SESSION_ID of the aggregate session", > > > > It is further stated in the first paragraph on page 34,: > > > > "By default, a session that is bound to another session with the > > BOUND_SESSION_ID object shares fate with it. This means that if a > > bound session is torn down, every binding session should be > torn down > > as well". > > > > Shouldn't this be the other way around? Obviously, the > tearing down of > > the aggregate session doesn't mean that every end-to-end session > > should be also torn down. But if there is an end-to-end > session torn > > down, the aggregated session should be torn down as well. > > > > Sven>> I think it is OK. See the definition of binding > > session and bound > > session in the paragraph above. The binding session is the one with > > SID_A (=the end-to-end one) in the example. The bound session (=the > > aggregate) is the one with SID_B. So it is only if the > bound session > > is torn down that all the binding sessions are torn down as > well, just > > as you say. > > > > cheers > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 08:06:10 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 IAA00368 for ; Mon, 24 May 2004 08:06: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 1BSE69-00038B-HH for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:58:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OBwTl5012032 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 07:58:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDrH-0001Ih-0k; Mon, 24 May 2004 07:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDd3-0007T1-Tj for nsis@optimus.ietf.org; Mon, 24 May 2004 07:28: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 HAA28114 for ; Mon, 24 May 2004 07:28:24 -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 1BSDd3-0007YB-5E for nsis@ietf.org; Mon, 24 May 2004 07:28:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDcD-0007Em-00 for nsis@ietf.org; Mon, 24 May 2004 07:27:34 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BSDbU-0006u6-00 for nsis@ietf.org; Mon, 24 May 2004 07:26:48 -0400 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4OBQj2S024964; Mon, 24 May 2004 13:26:45 +0200 Subject: RE: [NSIS] qos-nslp: session binding To: "Cheng Hong" Cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 May 2004 13:26:43 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/24/2004 13:26:44 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 Cheng Hong, I think it would be better to pick a new one and change the BOUND_SESSION_ID in the end-to-end session to that. What do you think? Cheers, Sven "Cheng Hong" on 24/05/2004 13:21:12 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , "'McDonald, Andrew'" , "'Georgios Karagiannis'" Subject: RE: [NSIS] qos-nslp: session binding Hi Sven, Thanks a lot for the reply. Now, it is clear. Just one more question: > available. The ingress/egress can then decide to either tear > down the end-to-end session or to set up a new aggregate > session to tie the end-to-end one to or to signal each of the > end-to-end ones separately. All these cases are supported by Does this also require that the new aggregate session to reuse the same Session ID, so that it could remain to be the bound session? cheers Cheng Hong > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Monday, May 24, 2004 7:01 PM > To: Cheng Hong > Cc: nsis@ietf.org; 'McDonald, Andrew'; 'Georgios Karagiannis' > Subject: RE: [NSIS] qos-nslp: session binding > > > Hi Cheng Hong, > > Please see inline for further comments. > > Cheers, > Sven > > > > > > "Cheng Hong" on 24/05/2004 11:54:33 > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > cc: , "'McDonald, Andrew'" > , > "'Georgios Karagiannis'" > Subject: RE: [NSIS] qos-nslp: session binding > > > Hi Sven, > > Thanks for the reply, regarding the issue: > > > Sven>> I think it is OK. See the definition of binding > > session and bound > > session in the paragraph above. The binding session is the one with > > SID_A (=the end-to-end one) in the example. The bound session (=the > > aggregate) is the one with SID_B. So it is only if the > bound session > > is torn down that all the binding sessions are torn down as > well, just > > as you say. > > That is my question. Should all the end-to-end (binding) be > torn down when the aggregate (bound) session is torn down? I > think there would be cases when one of the end-to-end > (binding) session needs to be torn down, and thus requires > the aggregate (bound) session to be also torn down (since the > member has changed). But this does not mean all the other end-to-end > (binding) session should also be torn down. > > Sven>> We had imagined it would work as follows: the > aggregate session > Sven>> is > torn down, by the ingress/egress or a QNE in the domain. If > it is the ingress or the egress, the binding information is > available. The ingress/egress can then decide to either tear > down the end-to-end session or to set up a new aggregate > session to tie the end-to-end one to or to signal each of the > end-to-end ones separately. All these cases are supported by > the draft since the use of the session binding information is > still the responsability of ingress/egress. If it is a QNE > (inside) that initiates the teardown, the TEAR will > eventually reach ingress or egress and we fall back in the > previous case. > > Also, there are cases where the network cannot afford to > sustain the aggregate session, and it has to be torn down, > but some member of the aggregation, e.g. some high priority > end-to-end session, could be allowed to remain. In this case, > not all the end-to-end (binding) sessions have to be torn down. > > Sven>> See above. The ingress/egress of the domain would know this and > decide to re-signal separate end-to-end session (with the > risk of failure of course). > > Or, the scenario you intent to deal with is different from the above? > > cheers > > Cheng Hong > > > > > > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: Monday, May 24, 2004 5:15 PM > > To: Cheng Hong > > Cc: nsis@ietf.org; 'McDonald, Andrew'; 'Georgios Karagiannis' > > Subject: RE: [NSIS] qos-nslp: session binding > > > > > > Hi Cheng Hong, > > > > Sorry for the delayed reply (holiday). Please see my > response inline. > > > > Cheers, > > Sven > > > > > > > > > > > > "Cheng Hong" on 20/05/2004 05:21:04 > > > > To: > > cc: "'McDonald, Andrew'" , "'Georgios > > Karagiannis'" , Sven VAN DEN > > BOSCH/BE/ALCATEL@ALCATEL > > Subject: RE: [NSIS] qos-nslp: session binding > > > > > > Hi all, > > > > Regarding the section 4.2.6 session binding, I have a > question about > > the first example given. In the second to last paragraph on > Page 33, > > it states: > > > > "For this purpose, the end-to-end session contains a > BOUND_SESSION_ID > > carrying the SESSION_ID of the aggregate session", > > > > It is further stated in the first paragraph on page 34,: > > > > "By default, a session that is bound to another session with the > > BOUND_SESSION_ID object shares fate with it. This means that if a > > bound session is torn down, every binding session should be > torn down > > as well". > > > > Shouldn't this be the other way around? Obviously, the > tearing down of > > the aggregate session doesn't mean that every end-to-end session > > should be also torn down. But if there is an end-to-end > session torn > > down, the aggregated session should be torn down as well. > > > > Sven>> I think it is OK. See the definition of binding > > session and bound > > session in the paragraph above. The binding session is the one with > > SID_A (=the end-to-end one) in the example. The bound session (=the > > aggregate) is the one with SID_B. So it is only if the > bound session > > is torn down that all the binding sessions are torn down as > well, just > > as you say. > > > > cheers > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 12:17:17 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 MAA17414 for ; Mon, 24 May 2004 12:17: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 1BSHlL-0007oj-Ck for nsis-archive@odin.ietf.org; Mon, 24 May 2004 11:53:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OFrFA1030025 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 11:53:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHdO-0005sC-Gt; Mon, 24 May 2004 11: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 1BSHCu-0008GM-EB for nsis@optimus.ietf.org; Mon, 24 May 2004 11:17:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13180 for ; Mon, 24 May 2004 11:17:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSHCr-0004xc-Ad for nsis@ietf.org; Mon, 24 May 2004 11:17:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHBo-0004qm-00 for nsis@ietf.org; Mon, 24 May 2004 11:16:32 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1BSHB2-0004hv-00 for nsis@ietf.org; Mon, 24 May 2004 11:15:45 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 16:14:46 +0100 Message-ID: From: "Hancock, Robert" To: nsis Date: Mon, 24 May 2004 16:14:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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] GIMPS features Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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, One of the items on our plans for GIMPS we made in Seoul was to look for items to remove (before we add any more...) At the moment, I don't believe there is anything in the core spec that can be removed (without opening the whole C/D-mode discussion again, which is not the point). However, there are some possibilities listed in the open issues section which at the moment it seems we could survive without. They are: 8.7 State teardown - the ability to allow GIMPS (or someone above GIMPS) to signal in the protocol that state *at the GIMPS level* isn't needed any more. My impression is that GIMPS level state itself is not so expensive that we need to be able to remove it efficiently, and that soft-state is good enough to handle cleanup. Allowing explicit teardown then also means we have an extra security threat to worry about. 8.8 Single shot message support - some facility provided by GIMPS to deliver a single message in some reliable way without going through the whole C-mode procedure. I'm not sure (in reality) how much more efficient this can be made than C-mode, and how often an NSLP will want to deliver just one message like this; so, my feeling would be say it is 'all or nothing'. (We could reflect such a potentiality in the conceptual API provided by GIMPS, but actually just implement it with C-mode.) Would anyone object to closing these two issues? (And anything else people would like to see the back of?) Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 12:31: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 MAA18304 for ; Mon, 24 May 2004 12:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSIGv-00053s-TC for nsis-archive@odin.ietf.org; Mon, 24 May 2004 12:25:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OGPrIQ019457 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 12:25:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHtq-0000nw-3i; Mon, 24 May 2004 12: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 1BSHhe-0006Zw-6a for nsis@optimus.ietf.org; Mon, 24 May 2004 11:49: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 LAA15708 for ; Mon, 24 May 2004 11:49: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 1BSHhd-0000mM-13 for nsis@ietf.org; Mon, 24 May 2004 11:49:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHgi-0000gw-00 for nsis@ietf.org; Mon, 24 May 2004 11:48:29 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BSHfl-0000X8-00 for nsis@ietf.org; Mon, 24 May 2004 11:47:29 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 16:46:58 +0100 Message-ID: From: "McDonald, Andrew" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp: query and response request Date: Mon, 24 May 2004 16:47:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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: , Hi, Geib, Ruediger wrote: >> Geib, Ruediger wrote: >>> the meaning is "multiple simultaneous message dialogues >>> referring to one session requiring response messages by >>> one originatior". >> >> I think it is impossible to exclude this. >> >> As one example, what happens if a RESPONSE message is lost on >> route (e.g. dropped because of overload/congestion)? In this >> case we could send another QUERY/RESERVE (which might contain >> different parameters), and subsequently get a RESPONSE. Is >> this for the original QUERY/RESERVE or the second one? Without >> a unique identifier (the RII), you can't tell them apart. > > The above holds if the session ID remains unchanged, meaning > you refer to an active session. Yes. > The RESPONSE message > carries a QSPEC object which should be interpreted by the > originator of the QUERY/RESERVE. There are cases where I wouldn't expect a QSPEC to be included in the RESPONSE. An "I don't understand your QSPEC" error, or an "Unsupported object in QoS NSLP message" error probably don't need one. Also, the QSPEC in the RESPONSE may well be different to that in the RESERVE. E.g. it may describe available resources, because the requested resources could not be satisfied. > Which other QoS NSLP contents > could be changed without being identifiable by a RESPONSE > without RII? In principle, anything could change. Most things (REFRESH_PERIOD, BOUND_SESSION_ID, RSN, SCOPING, etc) aren't echoed back in the RESPONSE. As one example, authorization data (POLICY_DATA) may change since the previously used credentials have just expired. The RESPONSE does not contain the POLICY_DATA sent in the RESERVE/QUERY. (Even flow routing information could change. However, in the current GIMPS draft the RESPONSE comes with sufficient information to identify the applicable FRI.) regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon May 24 12:40: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 MAA18557 for ; Mon, 24 May 2004 12:40: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 1BSIKe-0006IA-Rg for nsis-archive@odin.ietf.org; Mon, 24 May 2004 12:29:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OGTiOR024177 for nsis-archive@odin.ietf.org; Mon, 24 May 2004 12:29:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSI9N-0003kL-3T; Mon, 24 May 2004 12:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHsH-0000ap-LR for nsis@optimus.ietf.org; Mon, 24 May 2004 12:00: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 MAA16498 for ; Mon, 24 May 2004 12:00: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 1BSHsG-0001wq-Cl for nsis@ietf.org; Mon, 24 May 2004 12:00:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSHrP-0001sA-00 for nsis@ietf.org; Mon, 24 May 2004 11:59:32 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1BSHr5-0001mJ-00 for nsis@ietf.org; Mon, 24 May 2004 11:59:16 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 16:58:40 +0100 Message-ID: From: "Hancock, Robert" To: "'Yacine.El_Mghazli@alcatel.fr'" , David Oran Cc: nsis@ietf.org Subject: RE: [NSIS] common signalling application functions Date: Mon, 24 May 2004 16:58: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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA16499 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@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 [Apologies for the late reply:] Hi, Considering the various options discussed: 1. I suspect it's nicer to have a dedicated toolbox that to have re-use bits and pieces of insides of NSLPs (at least at an early stage). But that requires more work and organisation and documents, so it's really a question of energy ("good stuff" as Dave describes it does not come free.) After repeated calls=20 for input on this subject during the framework development, we didn't get very far (Bob made similar comments when the purpose of the signalling analysis work was being discussed), so I think it's probably best to consider addressing these problems in a=20 'bottom up' way at least for now. 2. I'm opposed to integrating this stuff into GIMPS. GIMPS has enough non-trivial things to do without adding more things which don't have a strong interaction with its transport=20 functions. 3. I checked Dave's list of common functions to see how these=20 things are currently being progressed, if at all. Here is my perception: *) precedence and pre-emption: the QoS model people have included a proposal in their latest draft. That could be evaluated from the perspective of other application users. *) separation of reserve and commit phases: at the moment, I still don't see _how_ this can be treated independently of the resource description issue (not why it is necessary to do so), and why=20 finessing it as part of the resource description is a bad idea. *) fate sharing: if this is a reference to wanting the state installed for one application to be conditional on the state installed for another application in failure cases, this was actually discussed at length in the requirements phase and agreed to be a non-requirement. The reason is that it can get almost unboundedly complex to do this in the network, and you can never do as good a job as in the end system; so, why go for extra efficiency in the form of network support when this is just to handle exceptional (failure) cases. but see also the next point: *) inter-nslp binding: there probably is an issue about setting up signalling state for multiple signalling applications needing=20 inter-NSLP interactions and hence possibly several round trips. I think we need examples of this to work on understanding what a general solution would look like. We do know there is a problem with NAT/other-NSLP interactions, but that is also a problem which affect GIMPS as well, so I would like to see how that works out before considering the case extending to a more general concern. *) policy control for AAA, etc.: I have to admit I don't really understand this one. If it is a matter of having unified handling of NSIS resource requests in the context of a AAA architecture, it is clearly a Good Thing; however, how much does it relate to common interactions within a node rather than having an impact on the wire NSIS protocols themselves? *) route recording: i can see this as being a common (i.e. shareable) object - provided the applications can agree on what information about the route to record (node ingress address, node egress address, ports, node FQDNs...). I think this sort of thing would best be handled as a set of common diagnostic objects; Xiaoming has already done some thinking here AFAIK. *) explicit routing: *IF* this was to be supported as a function I=20 think it would have to be in the transport in some form. I raised a previous email on whether this would ever be the case (i.e. in what sense explicit routing would be part of NSIS scope) which didn't really get discussed much (see the archive around 20/04); in any case,=20 it is becoming clearer how to fit variable message routing methods=20 into GIMPS (NATFW requires it IIRC) and this would just be one more. *) resource sharing: i think this has to be in the NSLP. So, at the moment, while seeing that it is probably a good thing for the NSIS 'architecture' to enable some commonality between signalling applications, the best specific cases are already being worked on. robert h. > -----Original Message----- > From: Yacine.El_Mghazli@alcatel.fr=20 > [mailto:Yacine.El_Mghazli@alcatel.fr] > Sent: Friday, April 30, 2004 15:24 > To: David Oran > Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; Hancock, > Robert; nsis@ietf.org; Tschofenig Hannes > Subject: Re: [NSIS] common signalling application functions (was RE: > Tentative Interi m Meeting schedule) >=20 >=20 > dear all, >=20 > I participated into the design of the AAA in the QoS-NSLP=20 > together with > hannes. I tend to agree that this should fall into the=20 > so-called 'common > sig app functions' block. >=20 > moreover when examinating the dave's list of targetted=20 > applications, we > could even narrow the scope of such a common block to AAA (at large... > let's say 'policy'). concerning the design alternative=20 > (r=FCdiger mentions > 'toolbox' vs. cross-ref between NSLPs), IMO the first one=20 > should lead to > a cleaner design and avoid doing twice the same thing. >=20 > I have finally a couple of comments/questions: >=20 > 1) did you consider integrating such a generic 'toolbox' into=20 > GIMPS ? or > maybe the WG wants GIMPS to keep strictly relating to transport ? >=20 > I would suggest to copy the RSVP design here: a generic=20 > POLICY_DATA 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=20 > of already > RFCed PEs could even be re-used as is. >=20 > 2) does the working group think that the design of such=20 > generic objects > will come together with some kind of framework ? authz protocols ? > requirements ? >=20 >=20 > thanks, > yacine >=20 >=20 >=20 >=20 >=20 > David Oran wrote: >=20 > > --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=20 > 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=20 > 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 > >> _______________________________________________ nsis mailing list=20 > >> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ nsis mailing list=20 > > nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis