From nsis-bounces@ietf.org Sat Oct 01 10:28:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELiLy-0005Hb-UT; Sat, 01 Oct 2005 10:28:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELiLw-0005HQ-L8 for nsis@megatron.ietf.org; Sat, 01 Oct 2005 10:28:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04882 for ; Sat, 1 Oct 2005 10:28:37 -0400 (EDT) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELiU0-0007cH-Ci for nsis@ietf.org; Sat, 01 Oct 2005 10:37:01 -0400 Received: (qmail invoked by alias); 01 Oct 2005 14:28:10 -0000 Received: from p54A3333F.dip0.t-ipconnect.de (EHLO [192.168.0.4]) [84.163.51.63] by mail.gmx.net (mp008) with SMTP; 01 Oct 2005 16:28:10 +0200 X-Authenticated: #4469397 Message-ID: <433E9CFB.5040400@gmx.li> Date: Sat, 01 Oct 2005 16:28:11 +0200 From: Thomas Herzog User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Subject: [NSIS] Stack Proposal Profiles: ordering of protocol numbers? References: <009201c5c4fb$47d60190$9900a8c0@comm.ad.roke.co.uk> In-Reply-To: <009201c5c4fb$47d60190$9900a8c0@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I am currently in the process of implementing the message association setup for GIST, so I must validate Stack Profiles against each other. The format of the Profiles is defined as a list of Protocol IDs, and there are some Profiles defined in the draft (TCP, TLS/TCP, TLS/SCTP), but however the "ordering" of the Protocols is not defined. So TLS/TCP could be laid out on bitlevel format like (2,56,6), but also (2,6,56). (2 being the length of the profile field). This may not be a problem if we only use the predefined profiles which currently only employ 2 protocol layers, but if there will be profiles in the future using 3 or more layers, checking for validity would become even more complex. So my question: Wouldn't it be good, if one defined the ordering of the protocols in a profile explicitly as "use Protocol #1 over Protocol #2 over ... Protocol #n"? So if one needs to validate profiles against each other, one could simply stop if the first (and such topmost) Protocol ID differs/is not supported? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 03 05:18:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMSZ-0001L5-JR; Mon, 03 Oct 2005 05:18:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMSX-0001Kg-NA for nsis@megatron.ietf.org; Mon, 03 Oct 2005 05:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14582 for ; Mon, 3 Oct 2005 05:18:07 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMMat-0000vo-5J for nsis@ietf.org; Mon, 03 Oct 2005 05:26:53 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j939HIL5008054; Mon, 3 Oct 2005 10:17:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Stack Proposal Profiles: ordering of protocol numbers? Date: Mon, 3 Oct 2005 10:17:17 +0100 Message-ID: Thread-Topic: [NSIS] Stack Proposal Profiles: ordering of protocol numbers? Thread-Index: AcXGlODJ0lIfTN4rQSmMmMPiIQ3BPABZh8lw From: "Hancock, Robert" To: "Thomas Herzog" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Thomas, You are perfectly correct. (The person implementing GIST here was after me to pin this down but it never found its way into the spec.) I suggest 'top to bottom' as the interpretation (as you say, and as the example is written. I'll add it to the tracker. Thanks, robert h. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Thomas Herzog > Sent: 01 October 2005 15:28 > To: nsis@ietf.org > Subject: [NSIS] Stack Proposal Profiles: ordering of protocol numbers? >=20 >=20 > Hi, >=20 > I am currently in the process of implementing the message association=20 > setup for GIST, so I must validate Stack Profiles against each other.=20 > The format of the Profiles is defined as a list of Protocol IDs, and=20 > there are some Profiles defined in the draft (TCP, TLS/TCP,=20 > TLS/SCTP),=20 > but however the "ordering" of the Protocols is not defined. >=20 > So TLS/TCP could be laid out on bitlevel format like=20 > (2,56,6), but also=20 > (2,6,56). (2 being the length of the profile field). >=20 > This may not be a problem if we only use the predefined=20 > profiles which=20 > currently only employ 2 protocol layers, but if there will be=20 > profiles=20 > in the future using 3 or more layers, checking for validity=20 > would become=20 > even more complex. >=20 > So my question: Wouldn't it be good, if one defined the=20 > ordering of the=20 > protocols in a profile explicitly as "use Protocol #1 over=20 > Protocol #2=20 > over ... Protocol #n"? >=20 > So if one needs to validate profiles against each other, one could=20 > simply stop if the first (and such topmost) Protocol ID=20 > differs/is not=20 > supported? >=20 > Cheers, Thomas >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 03 07:42:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOiX-0004ul-K0; Mon, 03 Oct 2005 07:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOiV-0004ug-Qa for nsis@megatron.ietf.org; Mon, 03 Oct 2005 07:42:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22168 for ; Mon, 3 Oct 2005 07:42:47 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMOqx-0004D7-Pa for nsis@ietf.org; Mon, 03 Oct 2005 07:51:33 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j93BgaCh027438 for ; Mon, 3 Oct 2005 13:42:36 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j93Bga9i029538 for ; Mon, 3 Oct 2005 13:42:36 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Oct 2005 13:42:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Oct 2005 13:42:36 +0200 Message-ID: Thread-Topic: FYI: A Proposed IETF BoF on Diff-Serv Control Plane Thread-Index: AcXIDfxERb52ubdTTPaVOvFGiQG8Sw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 03 Oct 2005 11:42:36.0675 (UTC) FILETIME=[8D11DD30:01C5C80F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] FYI: A Proposed IETF BoF on Diff-Serv Control Plane X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org forward from e2e mailing list:=20 Posted at the request of Bob Braden: ---- A Proposed IETF BoF on Diff-Serv Control Plane --------------------------------------------------------------- We've been working toward a possible IETF BoF on diffserv control plane elements to be under the Operations and Management Area. Our in-progress Background and Goals for the BoF: It's been some time since the Diffserv forwarding path elements were standardized. At that time, the approach was to get the mechanisms deployed in routers so that approaches to service creation and control plane could be attempted. Before closing, the Diffserv WG defined the concept of Per-Domain Behaviors (PDBs) in RFC 3086, but left the approach to controling PDBs open. Now Diffserv forwarding elements are available in most routers and are in use to create services in some networks. A variety of approaches are being used for control and management of Diffserv but there appears to be some commonality. A possible path for IETF work is to enumerate and classify the common elements and to work toward some best common practices. Additionally, it may be useful to present specifications for a range of diffserv control plane elements using common interfaces. The major issues to deploying Diffserv-based services are primarily operational. The deployment must be cost-effective, be secured against vulnerabilities and not become a vehicle for denial of service attacks. Standardization should result in existing toolsets being either expanded to cover more needed functionality or to interact with other tools. A standardization effort should cover how to secure the architecture to mitigate vulnerabilities. Standards for a control plane QoS agent for routers may be useful. A desired outcome of IETF efforts is to make multiple products available to network operators, obviating the time and personnel expense of individual solutions. The end goal is to enable more services, both for network customers and for control of the network, without taxing personnel. The starting point for a BoF is to look at what's out there, determine if there is indeed some uniformity of approach useful as a starting point, and determine what's missing. The intial focus would be the intradomain control plane moving to interdomain or AS under same provider and finally to interprovider or interoperator. ------------------------------------------------------------------ The entire in-progress proposal for the BoF can be viewed at www.pollere.com under Resources, then Current Work. If you are interested in helping to further shape the proposal, please sign up for the email list dcpel@ietf.org through www1.ietf.org/mailman/listinfo/dcpel and comment on the list. thanks, Kathie Nichols Scott Bradner _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 03 07:51:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOrO-0006nC-R8; Mon, 03 Oct 2005 07:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOrN-0006lc-4k for nsis@megatron.ietf.org; Mon, 03 Oct 2005 07:51:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22686 for ; Mon, 3 Oct 2005 07:51:56 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMOzn-0004Rk-2j for nsis@ietf.org; Mon, 03 Oct 2005 08:00:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j93BnFaR016687 for ; Mon, 3 Oct 2005 14:49:16 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 14:51:51 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 14:51:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Oct 2005 14:51:25 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478DF930AB@esebe100.NOE.Nokia.com> Thread-Topic: WGLC on GIST: ID ACTION:draft-ietf-nsis-ntlp-08.txt Thread-Index: AcXDntjTmJaIcPQXQN2b1AAbBBKU/AEcQA7A X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 03 Oct 2005 11:51:25.0024 (UTC) FILETIME=[C7FD8600:01C5C810] X-Spam-Score: 1.6 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] WGLC on GIST: ID ACTION:draft-ietf-nsis-ntlp-08.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all,=20 I'd like to request a Working Group Last Call on the GIST draft: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-08.txt There are several interoperable implementations, and the specification seems quite stable now. The WGLC will run for two weeks, until October 17th. I believe that Robert has an issue tracker set-up, so he will track errors. thanks, John >-----Original Message----- >From: i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org]=20 >Sent: 27 September, 2005 22:50 >To: i-d-announce@ietf.org >Cc: nsis@ietf.org >Subject: I-D ACTION:draft-ietf-nsis-ntlp-08.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Next Steps in Signaling=20 >Working Group of the IETF. > > Title : GIST: General Internet Signaling Transport > Author(s) : H. Schulzrinne, R. Hancock > Filename : draft-ietf-nsis-ntlp-08.txt > Pages : 126 > Date : 2005-9-27 >=09 >This document specifies protocol stacks for the routing and transport > of per-flow signaling messages along the path taken by that flow > through the network. The design uses existing transport and security > protocols under a common messaging layer, the General Internet > Signaling Transport (GIST), which provides a universal service for > diverse signaling applications. GIST does not handle signaling > application state itself, but manages its own internal state and the > configuration of the underlying transport and security protocols to > enable the transfer of messages in both directions along the flow > path. The combination of GIST and the lower layer transport and > security protocols provides a solution for the base protocol > component of the "Next Steps in Signaling" framework. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 03 07:59:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOz6-00089A-87; Mon, 03 Oct 2005 07:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOz5-000895-Dm for nsis@megatron.ietf.org; Mon, 03 Oct 2005 07:59:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23024 for ; Mon, 3 Oct 2005 07:59:54 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMP7X-0004ls-9A for nsis@ietf.org; Mon, 03 Oct 2005 08:08:41 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j93BxeL5013793; Mon, 3 Oct 2005 12:59:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC on GIST: ID ACTION:draft-ietf-nsis-ntlp-08.txt Date: Mon, 3 Oct 2005 12:59:35 +0100 Message-ID: Thread-Topic: [NSIS] WGLC on GIST: ID ACTION:draft-ietf-nsis-ntlp-08.txt Thread-Index: AcXDntjTmJaIcPQXQN2b1AAbBBKU/AEcQA7AAABi5aA= From: "Hancock, Robert" To: , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, the tracker is at=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/index One issue is already there. You can use it directly, or post issues/reviews to the list and I will do my best to insert them myself. It's a big help if people can be clear about whether comments are - that the spec is wrong - that the spec is right but unclear - that there is an interesting point to discuss - or something else cheers, robert h. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of john.loughney@nokia.com > Sent: 03 October 2005 12:51 > To: nsis@ietf.org > Subject: [NSIS] WGLC on GIST: ID ACTION:draft-ietf-nsis-ntlp-08.txt > Importance: High >=20 >=20 > Hi all,=20 >=20 > I'd like to request a Working Group Last Call on the GIST draft: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-08.txt >=20 > There are several interoperable implementations, and the specification > seems > quite stable now. The WGLC will run for two weeks, until=20 > October 17th. > I believe > that Robert has an issue tracker set-up, so he will track errors. >=20 > thanks, > John >=20 > >-----Original Message----- > >From: i-d-announce-bounces@ietf.org=20 > >[mailto:i-d-announce-bounces@ietf.org]=20 > >Sent: 27 September, 2005 22:50 > >To: i-d-announce@ietf.org > >Cc: nsis@ietf.org > >Subject: I-D ACTION:draft-ietf-nsis-ntlp-08.txt=20 > > > >A New Internet-Draft is available from the on-line=20 > >Internet-Drafts directories. > >This draft is a work item of the Next Steps in Signaling=20 > >Working Group of the IETF. > > > > Title : GIST: General Internet Signaling Transport > > Author(s) : H. Schulzrinne, R. Hancock > > Filename : draft-ietf-nsis-ntlp-08.txt > > Pages : 126 > > Date : 2005-9-27 > >=09 > >This document specifies protocol stacks for the routing and transport > > of per-flow signaling messages along the path taken by that flow > > through the network. The design uses existing transport and > security > > protocols under a common messaging layer, the General Internet > > Signaling Transport (GIST), which provides a universal service for > > diverse signaling applications. GIST does not handle signaling > > application state itself, but manages its own internal=20 > state and the > > configuration of the underlying transport and security=20 > protocols to > > enable the transfer of messages in both directions along the flow > > path. The combination of GIST and the lower layer transport and > > security protocols provides a solution for the base protocol > > component of the "Next Steps in Signaling" framework. >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 03 09:22:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQGz-0007wl-9F; Mon, 03 Oct 2005 09:22:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMQGx-0007wg-0f for nsis@megatron.ietf.org; Mon, 03 Oct 2005 09:22:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28225 for ; Mon, 3 Oct 2005 09:22:25 -0400 (EDT) From: jia@dei.uc.pt Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMQPO-00079C-VG for nsis@ietf.org; Mon, 03 Oct 2005 09:31:13 -0400 Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.137.203.250]) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id j93DLjlU000583; Mon, 3 Oct 2005 14:21:45 +0100 Received: from mail.dei.uc.pt (localhost.localdomain [127.0.0.1]) by mail.dei.uc.pt (8.13.5/8.13.5) with ESMTP id j93DLVFZ000591; Mon, 3 Oct 2005 14:21:32 +0100 Received: (from nobody@localhost) by mail.dei.uc.pt (8.13.5/8.12.5/Submit) id j93DLN62000590; Mon, 3 Oct 2005 14:21:23 +0100 X-Authentication-Warning: mail.dei.uc.pt: nobody set sender to jia@dei.uc.pt using -f Received: from gtDEI-Vlans2.dei.uc.pt (gtDEI-Vlans2.dei.uc.pt [193.137.203.230]) by mail.dei.uc.pt (IMP) with HTTP for ; Mon, 3 Oct 2005 14:21:23 +0100 Message-ID: <1128345683.4341305386df9@mail.dei.uc.pt> Date: Mon, 3 Oct 2005 14:21:23 +0100 To: "Hancock, Robert" Subject: RE: [NSIS]about retransmission of fresh query messages References: <009201c5c4fb$47d60190$9900a8c0@comm.ad.roke.co.uk> In-Reply-To: <009201c5c4fb$47d60190$9900a8c0@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-3.438, required 3, ALL_TRUSTED -1.80, BAYES_00 -2.60, NO_REAL_NAME 0.96) X-FCTUC-DEI-SIC-MailScanner-From: jia@dei.uc.pt X-Spam-Score: 0.3 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 8bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Robert, Thank you for your reply, Please see my comments below. Quoting "Hancock, Robert" : > Hi Jia Jia, > > You raise a valid question about 'refresh' handling. > Essentially I think there is a design choice which could > go two ways: > a) handle refresh messages differently (no need for retransmission, > just assume that a refresh will get through before routing state > expires), or > b) handle all Query messages the same way (retransmission with > an exponential backoff). > > The design choice in GIST is (b). This isn't explicit in 5.3.3 > but is (I hope) in 6.2, which is supposed to capture this sort > of detail more precisely. > > So, one question would be whether this needs to be explained > better. Section 6.2 of GIST does illustrate the design choice (b) better. However, I still think that it needs to be explained more clearly and in more details. For instance, The query node state machine in Fig.6 (section 6.2) indicates that,when the query node is at the "Awaiting Refresh" state and receives a ResponseMessage, it still needs to check whether a Confirm is required and send the Confirm if required. I think maybe it could be better if this information is also mentioned at Section 4.4.3 "State Maintenance Procedures"? Moreover, I didn't find the clear information about how a query node can determine whether a Confirm is required or not in the draft although the GIST draft did imply that the query node can determine that based on the R flag of the Common Header of the received Response message. > The other question would be whether the design decision is > correct in the first place. Given that we have a retransmission > mechanism for the initial Query, I think it is simpler to use > it for the refresh case also. Otherwise, there is a more > complex analysis needed for the timer setting for sending > refresh messages to account for the fact that one may be lost; > it also becomes trickier thinking about the fact that the > RS-validity time can be changed by either end. I understand the design decision of treating all the query messages in the same way to eliminate the complex analysis. I notice in Fig. 6 of section 6.2 that the "Awaiting Response" state and the "Awaiting Refresh" state use the same rule for their retransmission. Does it mean that the "Awaiting Refresh" state will set the same T1 and T2 timeout values (for retransmission algorithm) as the "Awaiting Response" state does, without considering the Validality Time of both nodes at all? In addition, when a NSLP needs the GIST to send one NSLP message, it indicates a Timeout value to the GIST, which specifies the length of time GIST should attempt to send this message before indicating an error. Then, My question is: what is the relationship between the T2 timeout value of the retransmission algorithm and this NSLP Timeout value? Fig. 6 of section 6.2 shows that, if the number of Queries sent has reached the threshold and no Response message is received, the GIST will indicate NO Response error to NSLP. However, as mentioned before, when the NSLP Timeout value is reached and the NSLP data was not sent out, the GIST should indicate an error to the NSLP. Is there any better way to relate the T2 value with the NSLP Timeout value and then to report only one error to the NSLP instead of two? > (So, a third question would be whether more of this rationale > should be captured.) Cheers, Jia Jia > > -----Original Message----- > > From: jia@dei.uc.pt [mailto:jia@dei.uc.pt] > > Sent: 29 September 2005 11:28 > > To: Hancock, Robert > > Cc: nsis@ietf.org > > Subject: [NSIS]about retransmission of fresh query messages > > > > > > Hi, Robert, > > > > Thanks for your prompt reply. I have another question to ask. > > > > In section 5.3.3, the draft describes the retransmission algorithms > > against the losses of Query, Response and Confirm messages. However, > > It seems that the draft doesn't specify when the > > retransmission algorithms > > should be used (correct me if I am wrong). > > I know the retransmission algorithms should be used in the case that > > the Q-node needs to discover its downstream peer by sending a > > new Query > > message. > > My question is that: > > > > should the retransmission algorithms also be used against the loss of > > refresh Query message? As we know, sending refresh Query > > message involves > > validality times of both Q-node and R-node. Then, how should > > the T1 and T2 > > timeout values (see section 5.3.3) be chosen in the case of > > retransmitting > > refresh > > Query message? > > > > My opinion is that we don't need to re-send any refresh Query > > message and just > > let > > the routing state removed if any refresh Query/response > > message is lost on the > > way. > > And then, the Q-node can have a new handshake process if it > > needs to send any > > message to > > its downstream peer afterwards. Any comments are welcome. > > > > Cheers, > > > > jia jia > > > > Quoting "Hancock, Robert" : > > > > > Hi Jia Jia, > > > > > > the crucial phrase in the NTLP spec is in section 4.3: > > > > > > "It is the responsibility of the Querying node to generate > > > a GIMPS-Query message before this timer expires, if it > > believes that > > > the flow is still active; otherwise, the Responding node > > may delete > > > the state." > > > > > > In other words, it's intended to be up to the implementor; the -08 > > > version will say this in slightly more formal terms in the state > > > machines description (section 6.2). Your formula seems quite > > > reasonable to me; a more cautious implementor might also include > > > some jitter to avoid network synchronisation problems. > > > > > > It would be a good wg last call point to discuss exactly how > > > prescriptive the specification should be on this sort of issue. > > > > > > cheers, > > > > > > robert h. > > > > > > > -----Original Message----- > > > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > > > Behalf Of jia@dei.uc.pt > > > > Sent: 26 September 2005 15:14 > > > > To: nsis@ietf.org > > > > Subject: [NSIS] about refresh query > > > > > > > > > > > > > > > > Dear colleagues, I am implementing the background maintenance > > > > support for GIST > > > > now, which needs to send refresh Query Messages after the > > > > Routing State is > > > > installed at the Q-node. The NTLP draft specifies the > > > > validality time in the > > > > NLI object, which means that the Query-node or Response-node > > > > will remove the > > > > Routing State from its routing table if this node doesn't > > > > receive any refresh > > > > Query/Response messages during the validality time period. My > > > > question is that: > > > > > > > > > > > > What is the timeout value I should set for the Timer of > > > > sending the refresh > > > > Query message? Obviously, it is not appropriate that the > > > > timeout value is set > > > > to the validality time and it seems that the ntlp draft > > > > doesn't notice this > > > > issue. Now I set the timeout for the Timer of sending refresh > > > > query message as > > > > follows: timeout = min(ValidalityTime of Q-node, ValidalityTime of > > > > R-node)*fraction_factor, ( fraction_factor= 3/4, currently). > > > > Any comments are > > > > welcome. > > > > > > > > Best Regards > > > > > > > > Jia Jia > > > > > > > > _______________________________________________ > > > > 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 nsis-bounces@ietf.org Tue Oct 04 05:49:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMjQ5-0003Jf-JZ; Tue, 04 Oct 2005 05:49:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMjQ4-0003JN-04 for nsis@megatron.ietf.org; Tue, 04 Oct 2005 05:49:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07219 for ; Tue, 4 Oct 2005 05:49:05 -0400 (EDT) Received: from revol3.enst.fr ([137.194.2.10] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMjYh-0003G9-FE for nsis@ietf.org; Tue, 04 Oct 2005 05:58:05 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 8CFFA6040 for ; Tue, 4 Oct 2005 11:49:04 +0200 (CEST) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol3.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97923-05 for ; Tue, 4 Oct 2005 11:49:03 +0200 (CEST) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 749196077 for ; Tue, 4 Oct 2005 11:49:03 +0200 (CEST) Received: from nary (dhcp192-210.enst.fr [137.194.192.210]) by infres.enst.fr (Postfix) with SMTP id 2669C13CBB for ; Tue, 4 Oct 2005 11:49:03 +0200 (MEST) Message-ID: <010701c5c8c8$d85f3620$d2c0c289@nary> From: "Thanh Tra LUU" To: References: Date: Tue, 4 Oct 2005 11:48:59 +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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Virus-Scanned: amavisd-new at enst.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Subject: [NSIS] MRI issue X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I look at the MRI definition in the GIST protocol. Even though it's clear that MRI is used as a guide for GIST nodes to route signaling messages. Two example of MRM are stated in the draft NTLP version 8 for predictive routing and NAT address revervation. The problem i see is why MRI must be at the NTLP level while GIST is only responsible for transporting signaling messages hop by hop. The MRI is something at NSLP signaling application level. I don't see any benefit of using MRM without NSLP in two foregoing examples. Moreover, because of the problems of compatibilty, it's difficult for GIST to define new MRI. I agree that in the case of RSVP, and only in this case MRM has a meaning. Thus, i think it's better if GIST only sends signaling message along the data path, sending directly or using an IP router alert option. Other routing information will be defined at the NSLP layer. nary ----- Original Message ----- From: To: Cc: Sent: Tuesday, September 27, 2005 9:50 PM Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-08.txt > 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 : GIST: General Internet Signaling Transport > Author(s) : H. Schulzrinne, R. Hancock > Filename : draft-ietf-nsis-ntlp-08.txt > Pages : 126 > Date : 2005-9-27 > > This document specifies protocol stacks for the routing and transport > of per-flow signaling messages along the path taken by that flow > through the network. The design uses existing transport and security > protocols under a common messaging layer, the General Internet > Signaling Transport (GIST), which provides a universal service for > diverse signaling applications. GIST does not handle signaling > application state itself, but manages its own internal state and the > configuration of the underlying transport and security protocols to > enable the transfer of messages in both directions along the flow > path. The combination of GIST and the lower layer transport and > security protocols provides a solution for the base protocol > component of the "Next Steps in Signaling" framework. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-08.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-ntlp-08.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-ntlp-08.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ---------------------------------------------------------------------------- ---- > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 04 05:52:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMjTU-0003sG-5g; Tue, 04 Oct 2005 05:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMjTR-0003rk-FD; Tue, 04 Oct 2005 05:52:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07359; Tue, 4 Oct 2005 05:52:34 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMjc4-0003Ku-Un; Tue, 04 Oct 2005 06:01:34 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j949qMqi010103; Tue, 4 Oct 2005 11:52:22 +0200 (MEST) Message-ID: <002501c5c8c9$518bdf30$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Nsis \(E-mail\)" , , "Hancock, Robert" Date: Tue, 4 Oct 2005 11:52:17 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.481 () ALL_TRUSTED,AWL,BAYES_00,HTML_30_40,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 04 Oct 2005 11:52:23 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink Subject: [NSIS] possible GIST open issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1498206483==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1498206483== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C5C8DA.11E54130" This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C5C8DA.11E54130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert Mayi Zoumaro Djayoon, Martijn Swanink and myself are implementing the=20 NSIS protocol suite using the QoS-NSLP and GIST (v.05) specification. This also includes the stateless/statefull functionalities as well as the RMD-QOS model. During this implementation phase we identified certain GIMPS (GIST) issues that we consider that they are still open, even in the last version of GIST. These issues are as follows: Issues related to NSLP-GIST API: -------------------------------- Issue_1: (SetStateLifetime): Among the information that the SetStaLifetime's parameters provides to GIMPS, there is none that enables GIMPS to identify the SetStaLifetime's initiator (the NSLP which has initiated the SetStateLifetime's primitive). We think that it will be useful to include the NSLP-ID in this service primitive. This service primitive will then become: SetStateLifetime(MRI, StateLifetime, NSLP-ID) Issue_2: When the GIST aggregation operation is applied in a node then = it is necessary that QoS-NSLP should have the possibility to notify GIST the message aggregation level. In other words the QoS-NSLP must be able to identify which QoS-NSLP messages are associated with a higher aggregation level and which QoS-NSLP messages are associated with a lower aggregation level. In order to accomplish this a variable, e.g., "AggLevel" must be carried by the SendMessage primitive Issue related to bypass/forwarding level --------------------------------------- Issue_3: (bypassforwarding): The exact information that should be encapsulated in the router alert value is still an open issue. Best Regards, Georgios ------=_NextPart_000_0022_01C5C8DA.11E54130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Robert
 
Mayi=20  Zoumaro Djayoon, Martijn Swanink and myself are implementing the=20
NSIS protocol=20 suite using the QoS-NSLP and GIST
(v.05) specification. This also = includes=20 the stateless/statefull
functionalities as well as the RMD-QOS=20 model.

During this implementation phase we identified certain = GIMPS=20 (GIST)
issues that we consider that they are still open, even in the=20 last
version of GIST.

These issues are as = follows:


Issues=20 related to NSLP-GIST = API:
--------------------------------
Issue_1:=20 (SetStateLifetime): Among the information that the
SetStaLifetime's=20 parameters provides to GIMPS, there is none that
enables GIMPS to = identify=20 the SetStaLifetime's initiator (the NSLP
which has initiated the=20 SetStateLifetime's primitive).
We think that it will be useful to = include the=20 NSLP-ID in this service
primitive. This service primitive will then=20 become:
SetStateLifetime(MRI, StateLifetime, = NSLP-ID)



Issue_2:=20 When the GIST aggregation operation is applied in a node then it
is = necessary=20 that QoS-NSLP should have the possibility to notify GIST
the message=20 aggregation level. In other words the QoS-NSLP must be able
to = identify which=20 QoS-NSLP messages are associated with a higher
aggregation level and = which=20 QoS-NSLP messages are associated with a
lower aggregation level. In = order to=20 accomplish this a variable, e.g.,
"AggLevel" must be carried by the=20 SendMessage primitive



Issue related to bypass/forwarding=20 level
---------------------------------------
Issue_3: = (bypassforwarding):=20 The exact information that should be
encapsulated in the router alert = value=20 is still an open issue.


Best=20 Regards,
Georgios
------=_NextPart_000_0022_01C5C8DA.11E54130-- --===============1498206483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1498206483==-- From nsis-bounces@ietf.org Tue Oct 04 09:42:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMn4J-0001du-Aa; Tue, 04 Oct 2005 09:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMn4H-0001dJ-Ad; Tue, 04 Oct 2005 09:42:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19537; Tue, 4 Oct 2005 09:42:51 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMnCt-0001Hj-M6; Tue, 04 Oct 2005 09:51:52 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j94DgBL5026409; Tue, 4 Oct 2005 14:42:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Oct 2005 14:42:11 +0100 Message-ID: Thread-Topic: possible GIST open issues Thread-Index: AcXIyYT87jH9C8orTq6/INCIchPgoAAHd/hA From: "Hancock, Robert" To: "Georgios Karagiannis" , "Nsis \(E-mail\)" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.9 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink Subject: [NSIS] RE: possible GIST open issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0436545932==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0436545932== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C8E9.6BBB832C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C8E9.6BBB832C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi georgios, all, =20 for the issues: =20 SetStateLifetime: agreed, this should be related to the NSLP in question.=20 added http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 =20 For the other two, I am not sure these are GIST issues. To be specific, GIST does not really have a concept of aggregation; it only has the concept of=20 different NSLPs, and that different NSLPs can be associated with different RAO values. How a set of NSLPIDs and RAO values is chosen by a=20 signalling application to achieve aggregation is up to the signalling=20 application, GIST doesn't know about the different levels or the relationships between them. =20 Do you think some additional functionality is required, or just more explanation? =20 r. -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 04 October 2005 10:52 To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink Subject: possible GIST open issues =09 =09 Hi Robert =20 Mayi Zoumaro Djayoon, Martijn Swanink and myself are implementing the=20 NSIS protocol suite using the QoS-NSLP and GIST (v.05) specification. This also includes the stateless/statefull functionalities as well as the RMD-QOS model. =09 During this implementation phase we identified certain GIMPS (GIST) issues that we consider that they are still open, even in the last version of GIST. =09 These issues are as follows: =09 =09 Issues related to NSLP-GIST API: -------------------------------- Issue_1: (SetStateLifetime): Among the information that the SetStaLifetime's parameters provides to GIMPS, there is none that enables GIMPS to identify the SetStaLifetime's initiator (the NSLP which has initiated the SetStateLifetime's primitive). We think that it will be useful to include the NSLP-ID in this service primitive. This service primitive will then become: SetStateLifetime(MRI, StateLifetime, NSLP-ID) =09 =09 =09 Issue_2: When the GIST aggregation operation is applied in a node then it is necessary that QoS-NSLP should have the possibility to notify GIST the message aggregation level. In other words the QoS-NSLP must be able to identify which QoS-NSLP messages are associated with a higher aggregation level and which QoS-NSLP messages are associated with a lower aggregation level. In order to accomplish this a variable, e.g., "AggLevel" must be carried by the SendMessage primitive =09 =09 =09 Issue related to bypass/forwarding level --------------------------------------- Issue_3: (bypassforwarding): The exact information that should be encapsulated in the router alert value is still an open issue. =09 =09 Best Regards, Georgios =09 ------_=_NextPart_001_01C5C8E9.6BBB832C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
hi=20 georgios, all,
 
for=20 the issues:
 
SetStateLifetime: agreed, this should be related to the NSLP in = question.=20
added=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69
 
For=20 the other two, I am not sure these are GIST issues. To be specific,=20 GIST
does=20 not really have a concept of aggregation; it only has the concept of=20
different NSLPs, and that different NSLPs can be associated = with=20 different
RAO=20 values. How a set of NSLPIDs and RAO values is chosen by a =
signalling application to achieve aggregation is up to the = signalling=20
application, GIST doesn't know about the different levels or = the=20 relationships
between them.
 
Do you=20 think some additional functionality is required, or just more=20 explanation?
 
r.
-----Original Message-----
From: = Georgios=20 Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 04 = October 2005=20 10:52
To: Nsis (E-mail); nsis-imp@ietf.org; Hancock,=20 Robert
Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn=20 Swanink
Subject: possible GIST open = issues

Hi=20 Robert
 
Mayi=20  Zoumaro Djayoon, Martijn Swanink and myself are implementing the =
NSIS protocol=20 suite using the QoS-NSLP and GIST
(v.05) specification. This also = includes=20 the stateless/statefull
functionalities as well as the RMD-QOS=20 model.

During this implementation phase we identified certain = GIMPS=20 (GIST)
issues that we consider that they are still open, even in = the=20 last
version of GIST.

These issues are as = follows:


Issues=20 related to NSLP-GIST = API:
--------------------------------
Issue_1:=20 (SetStateLifetime): Among the information that the
SetStaLifetime's = parameters provides to GIMPS, there is none that
enables GIMPS to = identify=20 the SetStaLifetime's initiator (the NSLP
which has initiated the=20 SetStateLifetime's primitive).
We think that it will be useful to = include=20 the NSLP-ID in this service
primitive. This service primitive will = then=20 become:
SetStateLifetime(MRI, StateLifetime,=20 NSLP-ID)



Issue_2: When the GIST aggregation operation = is=20 applied in a node then it
is necessary that QoS-NSLP should have = the=20 possibility to notify GIST
the message aggregation level. In other = words=20 the QoS-NSLP must be able
to identify which QoS-NSLP messages are=20 associated with a higher
aggregation level and which QoS-NSLP = messages are=20 associated with a
lower aggregation level. In order to accomplish = this a=20 variable, e.g.,
"AggLevel" must be carried by the SendMessage=20 primitive



Issue related to bypass/forwarding=20 level
---------------------------------------
Issue_3:=20 (bypassforwarding): The exact information that should = be
encapsulated in=20 the router alert value is still an open issue.


Best=20 = Regards,
Georgios
------_=_NextPart_001_01C5C8E9.6BBB832C-- --===============0436545932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0436545932==-- From nsis-bounces@ietf.org Tue Oct 04 10:04:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnPK-00084Q-DP; Tue, 04 Oct 2005 10:04:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnPI-00082d-3C for nsis@megatron.ietf.org; Tue, 04 Oct 2005 10:04:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20824 for ; Tue, 4 Oct 2005 10:04:33 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMnXx-0001sr-FQ for nsis@ietf.org; Tue, 04 Oct 2005 10:13:35 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j94E4JL5032023; Tue, 4 Oct 2005 15:04:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] MRI issue Date: Tue, 4 Oct 2005 15:04:19 +0100 Message-ID: Thread-Topic: [NSIS] MRI issue Thread-Index: AcXIyUOMS1RuNBuGS363lYAM7HzRlAAIS45Q From: "Hancock, Robert" To: "Thanh Tra LUU" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Nary, At the moment, I'm not quite sure that I follow the details of your argument or what you are proposing. - if you want to send messages along the data path, the definition of MRM 0 and the MRI format for it are required at the GIST level. Otherwise it has no way to know what path to send data along. There are several aspects of message routing which are all interrelated, and it makes sense to describe them together. - for the NAT reservation case, we think it is clear that since there is *no* existing flow path to send messages along, a different MRM *must* be defined. And indeed, many of the other aspects of=20 message routing are also changed in this case. but the rest of=20 GIST operation is not changed. - the MRI is used *both* at the GIST and NSLP level. The NSLP has to describe how it wants the messages to be routed, and GIST has to do the routing.=20 - there is discussion in the draft (end of 3.3 and 4.3.4) which=20 I think shows why there is no practical barrier to deploying new MRMs if they are actually required.=20 As a side comment, I don't think anyone expects new MRMs to be=20 defined very often.=20 Does this answer your concerns? robert h. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Thanh Tra LUU > Sent: 04 October 2005 10:49 > To: nsis@ietf.org > Subject: [NSIS] MRI issue >=20 >=20 > Hi, >=20 > I look at the MRI definition in the GIST protocol. Even=20 > though it's clear > that MRI is used as a guide for GIST nodes to route signaling=20 > messages. Two > example of MRM are stated in the draft NTLP version 8 for=20 > predictive routing > and NAT address revervation. >=20 > The problem i see is why MRI must be at the NTLP level while=20 > GIST is only > responsible for transporting signaling messages hop by hop. The MRI is > something at NSLP signaling application level. I don't see=20 > any benefit of > using MRM without NSLP in two foregoing examples. Moreover,=20 > because of the > problems of compatibilty, it's difficult for GIST to define new MRI. >=20 > I agree that in the case of RSVP, and only in this case MRM=20 > has a meaning. > Thus, i think it's better if GIST only sends signaling=20 > message along the > data path, sending directly or using an IP router alert option. Other > routing information will be defined at the NSLP layer. >=20 > nary >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ----- Original Message -----=20 > From: > To: > Cc: > Sent: Tuesday, September 27, 2005 9:50 PM > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-08.txt >=20 >=20 > > 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=20 > Working Group of > the IETF. > > > > Title : GIST: General Internet Signaling Transport > > Author(s) : H. Schulzrinne, R. Hancock > > Filename : draft-ietf-nsis-ntlp-08.txt > > Pages : 126 > > Date : 2005-9-27 > > > > This document specifies protocol stacks for the routing and=20 > transport > > of per-flow signaling messages along the path taken by that flow > > through the network. The design uses existing transport=20 > and security > > protocols under a common messaging layer, the General Internet > > Signaling Transport (GIST), which provides a universal=20 > service for > > diverse signaling applications. GIST does not handle signaling > > application state itself, but manages its own internal=20 > state and the > > configuration of the underlying transport and security=20 > protocols to > > enable the transfer of messages in both directions along the flow > > path. The combination of GIST and the lower layer transport and > > security protocols provides a solution for the base protocol > > component of the "Next Steps in Signaling" framework. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-08.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=20 > the body of the > message. > > You can also visit=20 > 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-ntlp-08.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-ntlp-08.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. > > >=20 >=20 > -------------------------------------------------------------- > -------------- > ---- >=20 >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 04 10:50:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo7P-0006yl-7J; Tue, 04 Oct 2005 10:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo7G-0006vE-BW; Tue, 04 Oct 2005 10:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24554; Tue, 4 Oct 2005 10:49:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMoFx-0003AS-LB; Tue, 04 Oct 2005 10:59:01 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMo7F-0007jJ-Hv; Tue, 04 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Oct 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-06.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : QoS-NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-06.txt Pages : 42 Date : 2005-10-4 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-06.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-qspec-06.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-qspec-06.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: <2005-10-4101548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-4101548.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Tue Oct 04 11:01:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMoIc-0001YC-Vb; Tue, 04 Oct 2005 11:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMoIb-0001Y7-Ho for nsis@megatron.ietf.org; Tue, 04 Oct 2005 11:01:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26637 for ; Tue, 4 Oct 2005 11:01:43 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMoRH-0003wQ-Hq for nsis@ietf.org; Tue, 04 Oct 2005 11:10:45 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j94F1BL5016303; Tue, 4 Oct 2005 16:01:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS]about retransmission of fresh query messages Date: Tue, 4 Oct 2005 16:01:11 +0100 Message-ID: Thread-Topic: [NSIS]about retransmission of fresh query messages Thread-Index: AcXIHcDBdnCQbaG7QRa72xxNTKb79gA1CYYg From: "Hancock, Robert" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jia Jia, There are a number of semi-related issues here. 1. Whether a Confirm is sent or not depends precisely on the R-flag setting in the Response. This is implied in a number of places, but is only really explicit in A.1, which is probably a bit late. Added http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue70 2. To be more explicit that the retransmission rules apply to all Query messages (not just the initial one), I would update 5.3.3.=20 This could also indicate something about what values to use for T1/T2 in this case, although I am not sure exactly what to say here. - Same T1/T2 as for initial Query seems reasonable (these are in any case implementation chosen), in the absence of any other constraints (but see below) - I don't see these as being tied to the RS-Validity time. T1/T2 are about trading off the the reliability of packet transfer between=20 particular nodes and the urgency of a particular message; the RS-Validity time is about how likely it is for a path to change. You can imagine scenarios where one could be much larger than the other, either way round. So, I would leave this open. - The question about the T1/T2 setting vs. the Timeout value from=20 SendMessage is a good one. Strictly these are different concepts, since T1/T2 apply only to Query messages, whereas the Timeout applies to=20 all messages. But it seems reasonable to say that T2 SHOULD be chosen=20 to be less than the Timeout requested for the message. I've added all this as another issue: http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue71 Cheers, Robert H. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of jia@dei.uc.pt > Sent: 03 October 2005 14:21 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS]about retransmission of fresh query messages >=20 >=20 > Hi, Robert, >=20 > Thank you for your reply, Please see my comments below.=20 >=20 > Quoting "Hancock, Robert" : >=20 > > Hi Jia Jia, > >=20 > > You raise a valid question about 'refresh' handling. > > Essentially I think there is a design choice which could > > go two ways: > > a) handle refresh messages differently (no need for retransmission, > > just assume that a refresh will get through before routing state > > expires), or > > b) handle all Query messages the same way (retransmission with > > an exponential backoff). > >=20 > > The design choice in GIST is (b). This isn't explicit in 5.3.3 > > but is (I hope) in 6.2, which is supposed to capture this sort > > of detail more precisely.=20 > >=20 > > So, one question would be whether this needs to be explained > > better. >=20 >=20 > Section 6.2 of GIST does illustrate the design choice (b)=20 > better. However, > I still think that it needs to be explained more clearly and=20 > in more details. > For instance, The query node state machine in Fig.6 (section=20 > 6.2) indicates > that,when the query node is at the "Awaiting Refresh" state=20 > and receives a > ResponseMessage, it still needs to check whether a Confirm is=20 > required and send > the Confirm if required. I think maybe it could be better if=20 > this information > is also mentioned at Section 4.4.3 "State Maintenance Procedures"? >=20 > Moreover, I didn't find the clear information about how a=20 > query node can > determine whether a Confirm is required or not in the draft=20 > although the GIST > draft did imply that the query node can determine that based=20 > on the R flag of > the Common Header of the received Response message. =20 >=20 >=20 > > The other question would be whether the design decision is > > correct in the first place. Given that we have a retransmission > > mechanism for the initial Query, I think it is simpler to use > > it for the refresh case also. Otherwise, there is a more=20 > > complex analysis needed for the timer setting for sending > > refresh messages to account for the fact that one may be lost; > > it also becomes trickier thinking about the fact that the > > RS-validity time can be changed by either end. >=20 > I understand the design decision of treating all the query=20 > messages in the same > way to eliminate the complex analysis. I notice in Fig. 6 of=20 > section 6.2 that=20 > the "Awaiting Response" state and the "Awaiting Refresh"=20 > state use the same rule > for their retransmission. Does it mean that the "Awaiting=20 > Refresh" state will > set the same T1 and T2 timeout values (for retransmission=20 > algorithm) as the > "Awaiting Response" state does, without considering the=20 > Validality Time of both > nodes at all?=20 >=20 > In addition, when a NSLP needs the GIST to send one NSLP=20 > message, it indicates a > Timeout value to the GIST, which specifies the length of time=20 > GIST should > attempt to send this message before indicating an error.=20 > Then, My question is: > what is the relationship between the T2 timeout value of the=20 > retransmission > algorithm and this NSLP Timeout value?=20 >=20 > Fig. 6 of section 6.2 shows that, if the number of Queries=20 > sent has reached the > threshold and no Response message is received, the GIST will=20 > indicate NO > Response error to NSLP.=20 > However, as mentioned before, when the NSLP Timeout value is=20 > reached and the > NSLP data was not sent out, the GIST should indicate an error=20 > to the NSLP. Is > there any better way to relate the T2 value with the NSLP=20 > Timeout value and > then to report only one error to the NSLP instead of two? > =20 > > (So, a third question would be whether more of this rationale > > should be captured.) > =20 > Cheers, > =20 > Jia Jia >=20 > > > -----Original Message----- > > > From: jia@dei.uc.pt [mailto:jia@dei.uc.pt]=20 > > > Sent: 29 September 2005 11:28 > > > To: Hancock, Robert > > > Cc: nsis@ietf.org > > > Subject: [NSIS]about retransmission of fresh query messages > > >=20 > > >=20 > > > Hi, Robert, > > >=20 > > > Thanks for your prompt reply. I have another question to ask. > > >=20 > > > In section 5.3.3, the draft describes the retransmission=20 > algorithms > > > against the losses of Query, Response and Confirm=20 > messages. However,=20 > > > It seems that the draft doesn't specify when the=20 > > > retransmission algorithms=20 > > > should be used (correct me if I am wrong). > > > I know the retransmission algorithms should be used in=20 > the case that > > > the Q-node needs to discover its downstream peer by sending a=20 > > > new Query > > > message. > > > My question is that: > > >=20 > > > should the retransmission algorithms also be used against=20 > the loss of > > > refresh Query message? As we know, sending refresh Query=20 > > > message involves=20 > > > validality times of both Q-node and R-node. Then, how should=20 > > > the T1 and T2=20 > > > timeout values (see section 5.3.3) be chosen in the case of=20 > > > retransmitting > > > refresh=20 > > > Query message?=20 > > >=20 > > > My opinion is that we don't need to re-send any refresh Query=20 > > > message and just > > > let=20 > > > the routing state removed if any refresh Query/response=20 > > > message is lost on the > > > way. > > > And then, the Q-node can have a new handshake process if it=20 > > > needs to send any > > > message to > > > its downstream peer afterwards. Any comments are welcome. > > >=20 > > > Cheers, > > >=20 > > > jia jia > > >=20 > > > Quoting "Hancock, Robert" : > > >=20 > > > > Hi Jia Jia, > > > >=20 > > > > the crucial phrase in the NTLP spec is in section 4.3: > > > >=20 > > > > "It is the responsibility of the Querying node to generate > > > > a GIMPS-Query message before this timer expires, if it=20 > > > believes that > > > > the flow is still active; otherwise, the Responding node=20 > > > may delete > > > > the state." > > > >=20 > > > > In other words, it's intended to be up to the=20 > implementor; the -08 > > > > version will say this in slightly more formal terms in the state > > > > machines description (section 6.2). Your formula seems quite > > > > reasonable to me; a more cautious implementor might also include > > > > some jitter to avoid network synchronisation problems. > > > >=20 > > > > It would be a good wg last call point to discuss exactly how=20 > > > > prescriptive the specification should be on this sort of issue. > > > >=20 > > > > cheers, > > > >=20 > > > > robert h. > > > >=20 > > > > > -----Original Message----- > > > > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > > > > > Behalf Of jia@dei.uc.pt > > > > > Sent: 26 September 2005 15:14 > > > > > To: nsis@ietf.org > > > > > Subject: [NSIS] about refresh query > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Dear colleagues, I am implementing the background maintenance=20 > > > > > support for GIST > > > > > now, which needs to send refresh Query Messages after the=20 > > > > > Routing State is > > > > > installed at the Q-node. The NTLP draft specifies the=20 > > > > > validality time in the > > > > > NLI object, which means that the Query-node or Response-node=20 > > > > > will remove the > > > > > Routing State from its routing table if this node doesn't=20 > > > > > receive any refresh > > > > > Query/Response messages during the validality time period. My=20 > > > > > question is that: > > > > >=20 > > > > >=20 > > > > > What is the timeout value I should set for the Timer of=20 > > > > > sending the refresh > > > > > Query message? Obviously, it is not appropriate that the=20 > > > > > timeout value is set > > > > > to the validality time and it seems that the ntlp draft=20 > > > > > doesn't notice this > > > > > issue. Now I set the timeout for the Timer of sending refresh=20 > > > > > query message as > > > > > follows: timeout =3D min(ValidalityTime of Q-node,=20 > ValidalityTime of > > > > > R-node)*fraction_factor, ( fraction_factor=3D 3/4, currently). = > > > > > Any comments are > > > > > welcome. > > > > >=20 > > > > > Best Regards > > > > >=20 > > > > > Jia Jia > > > > >=20 > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 02:27:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2km-0000Aa-Bl; Wed, 05 Oct 2005 02:27:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2kj-00008o-Kt; Wed, 05 Oct 2005 02:27:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26577; Wed, 5 Oct 2005 02:27:44 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN2tY-0008SU-M4; Wed, 05 Oct 2005 02:36:53 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j956Re5P014438; Wed, 5 Oct 2005 08:27:40 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j956Rd5B028191; Wed, 5 Oct 2005 08:27:39 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j956RVd00315; Wed, 5 Oct 2005 08:27:31 +0200 (MEST) Date: Wed, 5 Oct 2005 08:27:31 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: robert.hancock@roke.co.uk, nsis@ietf.org, nsis-imp@ietf.org Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 05 Oct 2005 06:27:31 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <7fTVRjHl.1128493651.3827170.karagian@ewi.utwente.nl> In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.457 () ALL_TRUSTED,AWL,BAYES_00,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 05 Oct 2005 08:27:42 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: "m.zoumaro-djayoon@student.utwente.nl" , Martijn Swanink Subject: [NSIS] aggregation based GIST bypass forwarding functionality needed X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert I have seen that in the current version of the GIST draft you have removed the description of the bypass forwarding functionality (see section 4.3.4 in previous version of GIMPS (http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt). What is the reason of this huge modification? Please note that this GIST functionality is needed in when GIST has to support the QoS-NSLP aggregated and stateless operation! My comment regarding the "GIST aggregation operation" is associated with the bypass forwarding functionality that is needed in the situation that aggregation or stateless operation is required by QoS-NSLP. Best Regards, Georgios On 10/4/2005, "Hancock, Robert" wrote: >hi georgios, all, >=20 >for the issues: >=20 >SetStateLifetime: agreed, this should be related to the NSLP in >question.=20 >added >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 >=20 >For the other two, I am not sure these are GIST issues. To be specific, >GIST >does not really have a concept of aggregation; it only has the concept >of=20 >different NSLPs, and that different NSLPs can be associated with >different >RAO values. How a set of NSLPIDs and RAO values is chosen by a=20 >signalling application to achieve aggregation is up to the signalling=20 >application, GIST doesn't know about the different levels or the >relationships >between them. >=20 >Do you think some additional functionality is required, or just more >explanation? >=20 >r. > >=09-----Original Message----- >=09From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >=09Sent: 04 October 2005 10:52 >=09To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert >=09Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >=09Subject: possible GIST open issues >=09 >=09 >=09Hi Robert >=09=20 >=09Mayi Zoumaro Djayoon, Martijn Swanink and myself are >implementing the=20 >=09NSIS protocol suite using the QoS-NSLP and GIST >=09(v.05) specification. This also includes the stateless/statefull >=09functionalities as well as the RMD-QOS model. >=09 >=09During this implementation phase we identified certain GIMPS >(GIST) >=09issues that we consider that they are still open, even in the >last >=09version of GIST. >=09 >=09These issues are as follows: >=09 >=09 >=09Issues related to NSLP-GIST API: >=09-------------------------------- >=09Issue_1: (SetStateLifetime): Among the information that the >=09SetStaLifetime's parameters provides to GIMPS, there is none >that >=09enables GIMPS to identify the SetStaLifetime's initiator (the >NSLP >=09which has initiated the SetStateLifetime's primitive). >=09We think that it will be useful to include the NSLP-ID in this >service >=09primitive. This service primitive will then become: >=09SetStateLifetime(MRI, StateLifetime, NSLP-ID) >=09 >=09 >=09 >=09Issue_2: When the GIST aggregation operation is applied in a >node then it >=09is necessary that QoS-NSLP should have the possibility to notify >GIST >=09the message aggregation level. In other words the QoS-NSLP must >be able >=09to identify which QoS-NSLP messages are associated with a higher >=09aggregation level and which QoS-NSLP messages are associated >with a >=09lower aggregation level. In order to accomplish this a variable, >e.g., >=09"AggLevel" must be carried by the SendMessage primitive >=09 >=09 >=09 >=09Issue related to bypass/forwarding level >=09--------------------------------------- >=09Issue_3: (bypassforwarding): The exact information that should >be >=09encapsulated in the router alert value is still an open issue. >=09 >=09 >=09Best Regards, >=09Georgios >=09 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 04:34:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN4ix-0003Fx-Ij; Wed, 05 Oct 2005 04:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN4iu-0003FS-DK; Wed, 05 Oct 2005 04:34:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06258; Wed, 5 Oct 2005 04:33:58 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN4rk-0003WU-NN; Wed, 05 Oct 2005 04:43:09 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j958XGL5032613; Wed, 5 Oct 2005 09:33:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2005 09:33:16 +0100 Message-ID: Thread-Topic: aggregation based GIST bypass forwarding functionality needed Thread-Index: AcXJdesBGsouk7nmRca4BnXEPC9hmAAES2Yg From: "Hancock, Robert" To: "Georgios Karagiannis" , , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink Subject: [NSIS] RE: aggregation based GIST bypass forwarding functionality needed X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios, The *title* of section 4.3.4 has changed, but the concept of bypassing has not been removed from the spec. The description just depends on whether it involves the NSLP or not (the case where it involves the NSLP is treated earlier.) robert h. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 05 October 2005 07:28 > To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > Subject: aggregation based GIST bypass forwarding functionality needed >=20 >=20 >=20 > Hi Robert >=20 > I have seen that in the current version of the GIST draft you have > removed the description of the bypass forwarding functionality (see > section 4.3.4 in previous version of GIMPS > (http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt). >=20 > What is the reason of this huge modification? >=20 > Please note that this GIST functionality is needed in when GIST has to > support the QoS-NSLP aggregated and stateless operation! >=20 > My comment regarding the "GIST aggregation operation" is associated > with the bypass forwarding functionality that is needed in the > situation that aggregation or stateless operation is required by > QoS-NSLP. >=20 > Best Regards, > Georgios >=20 >=20 >=20 > On 10/4/2005, "Hancock, Robert" wrote: >=20 > >hi georgios, all, > >=20 > >for the issues: > >=20 > >SetStateLifetime: agreed, this should be related to the NSLP in > >question.=20 > >added > >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 > >=20 > >For the other two, I am not sure these are GIST issues. To=20 > be specific, > >GIST > >does not really have a concept of aggregation; it only has=20 > the concept > >of=20 > >different NSLPs, and that different NSLPs can be associated with > >different > >RAO values. How a set of NSLPIDs and RAO values is chosen by a=20 > >signalling application to achieve aggregation is up to the=20 > signalling=20 > >application, GIST doesn't know about the different levels or the > >relationships > >between them. > >=20 > >Do you think some additional functionality is required, or just more > >explanation? > >=20 > >r. > > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > > Sent: 04 October 2005 10:52 > > To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert > > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > > Subject: possible GIST open issues > >=09 > >=09 > > Hi Robert > > =20 > > Mayi Zoumaro Djayoon, Martijn Swanink and myself are > >implementing the=20 > > NSIS protocol suite using the QoS-NSLP and GIST > > (v.05) specification. This also includes the stateless/statefull > > functionalities as well as the RMD-QOS model. > >=09 > > During this implementation phase we identified certain GIMPS > >(GIST) > > issues that we consider that they are still open, even in the > >last > > version of GIST. > >=09 > > These issues are as follows: > >=09 > >=09 > > Issues related to NSLP-GIST API: > > -------------------------------- > > Issue_1: (SetStateLifetime): Among the information that the > > SetStaLifetime's parameters provides to GIMPS, there is none > >that > > enables GIMPS to identify the SetStaLifetime's initiator (the > >NSLP > > which has initiated the SetStateLifetime's primitive). > > We think that it will be useful to include the NSLP-ID in this > >service > > primitive. This service primitive will then become: > > SetStateLifetime(MRI, StateLifetime, NSLP-ID) > >=09 > >=09 > >=09 > > Issue_2: When the GIST aggregation operation is applied in a > >node then it > > is necessary that QoS-NSLP should have the possibility to notify > >GIST > > the message aggregation level. In other words the QoS-NSLP must > >be able > > to identify which QoS-NSLP messages are associated with a higher > > aggregation level and which QoS-NSLP messages are associated > >with a > > lower aggregation level. In order to accomplish this a variable, > >e.g., > > "AggLevel" must be carried by the SendMessage primitive > >=09 > >=09 > >=09 > > Issue related to bypass/forwarding level > > --------------------------------------- > > Issue_3: (bypassforwarding): The exact information that should > >be > > encapsulated in the router alert value is still an open issue. > >=09 > >=09 > > Best Regards, > > Georgios > >=09 > > >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 05:15:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5Me-0001y2-85; Wed, 05 Oct 2005 05:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5Mb-0001uW-KN; Wed, 05 Oct 2005 05:15:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08454; Wed, 5 Oct 2005 05:14:59 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN5VS-0004iS-HL; Wed, 05 Oct 2005 05:24:11 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j959EuIA025128; Wed, 5 Oct 2005 11:14:56 +0200 (MEST) Message-ID: <005801c5c98d$41789380$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , , References: Subject: Re: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded Date: Wed, 5 Oct 2005 11:14:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.448 () ALL_TRUSTED,AWL,BAYES_00,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 05 Oct 2005 11:14:59 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert >From what I can read from the text is that only the GIST bypassing functionality is supported on bypassing nodes not hosting a NSLP. The description of bypassing a node due to the fact a QoS-NSLP aggregation region has to be bypassed is removed from the text, i.e., reference [17] is not used in the text anymore. I think that it is needed that both bypassing methods should be supported and that this should be made clear in the text. I have seen that the discussion regarding the selection of the RAO values is moved to the draft below http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt This draft explains how the aggregation based bypassing is notified, see section 3.2, and section 3.9. However, I think that there is an inconsistency on this point between these two sections . I will send a separate e-mail on this! I think that the description of bypassing a node due to the fact that a QoS-NSLP aggregation region has to be bypassed has to be briefly explained in the GIST draft. Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "Georgios Karagiannis" ; ; Cc: ; "Martijn Swanink" Sent: Wednesday, October 05, 2005 10:33 AM Subject: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded > Georgios, > > The *title* of section 4.3.4 has changed, but the concept of > bypassing has not been removed from the spec. The description > just depends on whether it involves the NSLP or not (the case > where it involves the NSLP is treated earlier.) > > robert h. > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 05 October 2005 07:28 >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> Subject: aggregation based GIST bypass forwarding functionality needed >> >> >> >> Hi Robert >> >> I have seen that in the current version of the GIST draft you have >> removed the description of the bypass forwarding functionality (see >> section 4.3.4 in previous version of GIMPS >> (http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt). >> >> What is the reason of this huge modification? >> >> Please note that this GIST functionality is needed in when GIST has to >> support the QoS-NSLP aggregated and stateless operation! >> >> My comment regarding the "GIST aggregation operation" is associated >> with the bypass forwarding functionality that is needed in the >> situation that aggregation or stateless operation is required by >> QoS-NSLP. >> >> Best Regards, >> Georgios >> >> >> >> On 10/4/2005, "Hancock, Robert" wrote: >> >> >hi georgios, all, >> > >> >for the issues: >> > >> >SetStateLifetime: agreed, this should be related to the NSLP in >> >question. >> >added >> >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 >> > >> >For the other two, I am not sure these are GIST issues. To >> be specific, >> >GIST >> >does not really have a concept of aggregation; it only has >> the concept >> >of >> >different NSLPs, and that different NSLPs can be associated with >> >different >> >RAO values. How a set of NSLPIDs and RAO values is chosen by a >> >signalling application to achieve aggregation is up to the >> signalling >> >application, GIST doesn't know about the different levels or the >> >relationships >> >between them. >> > >> >Do you think some additional functionality is required, or just more >> >explanation? >> > >> >r. >> > >> > -----Original Message----- >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> > Sent: 04 October 2005 10:52 >> > To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert >> > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> > Subject: possible GIST open issues >> > >> > >> > Hi Robert >> > >> > Mayi Zoumaro Djayoon, Martijn Swanink and myself are >> >implementing the >> > NSIS protocol suite using the QoS-NSLP and GIST >> > (v.05) specification. This also includes the stateless/statefull >> > functionalities as well as the RMD-QOS model. >> > >> > During this implementation phase we identified certain GIMPS >> >(GIST) >> > issues that we consider that they are still open, even in the >> >last >> > version of GIST. >> > >> > These issues are as follows: >> > >> > >> > Issues related to NSLP-GIST API: >> > -------------------------------- >> > Issue_1: (SetStateLifetime): Among the information that the >> > SetStaLifetime's parameters provides to GIMPS, there is none >> >that >> > enables GIMPS to identify the SetStaLifetime's initiator (the >> >NSLP >> > which has initiated the SetStateLifetime's primitive). >> > We think that it will be useful to include the NSLP-ID in this >> >service >> > primitive. This service primitive will then become: >> > SetStateLifetime(MRI, StateLifetime, NSLP-ID) >> > >> > >> > >> > Issue_2: When the GIST aggregation operation is applied in a >> >node then it >> > is necessary that QoS-NSLP should have the possibility to notify >> >GIST >> > the message aggregation level. In other words the QoS-NSLP must >> >be able >> > to identify which QoS-NSLP messages are associated with a higher >> > aggregation level and which QoS-NSLP messages are associated >> >with a >> > lower aggregation level. In order to accomplish this a variable, >> >e.g., >> > "AggLevel" must be carried by the SendMessage primitive >> > >> > >> > >> > Issue related to bypass/forwarding level >> > --------------------------------------- >> > Issue_3: (bypassforwarding): The exact information that should >> >be >> > encapsulated in the router alert value is still an open issue. >> > >> > >> > Best Regards, >> > Georgios >> > >> > >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 05:48:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5sg-0005fm-Ur; Wed, 05 Oct 2005 05:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN5sf-0005dZ-6h for nsis@megatron.ietf.org; Wed, 05 Oct 2005 05:48:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09967 for ; Wed, 5 Oct 2005 05:48:06 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN61T-0005bK-Sw for nsis@ietf.org; Wed, 05 Oct 2005 05:57:18 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j959lXL5020673; Wed, 5 Oct 2005 10:47:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded Date: Wed, 5 Oct 2005 10:47:33 +0100 Message-ID: Thread-Topic: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded Thread-Index: AcXJjV+zd+EqDxUNRIOI6d0X88TpQgAA7Y5g From: "Hancock, Robert" To: "Georgios Karagiannis" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, I think the text you are referring to was removed between=20 v06 and v07, not between v07 and v08. (RFC3175 was still in the v07 references section, but never used in the text.) In any case, I don't think any functionality has changed. GIST has always had the concept that it will skip over nodes which don't process an NSLPID, which is what 4.3.4 is (still) about. If signalling applications want to use a sequence of NSLPIDs to handle different aggregation levels, that is just a particular use of that functionality by that signalling=20 application.=20 Are you looking for a sentence somewhere to point out the=20 existence of that possibility, or something more? Robert H. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 05 October 2005 10:15 > To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > Subject: Re: [NSIS] RE: aggregation based GIST bypass=20 > forwarding functionalityneeded >=20 >=20 > Hi Robert >=20 > From what I can read from the text is that only the GIST bypassing=20 > functionality > is supported on bypassing nodes not hosting a NSLP. > The description of bypassing a node due to the fact a=20 > QoS-NSLP aggregation=20 > region has > to be bypassed is removed from the text, i.e., reference [17]=20 > is not used in=20 > the text anymore. >=20 > I think that it is needed that both bypassing methods should=20 > be supported=20 > and that this should be made > clear in the text. >=20 > I have seen that the discussion regarding the selection of=20 > the RAO values is=20 > moved to the draft below > http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt > This draft explains how the aggregation based bypassing is=20 > notified, see=20 > section 3.2, and section 3.9. > However, I think that there is an inconsistency on this point=20 > between these=20 > two sections . > I will send a separate e-mail on this! > I think that the description of bypassing a node due to the=20 > fact that a=20 > QoS-NSLP aggregation region has > to be bypassed has to be briefly explained in the GIST draft. >=20 >=20 > Best regards, > Georgios >=20 > ----- Original Message -----=20 > From: "Hancock, Robert" > To: "Georgios Karagiannis" ; ;=20 > > Cc: ; "Martijn Swanink"=20 > > Sent: Wednesday, October 05, 2005 10:33 AM > Subject: [NSIS] RE: aggregation based GIST bypass forwarding=20 > functionalityneeded >=20 >=20 > > Georgios, > > > > The *title* of section 4.3.4 has changed, but the concept of > > bypassing has not been removed from the spec. The description > > just depends on whether it involves the NSLP or not (the case > > where it involves the NSLP is treated earlier.) > > > > robert h. > > > >> -----Original Message----- > >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Sent: 05 October 2005 07:28 > >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org > >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > >> Subject: aggregation based GIST bypass forwarding=20 > functionality needed > >> > >> > >> > >> Hi Robert > >> > >> I have seen that in the current version of the GIST draft you have > >> removed the description of the bypass forwarding functionality (see > >> section 4.3.4 in previous version of GIMPS > >> (http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt). > >> > >> What is the reason of this huge modification? > >> > >> Please note that this GIST functionality is needed in when=20 > GIST has to > >> support the QoS-NSLP aggregated and stateless operation! > >> > >> My comment regarding the "GIST aggregation operation" is associated > >> with the bypass forwarding functionality that is needed in the > >> situation that aggregation or stateless operation is required by > >> QoS-NSLP. > >> > >> Best Regards, > >> Georgios > >> > >> > >> > >> On 10/4/2005, "Hancock, Robert" wrote: > >> > >> >hi georgios, all, > >> > > >> >for the issues: > >> > > >> >SetStateLifetime: agreed, this should be related to the NSLP in > >> >question. > >> >added > >>=20 > >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 > >> > > >> >For the other two, I am not sure these are GIST issues. To > >> be specific, > >> >GIST > >> >does not really have a concept of aggregation; it only has > >> the concept > >> >of > >> >different NSLPs, and that different NSLPs can be associated with > >> >different > >> >RAO values. How a set of NSLPIDs and RAO values is chosen by a > >> >signalling application to achieve aggregation is up to the > >> signalling > >> >application, GIST doesn't know about the different levels or the > >> >relationships > >> >between them. > >> > > >> >Do you think some additional functionality is required,=20 > or just more > >> >explanation? > >> > > >> >r. > >> > > >> > -----Original Message----- > >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> > Sent: 04 October 2005 10:52 > >> > To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert > >> > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > >> > Subject: possible GIST open issues > >> > > >> > > >> > Hi Robert > >> > > >> > Mayi Zoumaro Djayoon, Martijn Swanink and myself are > >> >implementing the > >> > NSIS protocol suite using the QoS-NSLP and GIST > >> > (v.05) specification. This also includes the stateless/statefull > >> > functionalities as well as the RMD-QOS model. > >> > > >> > During this implementation phase we identified certain GIMPS > >> >(GIST) > >> > issues that we consider that they are still open, even in the > >> >last > >> > version of GIST. > >> > > >> > These issues are as follows: > >> > > >> > > >> > Issues related to NSLP-GIST API: > >> > -------------------------------- > >> > Issue_1: (SetStateLifetime): Among the information that the > >> > SetStaLifetime's parameters provides to GIMPS, there is none > >> >that > >> > enables GIMPS to identify the SetStaLifetime's initiator (the > >> >NSLP > >> > which has initiated the SetStateLifetime's primitive). > >> > We think that it will be useful to include the NSLP-ID in this > >> >service > >> > primitive. This service primitive will then become: > >> > SetStateLifetime(MRI, StateLifetime, NSLP-ID) > >> > > >> > > >> > > >> > Issue_2: When the GIST aggregation operation is applied in a > >> >node then it > >> > is necessary that QoS-NSLP should have the possibility to notify > >> >GIST > >> > the message aggregation level. In other words the QoS-NSLP must > >> >be able > >> > to identify which QoS-NSLP messages are associated with a higher > >> > aggregation level and which QoS-NSLP messages are associated > >> >with a > >> > lower aggregation level. In order to accomplish this a variable, > >> >e.g., > >> > "AggLevel" must be carried by the SendMessage primitive > >> > > >> > > >> > > >> > Issue related to bypass/forwarding level > >> > --------------------------------------- > >> > Issue_3: (bypassforwarding): The exact information that should > >> >be > >> > encapsulated in the router alert value is still an open issue. > >> > > >> > > >> > Best Regards, > >> > Georgios > >> > > >> > > >> > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 06:15:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6Im-0007Qf-1d; Wed, 05 Oct 2005 06:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6Ii-0007Pl-JD for nsis@megatron.ietf.org; Wed, 05 Oct 2005 06:15:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11647 for ; Wed, 5 Oct 2005 06:15:01 -0400 (EDT) Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN6RY-0006RE-2P for nsis@ietf.org; Wed, 05 Oct 2005 06:24:14 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id C9E0C164B2C for ; Wed, 5 Oct 2005 12:14:58 +0200 (CEST) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88085-03 for ; Wed, 5 Oct 2005 12:14:57 +0200 (CEST) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 8D7A0164A0D for ; Wed, 5 Oct 2005 12:14:57 +0200 (CEST) Received: from nary (dhcp192-210.enst.fr [137.194.192.210]) by infres.enst.fr (Postfix) with SMTP id 4B55113CBB for ; Wed, 5 Oct 2005 12:14:56 +0200 (MEST) Message-ID: <004701c5c995$a0319040$d2c0c289@nary> From: "Thanh Tra LUU" To: References: <010701c5c8c8$d85f3620$d2c0c289@nary> Subject: Re: [NSIS] MRI issue Date: Wed, 5 Oct 2005 12:14:52 +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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Virus-Scanned: amavisd-new at enst.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi, in fact, the arguments are as follows: - the flow id can be changed anytime, because of mobility or other reasons (e.g. NAT). For this reason, session id is defined. - NSLP can ask GISP to transport a message hop by hop (with RAO) or directly to a specific node. - there is no meaning in two cases you give as examples if a GIST node does not support NSLP. A message must goes up to NSLP and again goes down to GIST. without NSLP, GIST cannot decide how MRI is changed in your examples. otherwise, GIST must be capable of communicating with NAT/FW ALG to know the change of IP address even without NSLP. i don't know weather this is a good idea or not. thus, i think MRI should be only as flow id as before. i'm afraid GIST becomes too "heavy". nary ----- Original Message ----- From: "Hancock, Robert" To: "Thanh Tra LUU" ; Sent: Tuesday, October 04, 2005 4:04 PM Subject: RE: [NSIS] MRI issue Hi Nary, At the moment, I'm not quite sure that I follow the details of your argument or what you are proposing. - if you want to send messages along the data path, the definition of MRM 0 and the MRI format for it are required at the GIST level. Otherwise it has no way to know what path to send data along. There are several aspects of message routing which are all interrelated, and it makes sense to describe them together. - for the NAT reservation case, we think it is clear that since there is *no* existing flow path to send messages along, a different MRM *must* be defined. And indeed, many of the other aspects of message routing are also changed in this case. but the rest of GIST operation is not changed. - the MRI is used *both* at the GIST and NSLP level. The NSLP has to describe how it wants the messages to be routed, and GIST has to do the routing. - there is discussion in the draft (end of 3.3 and 4.3.4) which I think shows why there is no practical barrier to deploying new MRMs if they are actually required. As a side comment, I don't think anyone expects new MRMs to be defined very often. Does this answer your concerns? robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 06:35:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6cv-0006b1-12; Wed, 05 Oct 2005 06:35:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6cs-0006ZE-7G for nsis@megatron.ietf.org; Wed, 05 Oct 2005 06:35:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13755 for ; Wed, 5 Oct 2005 06:35:51 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN6lh-0007M1-Mg for nsis@ietf.org; Wed, 05 Oct 2005 06:45:04 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j95AZaTR000589; Wed, 5 Oct 2005 12:35:36 +0200 (MEST) Message-ID: <008a01c5c998$868a26e0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded Date: Wed, 5 Oct 2005 12:35:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.446 () ALL_TRUSTED,AWL,BAYES_00,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 05 Oct 2005 12:35:40 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert I think a sentence will anyway be necessary to emphasize that the bypassing of a node is also applied when for example, a QOS-NSLP aggregation region has to be bypassed. Regarding the described aggregation based bypassing solution you assume that a NSLPID must be associated with a unique RAO value. This is however not consistent with what is emphasized in Section 3.9 of http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt This section emphasizes that: "These considerations imply that the RAO value should not be tied directly to the NSLPID, but should be selected for the application on broader considerations of likely deployment scenarios." Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "Georgios Karagiannis" ; Cc: ; "Martijn Swanink" Sent: Wednesday, October 05, 2005 11:47 AM Subject: RE: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded > Hi Georgios, > > I think the text you are referring to was removed between > v06 and v07, not between v07 and v08. (RFC3175 was still > in the v07 references section, but never used in the text.) > > In any case, I don't think any functionality has changed. > GIST has always had the concept that it will skip over nodes > which don't process an NSLPID, which is what 4.3.4 is (still) > about. If signalling applications want to use a sequence of > NSLPIDs to handle different aggregation levels, that is just > a particular use of that functionality by that signalling > application. > > Are you looking for a sentence somewhere to point out the > existence of that possibility, or something more? > > Robert H. > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 05 October 2005 10:15 >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> Subject: Re: [NSIS] RE: aggregation based GIST bypass >> forwarding functionalityneeded >> >> >> Hi Robert >> >> From what I can read from the text is that only the GIST bypassing >> functionality >> is supported on bypassing nodes not hosting a NSLP. >> The description of bypassing a node due to the fact a >> QoS-NSLP aggregation >> region has >> to be bypassed is removed from the text, i.e., reference [17] >> is not used in >> the text anymore. >> >> I think that it is needed that both bypassing methods should >> be supported >> and that this should be made >> clear in the text. >> >> I have seen that the discussion regarding the selection of >> the RAO values is >> moved to the draft below >> http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt >> This draft explains how the aggregation based bypassing is >> notified, see >> section 3.2, and section 3.9. >> However, I think that there is an inconsistency on this point >> between these >> two sections . >> I will send a separate e-mail on this! >> I think that the description of bypassing a node due to the >> fact that a >> QoS-NSLP aggregation region has >> to be bypassed has to be briefly explained in the GIST draft. >> >> >> Best regards, >> Georgios >> >> ----- Original Message ----- >> From: "Hancock, Robert" >> To: "Georgios Karagiannis" ; ; >> >> Cc: ; "Martijn Swanink" >> >> Sent: Wednesday, October 05, 2005 10:33 AM >> Subject: [NSIS] RE: aggregation based GIST bypass forwarding >> functionalityneeded >> >> >> > Georgios, >> > >> > The *title* of section 4.3.4 has changed, but the concept of >> > bypassing has not been removed from the spec. The description >> > just depends on whether it involves the NSLP or not (the case >> > where it involves the NSLP is treated earlier.) >> > >> > robert h. >> > >> >> -----Original Message----- >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >> Sent: 05 October 2005 07:28 >> >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org >> >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> >> Subject: aggregation based GIST bypass forwarding >> functionality needed >> >> >> >> >> >> >> >> Hi Robert >> >> >> >> I have seen that in the current version of the GIST draft you have >> >> removed the description of the bypass forwarding functionality (see >> >> section 4.3.4 in previous version of GIMPS >> >> (http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt). >> >> >> >> What is the reason of this huge modification? >> >> >> >> Please note that this GIST functionality is needed in when >> GIST has to >> >> support the QoS-NSLP aggregated and stateless operation! >> >> >> >> My comment regarding the "GIST aggregation operation" is associated >> >> with the bypass forwarding functionality that is needed in the >> >> situation that aggregation or stateless operation is required by >> >> QoS-NSLP. >> >> >> >> Best Regards, >> >> Georgios >> >> >> >> >> >> >> >> On 10/4/2005, "Hancock, Robert" wrote: >> >> >> >> >hi georgios, all, >> >> > >> >> >for the issues: >> >> > >> >> >SetStateLifetime: agreed, this should be related to the NSLP in >> >> >question. >> >> >added >> >> >> >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 >> >> > >> >> >For the other two, I am not sure these are GIST issues. To >> >> be specific, >> >> >GIST >> >> >does not really have a concept of aggregation; it only has >> >> the concept >> >> >of >> >> >different NSLPs, and that different NSLPs can be associated with >> >> >different >> >> >RAO values. How a set of NSLPIDs and RAO values is chosen by a >> >> >signalling application to achieve aggregation is up to the >> >> signalling >> >> >application, GIST doesn't know about the different levels or the >> >> >relationships >> >> >between them. >> >> > >> >> >Do you think some additional functionality is required, >> or just more >> >> >explanation? >> >> > >> >> >r. >> >> > >> >> > -----Original Message----- >> >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >> > Sent: 04 October 2005 10:52 >> >> > To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert >> >> > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> >> > Subject: possible GIST open issues >> >> > >> >> > >> >> > Hi Robert >> >> > >> >> > Mayi Zoumaro Djayoon, Martijn Swanink and myself are >> >> >implementing the >> >> > NSIS protocol suite using the QoS-NSLP and GIST >> >> > (v.05) specification. This also includes the stateless/statefull >> >> > functionalities as well as the RMD-QOS model. >> >> > >> >> > During this implementation phase we identified certain GIMPS >> >> >(GIST) >> >> > issues that we consider that they are still open, even in the >> >> >last >> >> > version of GIST. >> >> > >> >> > These issues are as follows: >> >> > >> >> > >> >> > Issues related to NSLP-GIST API: >> >> > -------------------------------- >> >> > Issue_1: (SetStateLifetime): Among the information that the >> >> > SetStaLifetime's parameters provides to GIMPS, there is none >> >> >that >> >> > enables GIMPS to identify the SetStaLifetime's initiator (the >> >> >NSLP >> >> > which has initiated the SetStateLifetime's primitive). >> >> > We think that it will be useful to include the NSLP-ID in this >> >> >service >> >> > primitive. This service primitive will then become: >> >> > SetStateLifetime(MRI, StateLifetime, NSLP-ID) >> >> > >> >> > >> >> > >> >> > Issue_2: When the GIST aggregation operation is applied in a >> >> >node then it >> >> > is necessary that QoS-NSLP should have the possibility to notify >> >> >GIST >> >> > the message aggregation level. In other words the QoS-NSLP must >> >> >be able >> >> > to identify which QoS-NSLP messages are associated with a higher >> >> > aggregation level and which QoS-NSLP messages are associated >> >> >with a >> >> > lower aggregation level. In order to accomplish this a variable, >> >> >e.g., >> >> > "AggLevel" must be carried by the SendMessage primitive >> >> > >> >> > >> >> > >> >> > Issue related to bypass/forwarding level >> >> > --------------------------------------- >> >> > Issue_3: (bypassforwarding): The exact information that should >> >> >be >> >> > encapsulated in the router alert value is still an open issue. >> >> > >> >> > >> >> > Best Regards, >> >> > Georgios >> >> > >> >> > >> >> >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 06:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6qf-0003ci-II; Wed, 05 Oct 2005 06:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6qb-0003cK-Ld for nsis@megatron.ietf.org; Wed, 05 Oct 2005 06:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14513 for ; Wed, 5 Oct 2005 06:50:02 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN6zS-0007kL-GL for nsis@ietf.org; Wed, 05 Oct 2005 06:59:15 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j95AmlL5004745; Wed, 5 Oct 2005 11:48:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded Date: Wed, 5 Oct 2005 11:48:47 +0100 Message-ID: Thread-Topic: [NSIS] RE: aggregation based GIST bypass forwarding functionalityneeded Thread-Index: AcXJmJzNZV0ExQFMRTedUwYydHaNHwAACUxg From: "Hancock, Robert" To: "Georgios Karagiannis" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: quoted-printable Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, I've created http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue72 to add a comment on aggegation support. On the RAO setting, I don't think there is a contradiction but=20 the language is hard to get right. The intention of the sentence in draft-loughney-nsis-ext-01.txt (which I wrote, btw) is to say that the RAO does not have to be identical to the NSLPID or 1:1 related to it; however, the RAO must be derivable from the NSLPID (uniquely). Indeed, section 9 of the GIST spec says "Every other NSLPID MUST be associated with a specific RAO value (multiple NSLPIDs MAY be associated with the same value)." robert h. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 05 October 2005 11:36 > To: Hancock, Robert; nsis@ietf.org > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > Subject: Re: [NSIS] RE: aggregation based GIST bypass=20 > forwarding functionalityneeded >=20 >=20 > Hi Robert >=20 > I think a sentence will anyway be necessary to emphasize that=20 > the bypassing=20 > of a node is also > applied when for example, a QOS-NSLP aggregation region has=20 > to be bypassed. >=20 > Regarding the described aggregation based bypassing solution=20 > you assume that=20 > a NSLPID must be associated > with a unique RAO value. >=20 > This is however not consistent with what is emphasized in=20 > Section 3.9 of > http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt >=20 > This section emphasizes that: > "These considerations imply that the RAO value should not be tied > directly to the NSLPID, but should be selected for the=20 > application on > broader considerations of likely deployment scenarios." >=20 >=20 > Best Regards, > Georgios >=20 >=20 > ----- Original Message -----=20 > From: "Hancock, Robert" > To: "Georgios Karagiannis" ; > Cc: ; "Martijn Swanink"=20 > > Sent: Wednesday, October 05, 2005 11:47 AM > Subject: RE: [NSIS] RE: aggregation based GIST bypass forwarding=20 > functionalityneeded >=20 >=20 > > Hi Georgios, > > > > I think the text you are referring to was removed between > > v06 and v07, not between v07 and v08. (RFC3175 was still > > in the v07 references section, but never used in the text.) > > > > In any case, I don't think any functionality has changed. > > GIST has always had the concept that it will skip over nodes > > which don't process an NSLPID, which is what 4.3.4 is (still) > > about. If signalling applications want to use a sequence of > > NSLPIDs to handle different aggregation levels, that is just > > a particular use of that functionality by that signalling > > application. > > > > Are you looking for a sentence somewhere to point out the > > existence of that possibility, or something more? > > > > Robert H. > > > >> -----Original Message----- > >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Sent: 05 October 2005 10:15 > >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org > >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > >> Subject: Re: [NSIS] RE: aggregation based GIST bypass > >> forwarding functionalityneeded > >> > >> > >> Hi Robert > >> > >> From what I can read from the text is that only the GIST bypassing > >> functionality > >> is supported on bypassing nodes not hosting a NSLP. > >> The description of bypassing a node due to the fact a > >> QoS-NSLP aggregation > >> region has > >> to be bypassed is removed from the text, i.e., reference [17] > >> is not used in > >> the text anymore. > >> > >> I think that it is needed that both bypassing methods should > >> be supported > >> and that this should be made > >> clear in the text. > >> > >> I have seen that the discussion regarding the selection of > >> the RAO values is > >> moved to the draft below > >> http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt > >> This draft explains how the aggregation based bypassing is > >> notified, see > >> section 3.2, and section 3.9. > >> However, I think that there is an inconsistency on this point > >> between these > >> two sections . > >> I will send a separate e-mail on this! > >> I think that the description of bypassing a node due to the > >> fact that a > >> QoS-NSLP aggregation region has > >> to be bypassed has to be briefly explained in the GIST draft. > >> > >> > >> Best regards, > >> Georgios > >> > >> ----- Original Message -----=20 > >> From: "Hancock, Robert" > >> To: "Georgios Karagiannis" ;=20 > ; > >> > >> Cc: ; "Martijn Swanink" > >> > >> Sent: Wednesday, October 05, 2005 10:33 AM > >> Subject: [NSIS] RE: aggregation based GIST bypass forwarding > >> functionalityneeded > >> > >> > >> > Georgios, > >> > > >> > The *title* of section 4.3.4 has changed, but the concept of > >> > bypassing has not been removed from the spec. The description > >> > just depends on whether it involves the NSLP or not (the case > >> > where it involves the NSLP is treated earlier.) > >> > > >> > robert h. > >> > > >> >> -----Original Message----- > >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> >> Sent: 05 October 2005 07:28 > >> >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org > >> >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > >> >> Subject: aggregation based GIST bypass forwarding > >> functionality needed > >> >> > >> >> > >> >> > >> >> Hi Robert > >> >> > >> >> I have seen that in the current version of the GIST=20 > draft you have > >> >> removed the description of the bypass forwarding=20 > functionality (see > >> >> section 4.3.4 in previous version of GIMPS > >> >>=20 > (http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt). > >> >> > >> >> What is the reason of this huge modification? > >> >> > >> >> Please note that this GIST functionality is needed in when > >> GIST has to > >> >> support the QoS-NSLP aggregated and stateless operation! > >> >> > >> >> My comment regarding the "GIST aggregation operation"=20 > is associated > >> >> with the bypass forwarding functionality that is needed in the > >> >> situation that aggregation or stateless operation is required by > >> >> QoS-NSLP. > >> >> > >> >> Best Regards, > >> >> Georgios > >> >> > >> >> > >> >> > >> >> On 10/4/2005, "Hancock, Robert"=20 > wrote: > >> >> > >> >> >hi georgios, all, > >> >> > > >> >> >for the issues: > >> >> > > >> >> >SetStateLifetime: agreed, this should be related to the NSLP in > >> >> >question. > >> >> >added > >> >> > >>=20 > >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 > >> >> > > >> >> >For the other two, I am not sure these are GIST issues. To > >> >> be specific, > >> >> >GIST > >> >> >does not really have a concept of aggregation; it only has > >> >> the concept > >> >> >of > >> >> >different NSLPs, and that different NSLPs can be=20 > associated with > >> >> >different > >> >> >RAO values. How a set of NSLPIDs and RAO values is chosen by a > >> >> >signalling application to achieve aggregation is up to the > >> >> signalling > >> >> >application, GIST doesn't know about the different=20 > levels or the > >> >> >relationships > >> >> >between them. > >> >> > > >> >> >Do you think some additional functionality is required, > >> or just more > >> >> >explanation? > >> >> > > >> >> >r. > >> >> > > >> >> > -----Original Message----- > >> >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> >> > Sent: 04 October 2005 10:52 > >> >> > To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert > >> >> > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink > >> >> > Subject: possible GIST open issues > >> >> > > >> >> > > >> >> > Hi Robert > >> >> > > >> >> > Mayi Zoumaro Djayoon, Martijn Swanink and myself are > >> >> >implementing the > >> >> > NSIS protocol suite using the QoS-NSLP and GIST > >> >> > (v.05) specification. This also includes the=20 > stateless/statefull > >> >> > functionalities as well as the RMD-QOS model. > >> >> > > >> >> > During this implementation phase we identified certain GIMPS > >> >> >(GIST) > >> >> > issues that we consider that they are still open, even in the > >> >> >last > >> >> > version of GIST. > >> >> > > >> >> > These issues are as follows: > >> >> > > >> >> > > >> >> > Issues related to NSLP-GIST API: > >> >> > -------------------------------- > >> >> > Issue_1: (SetStateLifetime): Among the information that the > >> >> > SetStaLifetime's parameters provides to GIMPS, there is none > >> >> >that > >> >> > enables GIMPS to identify the SetStaLifetime's initiator (the > >> >> >NSLP > >> >> > which has initiated the SetStateLifetime's primitive). > >> >> > We think that it will be useful to include the NSLP-ID in this > >> >> >service > >> >> > primitive. This service primitive will then become: > >> >> > SetStateLifetime(MRI, StateLifetime, NSLP-ID) > >> >> > > >> >> > > >> >> > > >> >> > Issue_2: When the GIST aggregation operation is applied in a > >> >> >node then it > >> >> > is necessary that QoS-NSLP should have the=20 > possibility to notify > >> >> >GIST > >> >> > the message aggregation level. In other words the=20 > QoS-NSLP must > >> >> >be able > >> >> > to identify which QoS-NSLP messages are associated=20 > with a higher > >> >> > aggregation level and which QoS-NSLP messages are associated > >> >> >with a > >> >> > lower aggregation level. In order to accomplish this=20 > a variable, > >> >> >e.g., > >> >> > "AggLevel" must be carried by the SendMessage primitive > >> >> > > >> >> > > >> >> > > >> >> > Issue related to bypass/forwarding level > >> >> > --------------------------------------- > >> >> > Issue_3: (bypassforwarding): The exact information that should > >> >> >be > >> >> > encapsulated in the router alert value is still an open issue. > >> >> > > >> >> > > >> >> > Best Regards, > >> >> > Georgios > >> >> > > >> >> > > >> >> > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > > >> > >> > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 05 08:57:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN8pp-0006mf-UP; Wed, 05 Oct 2005 08:57:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN8pk-0006mY-F9 for nsis@megatron.ietf.org; Wed, 05 Oct 2005 08:57:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21243 for ; Wed, 5 Oct 2005 08:57:18 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN8yc-0002wm-52 for nsis@ietf.org; Wed, 05 Oct 2005 09:06:31 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j95CvHXC000645 for ; Wed, 5 Oct 2005 14:57:17 +0200 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j95CvGO5012752 for ; Wed, 5 Oct 2005 14:57:16 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 14:57:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5C9AC.4D8BE92B" Subject: FW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-06.txt Date: Wed, 5 Oct 2005 14:57:12 +0200 Message-ID: <391E6FBF5E786940B9E2F7CA6376C708DE4447@blns00fa.ww002.siemens.net> X-MS-Has-Attach: yes Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-06.txt Thread-Index: AcXI869DjJK4rryKTG6LGW/Zj6NtowAuGS3w From: "Kappler, Cornelia" To: X-OriginalArrivalTime: 05 Oct 2005 12:57:16.0164 (UTC) FILETIME=[4FE12440:01C5C9AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C9AC.4D8BE92B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all,=20 a new version of the QSPEC is available now. Focus of the update was the bit-level coding. After a review by Chris Lang and Andrew McDonald we made substantial changes.=20 Still missing is the IANA considerations section.=20 Best regards, Cornelia -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Dienstag, 4. Oktober 2005 16:50 To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-06.txt=20 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 : QoS-NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-06.txt Pages : 42 Date : 2005-10-4 =09 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-06.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-qspec-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-qspec-06.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C5C9AC.4D8BE92B Content-Type: application/octet-stream; name="ATT297252.TXT" Content-Description: ATT297252.TXT Content-Disposition: attachment; filename="ATT297252.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS0xMC00MTAxNTQ4LkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbnNpcy1xc3BlYy0w Ni50eHQNCg== ------_=_NextPart_001_01C5C9AC.4D8BE92B Content-Type: application/octet-stream; name="draft-ietf-nsis-qspec-06.URL" Content-Description: draft-ietf-nsis-qspec-06.URL Content-Disposition: attachment; filename="draft-ietf-nsis-qspec-06.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW5zaXMtcXNwZWMtMDYudHh0DQo= ------_=_NextPart_001_01C5C9AC.4D8BE92B Content-Type: text/plain; name="ATT297253.txt" Content-Description: ATT297253.txt Content-Disposition: attachment; filename="ATT297253.txt" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5zaXMgbWFp bGluZyBsaXN0DQpuc2lzQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uc2lzDQo= ------_=_NextPart_001_01C5C9AC.4D8BE92B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C5C9AC.4D8BE92B-- From nsis-bounces@ietf.org Wed Oct 05 09:49:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9e5-0002fs-7v; Wed, 05 Oct 2005 09:49:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9Qj-0005rR-NU for nsis@megatron.ietf.org; Wed, 05 Oct 2005 09:35:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23653 for ; Wed, 5 Oct 2005 09:35:31 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN9Zc-00046u-Iu for nsis@ietf.org; Wed, 05 Oct 2005 09:44:45 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j95DZQAm013060; Wed, 5 Oct 2005 15:35:27 +0200 (MEST) Message-ID: <00b001c5c9b1$a5faf950$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] RE: aggregation based GIST bypass forwardingfunctionalityneeded Date: Wed, 5 Oct 2005 15:35:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.444 () ALL_TRUSTED,AWL,BAYES_00,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 05 Oct 2005 15:35:30 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Content-Transfer-Encoding: 7bit Cc: m.zoumaro-djayoon@student.utwente.nl, Martijn Swanink X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert Thank you very much! Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "Georgios Karagiannis" ; Cc: ; "Martijn Swanink" Sent: Wednesday, October 05, 2005 12:48 PM Subject: RE: [NSIS] RE: aggregation based GIST bypass forwardingfunctionalityneeded > Hi Georgios, > > I've created > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue72 > to add a comment on aggegation support. > > On the RAO setting, I don't think there is a contradiction but > the language is hard to get right. The intention of the sentence in > draft-loughney-nsis-ext-01.txt (which I wrote, btw) is to say > that the RAO does not have to be identical to the NSLPID or > 1:1 related to it; however, the RAO must be derivable from the > NSLPID (uniquely). Indeed, section 9 of the GIST spec says > > "Every other NSLPID MUST be associated with a specific RAO value > (multiple NSLPIDs MAY be associated with the same value)." > > robert h. > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 05 October 2005 11:36 >> To: Hancock, Robert; nsis@ietf.org >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> Subject: Re: [NSIS] RE: aggregation based GIST bypass >> forwarding functionalityneeded >> >> >> Hi Robert >> >> I think a sentence will anyway be necessary to emphasize that >> the bypassing >> of a node is also >> applied when for example, a QOS-NSLP aggregation region has >> to be bypassed. >> >> Regarding the described aggregation based bypassing solution >> you assume that >> a NSLPID must be associated >> with a unique RAO value. >> >> This is however not consistent with what is emphasized in >> Section 3.9 of >> http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt >> >> This section emphasizes that: >> "These considerations imply that the RAO value should not be tied >> directly to the NSLPID, but should be selected for the >> application on >> broader considerations of likely deployment scenarios." >> >> >> Best Regards, >> Georgios >> >> >> ----- Original Message ----- >> From: "Hancock, Robert" >> To: "Georgios Karagiannis" ; >> Cc: ; "Martijn Swanink" >> >> Sent: Wednesday, October 05, 2005 11:47 AM >> Subject: RE: [NSIS] RE: aggregation based GIST bypass forwarding >> functionalityneeded >> >> >> > Hi Georgios, >> > >> > I think the text you are referring to was removed between >> > v06 and v07, not between v07 and v08. (RFC3175 was still >> > in the v07 references section, but never used in the text.) >> > >> > In any case, I don't think any functionality has changed. >> > GIST has always had the concept that it will skip over nodes >> > which don't process an NSLPID, which is what 4.3.4 is (still) >> > about. If signalling applications want to use a sequence of >> > NSLPIDs to handle different aggregation levels, that is just >> > a particular use of that functionality by that signalling >> > application. >> > >> > Are you looking for a sentence somewhere to point out the >> > existence of that possibility, or something more? >> > >> > Robert H. >> > >> >> -----Original Message----- >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >> Sent: 05 October 2005 10:15 >> >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org >> >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> >> Subject: Re: [NSIS] RE: aggregation based GIST bypass >> >> forwarding functionalityneeded >> >> >> >> >> >> Hi Robert >> >> >> >> From what I can read from the text is that only the GIST bypassing >> >> functionality >> >> is supported on bypassing nodes not hosting a NSLP. >> >> The description of bypassing a node due to the fact a >> >> QoS-NSLP aggregation >> >> region has >> >> to be bypassed is removed from the text, i.e., reference [17] >> >> is not used in >> >> the text anymore. >> >> >> >> I think that it is needed that both bypassing methods should >> >> be supported >> >> and that this should be made >> >> clear in the text. >> >> >> >> I have seen that the discussion regarding the selection of >> >> the RAO values is >> >> moved to the draft below >> >> http://www.ietf.org/internet-drafts/draft-loughney-nsis-ext-01.txt >> >> This draft explains how the aggregation based bypassing is >> >> notified, see >> >> section 3.2, and section 3.9. >> >> However, I think that there is an inconsistency on this point >> >> between these >> >> two sections . >> >> I will send a separate e-mail on this! >> >> I think that the description of bypassing a node due to the >> >> fact that a >> >> QoS-NSLP aggregation region has >> >> to be bypassed has to be briefly explained in the GIST draft. >> >> >> >> >> >> Best regards, >> >> Georgios >> >> >> >> ----- Original Message ----- >> >> From: "Hancock, Robert" >> >> To: "Georgios Karagiannis" ; >> ; >> >> >> >> Cc: ; "Martijn Swanink" >> >> >> >> Sent: Wednesday, October 05, 2005 10:33 AM >> >> Subject: [NSIS] RE: aggregation based GIST bypass forwarding >> >> functionalityneeded >> >> >> >> >> >> > Georgios, >> >> > >> >> > The *title* of section 4.3.4 has changed, but the concept of >> >> > bypassing has not been removed from the spec. The description >> >> > just depends on whether it involves the NSLP or not (the case >> >> > where it involves the NSLP is treated earlier.) >> >> > >> >> > robert h. >> >> > >> >> >> -----Original Message----- >> >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >> >> Sent: 05 October 2005 07:28 >> >> >> To: Hancock, Robert; nsis@ietf.org; nsis-imp@ietf.org >> >> >> Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> >> >> Subject: aggregation based GIST bypass forwarding >> >> functionality needed >> >> >> >> >> >> >> >> >> >> >> >> Hi Robert >> >> >> >> >> >> I have seen that in the current version of the GIST >> draft you have >> >> >> removed the description of the bypass forwarding >> functionality (see >> >> >> section 4.3.4 in previous version of GIMPS >> >> >> >> (http://www.watersprings.org/pub/id/draft-ietf-nsis-ntlp-07.txt). >> >> >> >> >> >> What is the reason of this huge modification? >> >> >> >> >> >> Please note that this GIST functionality is needed in when >> >> GIST has to >> >> >> support the QoS-NSLP aggregated and stateless operation! >> >> >> >> >> >> My comment regarding the "GIST aggregation operation" >> is associated >> >> >> with the bypass forwarding functionality that is needed in the >> >> >> situation that aggregation or stateless operation is required by >> >> >> QoS-NSLP. >> >> >> >> >> >> Best Regards, >> >> >> Georgios >> >> >> >> >> >> >> >> >> >> >> >> On 10/4/2005, "Hancock, Robert" >> wrote: >> >> >> >> >> >> >hi georgios, all, >> >> >> > >> >> >> >for the issues: >> >> >> > >> >> >> >SetStateLifetime: agreed, this should be related to the NSLP in >> >> >> >question. >> >> >> >added >> >> >> >> >> >> >http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue69 >> >> >> > >> >> >> >For the other two, I am not sure these are GIST issues. To >> >> >> be specific, >> >> >> >GIST >> >> >> >does not really have a concept of aggregation; it only has >> >> >> the concept >> >> >> >of >> >> >> >different NSLPs, and that different NSLPs can be >> associated with >> >> >> >different >> >> >> >RAO values. How a set of NSLPIDs and RAO values is chosen by a >> >> >> >signalling application to achieve aggregation is up to the >> >> >> signalling >> >> >> >application, GIST doesn't know about the different >> levels or the >> >> >> >relationships >> >> >> >between them. >> >> >> > >> >> >> >Do you think some additional functionality is required, >> >> or just more >> >> >> >explanation? >> >> >> > >> >> >> >r. >> >> >> > >> >> >> > -----Original Message----- >> >> >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >> >> > Sent: 04 October 2005 10:52 >> >> >> > To: Nsis (E-mail); nsis-imp@ietf.org; Hancock, Robert >> >> >> > Cc: m.zoumaro-djayoon@student.utwente.nl; Martijn Swanink >> >> >> > Subject: possible GIST open issues >> >> >> > >> >> >> > >> >> >> > Hi Robert >> >> >> > >> >> >> > Mayi Zoumaro Djayoon, Martijn Swanink and myself are >> >> >> >implementing the >> >> >> > NSIS protocol suite using the QoS-NSLP and GIST >> >> >> > (v.05) specification. This also includes the >> stateless/statefull >> >> >> > functionalities as well as the RMD-QOS model. >> >> >> > >> >> >> > During this implementation phase we identified certain GIMPS >> >> >> >(GIST) >> >> >> > issues that we consider that they are still open, even in the >> >> >> >last >> >> >> > version of GIST. >> >> >> > >> >> >> > These issues are as follows: >> >> >> > >> >> >> > >> >> >> > Issues related to NSLP-GIST API: >> >> >> > -------------------------------- >> >> >> > Issue_1: (SetStateLifetime): Among the information that the >> >> >> > SetStaLifetime's parameters provides to GIMPS, there is none >> >> >> >that >> >> >> > enables GIMPS to identify the SetStaLifetime's initiator (the >> >> >> >NSLP >> >> >> > which has initiated the SetStateLifetime's primitive). >> >> >> > We think that it will be useful to include the NSLP-ID in this >> >> >> >service >> >> >> > primitive. This service primitive will then become: >> >> >> > SetStateLifetime(MRI, StateLifetime, NSLP-ID) >> >> >> > >> >> >> > >> >> >> > >> >> >> > Issue_2: When the GIST aggregation operation is applied in a >> >> >> >node then it >> >> >> > is necessary that QoS-NSLP should have the >> possibility to notify >> >> >> >GIST >> >> >> > the message aggregation level. In other words the >> QoS-NSLP must >> >> >> >be able >> >> >> > to identify which QoS-NSLP messages are associated >> with a higher >> >> >> > aggregation level and which QoS-NSLP messages are associated >> >> >> >with a >> >> >> > lower aggregation level. In order to accomplish this >> a variable, >> >> >> >e.g., >> >> >> > "AggLevel" must be carried by the SendMessage primitive >> >> >> > >> >> >> > >> >> >> > >> >> >> > Issue related to bypass/forwarding level >> >> >> > --------------------------------------- >> >> >> > Issue_3: (bypassforwarding): The exact information that should >> >> >> >be >> >> >> > encapsulated in the router alert value is still an open issue. >> >> >> > >> >> >> > >> >> >> > Best Regards, >> >> >> > Georgios >> >> >> > >> >> >> > >> >> >> >> >> > >> >> > _______________________________________________ >> >> > nsis mailing list >> >> > nsis@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> > >> >> >> >> >> > >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 03:14:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENPxg-0005Ov-8h; Thu, 06 Oct 2005 03:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENPxf-0005On-5v for nsis@megatron.ietf.org; Thu, 06 Oct 2005 03:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12720 for ; Thu, 6 Oct 2005 03:14:37 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENQ6g-0000GP-Fk for nsis@ietf.org; Thu, 06 Oct 2005 03:23:59 -0400 Received: (qmail invoked by alias); 06 Oct 2005 06:56:39 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp020) with SMTP; 06 Oct 2005 08:56:39 +0200 X-Authenticated: #29516787 Message-ID: <4344CAA0.8030606@gmx.net> Date: Thu, 06 Oct 2005 08:56:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org, andrew.mcdonald@roke.co.uk, karagian@cs.utwente.nl, sven.van_den_bosch@alcatel.be, jmanner@cs.helsinki.fi Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [NSIS] authorizing query messages X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all, as part of our work on the diameter-qos application and the radius-qos draft we came across the aspect of authorizing individual types of actions taken by the qos signaling protocol. from discussions in the past i remember that people wanted to authorize query messages as well. when we come to the concrete details we are not quite sure what it actually means. what would be the authorization decision regarding the query message people have in mind? ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 05:23:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENRyj-0000io-Ld; Thu, 06 Oct 2005 05:23:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENRyf-0000eC-Sa for nsis@megatron.ietf.org; Thu, 06 Oct 2005 05:23:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20695 for ; Thu, 6 Oct 2005 05:23:47 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENS7i-0006Ur-Lb for nsis@ietf.org; Thu, 06 Oct 2005 05:33:12 -0400 Received: from wrl-40.cs.helsinki.fi (wrl-40.cs.helsinki.fi [128.214.166.160]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 06 Oct 2005 12:23:43 +0300 id 00090012.4344ED1F.000032E0 Date: Thu, 6 Oct 2005 12:23:43 +0300 (EEST) From: Jukka MJ Manner To: Hannes Tschofenig In-Reply-To: <4344CAA0.8030606@gmx.net> Message-ID: References: <4344CAA0.8030606@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "McDonald, Andrew" , Georgios Karagiannis , nsis@ietf.org Subject: [NSIS] Re: authorizing query messages X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I would expect that in certain networks, not everybody may query the network of available resources. Thus, there could be need to include an auhtorization token, or ask from a Diameter server whether the node sending the query is allowed to do that. Cheers, Jukka On Thu, 6 Oct 2005, Hannes Tschofenig wrote: > hi all, > > as part of our work on the diameter-qos application and the radius-qos draft > we came across the aspect of authorizing individual types of actions taken by > the qos signaling protocol. from discussions in the past i remember that > people wanted to authorize query messages as well. when we come to the > concrete details we are not quite sure what it actually means. what would be > the authorization decision regarding the query message people have in mind? > > ciao > hannes > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 06:29:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENT00-00020V-9X; Thu, 06 Oct 2005 06:29:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENSzy-00020N-Mk for nsis@megatron.ietf.org; Thu, 06 Oct 2005 06:29:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22996 for ; Thu, 6 Oct 2005 06:29:11 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENT90-0000AD-IZ for nsis@ietf.org; Thu, 06 Oct 2005 06:38:37 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j96ASWL5024229; Thu, 6 Oct 2005 11:28:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] MRI issue Date: Thu, 6 Oct 2005 11:28:18 +0100 Message-ID: Thread-Topic: [NSIS] MRI issue Thread-Index: AcXJljdw91UzOlDyTrm//xWz7FweMAAyLiAA From: "Hancock, Robert" To: "Thanh Tra LUU" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Nary, I'm still not really following. Please see below: > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Thanh Tra LUU > Sent: 05 October 2005 11:15 > To: nsis@ietf.org > Subject: Re: [NSIS] MRI issue >=20 >=20 > hi, >=20 > in fact, the arguments are as follows: > - the flow id can be changed anytime, because of mobility or=20 > other reasons > (e.g. NAT). For this reason, session id is defined. True, but I'm not sure I see the relevance. > - NSLP can ask GISP to transport a message hop by hop (with=20 > RAO) or directly to a specific node. Partly true: the NSLP can ask GIST to transport a message along a flow path to the next/previous node. Whether RAO mechanisms are used is up to GIST. The NSLP *cannot* ask GIST to transport a message to a specific node *unless* it is a node which it has previously=20 received a message from. > - there is no meaning in two cases you give as examples if a=20 > GIST node does not support NSLP. A message must goes up to NSLP and again=20 > goes down to GIST.=20 True (well, at least the second sentence...) if the message is about that NSLP. > without NSLP, GIST cannot decide how MRI is changed in=20 > your examples. GIST never changes the MRI. It only uses the MRI to decide how to route messages. (NATs can change the MRI. It is an implementation issue whether this goes through the code that implements the NATFW NSLP, or some other code which manages binding tables in the NAT which is coordinated with the NATFW NSLP.) > otherwise, GIST must be capable of communicating with NAT/FW=20 > ALG to know the > change of IP address even without NSLP. i don't know weather=20 > this is a good > idea or not. >=20 > thus, i think MRI should be only as flow id as before. i'm afraid GIST > becomes too "heavy". The functionality is needed in any case. The question is how it is structured within the specification.=20 What MRI do you think the NATFW NSLP should use for the REA message? robert h. >=20 > nary >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Hancock, Robert" > To: "Thanh Tra LUU" ; > Sent: Tuesday, October 04, 2005 4:04 PM > Subject: RE: [NSIS] MRI issue >=20 >=20 > Hi Nary, >=20 > At the moment, I'm not quite sure that I follow the details of > your argument or what you are proposing. >=20 > - if you want to send messages along the data path, the definition > of MRM 0 and the MRI format for it are required at the GIST level. > Otherwise it has no way to know what path to send data along. There > are several aspects of message routing which are all interrelated, > and it makes sense to describe them together. >=20 > - for the NAT reservation case, we think it is clear that since > there is *no* existing flow path to send messages along, a different > MRM *must* be defined. And indeed, many of the other aspects of > message routing are also changed in this case. but the rest of > GIST operation is not changed. >=20 > - the MRI is used *both* at the GIST and NSLP level. The NSLP has > to describe how it wants the messages to be routed, and GIST has > to do the routing. >=20 > - there is discussion in the draft (end of 3.3 and 4.3.4) which > I think shows why there is no practical barrier to deploying new > MRMs if they are actually required. >=20 > As a side comment, I don't think anyone expects new MRMs to be > defined very often. >=20 > Does this answer your concerns? >=20 > robert h. >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 10:55:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENX9H-0001Vb-Go; Thu, 06 Oct 2005 10:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENX9F-0001VN-CM for nsis@megatron.ietf.org; Thu, 06 Oct 2005 10:55:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08601 for ; Thu, 6 Oct 2005 10:55:02 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1827HeB9pMAHnndmnxBRzABHQupuMHjejY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENXIK-0003A9-RU for nsis@ietf.org; Thu, 06 Oct 2005 11:04:30 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ENX8n-0003Yx-Sa; Thu, 06 Oct 2005 16:54:50 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B7965B25A; Thu, 6 Oct 2005 16:54:35 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ENX8l-0002jD-CS; Thu, 06 Oct 2005 16:54:35 +0200 Message-ID: <43453AAA.9060407@tm.uka.de> Date: Thu, 06 Oct 2005 16:54:34 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "nsis@ietf.org" , Jukka MJ Manner , andrew.mcdonald@roke.co.uk X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.5 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: Subject: [NSIS] Further open QoS NSLP issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, [I'm not really sure whether anyone is tracking my QoS NSLP issues at all here on this list...e.g., http://www1.ietf.org/mail-archive/web/nsis/current/msg05345.html http://www1.ietf.org/mail-archive/web/nsis/current/msg05359.html I got zero responses from the authors so far to the above message] While we are implementing things I have several additional comments for the QoS NSLP: * Wouldn't it make sense to forward 4xx/5xx RESPONSEs along the path upstream towards QNI even if no RII was originally included in the RESERVE? * Sec. 5.4.3 says "The RESPONSE message is impotent, it does not cause any state to be installed or modified." I don't think that the above statement is correct: a) in case of a failure (the RESPONSE carries code >=300) a QNE will usually release any already allocated resources which is deletion of state. Is this not seen as modification? b) in case a RESPONSE indicates that there are less resources available downstream than requested by the RESERVE, a QNE may/should free some resources which is a state modification. * It is not possible to send back an error for a QUERY w/o RII. In this case one could only detect that there is no corresponding RESERVE after a while and retransmit. This should be documented. * NOTIFY should also not alter any state. However, in case a notify signals a fatal error condition, state deletion may be a correct action (at least the state machine draft proposed this. If wrongly then we need clarification in the QoS NSLP draft). * How should a node behave if it gets a RESPONSE with a non-matching RSN? Drop it silently? If so, then please add a clear statement in sec. 5.4.3. Currently, you could not send back an error message, because NOTIFY is defined as asynchronous message. * Sec. 4.1 "Any node may include a request for a RESPONSE in its RESERVE messages. It does so by including a Request Identification Information (RII) object in the RESERVE message." One could clarify in sec. 4.1 and/or 5.3.2 that if an RII object is already included in a message, an interested QNE must not add an RII object, but may simply remember that RII to match the related RESPONSE it is interested in later. When it receives the RESPONSE, it forwards the RESPONSE upstream towards the RII originating node. * Sec. 5.2.1 says: "List of RII for outstanding responses with processing information the RII is a 32 bit number." Conceptually we have two RII lists in 5.2.1: Own RIIs (this QNE inserted originally the RII), Foreign RIIs (other nodes inserted the RII upstream, but the QNE is interested in the RESPONSE, too). * This would also help to clarify Sec. 5.4.3: "On receipt of a RESPONSE message containing an RII object, the QNE MUST attempt to match it to the outstanding response requests for that signalling session. If the match succeeds, then the RESPONSE MUST NOT be forwarded further along the path." This is only true in case the RII is found in the list of Own RIIs. * RII conflict Error Msg It is said that the RII should be unique within a session and different for each message. However, I could imagine a scenario when a QNI sends a RESERVE message with a specific RII and some QNE also initiates a RESERVE with the same RII value for the same session simultaneously. The QNE may trigger this RESERVE in order to reserve resources along a new branch due of a route change. Ok, the probability may be really small, but one should be prepared for such things... So due to some event, a QNE will receive a message with an RII that is already in use. In this case it might be good to let the QNE send an error message back stating that there is an RII conflict, i.e. it is already in use. * Who sends a response to the RESERVE with RII, sometimes it may be the QNR sometimes it may be a cross-over QNE, i.e. the RESERVE (e.g. carrying a TEAR) may not always be propagated all along the whole path to the far end, it may stop earlier at a cross-over node. IMHO this should be clarified in the text. Best regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 11:38:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENXpA-0006UA-Ne; Thu, 06 Oct 2005 11:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENXp8-0006U0-PQ for nsis@megatron.ietf.org; Thu, 06 Oct 2005 11:38:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10843 for ; Thu, 6 Oct 2005 11:38:19 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENXyE-00055F-3i for nsis@ietf.org; Thu, 06 Oct 2005 11:47:47 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j96Fbb4f008910; Thu, 6 Oct 2005 17:37:37 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j96Fbbdl013460; Thu, 6 Oct 2005 17:37:37 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Oct 2005 17:37:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] Re: authorizing query messages Date: Thu, 6 Oct 2005 17:37:35 +0200 Message-ID: Thread-Topic: [NSIS] Re: authorizing query messages Thread-Index: AcXKV8ceb34nKD4kRFqicbh2fh3H7wAMo7kw From: "Tschofenig, Hannes" To: "Jukka MJ Manner" , "Hannes Tschofenig" X-OriginalArrivalTime: 06 Oct 2005 15:37:36.0131 (UTC) FILETIME=[E03D5D30:01C5CA8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: "McDonald, Andrew" , Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi jukka,=20 thanks for your feedback. here is a proposal how to handle authorization for the query message: the query message triggers a QAR with the authentication info but without any QoS-Resources.=20 it might be necessary to indicate (somewhere) that this is only a query without the need to enable accounting and charging.=20 as such, the response in the QAA is also limited to the result rather than returning information like avps like CC-Time,Cost, QoS-Resources,Authz-time).=20 here is the figure:=20 End-Host Network Element Entity requesting QoS ( Diameter ( Diameter QoS Client) QoS Server) | | | +---QoS-Query------>| | | +- - - - - QAR - - - - - >| | |(QoS-Resources=3DNULL, | | | QoS-Auth-Data,User-ID)| | | +--------+--------------+ | | | Authorize request | | | | Keep no session data | | | | | | | +--------+--------------+ | |< - - - - QAA - - - - - -+ | |(Result-Code) | | | | | +-------+---------+ | |Proceeed with | | |QoS signaling | | |exchange | | +-------+---------+ | | | +----------QoS-Reserve---------------> | | | |<---------QoS-Response--------------- |<--QoS-Response----+ ciao hannes > Hi, >=20 > I would expect that in certain networks, not everybody may query the=20 > network of available resources. Thus, there could be need to=20 > include an=20 > auhtorization token, or ask from a Diameter server whether the node=20 > sending the query is allowed to do that. >=20 > Cheers, > Jukka >=20 >=20 > On Thu, 6 Oct 2005, Hannes Tschofenig wrote: >=20 > > hi all, > >=20 > > as part of our work on the diameter-qos application and the=20 > radius-qos draft > > we came across the aspect of authorizing individual types=20 > of actions taken by > > the qos signaling protocol. from discussions in the past i=20 > remember that > > people wanted to authorize query messages as well. when we=20 > come to the > > concrete details we are not quite sure what it actually=20 > means. what would be > > the authorization decision regarding the query message=20 > people have in mind? > >=20 > > ciao > > hannes > >=20 > >=20 > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 11:40:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENXrO-0006nX-Jo; Thu, 06 Oct 2005 11:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENXrN-0006mh-1W for nsis@megatron.ietf.org; Thu, 06 Oct 2005 11:40:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10905 for ; Thu, 6 Oct 2005 11:40:38 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENY0S-0005BF-0X for nsis@ietf.org; Thu, 06 Oct 2005 11:50:06 -0400 Received: from wrl-40.cs.helsinki.fi (wrl-40.cs.helsinki.fi [128.214.166.160]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 06 Oct 2005 18:40:36 +0300 id 00090065.43454574.000054E0 Date: Thu, 6 Oct 2005 18:40:36 +0300 (EEST) From: Jukka MJ Manner To: "Tschofenig, Hannes" Subject: Re: AW: [NSIS] Re: authorizing query messages In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: "McDonald, Andrew" , Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, looks good to me, although you have a slight error in your figure: change "QoS-Reserve" to "QoS-Query". :) Jukka On Thu, 6 Oct 2005, Tschofenig, Hannes wrote: > hi jukka, > > thanks for your feedback. here is a proposal how to handle authorization > for the query message: > > the query message triggers a QAR with the authentication info but > without any QoS-Resources. > it might be necessary to indicate (somewhere) that this is only a query > without the need to enable accounting and charging. > > as such, the response in the QAA is also limited to the result rather > than returning information like avps like CC-Time,Cost, > QoS-Resources,Authz-time). > > here is the figure: > > End-Host Network Element Entity > requesting QoS ( Diameter ( Diameter > QoS Client) QoS Server) > | | | > +---QoS-Query------>| | > | +- - - - - QAR - - - - - >| > | |(QoS-Resources=NULL, | > | | QoS-Auth-Data,User-ID)| > | | +--------+--------------+ > | | | Authorize request | > | | | Keep no session data | > | | | | > | | +--------+--------------+ > | |< - - - - QAA - - - - - -+ > | |(Result-Code) | > | | | > | +-------+---------+ > | |Proceeed with | > | |QoS signaling | > | |exchange | > | +-------+---------+ > | | > | +----------QoS-Reserve---------------> > | | > | |<---------QoS-Response--------------- > |<--QoS-Response----+ > > > ciao > hannes > > > Hi, > > > > I would expect that in certain networks, not everybody may query the > > network of available resources. Thus, there could be need to > > include an > > auhtorization token, or ask from a Diameter server whether the node > > sending the query is allowed to do that. > > > > Cheers, > > Jukka > > > > > > On Thu, 6 Oct 2005, Hannes Tschofenig wrote: > > > > > hi all, > > > > > > as part of our work on the diameter-qos application and the > > radius-qos draft > > > we came across the aspect of authorizing individual types > > of actions taken by > > > the qos signaling protocol. from discussions in the past i > > remember that > > > people wanted to authorize query messages as well. when we > > come to the > > > concrete details we are not quite sure what it actually > > means. what would be > > > the authorization decision regarding the query message > > people have in mind? > > > > > > ciao > > > hannes > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 12:24:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYXy-0003Ve-1d; Thu, 06 Oct 2005 12:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYXw-0003VZ-Vl for nsis@megatron.ietf.org; Thu, 06 Oct 2005 12:24:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13278 for ; Thu, 6 Oct 2005 12:24:37 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENYh3-000730-4t for nsis@ietf.org; Thu, 06 Oct 2005 12:34:06 -0400 Received: from wrl-40.cs.helsinki.fi (wrl-40.cs.helsinki.fi [128.214.166.160]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 06 Oct 2005 19:24:37 +0300 id 0008FD16.43454FC5.00002D15 Date: Thu, 6 Oct 2005 19:24:37 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless In-Reply-To: <43453AAA.9060407@tm.uka.de> Message-ID: References: <43453AAA.9060407@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: andrew.mcdonald@roke.co.uk, "nsis@ietf.org" Subject: [NSIS] Re: Further open QoS NSLP issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland, I'll try to answer some of your comments below. Sorry to have missed your feedback. Jukka On Thu, 6 Oct 2005, Roland Bless wrote: > Hi, > > [I'm not really sure whether anyone is tracking my QoS NSLP > issues at all here on this list...e.g., > http://www1.ietf.org/mail-archive/web/nsis/current/msg05345.html > http://www1.ietf.org/mail-archive/web/nsis/current/msg05359.html > I got zero responses from the authors so far to the above message] > > While we are implementing things I have several > additional comments for the QoS NSLP: > > * Wouldn't it make sense to forward 4xx/5xx RESPONSEs > along the path upstream towards QNI even if no RII was > originally included in the RESERVE? [JM]: We are in the middle of reworking out how/when/why errors are sent. In order to protect from DoS attacks, a QNE should consider twice before sending error messages upstream or downstream. > > * Sec. 5.4.3 says > "The RESPONSE message is > impotent, it does not cause any state to be installed or modified." > > I don't think that the above statement is correct: > a) in case of a failure (the RESPONSE carries code >=300) a QNE > will usually release any already allocated resources which > is deletion of state. Is this not seen as modification? [JM]: Good point. > b) in case a RESPONSE indicates that there are less resources > available downstream than requested by the RESERVE, a QNE > may/should free some resources which is a state modification. [JM]: So you mean that QNEs that already made the reservation should free those reservations? In general, yes, but a QoS model might have other rules? > > * It is not possible to send back an error for a QUERY w/o RII. > In this case one could only detect that there is no corresponding > RESERVE after a while and retransmit. This should be documented. [JM]: I'm still discussing the use of QUERY messages with my co-authors. I would see that all queries must have an RII. But then, how do simple queries differ from ones intended to trigger a receiver-initiated reservation... that is what I wonder mylsef... > > * NOTIFY should also not alter any state. However, in case a notify > signals a fatal error condition, state deletion may be a correct > action (at least the state machine draft proposed this. If wrongly > then we need clarification in the QoS NSLP draft). [JM]: I guess this depends on the QoS model? > > * How should a node behave if it gets a RESPONSE with a non-matching > RSN? > > Drop it silently? If so, then please add a clear statement in > sec. 5.4.3. > Currently, you could not send back an error message, because > NOTIFY is defined as asynchronous message. [JM]: Dropping a "wierd" message would be the default action. This has been added to my editor's copy for the forthcoming draft. > > * Sec. 4.1 > "Any node may include a request for a RESPONSE in its RESERVE > messages. It does so by including a Request Identification > Information (RII) object in the RESERVE message." > > One could clarify in sec. 4.1 and/or 5.3.2 that if an RII object is > already included in a message, an interested QNE must not add an > RII object, but may simply remember that RII to match the related > RESPONSE it is interested in later. When it receives the RESPONSE, > it forwards the RESPONSE upstream towards the RII originating node. [JM]: Good point. yet, there may emerge collisions with RIIs "shared" between QNEs. Should we actually support some kind of stacked RIIs? Same as we do for QSPECs already? > > * Sec. 5.2.1 says: > "List of RII for outstanding responses with processing information the > RII is a 32 bit number." > > Conceptually we have two RII lists in 5.2.1: > Own RIIs (this QNE inserted originally the RII), Foreign RIIs (other > nodes inserted the RII upstream, but the QNE is interested in the > RESPONSE, too). [JM]: Sounds right. > > * This would also help to clarify Sec. 5.4.3: > "On receipt of a RESPONSE message containing an RII object, the QNE > MUST attempt to match it to the outstanding response requests for > that signalling session. If the match succeeds, then the RESPONSE > MUST NOT be forwarded further along the path." > > This is only true in case the RII is found in the list of Own RIIs. > [JM]: Yes, good clarification. > * RII conflict Error Msg > It is said that the RII should be unique within a session and > different for each message. However, I could imagine a scenario > when a QNI sends a RESERVE message with a specific RII and some > QNE also initiates a RESERVE with the same RII value for the same > session simultaneously. The QNE may trigger this RESERVE in order > to reserve resources along a new branch due of a route change. > Ok, the probability may be really small, but one should be prepared > for such things... > So due to some event, a QNE will receive a message with an RII that is > already in use. In this case it might be good to let the QNE send an > error message back stating that there is an RII conflict, i.e. it is > already in use. [JM]: Need to think about this some more... > > * Who sends a response to the RESERVE with RII, sometimes it may > be the QNR sometimes it may be a cross-over QNE, i.e. the RESERVE > (e.g. carrying a TEAR) may not always be propagated all along the > whole path to the far end, it may stop earlier at a cross-over > node. IMHO this should be clarified in the text. [JM]: Will do. > > Best regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 06 15:45:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbgj-0005j6-8B; Thu, 06 Oct 2005 15:45:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbgh-0005iy-Tw for nsis@megatron.ietf.org; Thu, 06 Oct 2005 15:45:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26412 for ; Thu, 6 Oct 2005 15:45:53 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+0zBN33aQyyjIhKL4sQVCPNwCW4yNaA8A=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENbpq-0007iY-UU for nsis@ietf.org; Thu, 06 Oct 2005 15:55:23 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ENbgc-0004pJ-Ex; Thu, 06 Oct 2005 21:45:53 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 54394B26C; Thu, 6 Oct 2005 21:45:49 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ENbga-0002xB-Uh; Thu, 06 Oct 2005 21:45:49 +0200 Message-ID: <434570EB.7000901@tm.uka.de> Date: Thu, 06 Oct 2005 20:46:03 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner References: <43453AAA.9060407@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.5 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: andrew.mcdonald@roke.co.uk, "nsis@ietf.org" Subject: [NSIS] Re: Further open QoS NSLP issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jukka, Jukka MJ Manner wrote: > I'll try to answer some of your comments below. Sorry to have missed your > feedback. Thanks for the quick response. My comments below: >> * Wouldn't it make sense to forward 4xx/5xx RESPONSEs >> along the path upstream towards QNI even if no RII was >> originally included in the RESERVE? > > [JM]: We are in the middle of reworking out how/when/why errors are sent. > In order to protect from DoS attacks, a QNE should consider twice before > sending error messages upstream or downstream. Hmm. I'm not really sure about DoS attacks in this respect. With GIST and TLS below I don't see such a big risk. However, you're right: its always good to follow Jon Postel principle "Be liberal in what you accept, and conservative in what you send." On the other hand: in case the RESERVE carried an RII object, the QNE simply would send and forward such RESPONSES. >> * Sec. 5.4.3 says >> "The RESPONSE message is >> impotent, it does not cause any state to be installed or modified." >> >> I don't think that the above statement is correct: >> a) in case of a failure (the RESPONSE carries code >=300) a QNE >> will usually release any already allocated resources which >> is deletion of state. Is this not seen as modification? > > [JM]: Good point. > >> b) in case a RESPONSE indicates that there are less resources >> available downstream than requested by the RESERVE, a QNE >> may/should free some resources which is a state modification. > > [JM]: So you mean that QNEs that already made the reservation should free I had [min,max] reservations in mind.. Simple example: RESERVE requests at minimum 150kbit/s up to 500kbit/s bandwidth. Let's assume 500kbit/s are pre-allocated in this QNE, but a returning RESPONSE signals that only 300kbit/s could be reserved downstream along the path. If the QNE sees the response, it would usually free 200kbit/s which may be used by other reservations then. However, it actually depends on the policy of the QoS model. > those reservations? In general, yes, but a QoS model might have other > rules? Yes, but then this should be stated in this way: the specific action is up to the QoS model. But I would suggest to give an example what may happen. Currently, the draft description limits what a QoS model can do. >> * It is not possible to send back an error for a QUERY w/o RII. >> In this case one could only detect that there is no corresponding >> RESERVE after a while and retransmit. This should be documented. > > [JM]: I'm still discussing the use of QUERY messages with my co-authors. > I would see that all queries must have an RII. But then, how do simple > queries differ from ones intended to trigger a receiver-initiated > reservation... that is what I wonder mylsef... If QUERY has always an RII, IMHO the alternatives would be: a) a new message type (code) b) a flag in the common header Hmm, as you might know, I made a different suggestion for receiver-initiated reservations and mentioned to Andrew at the last meeting that the RESERVE-RI could also be sent hop by hop in some kind of bypassing mode instead of directly end-to-end. Actually, that's how we implemented it in our MARSP signaling protocol, because it has advantages with respect to signaling relationships and security. So the proposal is as follows: The receiver sends this RESERVE-RI to its next GIST hop towards the flow sender. Every GIST node / QNE would simply forward this RESERVE-RI. There is, however, no need to install any state (in the QoS NSLP), it's more like bypassing the node. If the RESERVE-RI arrives at the flow sender, it simply initiates a RESERVE (this is the analog to the receiver-initiated RESERVE triggered by the special QUERY) containing a BOUND_SESSION_ID, referring to the RESERVE-RI session. The receiver will handle the RESERVE as RESPONSE to its RESERVE-RI due to the matching BOUND_SESSION_ID. I see two advantages: a) RESERVE is always sender-initiated, which may simplify some things. b) The receiver doesn't have to worry about whether reverse path state was already installed before. >> * NOTIFY should also not alter any state. However, in case a notify >> signals a fatal error condition, state deletion may be a correct >> action (at least the state machine draft proposed this. If wrongly >> then we need clarification in the QoS NSLP draft). > > [JM]: I guess this depends on the QoS model? Yes, but then we should state that rather than stating that it has no effect at all. Like in the above case, an illustrating example what may happen would be also good here. >> * How should a node behave if it gets a RESPONSE with a non-matching >> RSN? >> >> Drop it silently? If so, then please add a clear statement in >> sec. 5.4.3. >> Currently, you could not send back an error message, because >> NOTIFY is defined as asynchronous message. > > [JM]: Dropping a "wierd" message would be the default action. This has > been added to my editor's copy for the forthcoming draft. Good. However, I think it's worth to mention this case explicitly. >> * Sec. 4.1 >> "Any node may include a request for a RESPONSE in its RESERVE >> messages. It does so by including a Request Identification >> Information (RII) object in the RESERVE message." >> >> One could clarify in sec. 4.1 and/or 5.3.2 that if an RII object is >> already included in a message, an interested QNE must not add an >> RII object, but may simply remember that RII to match the related >> RESPONSE it is interested in later. When it receives the RESPONSE, >> it forwards the RESPONSE upstream towards the RII originating node. > > [JM]: Good point. yet, there may emerge collisions with RIIs "shared" > between QNEs. Should we actually support some kind of stacked RIIs? Same > as we do for QSPECs already? No, I don't think it would be a good idea to stack RIIs. In the rare case of collisions, the QNI could immediately retry with another RII if we have an explicit 0x04 error for this. >> * RII conflict Error Msg >> It is said that the RII should be unique within a session and >> different for each message. However, I could imagine a scenario >> when a QNI sends a RESERVE message with a specific RII and some >> QNE also initiates a RESERVE with the same RII value for the same >> session simultaneously. The QNE may trigger this RESERVE in order >> to reserve resources along a new branch due of a route change. >> Ok, the probability may be really small, but one should be prepared >> for such things... >> So due to some event, a QNE will receive a message with an RII that is >> already in use. In this case it might be good to let the QNE send an >> error message back stating that there is an RII conflict, i.e. it is >> already in use. > > [JM]: Need to think about this some more... Mainly it specifies an action in case we have an RII conflict, which may be a rare event, but it may happen from time to time. I suggest to send a transient failure back, so the QNI can retry with another RII. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 07 03:48:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmyN-0004dA-Cu; Fri, 07 Oct 2005 03:48:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmyL-0004d2-A6 for nsis@megatron.ietf.org; Fri, 07 Oct 2005 03:48:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01746 for ; Fri, 7 Oct 2005 03:48:50 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENn7a-0000bd-7J for nsis@ietf.org; Fri, 07 Oct 2005 03:58:26 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j977mbh5023270; Fri, 7 Oct 2005 09:48:37 +0200 (MEST) Message-ID: <008d01c5cb13$871fc2f0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Roland Bless" , "Jukka MJ Manner" References: <43453AAA.9060407@tm.uka.de> <434570EB.7000901@tm.uka.de> Subject: Re: [NSIS] Re: Further open QoS NSLP issues Date: Fri, 7 Oct 2005 09:48:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.513 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 07 Oct 2005 09:48:41 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: andrew.mcdonald@roke.co.uk, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland and Jukka Below you can see my comments to your suggestions! ----- Original Message ----- From: "Roland Bless" To: "Jukka MJ Manner" Cc: ; Sent: Thursday, October 06, 2005 8:46 PM Subject: [NSIS] Re: Further open QoS NSLP issues -//- snip >>> b) in case a RESPONSE indicates that there are less resources >>> available downstream than requested by the RESERVE, a QNE >>> may/should free some resources which is a state modification. >> >> [JM]: So you mean that QNEs that already made the reservation should free > > I had [min,max] reservations in mind.. > Simple example: RESERVE requests at minimum 150kbit/s up to 500kbit/s > bandwidth. Let's assume 500kbit/s are pre-allocated in this QNE, but a > returning RESPONSE signals that only 300kbit/s could be reserved > downstream along the path. If the QNE sees the response, it would > usually free 200kbit/s which may be used by other reservations then. > However, it actually depends on the policy of the QoS model. > >> those reservations? In general, yes, but a QoS model might have other >> rules? > > Yes, but then this should be stated in this way: the specific action is > up to the QoS model. But I would suggest to give an example what may > happen. Currently, the draft description limits what a QoS model can do. [Georgios]: Agree, we will state that! > >>> * It is not possible to send back an error for a QUERY w/o RII. >>> In this case one could only detect that there is no corresponding >>> RESERVE after a while and retransmit. This should be documented. >> >> [JM]: I'm still discussing the use of QUERY messages with my co-authors. >> I would see that all queries must have an RII. But then, how do simple >> queries differ from ones intended to trigger a receiver-initiated >> reservation... that is what I wonder mylsef... > > If QUERY has always an RII, IMHO the alternatives would be: > a) a new message type (code) > b) a flag in the common header [Georgios]: I think that a flag in the common header will solve this problem! > > Hmm, as you might know, I made a different suggestion for > receiver-initiated reservations and mentioned to Andrew > at the last meeting that the RESERVE-RI could also be sent > hop by hop in some kind of bypassing mode instead of directly > end-to-end. Actually, that's how we implemented it in our MARSP > signaling protocol, because it has advantages with respect to > signaling relationships and security. So the proposal is as follows: > The receiver sends this RESERVE-RI to its next GIST hop towards > the flow sender. Every GIST node / QNE would simply forward > this RESERVE-RI. There is, however, no > need to install any state (in the QoS NSLP), it's more like bypassing > the node. If the RESERVE-RI arrives at the flow sender, it simply > initiates a RESERVE (this is the analog to the receiver-initiated > RESERVE triggered by the special QUERY) containing a BOUND_SESSION_ID, > referring to the RESERVE-RI session. The receiver will handle the > RESERVE as RESPONSE to its RESERVE-RI due to the matching > BOUND_SESSION_ID. > > I see two advantages: > a) RESERVE is always sender-initiated, which may simplify some things. > b) The receiver doesn't have to worry about whether reverse path > state was already installed before. [Georgios]: I think that your proposal can also be solved by a QUERY message in combination with a special QoS model! > >>> * NOTIFY should also not alter any state. However, in case a notify >>> signals a fatal error condition, state deletion may be a correct >>> action (at least the state machine draft proposed this. If wrongly >>> then we need clarification in the QoS NSLP draft). >> >> [JM]: I guess this depends on the QoS model? > > Yes, but then we should state that rather than stating that > it has no effect at all. Like in the above case, an illustrating > example what may happen would be also good here. [Georgios]: Agree on this! >>> * How should a node behave if it gets a RESPONSE with a non-matching >>> RSN? >>> >>> Drop it silently? If so, then please add a clear statement in >>> sec. 5.4.3. >>> Currently, you could not send back an error message, because >>> NOTIFY is defined as asynchronous message. >> >> [JM]: Dropping a "wierd" message would be the default action. This has >> been added to my editor's copy for the forthcoming draft. > > Good. However, I think it's worth to mention this case explicitly. [Georgios]: Agree >>> * Sec. 4.1 >>> "Any node may include a request for a RESPONSE in its RESERVE >>> messages. It does so by including a Request Identification >>> Information (RII) object in the RESERVE message." >>> >>> One could clarify in sec. 4.1 and/or 5.3.2 that if an RII object is >>> already included in a message, an interested QNE must not add an >>> RII object, but may simply remember that RII to match the related >>> RESPONSE it is interested in later. When it receives the RESPONSE, >>> it forwards the RESPONSE upstream towards the RII originating node. [Georgios]: Here I agree with Roland on this! We have to clarify it in the text! >> [JM]: Good point. yet, there may emerge collisions with RIIs "shared" >> between QNEs. Should we actually support some kind of stacked RIIs? Same >> as we do for QSPECs already? > > No, I don't think it would be a good idea to stack RIIs. > In the rare case of collisions, the QNI could immediately retry > with another RII if we have an explicit 0x04 error for this. [Georgios]: I agree that it is not a good idea to stack RIIs >>> * RII conflict Error Msg >>> It is said that the RII should be unique within a session and >>> different for each message. However, I could imagine a scenario >>> when a QNI sends a RESERVE message with a specific RII and some >>> QNE also initiates a RESERVE with the same RII value for the same >>> session simultaneously. The QNE may trigger this RESERVE in order >>> to reserve resources along a new branch due of a route change. >>> Ok, the probability may be really small, but one should be prepared >>> for such things... >>> So due to some event, a QNE will receive a message with an RII that is >>> already in use. In this case it might be good to let the QNE send an >>> error message back stating that there is an RII conflict, i.e. it is >>> already in use. >> >> [JM]: Need to think about this some more... > > Mainly it specifies an action in case we have an RII conflict, > which may be a rare event, but it may happen from time to time. > I suggest to send a transient failure back, so the QNI can > retry with another RII. [Georgios]: This is a good point! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 07 04:06:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENnFm-0001Ae-Jo; Fri, 07 Oct 2005 04:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENnFl-0001AS-2O for nsis@megatron.ietf.org; Fri, 07 Oct 2005 04:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02909 for ; Fri, 7 Oct 2005 04:06:50 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENnP0-0001cW-J7 for nsis@ietf.org; Fri, 07 Oct 2005 04:16:27 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9786mdx024535; Fri, 7 Oct 2005 10:06:48 +0200 (MEST) Message-ID: <00c601c5cb16$11550230$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Jukka MJ Manner" , "Tschofenig, Hannes" References: Subject: Re: AW: [NSIS] Re: authorizing query messages Date: Fri, 7 Oct 2005 10:06:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.511 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 07 Oct 2005 10:06:49 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: "McDonald, Andrew" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Hannes I also agree with Jukka on this point! Best Regards, Georgios ----- Original Message ----- From: "Jukka MJ Manner" To: "Tschofenig, Hannes" Cc: "McDonald, Andrew" ; "Georgios Karagiannis" ; Sent: Thursday, October 06, 2005 5:40 PM Subject: Re: AW: [NSIS] Re: authorizing query messages > > Hi, > > looks good to me, although you have a slight error in your figure: change > "QoS-Reserve" to "QoS-Query". :) > > Jukka > > On Thu, 6 Oct 2005, Tschofenig, Hannes wrote: > >> hi jukka, >> >> thanks for your feedback. here is a proposal how to handle authorization >> for the query message: >> >> the query message triggers a QAR with the authentication info but >> without any QoS-Resources. >> it might be necessary to indicate (somewhere) that this is only a query >> without the need to enable accounting and charging. >> >> as such, the response in the QAA is also limited to the result rather >> than returning information like avps like CC-Time,Cost, >> QoS-Resources,Authz-time). >> >> here is the figure: >> >> End-Host Network Element Entity >> requesting QoS ( Diameter ( Diameter >> QoS Client) QoS Server) >> | | | >> +---QoS-Query------>| | >> | +- - - - - QAR - - - - - >| >> | |(QoS-Resources=NULL, | >> | | QoS-Auth-Data,User-ID)| >> | | +--------+--------------+ >> | | | Authorize request | >> | | | Keep no session data | >> | | | | >> | | +--------+--------------+ >> | |< - - - - QAA - - - - - -+ >> | |(Result-Code) | >> | | | >> | +-------+---------+ >> | |Proceeed with | >> | |QoS signaling | >> | |exchange | >> | +-------+---------+ >> | | >> | +----------QoS-Reserve---------------> >> | | >> | |<---------QoS-Response--------------- >> |<--QoS-Response----+ >> >> >> ciao >> hannes >> >> > Hi, >> > >> > I would expect that in certain networks, not everybody may query the >> > network of available resources. Thus, there could be need to >> > include an >> > auhtorization token, or ask from a Diameter server whether the node >> > sending the query is allowed to do that. >> > >> > Cheers, >> > Jukka >> > >> > >> > On Thu, 6 Oct 2005, Hannes Tschofenig wrote: >> > >> > > hi all, >> > > >> > > as part of our work on the diameter-qos application and the >> > radius-qos draft >> > > we came across the aspect of authorizing individual types >> > of actions taken by >> > > the qos signaling protocol. from discussions in the past i >> > remember that >> > > people wanted to authorize query messages as well. when we >> > come to the >> > > concrete details we are not quite sure what it actually >> > means. what would be >> > > the authorization decision regarding the query message >> > people have in mind? >> > > >> > > ciao >> > > hannes >> > > >> > > >> > > >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 07 08:46:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrcY-0002bb-80; Fri, 07 Oct 2005 08:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrcW-0002bN-3O for nsis@megatron.ietf.org; Fri, 07 Oct 2005 08:46:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15583 for ; Fri, 7 Oct 2005 08:46:38 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENrln-0004Wo-6A for nsis@ietf.org; Fri, 07 Oct 2005 08:56:16 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j97CkZ7J012627 for ; Fri, 7 Oct 2005 14:46:35 +0200 (MEST) Message-ID: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: Date: Fri, 7 Oct 2005 14:46:30 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.518 () ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 07 Oct 2005 14:46:36 +0200 (MEST) X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [NSIS] remove packet_classifier object from QoS-NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749098148==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1749098148== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A0_01C5CB4D.E7A09BB0" This is a multi-part message in MIME format. ------=_NextPart_000_01A0_01C5CB4D.E7A09BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER object, in=20 our implementation, we have seen that the need of using such an object = for=20 filtering and packet classification is not needed. The main reason for that is that the RMF is responsible for = modifying/interacting with the packet classification function, see Figure 1 in QoS-NSLP draft. = Both=20 functions are not QoS-NSLP functions. Thus I do not understand why we have to generate such an object, since the QoS model, used in each node, should actually specify by using a = local policy on each node, which filters and how such filters must be used. Therefore I propose to remove the PACKET_CLASSIFIER from the=20 QOS-NSLP specification. Best regards, Georgios ------=_NextPart_000_01A0_01C5CB4D.E7A09BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all
 
After = trying to incorporate=20 the QoS-NSLP = PACKET_CLASSIFIER =20 object, in
our implementation,=20 we have seen=20 that the need of using such an = object for=20
filtering and packet classification is = not=20 needed.
 
The main reason for that is that the RMF is responsible for=20 modifying/interacting
with the packet classification function, see = Figure 1=20 in QoS-NSLP draft. Both
functions are=20 not QoS-NSLP functions.
Thus I do not understand why we have to = generate such=20 an object, since
the QoS model, used in each node, should = actually=20 specify by using a local policy on each node,
which filters=20 and how such filters must be used.
Therefore I=20 propose to remove the PACKET_CLASSIFIER from the
QOS-NSLP=20 specification.

 
Best regards,
Georgios
 
------=_NextPart_000_01A0_01C5CB4D.E7A09BB0-- --===============1749098148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1749098148==-- From nsis-bounces@ietf.org Fri Oct 07 10:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENt9Q-0002h6-3X; Fri, 07 Oct 2005 10:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENt9O-0002gV-5k; Fri, 07 Oct 2005 10:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21569; Fri, 7 Oct 2005 10:24:39 -0400 (EDT) Received: from smtp.ci.uc.pt ([193.136.200.57] helo=smtp-2-relay.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENtIe-0000bX-7V; Fri, 07 Oct 2005 10:34:19 -0400 Received: from smtp-2.ci.uc.pt (localhost [127.0.0.1]) by smtp-2-relay.ci.uc.pt (Postfix) with ESMTP id 76B0D192C78; Fri, 7 Oct 2005 15:24:18 +0100 (WEST) Received: from teste-d.ci.uc.pt (sendmail.uc.pt [193.136.200.162]) by smtp-2.ci.uc.pt (Postfix) with ESMTP id 1B0952FD008; Fri, 7 Oct 2005 15:24:18 +0100 (WEST) Received: from [192.168.0.119] (firewall.ismt.pt [212.13.37.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by teste-d.ci.uc.pt (Postfix) with ESMTP id B152C4A816C; Fri, 7 Oct 2005 15:24:08 +0100 (WEST) Message-ID: <43468500.9070606@dei.uc.pt> Date: Fri, 07 Oct 2005 15:24:00 +0100 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: nsis-imp@ietf.org, nsis@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [NSIS] NSIS Interop Meeting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2141920728==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============2141920728== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all,

Since only two implementations (different NSLPs) showed interest to participate in the Interop meeting in Coimbra, Portugal we decided not to held this event on the proposed date (October 24-25).

We are still available to host a future Interop meeting if the working group will need it.

Best regards,

Luís Cordeiro
http://www.dei.uc.pt
University of Coimbra
Portugal --===============2141920728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2141920728==-- From nsis-bounces@ietf.org Fri Oct 07 15:13:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxeh-0002M1-7x; Fri, 07 Oct 2005 15:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxef-0002Lt-Dd for nsis@megatron.ietf.org; Fri, 07 Oct 2005 15:13:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07416 for ; Fri, 7 Oct 2005 15:13:15 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENxnz-0004Lu-TS for nsis@ietf.org; Fri, 07 Oct 2005 15:22:57 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 07 Oct 2005 22:13:11 +0300 id 0008FD75.4346C8C7.0000116F Date: Fri, 7 Oct 2005 22:13:11 +0300 (EEST) From: Jukka MJ Manner To: Georgios Karagiannis Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP In-Reply-To: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, all, If people would rather see the packet classifier removed from the QoS-NSLP spec, then I would still like to see it defined in the QSPEC template. It would be good from an implementation point of view, and implementation effort, if there was a single suggestion on how to specify packet classifiers in QoS models. Still, I'd like to hear other views on what to do with the classifier. Cheers, Jukka On Fri, 7 Oct 2005, Georgios Karagiannis wrote: > Dear all > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER object, in > our implementation, we have seen that the need of using such an object for > filtering and packet classification is not needed. > > The main reason for that is that the RMF is responsible for modifying/interacting > with the packet classification function, see Figure 1 in QoS-NSLP draft. Both > functions are not QoS-NSLP functions. > Thus I do not understand why we have to generate such an object, since > the QoS model, used in each node, should actually specify by using a local policy on each node, > which filters and how such filters must be used. > Therefore I propose to remove the PACKET_CLASSIFIER from the > QOS-NSLP specification. > > > Best regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 07 15:14:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxfy-0002UY-1E; Fri, 07 Oct 2005 15:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxfw-0002UQ-Qg for nsis@megatron.ietf.org; Fri, 07 Oct 2005 15:14:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07505 for ; Fri, 7 Oct 2005 15:14:34 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENxpI-0004NB-FY for nsis@ietf.org; Fri, 07 Oct 2005 15:24:16 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 07 Oct 2005 22:14:35 +0300 id 0008FD7E.4346C91B.000016F6 Date: Fri, 7 Oct 2005 22:14:35 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org In-Reply-To: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [NSIS] Re-format the QoS-NSLP common header? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, I proposed earlier to re-format the COMMON HEADER The format of the COMMON HEADER seems wierd to me. The message type is 16 bits and can also hold flags? I would change this structure from [16-bit message type][16-bit flags] to [8-bit message type][8-bit message-specific flags][16-bit generic flags] Much cleaner to me, easier to parse, and leaves room for further enhancement through new flags, in my humble opinion. Do we really need 16-bits, to allow for 65535 different messages? We only have 4 now. AFAIK, Rob and Andrew have commented that this sounds like a good idea, and Georgios is somewhat against. Thus, currently, 3 people are humming for "for", and 1 is humming for "against". I'd like to hear more "humms". If I don't hear other "humms", I will deduce that there are no objections to make this change to the next draft. Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 07 16:43:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENz3n-0003pA-8B; Fri, 07 Oct 2005 16:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENz3l-0003ol-EM for nsis@megatron.ietf.org; Fri, 07 Oct 2005 16:43:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23687 for ; Fri, 7 Oct 2005 16:43:14 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENzD7-0003Yr-Jb for nsis@ietf.org; Fri, 07 Oct 2005 16:52:58 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j97KgZQT006680; Fri, 7 Oct 2005 22:42:35 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j97KgXRu026042; Fri, 7 Oct 2005 22:42:35 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Oct 2005 22:40:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] remove packet_classifier object from QoS-NSLP Date: Fri, 7 Oct 2005 22:40:30 +0200 Message-ID: Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXLc0yw2Q1TQ33MR/K3wU2Oq+KCqQACxMRw From: "Tschofenig, Hannes" To: "Jukka MJ Manner" , "Georgios Karagiannis" X-OriginalArrivalTime: 07 Oct 2005 20:40:30.0966 (UTC) FILETIME=[5BB2D960:01C5CB7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi jukka,=20 i do not understand why define information at the qos nslp that is = already available from the lower layer (gist).=20 in the natfw nslp we reuse the lower layer information. we only = discussed the ability to extend the mrm when it is not sufficient.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > Auftrag von Jukka MJ Manner > Gesendet: Freitag, 7. Oktober 2005 21:13 > An: Georgios Karagiannis > Cc: nsis@ietf.org > Betreff: Re: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 >=20 > Hi Georgios, all, >=20 > If people would rather see the packet classifier removed from=20 > the QoS-NSLP=20 > spec, then I would still like to see it defined in the QSPEC=20 > template. It=20 > would be good from an implementation point of view, and=20 > implementation=20 > effort, if there was a single suggestion on how to specify packet=20 > classifiers in QoS models. >=20 > Still, I'd like to hear other views on what to do with the classifier. >=20 > Cheers, > Jukka >=20 > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: >=20 > > Dear all > >=20 > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER =20 > object, in=20 > > our implementation, we have seen that the need of using=20 > such an object for=20 > > filtering and packet classification is not needed. > >=20 > > The main reason for that is that the RMF is responsible for=20 > modifying/interacting > > with the packet classification function, see Figure 1 in=20 > QoS-NSLP draft. Both=20 > > functions are not QoS-NSLP functions. > > Thus I do not understand why we have to generate such an=20 > object, since > > the QoS model, used in each node, should actually specify=20 > by using a local policy on each node, > > which filters and how such filters must be used. > > Therefore I propose to remove the PACKET_CLASSIFIER from the=20 > > QOS-NSLP specification. > >=20 > >=20 > > Best regards, > > Georgios > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 08 01:30:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO7I3-0001Ov-VK; Sat, 08 Oct 2005 01:30:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO7I2-0001Oe-1P; Sat, 08 Oct 2005 01:30:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18976; Sat, 8 Oct 2005 01:30:33 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO7RS-00045E-0J; Sat, 08 Oct 2005 01:40:19 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j985UTi3009021; Sat, 8 Oct 2005 08:30:29 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Oct 2005 08:30:29 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Oct 2005 08:30:28 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Oct 2005 08:30:25 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01141ED5@esebe100.NOE.Nokia.com> Thread-Topic: [Nsis-imp] NSIS Interop Meeting Thread-Index: AcXLS9KHn0kdV750SduGmGA5mqJSfAAfXhIQ To: , , X-OriginalArrivalTime: 08 Oct 2005 05:30:28.0572 (UTC) FILETIME=[648C79C0:01C5CBC9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Subject: [NSIS] RE: [Nsis-imp] NSIS Interop Meeting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Well, maybe we should tentatively plan something in the January = time-frame, if the various teams think that would be a better time ... =20 John ________________________________ From: nsis-imp-bounces@lists.ietf.org = [mailto:nsis-imp-bounces@lists.ietf.org] On Behalf Of ext Lu=EDs = Cordeiro Sent: 07 October, 2005 17:24 To: nsis-imp@ietf.org; nsis@ietf.org Subject: [Nsis-imp] NSIS Interop Meeting =09 =09 Hi all, =09 Since only two implementations (different NSLPs) showed interest to = participate in the Interop meeting in Coimbra, Portugal we decided not = to held this event on the proposed date (October 24-25). =09 We are still available to host a future Interop meeting if the working = group will need it. =09 Best regards, =09 Lu=EDs Cordeiro http://www.dei.uc.pt University of Coimbra Portugal=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Oct 09 18:55:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOk4S-00034m-Q4; Sun, 09 Oct 2005 18:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOk4P-00034W-LJ for nsis@megatron.ietf.org; Sun, 09 Oct 2005 18:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16759 for ; Sun, 9 Oct 2005 18:55:02 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOkE8-0000qp-Ah for nsis@ietf.org; Sun, 09 Oct 2005 19:05:12 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j99MsJL5016403; Sun, 9 Oct 2005 23:54:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RBBWC6GK; Sun, 9 Oct 2005 23:58:31 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Date: Sun, 9 Oct 2005 23:54:14 +0100 Message-ID: <01af01c5cd24$5fc88260$0302a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXNJPiJ6JL5Ej9FQzi/az7Jmd0ktA== From: "Hancock, Robert" To: "Tschofenig, Hannes" , "Jukka MJ Manner" , "Georgios Karagiannis" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1533999672==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1533999672== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CD24.F7CF4580" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CD24.F7CF4580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IIRC the issue (raised at the Munich interim) is that it may be that the MRI at the GIST level can't be constructed that exactly matches the packet classifier needed. there are two cases: - that the packet classifier needs to be more specific, i.e. taking into account more data than could ever be relevant for message routing. - that the packet classifier needs to be less specific. the particular example is where you want to do something like=20 rfc3175 where the only relevant part is the ingress/egress interface and DSCP. whether this data should be in the qos-nslp or qspec is less clear to me. the concept in my head has always been that the qos-nslp carried everything about *what* resource reservation action you wanted to carry out, and the qspec was about how much "stuff" you actually wanted to reserve. the packet classifier needs to be given in every message about a transaction, whereas the "how much" information only in some; and the classifier can probably be universal, whereas the qspec need not be. I don't see why having it in the qos-nslp is hard. r. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Tschofenig, Hannes > Sent: 07 October 2005 21:41 > To: Jukka MJ Manner; Georgios Karagiannis > Cc: nsis@ietf.org > Subject: AW: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 > hi jukka,=20 >=20 > i do not understand why define information at the qos nslp=20 > that is already available from the lower layer (gist).=20 > in the natfw nslp we reuse the lower layer information. we=20 > only discussed the ability to extend the mrm when it is not=20 > sufficient.=20 >=20 > ciao > hannes >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > > Auftrag von Jukka MJ Manner > > Gesendet: Freitag, 7. Oktober 2005 21:13 > > An: Georgios Karagiannis > > Cc: nsis@ietf.org > > Betreff: Re: [NSIS] remove packet_classifier object from QoS-NSLP > >=20 > >=20 > >=20 > > Hi Georgios, all, > >=20 > > If people would rather see the packet classifier removed from=20 > > the QoS-NSLP=20 > > spec, then I would still like to see it defined in the QSPEC=20 > > template. It=20 > > would be good from an implementation point of view, and=20 > > implementation=20 > > effort, if there was a single suggestion on how to specify packet=20 > > classifiers in QoS models. > >=20 > > Still, I'd like to hear other views on what to do with the=20 > classifier. > >=20 > > Cheers, > > Jukka > >=20 > > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: > >=20 > > > Dear all > > >=20 > > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER =20 > > object, in=20 > > > our implementation, we have seen that the need of using=20 > > such an object for=20 > > > filtering and packet classification is not needed. > > >=20 > > > The main reason for that is that the RMF is responsible for=20 > > modifying/interacting > > > with the packet classification function, see Figure 1 in=20 > > QoS-NSLP draft. Both=20 > > > functions are not QoS-NSLP functions. > > > Thus I do not understand why we have to generate such an=20 > > object, since > > > the QoS model, used in each node, should actually specify=20 > > by using a local policy on each node, > > > which filters and how such filters must be used. > > > Therefore I propose to remove the PACKET_CLASSIFIER from the=20 > > > QOS-NSLP specification. > > >=20 > > >=20 > > > Best regards, > > > Georgios > > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C5CD24.F7CF4580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] remove packet_classifier object from QoS-NSLP

IIRC the issue (raised at the Munich interim) is = that
it may be that the MRI at the GIST level can't be = constructed
that exactly matches the packet classifier needed. = there
are two cases:

- that the packet classifier needs to be more = specific, i.e.
taking into account more data than could ever be = relevant for
message routing.

- that the packet classifier needs to be less = specific. the
particular example is where you want to do something = like
rfc3175 where the only relevant part is the = ingress/egress
interface and DSCP.

whether this data should be in the qos-nslp or qspec = is less
clear to me. the concept in my head has always been = that the
qos-nslp carried everything about *what* resource = reservation
action you wanted to carry out, and the qspec was = about how
much "stuff" you actually wanted to = reserve. the packet classifier
needs to be given in every message about a = transaction, whereas
the "how much" information only in some; = and the classifier can
probably be universal, whereas the qspec need not be. = I don't
see why having it in the qos-nslp is hard.

r.

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of Tschofenig, Hannes
> Sent: 07 October 2005 21:41
> To: Jukka MJ Manner; Georgios Karagiannis
> Cc: nsis@ietf.org
> Subject: AW: [NSIS] remove packet_classifier = object from QoS-NSLP
>
>
> hi jukka,
>
> i do not understand why define information at = the qos nslp
> that is already available from the lower layer = (gist).
> in the natfw nslp we reuse the lower layer = information. we
> only discussed the ability to extend the mrm = when it is not
> sufficient.
>
> ciao
> hannes
>
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = Im
> > Auftrag von Jukka MJ Manner
> > Gesendet: Freitag, 7. Oktober 2005 = 21:13
> > An: Georgios Karagiannis
> > Cc: nsis@ietf.org
> > Betreff: Re: [NSIS] remove = packet_classifier object from QoS-NSLP
> >
> >
> >
> > Hi Georgios, all,
> >
> > If people would rather see the packet = classifier removed from
> > the QoS-NSLP
> > spec, then I would still like to see it = defined in the QSPEC
> > template. It
> > would be good from an implementation point = of view, and
> > implementation
> > effort, if there was a single suggestion on = how to specify packet
> > classifiers in QoS models.
> >
> > Still, I'd like to hear other views on what = to do with the
> classifier.
> >
> > Cheers,
> > Jukka
> >
> > On Fri, 7 Oct 2005, Georgios Karagiannis = wrote:
> >
> > > Dear all
> > >
> > > After trying to incorporate the = QoS-NSLP PACKET_CLASSIFIER 
> > object, in
> > > our implementation, we have seen that = the need of using
> > such an object for
> > > filtering and packet classification is = not needed.
> > >
> > > The main reason for that is that the = RMF is responsible for
> > modifying/interacting
> > > with the packet classification = function, see Figure 1 in
> > QoS-NSLP draft. Both
> > > functions are not QoS-NSLP = functions.
> > > Thus I do not understand why we have = to generate such an
> > object, since
> > > the QoS model, used in each node, = should actually specify
> > by using a local policy on each = node,
> > > which filters and how such filters = must be used.
> > > Therefore I propose to remove the = PACKET_CLASSIFIER from the
> > > QOS-NSLP specification.
> > >
> > >
> > > Best regards,
> > > Georgios
> > >
> >
> > = _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.or= g/mailman/listinfo/nsis
> >
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C5CD24.F7CF4580-- --===============1533999672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1533999672==-- From nsis-bounces@ietf.org Mon Oct 10 01:28:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOqDT-0002gZ-Uw; Mon, 10 Oct 2005 01:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOqDR-0002fl-R7 for nsis@megatron.ietf.org; Mon, 10 Oct 2005 01:28:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02295 for ; Mon, 10 Oct 2005 01:28:48 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOqNH-0000x2-0b for nsis@ietf.org; Mon, 10 Oct 2005 01:39:00 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j9A5SQSr025173; Mon, 10 Oct 2005 07:28:26 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j9A5SO5B012675; Mon, 10 Oct 2005 07:28:25 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j9A5SPl04670; Mon, 10 Oct 2005 07:28:25 +0200 (MEST) Date: Mon, 10 Oct 2005 07:28:25 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: robert.hancock@roke.co.uk, hannes.tschofenig@siemens.com, jmanner@cs.Helsinki.FI Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 10 Oct 2005 05:28:25 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <0BnnQqKI.1128922104.7170150.karagian@ewi.utwente.nl> In-Reply-To: <01af01c5cd24$5fc88260$0302a8c0@comm.ad.roke.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.502 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 10 Oct 2005 07:28:28 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert The problem is that the packet classifier functionality is strict associated with a QoS model. A PACKET_CLASSIFIER object specifies which filter should be used by the packet classifier functionlaity on filtering the user data packets. Suppose now that for the same session two qos models are used, one that goes end-to-end and the other one that goes edge to edge within a domain. Note that this is the case when stacking of QSPEC's is used. If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter information should this object contain, the filter information required by the end-to-end QoS model or the edge-to-edge QoS model? Best Regards, Georgios On 10/9/2005, "Hancock, Robert" wrote: >IIRC the issue (raised at the Munich interim) is that >it may be that the MRI at the GIST level can't be constructed >that exactly matches the packet classifier needed. there >are two cases: > >- that the packet classifier needs to be more specific, i.e. >taking into account more data than could ever be relevant for >message routing. > >- that the packet classifier needs to be less specific. the >particular example is where you want to do something like=20 >rfc3175 where the only relevant part is the ingress/egress >interface and DSCP. > >whether this data should be in the qos-nslp or qspec is less >clear to me. the concept in my head has always been that the >qos-nslp carried everything about *what* resource reservation >action you wanted to carry out, and the qspec was about how >much "stuff" you actually wanted to reserve. the packet classifier >needs to be given in every message about a transaction, whereas >the "how much" information only in some; and the classifier can >probably be universal, whereas the qspec need not be. I don't >see why having it in the qos-nslp is hard. > >r. > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >> Behalf Of Tschofenig, Hannes >> Sent: 07 October 2005 21:41 >> To: Jukka MJ Manner; Georgios Karagiannis >> Cc: nsis@ietf.org >> Subject: AW: [NSIS] remove packet_classifier object from QoS-NSLP >>=20 >>=20 >> hi jukka,=20 >>=20 >> i do not understand why define information at the qos nslp=20 >> that is already available from the lower layer (gist).=20 >> in the natfw nslp we reuse the lower layer information. we=20 >> only discussed the ability to extend the mrm when it is not=20 >> sufficient.=20 >>=20 >> ciao >> hannes >>=20 >>=20 >> > -----Urspr=FCngliche Nachricht----- >> > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 >> > Auftrag von Jukka MJ Manner >> > Gesendet: Freitag, 7. Oktober 2005 21:13 >> > An: Georgios Karagiannis >> > Cc: nsis@ietf.org >> > Betreff: Re: [NSIS] remove packet_classifier object from QoS-NSLP >> >=20 >> >=20 >> >=20 >> > Hi Georgios, all, >> >=20 >> > If people would rather see the packet classifier removed from=20 >> > the QoS-NSLP=20 >> > spec, then I would still like to see it defined in the QSPEC=20 >> > template. It=20 >> > would be good from an implementation point of view, and=20 >> > implementation=20 >> > effort, if there was a single suggestion on how to specify packet=20 >> > classifiers in QoS models. >> >=20 >> > Still, I'd like to hear other views on what to do with the=20 >> classifier. >> >=20 >> > Cheers, >> > Jukka >> >=20 >> > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: >> >=20 >> > > Dear all >> > >=20 >> > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER =20 >> > object, in=20 >> > > our implementation, we have seen that the need of using=20 >> > such an object for=20 >> > > filtering and packet classification is not needed. >> > >=20 >> > > The main reason for that is that the RMF is responsible for=20 >> > modifying/interacting >> > > with the packet classification function, see Figure 1 in=20 >> > QoS-NSLP draft. Both=20 >> > > functions are not QoS-NSLP functions. >> > > Thus I do not understand why we have to generate such an=20 >> > object, since >> > > the QoS model, used in each node, should actually specify=20 >> > by using a local policy on each node, >> > > which filters and how such filters must be used. >> > > Therefore I propose to remove the PACKET_CLASSIFIER from the=20 >> > > QOS-NSLP specification. >> > >=20 >> > >=20 >> > > Best regards, >> > > Georgios >> > >=20 >> >=20 >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >=20 >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 01:59:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOqgs-0006dV-9v; Mon, 10 Oct 2005 01:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOqgl-0006d3-Sx for nsis@megatron.ietf.org; Mon, 10 Oct 2005 01:59:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03735 for ; Mon, 10 Oct 2005 01:59:06 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOqqc-0001gO-0t for nsis@ietf.org; Mon, 10 Oct 2005 02:09:18 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9A5vbFb006011; Mon, 10 Oct 2005 14:57:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9A5vak16646; Mon, 10 Oct 2005 14:57:36 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id j9A5vW121319; Mon, 10 Oct 2005 14:57:33 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Date: Mon, 10 Oct 2005 13:55:04 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD6DEA5F@pslexc01.psl.local> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXNW4q2b6U8yZWaTeK1YOv43m5skAAALnaw From: "Cheng Hong" To: "Georgios Karagiannis" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, The scenario you raised is an important case to consider. However, I = would like to clarify if over the same section of the path, both of the = PACKET_CLASSIFIERs (end2end and edge2edge) would be used by the QNE at = the same time. For example, in the stacking case, path within a domain = probably would only be applicable with the edge2edge PACKET_CLASSIFIER = (and the end2end PACKET_CLASSIFIER would be transparent).=20 It seems to me that the QSPEC has to be associated with a = PACKET_CLASSIFIER object. This is to be interpreted by the RMF. Whether = the PACKET_CLASSIFIER object is to be included inside the QSPEC or as a = QoS-NSLP object it is up to discussion. There are advantage and = disadvantage for both options. Placing the PACKET_CLASSIFIER object as a = QoS-NSLP object has the advantage of being QoS model independent, which = means the nodes can process the information element without being QoS = model aware, e.g. at address boundaries nodes. Also, I tend to agree = with Robert's reasoning on the place of the object. For the QSPEC stacking case, the PACKET_CLASSIFIER object in the = QOS-NSLP could also be made stackable. Thus, the corresponding = PACKET_CLASSIFIER could correspond to the correct QSPEC. Implementation = wise, do you think this is feasible? Just my 2cents Cheng Hong =20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Georgios Karagiannis > Sent: Monday, October 10, 2005 1:28 PM > To: robert.hancock@roke.co.uk; hannes.tschofenig@siemens.com;=20 > jmanner@cs.Helsinki.FI > Cc: nsis@ietf.org > Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 > Hi Robert >=20 > The problem is that the packet classifier functionality is=20 > strict associated with a QoS model. A PACKET_CLASSIFIER=20 > object specifies which filter should be used by the packet=20 > classifier functionlaity on filtering the user data packets. > Suppose now that for the same session two qos models are=20 > used, one that goes end-to-end and the other one that goes=20 > edge to edge within a domain. Note that this is the case when=20 > stacking of QSPEC's is used. > If the PACKET_CLASSIFIER object is a QOS-NSLP object, which=20 > filter information should this object contain, the filter=20 > information required by the end-to-end QoS model or the=20 > edge-to-edge QoS model? >=20 > Best Regards, > Georgios >=20 >=20 >=20 > On 10/9/2005, "Hancock, Robert" wrote: >=20 > >IIRC the issue (raised at the Munich interim) is that it may be that=20 > >the MRI at the GIST level can't be constructed that exactly=20 > matches the=20 > >packet classifier needed. there are two cases: > > > >- that the packet classifier needs to be more specific, i.e. > >taking into account more data than could ever be relevant=20 > for message=20 > >routing. > > > >- that the packet classifier needs to be less specific. the=20 > particular=20 > >example is where you want to do something like > >rfc3175 where the only relevant part is the ingress/egress interface=20 > >and DSCP. > > > >whether this data should be in the qos-nslp or qspec is less=20 > clear to=20 > >me. the concept in my head has always been that the qos-nslp carried=20 > >everything about *what* resource reservation action you=20 > wanted to carry=20 > >out, and the qspec was about how much "stuff" you actually wanted to=20 > >reserve. the packet classifier needs to be given in every=20 > message about=20 > >a transaction, whereas the "how much" information only in=20 > some; and the=20 > >classifier can probably be universal, whereas the qspec need=20 > not be. I=20 > >don't see why having it in the qos-nslp is hard. > > > >r. > > > >> -----Original Message----- > >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > On Behalf=20 > >> Of Tschofenig, Hannes > >> Sent: 07 October 2005 21:41 > >> To: Jukka MJ Manner; Georgios Karagiannis > >> Cc: nsis@ietf.org > >> Subject: AW: [NSIS] remove packet_classifier object from QoS-NSLP > >>=20 > >>=20 > >> hi jukka, > >>=20 > >> i do not understand why define information at the qos nslp that is=20 > >> already available from the lower layer (gist). > >> in the natfw nslp we reuse the lower layer information. we only=20 > >> discussed the ability to extend the mrm when it is not sufficient. > >>=20 > >> ciao > >> hannes > >>=20 > >>=20 > >> > -----Urspr=FCngliche Nachricht----- > >> > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > >> > Auftrag von Jukka MJ Manner > >> > Gesendet: Freitag, 7. Oktober 2005 21:13 > >> > An: Georgios Karagiannis > >> > Cc: nsis@ietf.org > >> > Betreff: Re: [NSIS] remove packet_classifier object from QoS-NSLP > >> >=20 > >> >=20 > >> >=20 > >> > Hi Georgios, all, > >> >=20 > >> > If people would rather see the packet classifier removed=20 > from the=20 > >> > QoS-NSLP spec, then I would still like to see it defined in the=20 > >> > QSPEC template. It would be good from an implementation point of=20 > >> > view, and implementation effort, if there was a single=20 > suggestion=20 > >> > on how to specify packet classifiers in QoS models. > >> >=20 > >> > Still, I'd like to hear other views on what to do with the > >> classifier. > >> >=20 > >> > Cheers, > >> > Jukka > >> >=20 > >> > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: > >> >=20 > >> > > Dear all > >> > >=20 > >> > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER > >> > object, in > >> > > our implementation, we have seen that the need of using > >> > such an object for > >> > > filtering and packet classification is not needed. > >> > >=20 > >> > > The main reason for that is that the RMF is responsible for > >> > modifying/interacting > >> > > with the packet classification function, see Figure 1 in > >> > QoS-NSLP draft. Both > >> > > functions are not QoS-NSLP functions. > >> > > Thus I do not understand why we have to generate such an > >> > object, since > >> > > the QoS model, used in each node, should actually specify > >> > by using a local policy on each node, > >> > > which filters and how such filters must be used. > >> > > Therefore I propose to remove the PACKET_CLASSIFIER from the=20 > >> > > QOS-NSLP specification. > >> > >=20 > >> > >=20 > >> > > Best regards, > >> > > Georgios > >> > >=20 > >> >=20 > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> >=20 > >>=20 > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >>=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 02:20:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOr1Q-0000kM-PL; Mon, 10 Oct 2005 02:20:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOr1O-0000kD-CV for nsis@megatron.ietf.org; Mon, 10 Oct 2005 02:20:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17673 for ; Mon, 10 Oct 2005 02:20:24 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOrBE-00028G-Ka for nsis@ietf.org; Mon, 10 Oct 2005 02:30:37 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j9A6KKiN026821; Mon, 10 Oct 2005 08:20:20 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j9A6KH5B016822; Mon, 10 Oct 2005 08:20:17 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j9A6KIj05956; Mon, 10 Oct 2005 08:20:18 +0200 (MEST) Date: Mon, 10 Oct 2005 08:20:18 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: Hong.Cheng@sg.panasonic.com, robert.hancock@roke.co.uk, hannes.tschofenig@siemens.com, jmanner@cs.Helsinki.FI Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 10 Oct 2005 06:20:17 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <5F09D220B62F79418461A978CA0921BD6DEA5F@pslexc01.psl.local> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.477 () ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 10 Oct 2005 08:20:23 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: quoted-printable Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cheng Agree with you that the QSPEC has to be associated with a PACKET_CLASSIFIER object, then why not include the PACKET_CLASSIFIER object intothe QSPEC object? Best Regards, Georgios On 10/10/2005, "Cheng Hong" wrote: >Hi Georgios, > >The scenario you raised is an important case to consider. However, I would l= ike to clarify if over the same section of the path, both of the PACKET_CLASS= IFIERs (end2end and edge2edge) would be used by the QNE at the same time. For= example, in the stacking case, path within a domain probably would only be a= pplicable with the edge2edge PACKET_CLASSIFIER (and the end2end PACKET_CLASSI= FIER would be transparent). > >It seems to me that the QSPEC has to be associated with a PACKET_CLASSIFIER = object. This is to be interpreted by the RMF. Whether the PACKET_CLASSIFIER = object is to be included inside the QSPEC or as a QoS-NSLP object it is up to= discussion. There are advantage and disadvantage for both options. Placing t= he PACKET_CLASSIFIER object as a QoS-NSLP object has the advantage of being Q= oS model independent, which means the nodes can process the information eleme= nt without being QoS model aware, e.g. at address boundaries nodes. Also, I t= end to agree with Robert's reasoning on the place of the object. > >For the QSPEC stacking case, the PACKET_CLASSIFIER object in the QOS-NSLP co= uld also be made stackable. Thus, the corresponding PACKET_CLASSIFIER could c= orrespond to the correct QSPEC. Implementation wise, do you think this is fea= sible? > >Just my 2cents > >Cheng Hong > > > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of Georgios Karagiannis >> Sent: Monday, October 10, 2005 1:28 PM >> To: robert.hancock@roke.co.uk; hannes.tschofenig@siemens.com; >> jmanner@cs.Helsinki.FI >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP >> >> >> Hi Robert >> >> The problem is that the packet classifier functionality is >> strict associated with a QoS model. A PACKET_CLASSIFIER >> object specifies which filter should be used by the packet >> classifier functionlaity on filtering the user data packets. >> Suppose now that for the same session two qos models are >> used, one that goes end-to-end and the other one that goes >> edge to edge within a domain. Note that this is the case when >> stacking of QSPEC's is used. >> If the PACKET_CLASSIFIER object is a QOS-NSLP object, which >> filter information should this object contain, the filter >> information required by the end-to-end QoS model or the >> edge-to-edge QoS model? >> >> Best Regards, >> Georgios >> >> >> >> On 10/9/2005, "Hancock, Robert" wrote: >> >> >IIRC the issue (raised at the Munich interim) is that it may be that >> >the MRI at the GIST level can't be constructed that exactly >> matches the >> >packet classifier needed. there are two cases: >> > >> >- that the packet classifier needs to be more specific, i.e. >> >taking into account more data than could ever be relevant >> for message >> >routing. >> > >> >- that the packet classifier needs to be less specific. the >> particular >> >example is where you want to do something like >> >rfc3175 where the only relevant part is the ingress/egress interface >> >and DSCP. >> > >> >whether this data should be in the qos-nslp or qspec is less >> clear to >> >me. the concept in my head has always been that the qos-nslp carried >> >everything about *what* resource reservation action you >> wanted to carry >> >out, and the qspec was about how much "stuff" you actually wanted to >> >reserve. the packet classifier needs to be given in every >> message about >> >a transaction, whereas the "how much" information only in >> some; and the >> >classifier can probably be universal, whereas the qspec need >> not be. I >> >don't see why having it in the qos-nslp is hard. >> > >> >r. >> > >> >> -----Original Message----- >> >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >> On Behalf >> >> Of Tschofenig, Hannes >> >> Sent: 07 October 2005 21:41 >> >> To: Jukka MJ Manner; Georgios Karagiannis >> >> Cc: nsis@ietf.org >> >> Subject: AW: [NSIS] remove packet_classifier object from QoS-NSLP >> >> >> >> >> >> hi jukka, >> >> >> >> i do not understand why define information at the qos nslp that is >> >> already available from the lower layer (gist). >> >> in the natfw nslp we reuse the lower layer information. we only >> >> discussed the ability to extend the mrm when it is not sufficient. >> >> >> >> ciao >> >> hannes >> >> >> >> >> >> > -----Urspr=FCngliche Nachricht----- >> >> > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im >> >> > Auftrag von Jukka MJ Manner >> >> > Gesendet: Freitag, 7. Oktober 2005 21:13 >> >> > An: Georgios Karagiannis >> >> > Cc: nsis@ietf.org >> >> > Betreff: Re: [NSIS] remove packet_classifier object from QoS-NSLP >> >> > >> >> > >> >> > >> >> > Hi Georgios, all, >> >> > >> >> > If people would rather see the packet classifier removed >> from the >> >> > QoS-NSLP spec, then I would still like to see it defined in the >> >> > QSPEC template. It would be good from an implementation point of >> >> > view, and implementation effort, if there was a single >> suggestion >> >> > on how to specify packet classifiers in QoS models. >> >> > >> >> > Still, I'd like to hear other views on what to do with the >> >> classifier. >> >> > >> >> > Cheers, >> >> > Jukka >> >> > >> >> > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: >> >> > >> >> > > Dear all >> >> > > >> >> > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER >> >> > object, in >> >> > > our implementation, we have seen that the need of using >> >> > such an object for >> >> > > filtering and packet classification is not needed. >> >> > > >> >> > > The main reason for that is that the RMF is responsible for >> >> > modifying/interacting >> >> > > with the packet classification function, see Figure 1 in >> >> > QoS-NSLP draft. Both >> >> > > functions are not QoS-NSLP functions. >> >> > > Thus I do not understand why we have to generate such an >> >> > object, since >> >> > > the QoS model, used in each node, should actually specify >> >> > by using a local policy on each node, >> >> > > which filters and how such filters must be used. >> >> > > Therefore I propose to remove the PACKET_CLASSIFIER from the >> >> > > QOS-NSLP specification. >> >> > > >> >> > > >> >> > > Best regards, >> >> > > Georgios >> >> > > >> >> > >> >> > _______________________________________________ >> >> > nsis mailing list >> >> > nsis@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> > >> >> >> >> _______________________________________________ >> >> nsis mailing list >> >> nsis@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 02:59:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOrdW-0006sj-7F; Mon, 10 Oct 2005 02:59:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOrdU-0006qy-DR for nsis@megatron.ietf.org; Mon, 10 Oct 2005 02:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20751 for ; Mon, 10 Oct 2005 02:59:46 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOrnK-0003IZ-VI for nsis@ietf.org; Mon, 10 Oct 2005 03:09:59 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9A6xOFb015035; Mon, 10 Oct 2005 15:59:24 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9A6xNk03309; Mon, 10 Oct 2005 15:59:23 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id j9A6xM013475; Mon, 10 Oct 2005 15:59:22 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Date: Mon, 10 Oct 2005 14:56:41 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD6DEA84@pslexc01.psl.local> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXNYl4zN2qcgDBvQKGeJvzZP1QWRAAA8mQw From: "Cheng Hong" To: "Georgios Karagiannis" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, As described in the previous email, there are advantage and disadvantage = for doing that. The disadvantage of including the PACKET_CLASSIFIER = object into the QSPEC is that the NSIS node needs to be specific = QOS-Model aware to process the packet classification information. This = will be a hard requirement for the address boundary nodes to meet, e.g. = NAT. Having that object in NSLP layer or NTLP layer will make it easier. = Where to place the information element is a trade off between different = implementation aspects. It just seems that this aspects leads to placing = PACKET_CLASSIFIER outside of the QSPEC. Personally, I don't have strong = preference of where to place it.=20 cheers Cheng Hong =20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Monday, October 10, 2005 2:20 PM > To: Cheng Hong; robert.hancock@roke.co.uk;=20 > hannes.tschofenig@siemens.com; jmanner@cs.Helsinki.FI > Cc: nsis@ietf.org > Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 > Hi Cheng >=20 > Agree with you that the QSPEC has to be associated with a=20 > PACKET_CLASSIFIER object, then why not include the=20 > PACKET_CLASSIFIER object intothe QSPEC object? >=20 > Best Regards, > Georgios >=20 > On 10/10/2005, "Cheng Hong" wrote: >=20 > >Hi Georgios, > > > >The scenario you raised is an important case to consider.=20 > However, I would like to clarify if over the same section of=20 > the path, both of the PACKET_CLASSIFIERs (end2end and=20 > edge2edge) would be used by the QNE at the same time. For=20 > example, in the stacking case, path within a domain probably=20 > would only be applicable with the edge2edge PACKET_CLASSIFIER=20 > (and the end2end PACKET_CLASSIFIER would be transparent). > > > >It seems to me that the QSPEC has to be associated with a=20 > PACKET_CLASSIFIER object. This is to be interpreted by the=20 > RMF. Whether the PACKET_CLASSIFIER object is to be included=20 > inside the QSPEC or as a QoS-NSLP object it is up to=20 > discussion. There are advantage and disadvantage for both=20 > options. Placing the PACKET_CLASSIFIER object as a QoS-NSLP=20 > object has the advantage of being QoS model independent,=20 > which means the nodes can process the information element=20 > without being QoS model aware, e.g. at address boundaries=20 > nodes. Also, I tend to agree with Robert's reasoning on the=20 > place of the object. > > > >For the QSPEC stacking case, the PACKET_CLASSIFIER object in=20 > the QOS-NSLP could also be made stackable. Thus, the=20 > corresponding PACKET_CLASSIFIER could correspond to the=20 > correct QSPEC. Implementation wise, do you think this is feasible? > > > >Just my 2cents > > > >Cheng Hong > > > > > > > >> -----Original Message----- > >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > On Behalf=20 > >> Of Georgios Karagiannis > >> Sent: Monday, October 10, 2005 1:28 PM > >> To: robert.hancock@roke.co.uk; hannes.tschofenig@siemens.com;=20 > >> jmanner@cs.Helsinki.FI > >> Cc: nsis@ietf.org > >> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > >> > >> > >> Hi Robert > >> > >> The problem is that the packet classifier functionality is strict=20 > >> associated with a QoS model. A PACKET_CLASSIFIER object specifies=20 > >> which filter should be used by the packet classifier=20 > functionlaity on=20 > >> filtering the user data packets. > >> Suppose now that for the same session two qos models are used, one=20 > >> that goes end-to-end and the other one that goes edge to=20 > edge within=20 > >> a domain. Note that this is the case when stacking of QSPEC's is=20 > >> used. > >> If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter=20 > >> information should this object contain, the filter information=20 > >> required by the end-to-end QoS model or the edge-to-edge QoS model? > >> > >> Best Regards, > >> Georgios > >> > >> > >> > >> On 10/9/2005, "Hancock, Robert" wrote: > >> > >> >IIRC the issue (raised at the Munich interim) is that it=20 > may be that=20 > >> >the MRI at the GIST level can't be constructed that exactly > >> matches the > >> >packet classifier needed. there are two cases: > >> > > >> >- that the packet classifier needs to be more specific, i.e. > >> >taking into account more data than could ever be relevant > >> for message > >> >routing. > >> > > >> >- that the packet classifier needs to be less specific. the > >> particular > >> >example is where you want to do something like > >> >rfc3175 where the only relevant part is the=20 > ingress/egress interface=20 > >> >and DSCP. > >> > > >> >whether this data should be in the qos-nslp or qspec is less > >> clear to > >> >me. the concept in my head has always been that the=20 > qos-nslp carried=20 > >> >everything about *what* resource reservation action you > >> wanted to carry > >> >out, and the qspec was about how much "stuff" you=20 > actually wanted to=20 > >> >reserve. the packet classifier needs to be given in every > >> message about > >> >a transaction, whereas the "how much" information only in > >> some; and the > >> >classifier can probably be universal, whereas the qspec need > >> not be. I > >> >don't see why having it in the qos-nslp is hard. > >> > > >> >r. > >> > > >> >> -----Original Message----- > >> >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] > >> On Behalf > >> >> Of Tschofenig, Hannes > >> >> Sent: 07 October 2005 21:41 > >> >> To: Jukka MJ Manner; Georgios Karagiannis > >> >> Cc: nsis@ietf.org > >> >> Subject: AW: [NSIS] remove packet_classifier object=20 > from QoS-NSLP > >> >> > >> >> > >> >> hi jukka, > >> >> > >> >> i do not understand why define information at the qos=20 > nslp that is=20 > >> >> already available from the lower layer (gist). > >> >> in the natfw nslp we reuse the lower layer information. we only=20 > >> >> discussed the ability to extend the mrm when it is not=20 > sufficient. > >> >> > >> >> ciao > >> >> hannes > >> >> > >> >> > >> >> > -----Urspr=FCngliche Nachricht----- > >> >> > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > >> >> > Auftrag von Jukka MJ Manner > >> >> > Gesendet: Freitag, 7. Oktober 2005 21:13 > >> >> > An: Georgios Karagiannis > >> >> > Cc: nsis@ietf.org > >> >> > Betreff: Re: [NSIS] remove packet_classifier object from=20 > >> >> > QoS-NSLP > >> >> > > >> >> > > >> >> > > >> >> > Hi Georgios, all, > >> >> > > >> >> > If people would rather see the packet classifier removed > >> from the > >> >> > QoS-NSLP spec, then I would still like to see it=20 > defined in the=20 > >> >> > QSPEC template. It would be good from an=20 > implementation point of=20 > >> >> > view, and implementation effort, if there was a single > >> suggestion > >> >> > on how to specify packet classifiers in QoS models. > >> >> > > >> >> > Still, I'd like to hear other views on what to do with the > >> >> classifier. > >> >> > > >> >> > Cheers, > >> >> > Jukka > >> >> > > >> >> > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: > >> >> > > >> >> > > Dear all > >> >> > > > >> >> > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER > >> >> > object, in > >> >> > > our implementation, we have seen that the need of using > >> >> > such an object for > >> >> > > filtering and packet classification is not needed. > >> >> > > > >> >> > > The main reason for that is that the RMF is responsible for > >> >> > modifying/interacting > >> >> > > with the packet classification function, see Figure 1 in > >> >> > QoS-NSLP draft. Both > >> >> > > functions are not QoS-NSLP functions. > >> >> > > Thus I do not understand why we have to generate such an > >> >> > object, since > >> >> > > the QoS model, used in each node, should actually specify > >> >> > by using a local policy on each node, > >> >> > > which filters and how such filters must be used. > >> >> > > Therefore I propose to remove the PACKET_CLASSIFIER=20 > from the=20 > >> >> > > QOS-NSLP specification. > >> >> > > > >> >> > > > >> >> > > Best regards, > >> >> > > Georgios > >> >> > > > >> >> > > >> >> > _______________________________________________ > >> >> > nsis mailing list > >> >> > nsis@ietf.org > >> >> > https://www1.ietf.org/mailman/listinfo/nsis > >> >> > > >> >> > >> >> _______________________________________________ > >> >> nsis mailing list > >> >> nsis@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/nsis > >> >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 03:03:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOrgx-0007VH-TM; Mon, 10 Oct 2005 03:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOrgu-0007V4-04 for nsis@megatron.ietf.org; Mon, 10 Oct 2005 03:03:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20952 for ; Mon, 10 Oct 2005 03:03:18 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOrqk-0003OZ-Ll for nsis@ietf.org; Mon, 10 Oct 2005 03:13:31 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j9A72rcE022592; Mon, 10 Oct 2005 16:02:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j9A72sF23476; Mon, 10 Oct 2005 16:02:54 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id j9A72s525989; Mon, 10 Oct 2005 16:02:54 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml22) id j9A72sk05773; Mon, 10 Oct 2005 16:02:54 +0900 (JST) Received: from [10.179.71.70] by soml22.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j9A72n905729; Mon, 10 Oct 2005 16:02:49 +0900 (JST) Date: Mon, 10 Oct 2005 16:02:50 +0900 From: Takako Sanda To: Georgios Karagiannis , "nsis@ietf.org" Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP In-Reply-To: References: <5F09D220B62F79418461A978CA0921BD6DEA5F@pslexc01.psl.local> Message-Id: <20051010155057.9553.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Cc: hannes.tschofenig@siemens.com, jmanner@cs.Helsinki.FI, Hong.Cheng@sg.panasonic.com, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, As Robert said the MRI at the GIST wouldn't be enough to generate a packet classifier. Therefore, the object for packet classifier other than MRI will be necessary. However, as Hannes said NAT traversal issue is unavoidable. Thus we also need to consider where should be the best place the object is placed. BR, Takako On Mon, 10 Oct 2005 08:20:18 +0200 (MEST) Georgios Karagiannis wrote: > > Hi Cheng > > Agree with you that the QSPEC has to be associated with a > PACKET_CLASSIFIER object, then why not include the PACKET_CLASSIFIER > object intothe QSPEC object? > > Best Regards,e > Georgios > > On 10/10/2005, "Cheng Hong" wrote: > > >Hi Georgios, > > > >The scenario you raised is an important case to consider. However, I would like to clarify if over the same section of the path, both of the PACKET_CLASSIFIERs (end2end and edge2edge) would be used by the QNE at the same time. For example, in the stacking case, path within a domain probably would only be applicable with the edge2edge PACKET_CLASSIFIER (and the end2end PACKET_CLASSIFIER would be transparent). > > > >It seems to me that the QSPEC has to be associated with a PACKET_CLASSIFIER object. This is to be interpreted by the RMF. Whether the PACKET_CLASSIFIER object is to be included inside the QSPEC or as a QoS-NSLP object it is up to discussion. There are advantage and disadvantage for both options. Placing the PACKET_CLASSIFIER object as a QoS-NSLP object has the advantage of being QoS model independent, which means the nodes can process the information element without being QoS model aware, e.g. at address boundaries nodes. Also, I tend to agree with Robert's reasoning on the place of the object. > > > >For the QSPEC stacking case, the PACKET_CLASSIFIER object in the QOS-NSLP could also be made stackable. Thus, the corresponding PACKET_CLASSIFIER could correspond to the correct QSPEC. Implementation wise, do you think this is feasible? > > > >Just my 2cents > > > >Cheng Hong > > > > > > > >> -----Original Message----- > >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > >> Behalf Of Georgios Karagiannis > >> Sent: Monday, October 10, 2005 1:28 PM > >> To: robert.hancock@roke.co.uk; hannes.tschofenig@siemens.com; > >> jmanner@cs.Helsinki.FI > >> Cc: nsis@ietf.org > >> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > >> > >> > >> Hi Robert > >> > >> The problem is that the packet classifier functionality is > >> strict associated with a QoS model. A PACKET_CLASSIFIER > >> object specifies which filter should be used by the packet > >> classifier functionlaity on filtering the user data packets. > >> Suppose now that for the same session two qos models are > >> used, one that goes end-to-end and the other one that goes > >> edge to edge within a domain. Note that this is the case when > >> stacking of QSPEC's is used. > >> If the PACKET_CLASSIFIER object is a QOS-NSLP object, which > >> filter information should this object contain, the filter > >> information required by the end-to-end QoS model or the > >> edge-to-edge QoS model? > >> > >> Best Regards, > >> Georgios > >> > >> > >> > >> On 10/9/2005, "Hancock, Robert" wrote: > >> > >> >IIRC the issue (raised at the Munich interim) is that it may be that > >> >the MRI at the GIST level can't be constructed that exactly > >> matches the > >> >packet classifier needed. there are two cases: > >> > > >> >- that the packet classifier needs to be more specific, i.e. > >> >taking into account more data than could ever be relevant > >> for message > >> >routing. > >> > > >> >- that the packet classifier needs to be less specific. the > >> particular > >> >example is where you want to do something like > >> >rfc3175 where the only relevant part is the ingress/egress interface > >> >and DSCP. > >> > > >> >whether this data should be in the qos-nslp or qspec is less > >> clear to > >> >me. the concept in my head has always been that the qos-nslp carried > >> >everything about *what* resource reservation action you > >> wanted to carry > >> >out, and the qspec was about how much "stuff" you actually wanted to > >> >reserve. the packet classifier needs to be given in every > >> message about > >> >a transaction, whereas the "how much" information only in > >> some; and the > >> >classifier can probably be universal, whereas the qspec need > >> not be. I > >> >don't see why having it in the qos-nslp is hard. > >> > > >> >r. > >> > > >> >> -----Original Message----- > >> >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] > >> On Behalf > >> >> Of Tschofenig, Hannes > >> >> Sent: 07 October 2005 21:41 > >> >> To: Jukka MJ Manner; Georgios Karagiannis > >> >> Cc: nsis@ietf.org > >> >> Subject: AW: [NSIS] remove packet_classifier object from QoS-NSLP > >> >> > >> >> > >> >> hi jukka, > >> >> > >> >> i do not understand why define information at the qos nslp that is > >> >> already available from the lower layer (gist). > >> >> in the natfw nslp we reuse the lower layer information. we only > >> >> discussed the ability to extend the mrm when it is not sufficient. > >> >> > >> >> ciao > >> >> hannes > >> >> > >> >> > >> >> > -----Urspr|ngliche Nachricht----- > >> >> > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im > >> >> > Auftrag von Jukka MJ Manner > >> >> > Gesendet: Freitag, 7. Oktober 2005 21:13 > >> >> > An: Georgios Karagiannis > >> >> > Cc: nsis@ietf.org > >> >> > Betreff: Re: [NSIS] remove packet_classifier object from QoS-NSLP > >> >> > > >> >> > > >> >> > > >> >> > Hi Georgios, all, > >> >> > > >> >> > If people would rather see the packet classifier removed > >> from the > >> >> > QoS-NSLP spec, then I would still like to see it defined in the > >> >> > QSPEC template. It would be good from an implementation point of > >> >> > view, and implementation effort, if there was a single > >> suggestion > >> >> > on how to specify packet classifiers in QoS models. > >> >> > > >> >> > Still, I'd like to hear other views on what to do with the > >> >> classifier. > >> >> > > >> >> > Cheers, > >> >> > Jukka > >> >> > > >> >> > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: > >> >> > > >> >> > > Dear all > >> >> > > > >> >> > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER > >> >> > object, in > >> >> > > our implementation, we have seen that the need of using > >> >> > such an object for > >> >> > > filtering and packet classification is not needed. > >> >> > > > >> >> > > The main reason for that is that the RMF is responsible for > >> >> > modifying/interacting > >> >> > > with the packet classification function, see Figure 1 in > >> >> > QoS-NSLP draft. Both > >> >> > > functions are not QoS-NSLP functions. > >> >> > > Thus I do not understand why we have to generate such an > >> >> > object, since > >> >> > > the QoS model, used in each node, should actually specify > >> >> > by using a local policy on each node, > >> >> > > which filters and how such filters must be used. > >> >> > > Therefore I propose to remove the PACKET_CLASSIFIER from the > >> >> > > QOS-NSLP specification. > >> >> > > > >> >> > > > >> >> > > Best regards, > >> >> > > Georgios > >> >> > > > >> >> > > >> >> > _______________________________________________ > >> >> > nsis mailing list > >> >> > nsis@ietf.org > >> >> > https://www1.ietf.org/mailman/listinfo/nsis > >> >> > > >> >> > >> >> _______________________________________________ > >> >> nsis mailing list > >> >> nsis@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/nsis > >> >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 05:17:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOtms-0003PY-3w; Mon, 10 Oct 2005 05:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOtmp-0003PQ-24 for nsis@megatron.ietf.org; Mon, 10 Oct 2005 05:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26862 for ; Mon, 10 Oct 2005 05:17:32 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOtwe-0006ss-U8 for nsis@ietf.org; Mon, 10 Oct 2005 05:27:47 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9A9HPmA007922; Mon, 10 Oct 2005 11:17:26 +0200 (MEST) Message-ID: <00b701c5cd7b$6e8db7a0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Cheng Hong" , , , References: <5F09D220B62F79418461A978CA0921BD6DEA84@pslexc01.psl.local> Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP Date: Mon, 10 Oct 2005 11:17:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.52 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 10 Oct 2005 11:17:29 +0200 (MEST) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id j9A9HPmA007922 X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cheng The main disadvantage, of not including this object in the QSPEC, is that the PACKET_CLASSIFIER object in the QOS-NSLP should be made=20 stackable. Do we want this? Best Regards, Georgios ----- Original Message -----=20 From: "Cheng Hong" To: "Georgios Karagiannis" ;=20 ; ;=20 Cc: Sent: Monday, October 10, 2005 8:56 AM Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > Hi Georgios, > > As described in the previous email, there are advantage and disadvantag= e=20 > for doing that. The disadvantage of including the PACKET_CLASSIFIER obj= ect=20 > into the QSPEC is that the NSIS node needs to be specific QOS-Model awa= re=20 > to process the packet classification information. This will be a hard=20 > requirement for the address boundary nodes to meet, e.g. NAT. Having th= at=20 > object in NSLP layer or NTLP layer will make it easier. Where to place = the=20 > information element is a trade off between different implementation=20 > aspects. It just seems that this aspects leads to placing=20 > PACKET_CLASSIFIER outside of the QSPEC. Personally, I don't have strong= =20 > preference of where to place it. > > cheers > > Cheng Hong > > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Monday, October 10, 2005 2:20 PM >> To: Cheng Hong; robert.hancock@roke.co.uk; >> hannes.tschofenig@siemens.com; jmanner@cs.Helsinki.FI >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP >> >> >> Hi Cheng >> >> Agree with you that the QSPEC has to be associated with a >> PACKET_CLASSIFIER object, then why not include the >> PACKET_CLASSIFIER object intothe QSPEC object? >> >> Best Regards, >> Georgios >> >> On 10/10/2005, "Cheng Hong" wrote: >> >> >Hi Georgios, >> > >> >The scenario you raised is an important case to consider. >> However, I would like to clarify if over the same section of >> the path, both of the PACKET_CLASSIFIERs (end2end and >> edge2edge) would be used by the QNE at the same time. For >> example, in the stacking case, path within a domain probably >> would only be applicable with the edge2edge PACKET_CLASSIFIER >> (and the end2end PACKET_CLASSIFIER would be transparent). >> > >> >It seems to me that the QSPEC has to be associated with a >> PACKET_CLASSIFIER object. This is to be interpreted by the >> RMF. Whether the PACKET_CLASSIFIER object is to be included >> inside the QSPEC or as a QoS-NSLP object it is up to >> discussion. There are advantage and disadvantage for both >> options. Placing the PACKET_CLASSIFIER object as a QoS-NSLP >> object has the advantage of being QoS model independent, >> which means the nodes can process the information element >> without being QoS model aware, e.g. at address boundaries >> nodes. Also, I tend to agree with Robert's reasoning on the >> place of the object. >> > >> >For the QSPEC stacking case, the PACKET_CLASSIFIER object in >> the QOS-NSLP could also be made stackable. Thus, the >> corresponding PACKET_CLASSIFIER could correspond to the >> correct QSPEC. Implementation wise, do you think this is feasible? >> > >> >Just my 2cents >> > >> >Cheng Hong >> > >> > >> > >> >> -----Original Message----- >> >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >> On Behalf >> >> Of Georgios Karagiannis >> >> Sent: Monday, October 10, 2005 1:28 PM >> >> To: robert.hancock@roke.co.uk; hannes.tschofenig@siemens.com; >> >> jmanner@cs.Helsinki.FI >> >> Cc: nsis@ietf.org >> >> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP >> >> >> >> >> >> Hi Robert >> >> >> >> The problem is that the packet classifier functionality is strict >> >> associated with a QoS model. A PACKET_CLASSIFIER object specifies >> >> which filter should be used by the packet classifier >> functionlaity on >> >> filtering the user data packets. >> >> Suppose now that for the same session two qos models are used, one >> >> that goes end-to-end and the other one that goes edge to >> edge within >> >> a domain. Note that this is the case when stacking of QSPEC's is >> >> used. >> >> If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter >> >> information should this object contain, the filter information >> >> required by the end-to-end QoS model or the edge-to-edge QoS model? >> >> >> >> Best Regards, >> >> Georgios >> >> >> >> >> >> >> >> On 10/9/2005, "Hancock, Robert" wrote: >> >> >> >> >IIRC the issue (raised at the Munich interim) is that it >> may be that >> >> >the MRI at the GIST level can't be constructed that exactly >> >> matches the >> >> >packet classifier needed. there are two cases: >> >> > >> >> >- that the packet classifier needs to be more specific, i.e. >> >> >taking into account more data than could ever be relevant >> >> for message >> >> >routing. >> >> > >> >> >- that the packet classifier needs to be less specific. the >> >> particular >> >> >example is where you want to do something like >> >> >rfc3175 where the only relevant part is the >> ingress/egress interface >> >> >and DSCP. >> >> > >> >> >whether this data should be in the qos-nslp or qspec is less >> >> clear to >> >> >me. the concept in my head has always been that the >> qos-nslp carried >> >> >everything about *what* resource reservation action you >> >> wanted to carry >> >> >out, and the qspec was about how much "stuff" you >> actually wanted to >> >> >reserve. the packet classifier needs to be given in every >> >> message about >> >> >a transaction, whereas the "how much" information only in >> >> some; and the >> >> >classifier can probably be universal, whereas the qspec need >> >> not be. I >> >> >don't see why having it in the qos-nslp is hard. >> >> > >> >> >r. >> >> > >> >> >> -----Original Message----- >> >> >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >> >> On Behalf >> >> >> Of Tschofenig, Hannes >> >> >> Sent: 07 October 2005 21:41 >> >> >> To: Jukka MJ Manner; Georgios Karagiannis >> >> >> Cc: nsis@ietf.org >> >> >> Subject: AW: [NSIS] remove packet_classifier object >> from QoS-NSLP >> >> >> >> >> >> >> >> >> hi jukka, >> >> >> >> >> >> i do not understand why define information at the qos >> nslp that is >> >> >> already available from the lower layer (gist). >> >> >> in the natfw nslp we reuse the lower layer information. we only >> >> >> discussed the ability to extend the mrm when it is not >> sufficient. >> >> >> >> >> >> ciao >> >> >> hannes >> >> >> >> >> >> >> >> >> > -----Urspr=FCngliche Nachricht----- >> >> >> > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im >> >> >> > Auftrag von Jukka MJ Manner >> >> >> > Gesendet: Freitag, 7. Oktober 2005 21:13 >> >> >> > An: Georgios Karagiannis >> >> >> > Cc: nsis@ietf.org >> >> >> > Betreff: Re: [NSIS] remove packet_classifier object from >> >> >> > QoS-NSLP >> >> >> > >> >> >> > >> >> >> > >> >> >> > Hi Georgios, all, >> >> >> > >> >> >> > If people would rather see the packet classifier removed >> >> from the >> >> >> > QoS-NSLP spec, then I would still like to see it >> defined in the >> >> >> > QSPEC template. It would be good from an >> implementation point of >> >> >> > view, and implementation effort, if there was a single >> >> suggestion >> >> >> > on how to specify packet classifiers in QoS models. >> >> >> > >> >> >> > Still, I'd like to hear other views on what to do with the >> >> >> classifier. >> >> >> > >> >> >> > Cheers, >> >> >> > Jukka >> >> >> > >> >> >> > On Fri, 7 Oct 2005, Georgios Karagiannis wrote: >> >> >> > >> >> >> > > Dear all >> >> >> > > >> >> >> > > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER >> >> >> > object, in >> >> >> > > our implementation, we have seen that the need of using >> >> >> > such an object for >> >> >> > > filtering and packet classification is not needed. >> >> >> > > >> >> >> > > The main reason for that is that the RMF is responsible for >> >> >> > modifying/interacting >> >> >> > > with the packet classification function, see Figure 1 in >> >> >> > QoS-NSLP draft. Both >> >> >> > > functions are not QoS-NSLP functions. >> >> >> > > Thus I do not understand why we have to generate such an >> >> >> > object, since >> >> >> > > the QoS model, used in each node, should actually specify >> >> >> > by using a local policy on each node, >> >> >> > > which filters and how such filters must be used. >> >> >> > > Therefore I propose to remove the PACKET_CLASSIFIER >> from the >> >> >> > > QOS-NSLP specification. >> >> >> > > >> >> >> > > >> >> >> > > Best regards, >> >> >> > > Georgios >> >> >> > > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > nsis mailing list >> >> >> > nsis@ietf.org >> >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > >> >> >> >> >> >> _______________________________________________ >> >> >> nsis mailing list >> >> >> nsis@ietf.org >> >> >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> >> >> >> _______________________________________________ >> >> nsis mailing list >> >> nsis@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 06:47:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvBY-0007un-QV; Mon, 10 Oct 2005 06:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvBW-0007ui-Nz for nsis@megatron.ietf.org; Mon, 10 Oct 2005 06:47:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00736 for ; Mon, 10 Oct 2005 06:47:07 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOvLO-0000cZ-P7 for nsis@ietf.org; Mon, 10 Oct 2005 06:57:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9AAjB1o023319; Mon, 10 Oct 2005 13:45:12 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2005 13:46:59 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2005 13:46:58 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Date: Mon, 10 Oct 2005 13:46:57 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01141FF0@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXNJPiJ6JL5Ej9FQzi/az7Jmd0ktAAYt1vA To: , , , X-OriginalArrivalTime: 10 Oct 2005 10:46:58.0892 (UTC) FILETIME=[F07CD8C0:01C5CD87] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org whether this data should be in the qos-nslp or qspec is less=20 clear to me. the concept in my head has always been that the=20 qos-nslp carried everything about *what* resource reservation=20 action you wanted to carry out, and the qspec was about how=20 much "stuff" you actually wanted to reserve. the packet classifier=20 needs to be given in every message about a transaction, whereas=20 the "how much" information only in some; and the classifier can=20 probably be universal, whereas the qspec need not be. I don't=20 see why having it in the qos-nslp is hard. =20 =20 This is where I thought we left it after the interim meeting. I guess if we remove it, I'd like to have some more reasoning behind the removal. =20 John=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 07:27:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvos-0005Ug-JU; Mon, 10 Oct 2005 07:27:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvor-0005U6-Bz for nsis@megatron.ietf.org; Mon, 10 Oct 2005 07:27:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02446 for ; Mon, 10 Oct 2005 07:27:48 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOvyi-0001bc-Ox for nsis@ietf.org; Mon, 10 Oct 2005 07:38:03 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9ABRg86015703; Mon, 10 Oct 2005 13:27:42 +0200 (MEST) Message-ID: <011b01c5cd8d$a1ffb5e0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: , , , References: <1AA39B75171A7144A73216AED1D7478D01141FF0@esebe100.NOE.Nokia.com> Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP Date: Mon, 10 Oct 2005 13:27:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.521 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 10 Oct 2005 13:27:44 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John I do not have any problem on including this object in the QSPEC. Please note that the packet classifier functionality is strict associated with a QoS model. A PACKET_CLASSIFIER object specifies which filter should be used by the packet classifier functionlaity on filtering the user data packets. Suppose now that for the same session two qos models are used, one that goes end-to-end and the other one that goes edge to edge within a domain. Note that this is the case when stacking of QSPEC's is used. If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter information should this object contain, the filter information required by the end-to-end QoS model or the edge-to-edge QoS model? In this case this problem can be solved by making the PACKET_CLASSIFIER object in the stackable! Do we want this? Another solution is to introduce the PACKET_CLASSIFIER object into the QSPEC. Best regards, Georgios ----- Original Message ----- From: To: ; ; ; Cc: Sent: Monday, October 10, 2005 12:46 PM Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > whether this data should be in the qos-nslp or qspec is less > clear to me. the concept in my head has always been that the > qos-nslp carried everything about *what* resource reservation > action you wanted to carry out, and the qspec was about how > much "stuff" you actually wanted to reserve. the packet classifier > needs to be given in every message about a transaction, whereas > the "how much" information only in some; and the classifier can > probably be universal, whereas the qspec need not be. I don't > see why having it in the qos-nslp is hard. > > This is where I thought we left it after the interim meeting. I guess > if we remove it, I'd like to have some more reasoning behind the > removal. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 10:00:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyCF-0005rr-Rc; Mon, 10 Oct 2005 10:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyCE-0005rK-TI for nsis@megatron.ietf.org; Mon, 10 Oct 2005 10:00:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10298 for ; Mon, 10 Oct 2005 10:00:04 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOyM5-0005hS-O0 for nsis@ietf.org; Mon, 10 Oct 2005 10:10:21 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IO500J4IDJPTD@mailout2.samsung.com> for nsis@ietf.org; Mon, 10 Oct 2005 22:59:49 +0900 (KST) Received: from LocalHost ([75.2.43.239]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IO500AH2DJP01@mmp1.samsung.com> for nsis@ietf.org; Mon, 10 Oct 2005 22:59:49 +0900 (KST) Date: Mon, 10 Oct 2005 22:59:48 +0900 From: Sung-Hyuck Lee To: nsis@ietf.org Message-id: <001001c5cda2$e1326720$ef2b024b@LocalHost> Organization: SAIT MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [NSIS] NSIS mobility issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0883667428==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0883667428== Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBcyB5b3Uga25vdywgIE5TSVMgbW9iaWxpdHkgYXV0aG9ycyBoYXZlIGVzdGFi bGlzaGVkIHRoZSBOU0lTIG1vYmlsaXR5IA0KaXNzdWUgdHJhY2tlcic6IGh0dHA6Ly93d3cudHNj aG9mZW5pZy5jb206ODA4MC9uc2lzbW9iLy4gQWxzbywgdGhlIGF1dGhvcnMgDQp3b3VsZCBsaWtl IHRvIGFkZHJlc3MgdGhlIGZvbGxvd2luZyBpc3N1ZXMgdG8gZnVydGhlciBkaXNjdXNzIHRob3Nl IGlzc3VlcyANCm9uIHRoZSBtYWlsaW5nIGxpc3QuIEl0IHdvdWxkIGJlIHZlcnkgbXVjaCBhcHBy ZWNpYXRlZCBpZiBOU0lTIGZvbGtzIGdpdmUgc29tZSANCmd1aWRlcyBhbmQgY29tbWVudHMgb24g dGhlIGZvbGxvd2luZyBpc3N1ZXMgYWRkcmVzc2VkIGluIA0KaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uc2lzLWFwcGxpY2FiaWxpdHktbW9iaWxpdHktc2ln bmFsaW5nLTAyLnR4dC4gDQpUaGUgbW9yZSBkZXRhaWxlZCBpc3N1ZXMgY2FuIGJlIGZvdW5kIGlu IE5TSVMgbW9iaWxpdHkgaXNzdWUgdHJhY2tlci4NCg0KKiBDbG9zZWQNCiAgIC0gIzQ6IEF1dGhv cml6YXRpb24tcmVsYXRlZCBpc3N1ZXMgd2l0aCB0ZWFyZG93biANCiAgICAgICAgICBzb2x2ZWQg YnkgZGlzYWJsaW5nIG9mICJyZXZlcnNlIHJlbW92YWwiIA0KDQogICAtICM3OiBQcmlvcml0eSBv ZiBzaWduYWxpbmcgbWVzc2FnZXMgDQogICAgICAgICAgSXQgaXMgZGlmZmljdWx0IGZvciB0aGUg c2lnbmFsaW5nIHByaW9yaXR5IHRvIGJlIHVzZWQgZHVlIHRvIHNlY3VyaXR5IGlzc3VlcyANCg0K KiBSZW1haW5pbmcgaXNzdWVzIHRvIGJlIHJlc29sdmVkOiANCg0KICAgLSAjMTogQ1JOIGRpc2Nv dmVyeSANCiAgICAgICB0aGUgcHJvcyBhbmQgY29ucyBvZiB0d28gZGlzY292ZXJ5IG1lY2hhbmlz bXMgb24gQ1JOIHdhcyANCiAgICAgICBkZXNjcmliZWQgaW4gbW9yZSBkZXRhaWxzOiBlaXRoZXIg YXQgTlRMUCAgbGF5ZXIgb3IgTlNMUCBsYXllci4gDQoNCiAgIC0gIzI6IE1vYmlsZSBJUCBzcGVj aWZpYyBBUEkgDQogICAgICAgVGhpcyBpc3N1ZSBpcyBhIGxpdHRsZSBpbXBsZW1lbnRhdGlvbi1z cGVjaWZpYywgYnV0IHRoZSB1c2FnZSBvZiANCiAgICAgICAgYW4gQVBJIG5lZWRzIHRvIGJlIGRl c2NyaWJlZC4gDQoNCiAgIC0jMzogSW52YWxpZCBOU0lTIFJlc3BvbmRlciBwcm9ibGVtIA0KICAg ICAgICBTb21lIHBvc3NpYmxlIHByb3Bvc2FscyB0byBzb2x2ZSB0aGUgJ2ludmFsaWQgTlInIHBy b2JsZW0gaW4gDQogICAgICAgIG1vYmlsaXR5IHNjZW5hcmlvcyB3YXMgZGVzY3JpYmVkIChlLmcu LCBoaW50IGluZm9ybWF0aW9uOiANCiAgICAgICAgaGFuZG92ZXJfaW5pdCAoSEkpKS4gVGhpcyBp c3N1ZSBpcyBwZXJ0aW5lbnQgdG8gIzExLiANCg0KICAgLSAjNTogT3B0aW1hbCByZWZyZXNoIHRp bWVyIHZhbHVlIGZvciBtb2JpbGUgZW52aXJvbm1lbnQgDQogICAgICAgICBJdCBpcyBkaWZmaWN1 bHQgdG8gcHJvdmlkZSBnZW5lcmljIG1lY2hhbmlzbSwgYnV0IHByb3ZpZGUgc3BlY2lmaWMgdmFs dWVzIA0KICAgICAgICAoZm9yIHNwZWNpZmljIHNjZW5hcmlvcykgaWYgcG9zc2libGUuIA0KDQog ICAtICM2OiBDUk4gZGlzY292ZXJ5IGFuZCBQYXRoIFVwZGF0ZSBvbiB0aGUgSVAtdHVubmVsaW5n IHBhdGggDQogICAgICAgICBwb3NzaWJsZSBpc3N1ZXMgaW4gTlNJUy1tb2JpbGl0eSBkcmFmdCAo LTAyKSB3ZXJlIGRlc2NyaWJlZC4gDQogICAgICAgICBTdWdnZXN0IHNvbHV0aW9ucyBpbiBzZXBh cmF0ZSBkcmFmdHMuIA0KIA0KICAgLSAjODogTG9jYWxpemVkIFBhdGggVXBkYXRlIA0KICAgICAg ICBJZGVudGlmeSB0aGUgZGlmZmVyZW5jZSBiL3cgdGhlIGxvY2FsaXplZCBtb2JpbGl0eSBhbmQg bWljcm8gbW9iaWxpdHkgDQogICAgICAgIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGluIGNhc2Ugb2Yg aW50ZXJhY3Rpb24gd2l0aCBOU0lTIHByb3RvY29scy4gDQogICAgICAgIENvbnNpZGVyIHNpZ25h bGluZyBvcHRpbWl6YXRpb24gaW4gdGhlIHZlcnRpY2FsIGhhbmRvdmVyIHNjZW5hcmlvcy4gDQoN CiAgIC0gIzk6IERlYWQgUGVlciBEaXNjb3ZlcnkNCiAgICAgICAgICAgIERlYWQgcGVlcnMgKGUu Zy4sIEFSIChvciBGQSksIENSTiwgSEEgb3IgTU4gKSBjYW4gb2NjdXIgZWl0aGVyIA0KICAgICAg ICBiZWNhdXNlIGEgbGluayBvciBhIG5ldHdvcmsgbm9kZSBmYWlsZWQsIG9yIE1OIG1vdmVkIGF3 YXkgDQogICAgICAgIHdpdGhvdXQgaW5mb3JtaW5nIE5UTFAvTlNMUCAoZS5nLiwgUW9TLSBvciBO QVQvRlctTlNMUCkuIA0KICAgICAgICBHSU1QUyBkaXNjb3Zlcnkgd2lsbCBkZXRlY3QgdGhlIHBy b2JsZW0gYWZ0ZXIgc29tZSB0aW1lOiBpdCBzYXlzIA0KICAgICAgICB0aGF0IEdJTVBTIGRpc2Nv dmVyeSBtaWdodCBiZSB0b28gc2xvdy4gDQoNCiAgICAgIC0gUXVlc3Rpb25zIGZvciAjOTogDQog ICAgICAgICAgICBIb3cgY2FuIGRlYWQgcGVlcnMgYmUgZGV0ZWN0ZWQgaW4gYSBmYXN0IGFuZCBl ZmZpY2llbnQgbWFubmVyIGluIA0KICAgICAgICAgbW9iaWxpdHkgc2NlbmFyaW9zPyBEbyBzb21l ICJkZWFkIHBlZXIiIGNhc2VzIG5lZWQgdG8gYmUgDQogICAgICAgICBpZGVudGlmaWVkPyAoZS5n LiwgTU6hryBtb3ZpbmctYXdheSwgQ1JOIGZhaWx1cmUsIENBUnOhryBmYWlsdXJlLCANCiAgICAg ICAgIEZBL0hBoa9zIGZhaWx1cmUsIGFuZCBzbyBvbikgIA0KDQogIC0gIzEwOiAgTXVsdGlob21p bmcgaXNzdWVzDQogICAgICAgICAgICAgQW4gTlNJUy1hd2FyZSBub2RlIChlLmcuLCBNTiwgSEEs IENOLCBldGMuKSBtYXkgYmUgbXVsdGlob21lZC4gDQogICAgICAgICBOU0lTIHNpZ25hbGluZyBj YW4gYmUgdXNlZCBpbiBzdWNoIG11bHRpaG9tZWQgZW52aXJvbm1lbnRzLiANCiAgICAgICAgIElu IHRoaXMgY2FzZSwgd2hpY2ggTnhMUCBmdW5jdGlvbmFsaXR5IGlzIG5lZWRlZCBpbiB2YXJpb3Vz IA0KICAgICAgICAgbXVsdGlob21pbmcgc2NlbmFyaW9zIChlLmcuLCBiYW5kd2lkdGggaW5jcmVh c2UsIGxvYWQgYmFsYW5jaW5nLCANCiAgICAgICAgIGJpLWNhc3RpbmcsIHJlc2lsaWVuY2UsIGV0 Yy4pIGlzIGFuIG9wZW4gcXVlc3Rpb24uIEFuIG92ZXJhbGwgDQogICAgICAgICBjb29yZGluYXRp b24gZm9yIGludGVyd29ya2luZyBiZXR3ZWVuIHRoZSBOU0lTIHByb3RvY29sIA0KICAgICAgICAg c3VpdGUgYW5kIG11bHRpaG9taW5nIGNhcGFiaWxpdHkgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGZ1 cnRoZXIuIA0KDQogICAgICAtIFF1ZXN0aW9ucyBmb3IgIzEwOiANCiAgICAgICAgICAgSG93IHNo b3VsZCBtdWx0aXBsZSBDUk5zIGRpZmZlcmVudGlhdGUgdGhlIFBhdGggVXBkYXRlIGZvciANCiAg ICAgICAgbXVsdGlob21pbmcgZnJvbSB0aGUgZ2VuZXJpYyBQYXRoIFVwZGF0ZT8gSG93IGRvIENS TnMgYXV0aG9yaXplIA0KICAgICAgICBtdWx0aXBsZSBmbG93cyB3aXRoIGRpZmZlcmVudCBmbG93 IGlkZW50aWZpZXJzIGZvciB0aGUgc2FtZSBzZXNzaW9uPyANCiANCiAgLSAjMTEgTW9iaWxpdHkg T2JqZWN0DQogICAgICAgICAgVGhlIE1vYmlsaXR5IG9iamVjdHMgc3VjaCBhcyAnTW9iaWxpdHlf RXZlbnRfQ291bnRlciAoTUVDKScgYW5kIA0KICAgICAgICdIYW5kb3Zlcl9Jbml0IChISSknIGNh biBiZSB1c2VkIHRvIHNvbHZlIHRoZSBwaW5nLXBvbmcgdHlwZSANCiAgICAgICBoYW5kb3ZlciBh bmQgdGhlIEludmFsaWQgTlIgcHJvYmxlbSwgcmVzcGVjdGl2ZWx5LiBUaGUgTUVDIGZpZWxkIGNh biANCiAgICAgICBpbmZvcm0gdGhlIENSTiBvZiB3aGljaCBpbmNvbWluZyBtZXNzYWdlIGlzIHRo ZSBsYXRlc3QuIFRoZSBISSBmaWVsZCANCiAgICAgICBjYW4gZXhwbGljaXRseSBpbmZvcm0gQVIg KG9yIENSTikgdGhhdCBhIGhhbmRvdmVyIGlzIG5vdyBpbml0aWF0ZWQuIA0KDQogICAgIC0gUXVl c3Rpb24gZm9yICMxMTogDQogICAgICAgIERvIHRob3NlIG1vYmlsaXR5IG9iamVjdHMgbmVlZCB0 byBiZSBpbmNsdWRlZCBpbiBOeExQIG1lc3NhZ2VzPw0KIA0KICAtICMxMiBUZXJtaW5vbG9neTog UGF0aCBVcGRhdGUNCiAgICAgICAgVGhlIHRlcm0sICJQYXRoIFVwZGF0ZSIgaGFzIGJlZW4gY2hv c2VuIHdpdGggdGhlIGluaXRpYWwgbW9iaWxpdHkNCiAgICAgICAgbWFueWZvbGtzLWRyYWZ0LiBT b21lIGZvbGtzIHRoaW5rIHRoYXQgdGhlIHRlcm0gZG9lcyBub3QgDQogICAgICAgIGFwcHJvcHJp YXRlbHkgcmVwcmVzZW50IHRoZSBtZWFuaW5nIG9mIE5TSVMgc3RhdGUgcmVjb3ZlcnkuIA0KICAg ICAgICBDdXJyZW50bHksIHRoZSBjYW5kaWRhdGVzIGZvciBzdWJzdGl0dXRpb24gb2YgdGhlIHRl cm0gYXJlIA0KDQogICAgICAgICBpKSAiU3RhdGUgUmVjb3ZlcnkiIGFuZCBpaSkgIlN0YXRlIFVw ZGF0ZSIuIEFueSBzdWdnZXN0aW9uPyANCg0KDQogKiBTb21lIG92ZXJsYXBwZWQgaXNzdWVzIGJl dHdlZW4gUW9TLU5TTFAgYW5kIE5TSVMtbW9iaWxpdHkgZHJhZnRzIA0KDQogICAtIFFvUy1OU0xQ ICMyOTogTWFrZS1iZWZvcmUtYnJlYWsgaGFuZG92ZXJzIChpbmNsdWRpbmcgDQogICAgICBTZWFt b2J5LXJlbGF0ZWQgaXNzdWVzKSB3ZXJlIGFkZHJlc3NlZCBhdCB0aGUgaW5pdGlhbCBOU0lTLW1v YmlsaXR5IA0KICAgICAgZHJhZnQuIFdhcyB0aGlzIGlzc3VlIGNsb3NlZD8gDQogIA0KICAgLSBR b1MtTlNMUCAjMzI6IExhc3Qgbm9kZSBwcm9ibGVtIGlzIHNpbWlsYXIgdG8gdGhlICJJbnZhbGlk IE5SIA0KICAgICAgcHJvYmxlbSAoIzMpIiANCiANCiAgIC0gUW9TLU5TTFAgIzMzOiBQcmlvcml0 eSBvZiBzaWduYWxpbmcgbWVzc2FnZXMgdG8gR0lNUFMtTlNMUCBBUEkgDQogICAgICAgICYgIzM5 IEV4cGxpY2l0IGluZGljYXRpb24gb2YgcmVmcmVzaCBhcmUgcmVsYXRlZCB0byB0aGUgInByaW9y aXR5IG9mIA0KICAgICAgICBzaWduYWxpbmcgbWVzc2FnZXMgKCM3KSIgDQogIA0KICAgLSBRb1Mt TlNMUCAjMTc6IE5vZGUgZmFpbHVyZSBhbmQgcmVzdGFydCBoYW5kbGluZyANCiAgICAgICAgIkRl YWQgcGVlciBkaXNjb3ZlcnkgKCM5KSIgDQoNCiAgIC0gUXVlc3Rpb25zOiBIb3cgc2hvdWxkIHdl IHJlc29sdmUgdGhlIGNvbmZsaWN0PyBBbHNvLCB3aG8gDQogICAgICBkZXNjcmliZXMgd2hhdD8g DQoNCg0KICBUaGFua3MsDQoNCiBTdW5nLUh5dWNrIExlZQ0K --===============0883667428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0883667428==-- From nsis-bounces@ietf.org Mon Oct 10 11:11:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzIz-0006YX-Pk; Mon, 10 Oct 2005 11:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzIy-0006YA-6a for nsis@megatron.ietf.org; Mon, 10 Oct 2005 11:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21116 for ; Mon, 10 Oct 2005 11:11:05 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOzSr-000144-Om for nsis@ietf.org; Mon, 10 Oct 2005 11:21:23 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 10 Oct 2005 11:10:47 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101011104328968 ; Mon, 10 Oct 2005 11:10:45 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP; Mon, 10 Oct 2005 11:10:43 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2005 11:14:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [NSIS] QoS-NSLP, QSPEC, and QoS Model Date: Mon, 10 Oct 2005 11:14:00 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8660898E3@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] QoS-NSLP, QSPEC, and QoS Model Thread-Index: AcXNjpJuhQfGIoQ8TcGUoNWSmY/JrwAGD5Lw From: "Roy, Radhika \(AEAD\)" To: "Georgios Karagiannis" , , , , X-OriginalArrivalTime: 10 Oct 2005 15:14:18.0859 (UTC) FILETIME=[490D93B0:01C5CDAD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0aa23132abbc731e36938583486affe0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064815901==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============2064815901== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CDAD.3DE1F242" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CDAD.3DE1F242 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, John, George, and all: We are extremely confused to see the discussions that QSPEC and QoS models are used in the same breadth in providing the examples of packet classifiers of QoS-NSLP. For example, when it is said that one QoS model is used end-to-end and while other goes to edge-to-edge in the name of QSPEC. Let us go back to QSPEC for a while. QSPEC provides the "generalized" templates for using different QoS parameters (e.g., delay, delay jitter, packet loss). It does not "standardize" any specific values, end-to-end, edge-to-edge, backbone node-to-backbone node, or access node-to-access node, etc. A QoS model may specify many things that are implementation specifics, and may contain the followings: 1. Specific value of each QoS parameter (e.g., delay, delay jitter, packet loss). Note: If any value of any parameter is changed, it will NOT be the same QOS model. 2. Specific QoS domain (e.g., end-to-end, edge-to-edge, backbone node-to-backbone node, or access node-to-access node, etc.). Note: If the definition of the domain is changed, it will NOT be the same QOS model. So, we have also seen that each QoS model that will use the "generalized" QSPEC templates needs to have the separate draft (http://www1.ietf.org/mail-archive/web/nsis/current/msg05366.html and related threads). The conclusion is this:=20 a. Any references of QoS models in the QoS-NSLP discussions must NOT refer QSPEC. b. Any references of QSPEC in the QoS-NSLP discussions must NOT refer QoS models. That is, any references to QSPEC do NOT mean QoS model and vice versa. Also, it is again clear why any references of QoS model in the QSPEC draft must be removed. The latest the QSPEC draft has NOT taken care of this. If anyone does takes any specific examples using the specific network, end-to-end codecs, specific QoS values, QSPEC templates, QoS models, and domains can discover the above findings very easily.=20 The best way is to start with SIP call flows and then integrate with the NSIS QoS-NSLP, QSPEC, and QoS model signaling messages step-by-step. It is technical, nothing magical. Any comments? Best regards, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Monday, October 10, 2005 7:28 AM To: john.loughney@nokia.com; robert.hancock@roke.co.uk; hannes.tschofenig@siemens.com; jmanner@cs.Helsinki.FI Cc: nsis@ietf.org Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP Hi John I do not have any problem on including this object in the QSPEC. Please note that the packet classifier functionality is strict associated with a QoS model. A PACKET_CLASSIFIER object specifies which filter should be used by the packet classifier functionlaity on filtering the user data packets. Suppose now that for the same session two qos models are used, one that goes end-to-end and the other one that goes edge to edge within a domain. Note that this is the case when stacking of QSPEC's is used. If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter information should this object contain, the filter information required by the end-to-end QoS model or the edge-to-edge QoS model? In this case this problem can be solved by making the PACKET_CLASSIFIER=20 object in the stackable! Do we want this? Another solution is to introduce the PACKET_CLASSIFIER object into the=20 QSPEC. Best regards, Georgios ----- Original Message -----=20 From: To: ; ;=20 ; Cc: Sent: Monday, October 10, 2005 12:46 PM Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > whether this data should be in the qos-nslp or qspec is less > clear to me. the concept in my head has always been that the > qos-nslp carried everything about *what* resource reservation > action you wanted to carry out, and the qspec was about how > much "stuff" you actually wanted to reserve. the packet classifier > needs to be given in every message about a transaction, whereas > the "how much" information only in some; and the classifier can > probably be universal, whereas the qspec need not be. I don't > see why having it in the qos-nslp is hard. > > This is where I thought we left it after the interim meeting. I guess > if we remove it, I'd like to have some more reasoning behind the > removal. > > John > ------_=_NextPart_001_01C5CDAD.3DE1F242 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [NSIS] QoS-NSLP, QSPEC, and QoS Model

Hi, John, George, and all:

We are extremely confused to see the discussions that QSPEC and = QoS models are used in the same breadth in providing the examples of packet classifiers of QoS-NSLP. For example, when it is said that one QoS model is used = end-to-end and while = other goes to edge-to-edge = in the name of QSPEC.

Let us go back to QSPEC for a while. QSPEC provides the = "generalized" templates for using different QoS = parameters (e.g., delay, delay jitter, packet loss). It does not "standardize" any specific = values, = end-to-end, edge-to-edge, backbone = node-to-backbone node, or access node-to-access node, = etc.

A QoS model may specify many things that are implementation = specifics, and may = contain = the followings:

1.      = Specific value of = each = QoS parameter (e.g., delay, delay jitter, packet loss). Note: If any value of any parameter is changed, it will NOT be the same QOS = model.

2.      = Specific QoS domain (e.g., end-to-end, edge-to-edge, backbone = node-to-backbone node, or access node-to-access node, = etc.). Note: If the definition of the = domain = is = changed, it will NOT be the same QOS model.

So, we have also = seen that each QoS model that will use the "generalized" = QSPEC templates = needs to have the separate = draft (http://www1.ietf.org/mail-archive/web/nsis/current/msg05366.html and related = threads).

The conclusion is this:

a.      = Any references of QoS models in the = QoS-NSLP discussions must NOT refer = QSPEC.
b.      = Any references of QSPEC = in the QoS-NSLP discussions must NOT = refer QoS = models.

That is, any = references to QSPEC do NOT mean QoS model and vice = versa.

Also, it = is again clear = why any references of QoS model in the = QSPEC draft must be removed. The latest = the QSPEC draft has NOT taken = care = of this.

If anyone does takes any specific examples = using = the specific network, end-to-end = codecs, specific QoS values, QSPEC templates, QoS = models, = and domains can discover the above findings very = easily. =

The best way is to start = with SIP call flows and = then = integrate = with the NSIS QoS-NSLP, QSPEC, and QoS = model signaling messages = step-by-step. It is technical, = nothing magical.

Any comments?

Best regards,

Radhika

-----Original Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of Georgios Karagiannis
Sent: Monday, October 10, 2005 7:28 AM
To: john.loughney@nokia.com; robert.hancock@roke.co.uk; = hannes.tschofenig@siemens.com; jmanner@cs.Helsinki.FI
Cc: nsis@ietf.org
Subject: Re: [NSIS] remove packet_classifier object from = QoS-NSLP

Hi John

I do not have any problem on including this object in the = QSPEC.

Please note that the packet classifier functionality is = strict

associated with a QoS model. A PACKET_CLASSIFIER object specifies = which

filter should be used by the packet classifier functionlaity = on

filtering the user data packets.

Suppose now that for the same session two qos models are used, = one that

goes end-to-end and the other one that goes edge to edge within = a

domain. Note that this is the case when stacking of QSPEC's is = used.

If the PACKET_CLASSIFIER object is a QOS-NSLP object, which = filter

information should this object contain, the filter information = required

by the end-to-end QoS model or the edge-to-edge QoS = model?

In this case this problem can be solved by making the = PACKET_CLASSIFIER

object in  the

stackable!

Do we want this?

Another solution is to introduce the PACKET_CLASSIFIER object = into the

QSPEC.

Best regards,

Georgios

----- Original Message -----

From: <john.loughney@nokia.com>

To: <robert.hancock@roke.co.uk>; = <hannes.tschofenig@siemens.com>;

<jmanner@cs.Helsinki.FI>; = <karagian@cs.utwente.nl>

Cc: <nsis@ietf.org>

Sent: Monday, October 10, 2005 12:46 PM

Subject: RE: [NSIS] remove packet_classifier object from = QoS-NSLP


> whether this data should be in the qos-nslp or qspec is = less

> clear to me. the concept in my head has always been that = the

> qos-nslp carried everything about *what* resource = reservation

> action you wanted to carry out, and the qspec was about = how

> much "stuff" you actually wanted to reserve. the = packet classifier

> needs to be given in every message about a transaction, = whereas

> the "how much" information only in some; and the = classifier can

> probably be universal, whereas the qspec need not be. I = don't

> see why having it in the qos-nslp is hard.

>

> This is where I thought we left it after the interim = meeting. I guess

> if we remove it, I'd like to have some more reasoning behind = the

> removal.

>

> John

>

------_=_NextPart_001_01C5CDAD.3DE1F242-- --===============2064815901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2064815901==-- From nsis-bounces@ietf.org Mon Oct 10 16:26:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP4Dx-000461-Al; Mon, 10 Oct 2005 16:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP4Du-00045v-RI for nsis@megatron.ietf.org; Mon, 10 Oct 2005 16:26:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23002 for ; Mon, 10 Oct 2005 16:26:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP4Ns-0000l9-0l for nsis@ietf.org; Mon, 10 Oct 2005 16:36:33 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2005 13:26:04 -0700 X-IronPort-AV: i="3.97,195,1125903600"; d="scan'208"; a="350343695:sNHT28211328" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9AKQ1KC016914; Mon, 10 Oct 2005 13:26:01 -0700 (PDT) Received: from [192.168.50.15] (rtp-vpn4-475.cisco.com [10.82.209.219]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9AKaq8o002472; Mon, 10 Oct 2005 13:36:55 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: AW: [NSIS] Re: authorizing query messages Date: Mon, 10 Oct 2005 10:52:13 -0400 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=2320; t=1128976619; x=1129408819; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20AW=3A=20[NSIS]=20Re=3A=20authorizing=20query=20messages| From:David=20R=20Oran=20| Date:Mon,=2010=20Oct=202005=2010=3A52=3A13=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=QTCobfOd3PVBYl/Uic4t/Uujjq1fYAtFVXYpKl/vVefXnhzq+Hf9yorQBYA9ZFVpQHqXKzmG QEsLa1zrO+IBeFlWUFu2VouILF8p/tcZGQfoXvUuCbWJ9QRQrV00L35KDISt5QoCUwDbFZGCev/ LLt+JqpBRYluLmwDXoDnHm3s= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.7 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Do you think it makes sense to have the authorization response to the query return a QSPEC with the user's authorized resources so that can be returned along with the available resources (or alternatively used by the NSLP to reduce the reported available resources to only the amount authorized? On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote: > hi jukka, > > thanks for your feedback. here is a proposal how to handle > authorization > for the query message: > > the query message triggers a QAR with the authentication info but > without any QoS-Resources. > it might be necessary to indicate (somewhere) that this is only a > query > without the need to enable accounting and charging. > > as such, the response in the QAA is also limited to the result rather > than returning information like avps like CC-Time,Cost, > QoS-Resources,Authz-time). > > here is the figure: > > End-Host Network Element Entity > requesting QoS ( Diameter ( Diameter > QoS Client) QoS Server) > | | | > +---QoS-Query------>| | > | +- - - - - QAR - - - - - >| > | |(QoS-Resources=NULL, | > | | QoS-Auth-Data,User-ID)| > | | +--------+--------------+ > | | | Authorize request | > | | | Keep no session data | > | | | | > | | +--------+--------------+ > | |< - - - - QAA - - - - - -+ > | |(Result-Code) | > | | | > | +-------+---------+ > | |Proceeed with | > | |QoS signaling | > | |exchange | > | +-------+---------+ > | | > | +----------QoS-Reserve---------------> > | | > | |<---------QoS-Response--------------- > |<--QoS-Response----+ > > > ciao > hannes > > > >> Hi, >> >> I would expect that in certain networks, not everybody may query the >> network of available resources. Thus, there could be need to >> include an >> auhtorization token, or ask from a Diameter server whether the node >> sending the query is allowed to do that. >> >> Cheers, >> Jukka >> >> >> On Thu, 6 Oct 2005, Hannes Tschofenig wrote: >> >> >> >>> hi all, >>> >>> as part of our work on the diameter-qos application and the >>> >>> >> radius-qos draft >> >> >>> we came across the aspect of authorizing individual types >>> >>> >> of actions taken by >> >> >>> the qos signaling protocol. from discussions in the past i >>> >>> >> remember that >> >> >>> people wanted to authorize query messages as well. when we >>> >>> >> come to the >> >> >>> concrete details we are not quite sure what it actually >>> >>> >> means. what would be >> >> >>> the authorization decision regarding the query message >>> >>> >> people have in mind? >> >> >>> >>> ciao >>> hannes >>> >>> >>> >>> >>> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 10 17:14:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP4yK-0008EA-4u; Mon, 10 Oct 2005 17:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP4yI-0008E5-1g for nsis@megatron.ietf.org; Mon, 10 Oct 2005 17:14:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25220 for ; Mon, 10 Oct 2005 17:14:07 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP58D-0001ut-Ax for nsis@ietf.org; Mon, 10 Oct 2005 17:24:29 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 10 Oct 2005 17:13:52 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101017134827166 ; Mon, 10 Oct 2005 17:13:51 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Mon, 10 Oct 2005 17:13:47 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2005 17:17:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Mon, 10 Oct 2005 17:17:04 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8660898E4@bh-exchange02.saic-abingdon.com> Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXN2ZD3Cw0fPDwEQByJ+bnBPAV3IQAAksBQ From: "Roy, Radhika \(AEAD\)" To: "Tschofenig, Hannes" X-OriginalArrivalTime: 10 Oct 2005 21:17:23.0078 (UTC) FILETIME=[01759A60:01C5CDE0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a7d7b1ff9fdb39b8762b25bc5367e56 Cc: "McDonald, Andrew" , Georgios Karagiannis , David R Oran , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0700829455==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0700829455== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CDDF.F617DDCC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CDDF.F617DDCC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Hanes and all: I think that this is one of the important points that we need to consider here for authorization using DIAMETER (as Dave pointed out). The DIAMETER server needs to authorize QoS resources (which is also coupled with authentication). If the "amount" of QoS resources of each kind (e.g., audio, video, data) are considered, QSPEC needs to be used (by the way, NOT the QoS models because QoS models are coupled with "domains" and NSIS is not dealing with domains per se). So, the point is this: DIAMETR QoS application support also needs to be augmented with the "generalized" QSPEC. As I explained before, the support of specific QoS models do not automatically mean the support of the "generalized" QSPEC, DIAMETER QoS application also needs to be extended for each QoS model.=20 Going further, DIAMETER SIP application standard also needs to be coupled with this from the application QoS signaling point of view.=20 Anyway, this is NOT rocket science as people are dealing with these kinds things on end-to-end basis using SIP, RADIUS/DIAMETR, RSVP, and DiffServ for implementations as standards have NOT progressed to support those completely yet. Any comments? Best regards, Radhika PS: By the way, do people understand now how QoS models that deal with certain domains based on certain specific values of each QoS parameter make the "generalized" QSPEC templates messy if the same QSPEC draft deals with both? -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of David R Oran Sent: Monday, October 10, 2005 10:52 AM To: Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: Re: AW: [NSIS] Re: authorizing query messages Do you think it makes sense to have the authorization response to the =20 query return a QSPEC with the user's authorized resources so that can =20 be returned along with the available resources (or alternatively used =20 by the NSLP to reduce the reported available resources to only the =20 amount authorized? On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote: > hi jukka, > > thanks for your feedback. here is a proposal how to handle =20 > authorization > for the query message: > > the query message triggers a QAR with the authentication info but > without any QoS-Resources. > it might be necessary to indicate (somewhere) that this is only a =20 > query > without the need to enable accounting and charging. > > as such, the response in the QAA is also limited to the result rather > than returning information like avps like CC-Time,Cost, > QoS-Resources,Authz-time). > > here is the figure: > > End-Host Network Element Entity > requesting QoS ( Diameter ( Diameter > QoS Client) QoS Server) > | | | > +---QoS-Query------>| | > | +- - - - - QAR - - - - - >| > | |(QoS-Resources=3DNULL, | > | | QoS-Auth-Data,User-ID)| > | | +--------+--------------+ > | | | Authorize request | > | | | Keep no session data | > | | | | > | | +--------+--------------+ > | |< - - - - QAA - - - - - -+ > | |(Result-Code) | > | | | > | +-------+---------+ > | |Proceeed with | > | |QoS signaling | > | |exchange | > | +-------+---------+ > | | > | +----------QoS-Reserve---------------> > | | > | |<---------QoS-Response--------------- > |<--QoS-Response----+ > > > ciao > hannes > > > >> Hi, >> >> I would expect that in certain networks, not everybody may query the >> network of available resources. Thus, there could be need to >> include an >> auhtorization token, or ask from a Diameter server whether the node >> sending the query is allowed to do that. >> >> Cheers, >> Jukka ------_=_NextPart_001_01C5CDDF.F617DDCC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: AW: [NSIS] Re: authorizing query messages

Hi, Hanes and all:

I think that this is one of the important points that we need to = consider here for authorization using DIAMETER (as Dave pointed out).

The DIAMETER server needs to authorize QoS = resources (which is also = coupled with authentication). If the "amount" = of QoS resources of each kind = (e.g., audio, video, data) are considered, QSPEC needs to be used (by = the way, = NOT the QoS models because = QoS models are coupled with = "domains" and NSIS is not = dealing with domains per se).

So, the point is this: DIAMETR QoS application support also needs to be = augmented with the "generalized" = QSPEC.

As I explained before, the support of specific QoS models do = not automatically mean the support of the = "generalized" = QSPEC, DIAMETER QoS application = also needs to be extended for each QoS model.

Going further, DIAMETER SIP application standard also needs = to be coupled with this from the application QoS signaling point = of view. =

Anyway, this is NOT rocket science as people are dealing with = these kinds things on = end-to-end basis using SIP, = RADIUS/DIAMETR, RSVP,  = and DiffServ for implementations as standards have NOT progressed to support those completely yet.

Any comments?

Best regards,

Radhika

PS: By the way, do people understand now how QoS models that deal with certain domains based on certain specific values of each QoS = parameter = make the "generalized" = QSPEC templates messy if the same QSPEC draft = deals with both?

-----Original Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of David R Oran
Sent: Monday, October 10, 2005 10:52 AM
To: Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org
Subject: Re: AW: [NSIS] Re: authorizing query = messages

Do you think it makes sense to have the authorization response to = the 

query return a QSPEC with the user's authorized resources so that = can 

be returned along with the available resources (or alternatively = used 

by the NSLP to reduce the reported available resources to only = the 

amount authorized?

On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes = wrote:


> hi jukka,

>

> thanks for your feedback. here is a proposal how to = handle 

> authorization

> for the query message:

>

> the query message triggers a QAR with the authentication = info but

> without any QoS-Resources.

> it might be necessary to indicate (somewhere) that this is = only a 

> query

> without the need to enable accounting and = charging.

>

> as such, the response in the QAA is also limited to the = result rather

> than returning information like avps like = CC-Time,Cost,

> QoS-Resources,Authz-time).

>

> here is the figure:

>

>    = End-Host         Network = Element           =   Entity

>   requesting QoS      ( = Diameter           = ;   ( Diameter

>          &n= bsp;           &nb= sp; QoS = Client)           =   QoS Server)

>       = |            =        = |            =              = |

>       = +---QoS-Query------>|        &= nbsp;           &n= bsp;    |

>       = |            =        +- - - - - QAR - - - - - = >|

>       = |            =        = |(QoS-Resources=3DNULL,     |

>       = |            =        |   = QoS-Auth-Data,User-ID)|

>       = |            =        = |            =     +--------+--------------+

>       = |            =        = |            =     |  Authorize request    = |

>       = |            =        = |            =     |  Keep no session data |

>       = |            =        = |            =     = |            =            = |

>       = |            =        = |            =     +--------+--------------+

>       = |            =        |< - - - - QAA - - - - - = -+

>       = |            =        = |(Result-Code)          = ;  |

>       = |            =        = |            =              = |

>       = |           = +-------+---------+

>       = |           |Proceeed = with    |

>       = |           |QoS = signaling    |

>       = |           = |exchange         = |

>       = |           = +-------+---------+

>       = |            =        |

>       = |            =        = +----------QoS-Reserve--------------->

>       = |            =        |

>       = |            =        = |<---------QoS-Response---------------

>       = |<--QoS-Response----+

>

>

> ciao

> hannes

>

>

>

>> Hi,

>>

>> I would expect that in certain networks, not everybody = may query the

>> network of available resources. Thus, there could be = need to

>> include an

>> auhtorization token, or ask from a Diameter server = whether the node

>> sending the query is allowed to do = that.

>>

>> Cheers,

>> Jukka

------_=_NextPart_001_01C5CDDF.F617DDCC-- --===============0700829455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0700829455==-- From nsis-bounces@ietf.org Tue Oct 11 04:08:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPFBQ-00040r-Ec; Tue, 11 Oct 2005 04:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPFBO-00040g-Rc for nsis@megatron.ietf.org; Tue, 11 Oct 2005 04:08:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06856 for ; Tue, 11 Oct 2005 04:08:20 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPFLS-0000C5-Af for nsis@ietf.org; Tue, 11 Oct 2005 04:18:47 -0400 Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7F4711C934 for ; Tue, 11 Oct 2005 10:08:12 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Oct 2005 10:08:12 +0200 Date: Tue, 11 Oct 2005 10:08:11 +0200 From: Martin Stiemerling To: nsis Message-ID: <21308534E6B4956A7F0B0735@[10.1.1.109]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 11 Oct 2005 08:08:12.0435 (UTC) FILETIME=[ECB09E30:01C5CE3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [NSIS] NSLP-Data in intial GIST-Query X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, GIST-Query messages may carry a NSLP-Data object containing information for the NSLP. I'm now assuming an initial GIST-Query send downstream looking for the next peer., carrying NSLP-Data, and a GIST downstream node using a stateless approach (delayed state setup, using a responder cookie ). In this case, the NSLP data would be lost, if not re-transmitted in the GIST-Confirm/GIST-Data later, since the downstream peer does not keep any state about the initial GIST-Query. There is no text (as far as I know) describing what the sending GIST-peer should do in this case. In the case of a "stateless" downstream peer (querying node sees response with responder cookie and R-flag set), the querying must re-send the NSLP-data in the next message. I may have missed something while reading the draft, but this issue was coming to mind afterwards. With best regards, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 05:10:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPG9O-0000tf-PD; Tue, 11 Oct 2005 05:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPG9M-0000tW-Qz for nsis@megatron.ietf.org; Tue, 11 Oct 2005 05:10:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09343 for ; Tue, 11 Oct 2005 05:10:18 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPGJQ-0001gC-KQ for nsis@ietf.org; Tue, 11 Oct 2005 05:20:46 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9B9A6XZ019093; Tue, 11 Oct 2005 11:10:06 +0200 (MEST) Message-ID: <006d01c5ce43$934c0290$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Martin Stiemerling" , "Hancock, Robert" References: <21308534E6B4956A7F0B0735@[10.1.1.109]> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query Date: Tue, 11 Oct 2005 11:07:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.525 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 11 Oct 2005 11:10:07 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: s0076309@student.utwente.nl, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Martin I think that your example is not very clear! Please note that during the discovery phase it is assumed that the querying and responding node do not have to create the GIST routing state. Thus your example is valid for both GIST stateless and GIST stateful responding nodes. Please note however, that the sending node will wait for a timeout, and if no GIST-Response arrives in time, then it will resend the complete GIST QUERY message including the payload. Please also note that if the GIST responding node receives the GIST_QUERY message, it will send the payload to the appropriate NSLP. Thus even during the first GIST-QUERY the NSLP-DATA will be forwarded to the NSLP. But anyway, you raised a good point! The real problem that occurs due to the stateless GIST responding node is that the GIST queying node will keep retransmiting the GIST-QUERY message! Therefore, I think that it is needed to specify a way such that the stateless GIST responding node will inform the GIST querying node that the GIST responding node is a stateless node. Best Regards, Mayi and Georgios ----- Original Message ----- From: "Martin Stiemerling" To: "nsis" Sent: Tuesday, October 11, 2005 10:08 AM Subject: [NSIS] NSLP-Data in intial GIST-Query > Hi, > > GIST-Query messages may carry a NSLP-Data object containing information > for the NSLP. I'm now assuming an initial GIST-Query send downstream > looking for the next peer., carrying NSLP-Data, and a GIST downstream node > using a stateless approach (delayed state setup, using a responder > cookie ). In this case, the NSLP data would be lost, if not re-transmitted > in the GIST-Confirm/GIST-Data later, since the downstream peer does not > keep any state about the initial GIST-Query. There is no text (as far as I > know) describing what the sending GIST-peer should do in this case. In the > case of a "stateless" downstream peer (querying node sees response with > responder cookie and R-flag set), the querying must re-send the NSLP-data > in the next message. > > I may have missed something while reading the draft, but this issue was > coming to mind afterwards. > > With best regards, > > Martin > > _______________________________________________ > 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 nsis-bounces@ietf.org Tue Oct 11 05:14:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGDG-0001lo-42; Tue, 11 Oct 2005 05:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGDE-0001lS-2i for nsis@megatron.ietf.org; Tue, 11 Oct 2005 05:14:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09517 for ; Tue, 11 Oct 2005 05:14:17 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPGNH-0001mp-QE for nsis@ietf.org; Tue, 11 Oct 2005 05:24:45 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9B9EEMp019404; Tue, 11 Oct 2005 11:14:14 +0200 (MEST) Message-ID: <006e01c5ce44$27530f60$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Date: Tue, 11 Oct 2005 11:14:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.523 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 11 Oct 2005 11:14:16 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: "Nsis \(E-mail\)" Subject: [NSIS] probably new open issue X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert I have a problem with section A.4.4.5 in the GIST draft, see below, and in particular related to the way of how a GIST-DATA message is treated by a stateless GIST responding node. It will be good to clarify what it is meant, in Section A.4.4.5, by the term unexpected Data message. Please note that a stateless GIST responding node MUST be able to receive a GIST DATA message without that this will generate an error situation. ------------------------- A.4.4.5. No Routing State Class: Protocol-Error Code: 5 Additional Info: None This message is sent if a node receives a message for which there is no matching routing state (and therefore no appropriate Q/R-SM). This can occur either at a Querying node which receives an unexpected Response message, or at a Responding node which receives an unexpected Data message. ------------------------------ Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 05:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGHX-0002gj-96; Tue, 11 Oct 2005 05:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGHV-0002gb-Iy for nsis@megatron.ietf.org; Tue, 11 Oct 2005 05:18:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09673 for ; Tue, 11 Oct 2005 05:18:43 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPGRX-0001sE-Fb for nsis@ietf.org; Tue, 11 Oct 2005 05:29:10 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9B9IYxK023432 for ; Tue, 11 Oct 2005 12:18:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Oct 2005 12:18:37 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Oct 2005 12:18:37 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2005 12:18:36 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D011421D4@esebe100.NOE.Nokia.com> Thread-Topic: IETF 56 - NSIS agenda Thread-Index: AcXORMJCWt8t+WAkTy2ZdK30FUiYgw== To: X-OriginalArrivalTime: 11 Oct 2005 09:18:37.0666 (UTC) FILETIME=[C31FB420:01C5CE44] X-Spam-Score: 0.4 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Subject: [NSIS] IETF 56 - NSIS agenda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, This is an open call for meeting items for the IETF meeting in Vancouver. I have a strong preference for giving time to existing wg items, to make sure we make forward progress on them. For non-working group drafts, please send me a request with some explaination on why meeting time is useful for discussion the draft. Send to me: Draft name Presenter name time needed. thanks, JOhn _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 05:42:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGeU-0007hY-4A; Tue, 11 Oct 2005 05:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGeS-0007hT-0k for nsis@megatron.ietf.org; Tue, 11 Oct 2005 05:42:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10493 for ; Tue, 11 Oct 2005 05:42:24 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPGoU-0002RB-O0 for nsis@ietf.org; Tue, 11 Oct 2005 05:52:53 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j9B9gH0P019794; Tue, 11 Oct 2005 11:42:17 +0200 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j9B9gHxe008196; Tue, 11 Oct 2005 11:42:17 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 11:42:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [NSIS] remove packet_classifier object from QoS-NSLP Date: Tue, 11 Oct 2005 11:42:12 +0200 Message-ID: <391E6FBF5E786940B9E2F7CA6376C708DE4489@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXNjiBvnn/CxKhUQLKOXYbVik+YCQAsQXkAAAI1zPA= From: "Kappler, Cornelia" To: "Georgios Karagiannis" X-OriginalArrivalTime: 11 Oct 2005 09:42:16.0215 (UTC) FILETIME=[10A51A70:01C5CE48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios,=20 if indeed the packet classifier is QSPEC / QoS Model dependent, and we would need stacked packet classifiers as well as stacked QSPECs it would make sense to include it in the QSPEC. However I dont understand why you would use separate packet classfiers for stacked QSPECs (one of them e.g. e2e QSPEC, the other a domain-specific RMD QSPEC). The packet classfier specifies what packets receive the treatment described in the QSPEC. I'd rather expect that for a given QoS NSLP message, the packets being singled out for treatment are always the same (no matter what QoS Model is used to reserve resources).=20 Can you make your example more concrete? Cornelia > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Georgios Karagiannis > Sent: Montag, 10. Oktober 2005 13:28 > To: john.loughney@nokia.com; robert.hancock@roke.co.uk;=20 > Tschofenig, Hannes; jmanner@cs.Helsinki.FI > Cc: nsis@ietf.org > Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 > Hi John >=20 > I do not have any problem on including this object in the QSPEC. >=20 > Please note that the packet classifier functionality is strict > associated with a QoS model. A PACKET_CLASSIFIER object=20 > specifies which > filter should be used by the packet classifier functionlaity on > filtering the user data packets. > Suppose now that for the same session two qos models are=20 > used, one that > goes end-to-end and the other one that goes edge to edge within a > domain. Note that this is the case when stacking of QSPEC's is used. > If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter > information should this object contain, the filter=20 > information required > by the end-to-end QoS model or the edge-to-edge QoS model? >=20 > In this case this problem can be solved by making the=20 > PACKET_CLASSIFIER=20 > object in the > stackable! > Do we want this? >=20 > Another solution is to introduce the PACKET_CLASSIFIER object=20 > into the=20 > QSPEC. >=20 > Best regards, > Georgios >=20 > ----- Original Message -----=20 > From: > To: ; ;=20 > ; > Cc: > Sent: Monday, October 10, 2005 12:46 PM > Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 > > whether this data should be in the qos-nslp or qspec is less > > clear to me. the concept in my head has always been that the > > qos-nslp carried everything about *what* resource reservation > > action you wanted to carry out, and the qspec was about how > > much "stuff" you actually wanted to reserve. the packet classifier > > needs to be given in every message about a transaction, whereas > > the "how much" information only in some; and the classifier can > > probably be universal, whereas the qspec need not be. I don't > > see why having it in the qos-nslp is hard. > > > > This is where I thought we left it after the interim=20 > meeting. I guess > > if we remove it, I'd like to have some more reasoning behind the > > removal. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 05:55:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGqh-0002Gv-F4; Tue, 11 Oct 2005 05:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGqf-0002GT-FH for nsis@megatron.ietf.org; Tue, 11 Oct 2005 05:55:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11023 for ; Tue, 11 Oct 2005 05:55:02 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPH0k-0002ll-N9 for nsis@ietf.org; Tue, 11 Oct 2005 06:05:31 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9B9t1Qc021772; Tue, 11 Oct 2005 11:55:01 +0200 (MEST) Message-ID: <00a701c5ce49$d9882580$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Kappler, Cornelia" References: <391E6FBF5E786940B9E2F7CA6376C708DE4489@blns00fa.ww002.siemens.net> Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP Date: Tue, 11 Oct 2005 11:54:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.522 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 11 Oct 2005 11:55:02 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cornelia Please see in line! ----- Original Message ----- From: "Kappler, Cornelia" To: "Georgios Karagiannis" Cc: Sent: Tuesday, October 11, 2005 11:42 AM Subject: FW: [NSIS] remove packet_classifier object from QoS-NSLP > Hi Georgios, > > if indeed the packet classifier is QSPEC / QoS Model dependent, and we > would need stacked packet classifiers as well as stacked QSPECs it would > make sense to include it in the QSPEC. > > However I dont understand why you would use separate packet classfiers > for stacked QSPECs (one of them e.g. e2e QSPEC, the other a > domain-specific RMD QSPEC). The packet classfier specifies what packets > receive the treatment described in the QSPEC. Georgios: Please note that this does not apply to RMD. Regarding the packet classifier, the packet classifier should know what kind of filtering should use on the user data packets. For example: * in a Intserv based model, the flow ID will be used to filter the user data packest and associate them with the Intserv based RMF reservation state * in another QoS model, the combination of IP source address and DSCP might be used to filter the user data packets and associate them with the RMF reservation state The packet classifier can get this knowledge by: * local policy, configuring the node to associate the RMF reservation state with all user data packets that are filtered based on a predefined and configured rule * using signaling, where the QNE that activates the signaling related to a QoS model, for example QoS model A, and if needed stacks a QSPEC (for QoS model A, is also including the type of the filter that all QNE's using the QoS model A, will have to use! > I'd rather expect that for > a given QoS NSLP message, the packets being singled out for treatment > are always the same (no matter what QoS Model is used to reserve > resources). > > Can you make your example more concrete? Georgios: The filtering/packet classification of the user data packets depends on the QoS model used, see above! When for the same session, a e2e QoS model is used in combination with a local QoS model, that use stacking of QSPECs, a problem will ocuur if the PACKET_CLASSIFIER will either not be stacked or included in the QSPEC (it this way relating each QSPEC to one PACKET CLASSIFIER). Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 06:01:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGwr-0003hF-Ec; Tue, 11 Oct 2005 06:01:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPGwp-0003fr-IW for nsis@megatron.ietf.org; Tue, 11 Oct 2005 06:01:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11271 for ; Tue, 11 Oct 2005 06:01:24 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPH6r-0002ud-G3 for nsis@ietf.org; Tue, 11 Oct 2005 06:11:53 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9BA0fL5006086; Tue, 11 Oct 2005 11:00:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2005 11:00:41 +0100 Message-ID: Thread-Topic: probably new open issue Thread-Index: AcXORDWRf4xIUuTHSV29UYxjNd9wcAABkvwA From: "Hancock, Robert" To: "Georgios Karagiannis" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: "Nsis \(E-mail\)" Subject: [NSIS] RE: probably new open issue X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi georgios, i've added this (and a couple of other points) as a new issue: http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue73 basically, the error message means "There is no routing state *when there should be*" and the text needs to be updated to say that. r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 11 October 2005 10:14 > To: Hancock, Robert > Cc: Nsis (E-mail) > Subject: probably new open issue >=20 >=20 > Hi Robert >=20 >=20 > I have a problem with section A.4.4.5 in the GIST draft, see=20 > below, and in=20 > particular related to > the way of how a GIST-DATA message is treated by a stateless=20 > GIST responding=20 > node. > It will be good to clarify what it is meant, in Section=20 > A.4.4.5, by the term=20 > unexpected Data message. >=20 > Please note that a stateless GIST responding node MUST be=20 > able to receive a=20 > GIST DATA > message without that this will generate an error situation. >=20 >=20 >=20 > ------------------------- >=20 > A.4.4.5. No Routing State >=20 > Class: Protocol-Error > Code: 5 > Additional Info: None >=20 > This message is sent if a node receives a message for=20 > which there is > no matching routing state (and therefore no appropriate Q/R-SM). > This can occur either at a Querying node which receives an=20 > unexpected > Response message, or at a Responding node which receives an > unexpected Data message. >=20 > ------------------------------ >=20 > Best regards, > Georgios >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 06:54:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPHlt-0007RU-Rp; Tue, 11 Oct 2005 06:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPHlr-0007RG-Mh for nsis@megatron.ietf.org; Tue, 11 Oct 2005 06:54:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13873 for ; Tue, 11 Oct 2005 06:54:08 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPHvx-0004KH-6G for nsis@ietf.org; Tue, 11 Oct 2005 07:04:37 -0400 Received: (qmail invoked by alias); 11 Oct 2005 10:54:00 -0000 Received: from p54A30354.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.3.84] by mail.gmx.net (mp024) with SMTP; 11 Oct 2005 12:54:00 +0200 X-Authenticated: #4469397 Message-ID: <434B99CC.80903@gmx.li> Date: Tue, 11 Oct 2005 12:54:04 +0200 From: Thomas Herzog User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] NSLP-Data in intial GIST-Query References: <21308534E6B4956A7F0B0735@[10.1.1.109]> <006d01c5ce43$934c0290$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <006d01c5ce43$934c0290$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , s0076309@student.utwente.nl, nsis , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Georgios, I think Martin referred to a stateful responder node which is set up for late state installation. In this case, the responder node will not keep *ANY* state and only dispatch a Response which contains the responder cookie and R-flag set to request a Confirm. The question now arisen was rather: Would the Responder node pass the NSLP data payload which MAY be included in the Query to it's NSLP? Let's look at the state machine definitions in Draft-08: For the stateless responder node approach, draft-08 includes a rule in the Node State Machine (6.1), that incoming GIST DATA messages should be passed to the appropriate NSLP instance, if there is no state associated with the message peer: Rule 4 (rx_Data): pass directly to NSLP In the case of a stateless responder node, it would in my opinion always dispatch at least a response, even if it keeps no state, so the querying Node would stop transmitting queries: Rule 1 (rx_Query): if (routing state can be created without a full 3-way handshake) then create R-SM and pass message to it else send Response However, maybe one should include here "routing state to be set up and this can be created without a full 3-way handshake" in the "if" instruction. So finally: it is not stated that the POSSIBLE payload in a Query is passed to the NSLP instance in the State Machine definitions. Responder Node State Machine rules 1 and 5 do not specify that there is something to do with included payload in Query Messages. However, it is allowed to include NSLP data payload in initial GIST QUERY and also RESPONSE/CONFIRM messages. The draft does not state what to do with this payload in the state machine definitions. In another section, the draft states, that GIST MAY do this or that (check with NSLP in case of ongoing Message Association setup and include NSLP data in the response). A node which is set up stateful and for late state setup could even send the NSLP data payload back in the response so the Querying Node could include it in the Confirm without remembering it....I think the state machine definitions are somewhat lacking to as what to exactly do with NSLP data payload in Messages other than GIST DATA. (an implementation could even decide to totally ignore NSLP data payload in these Messages and not to use it for it's own processing at all?!?!?) Cheers, Thomas Georgios Karagiannis wrote: > Hi Martin > > I think that your example is not very clear! > Please note that during the discovery phase it is assumed that the > querying and responding node do not have to create the GIST routing > state. > > Thus your example is valid for both GIST stateless and GIST stateful > responding nodes. > Please note however, that the sending node will wait for a timeout, > and if no GIST-Response arrives in time, > then it will resend the complete GIST QUERY message including the > payload. > Please also note that if the GIST responding node receives the > GIST_QUERY message, > it will send the payload to the appropriate NSLP. Thus even during the > first GIST-QUERY the NSLP-DATA > will be forwarded to the NSLP. > > But anyway, you raised a good point! > The real problem that occurs due to the stateless GIST responding node > is that the > GIST queying node will keep retransmiting the GIST-QUERY message! > > Therefore, I think that it is needed to specify a way such that the > stateless GIST responding node > will inform the GIST querying node that the GIST responding node is a > stateless node. > > Best Regards, > Mayi and Georgios > > > ----- Original Message ----- From: "Martin Stiemerling" > > To: "nsis" > Sent: Tuesday, October 11, 2005 10:08 AM > Subject: [NSIS] NSLP-Data in intial GIST-Query > > >> Hi, >> >> GIST-Query messages may carry a NSLP-Data object containing >> information for the NSLP. I'm now assuming an initial GIST-Query send >> downstream looking for the next peer., carrying NSLP-Data, and a GIST >> downstream node using a stateless approach (delayed state setup, >> using a responder cookie ). In this case, the NSLP data would be >> lost, if not re-transmitted in the GIST-Confirm/GIST-Data later, >> since the downstream peer does not keep any state about the initial >> GIST-Query. There is no text (as far as I know) describing what the >> sending GIST-peer should do in this case. In the case of a >> "stateless" downstream peer (querying node sees response with >> responder cookie and R-flag set), the querying must re-send the >> NSLP-data in the next message. >> >> I may have missed something while reading the draft, but this issue >> was coming to mind afterwards. >> >> With best regards, >> >> Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 07:26:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIH4-0006AP-NJ; Tue, 11 Oct 2005 07:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIH3-0006AA-53 for nsis@megatron.ietf.org; Tue, 11 Oct 2005 07:26:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15350 for ; Tue, 11 Oct 2005 07:26:23 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPIQw-00059p-UD for nsis@ietf.org; Tue, 11 Oct 2005 07:36:39 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j9BBQ91V030498; Tue, 11 Oct 2005 13:26:09 +0200 Received: from mhpahx2c.ww002.siemens.net (mhpahx2c.mch.sbs.de [139.25.165.55]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j9BBQ8mw008853; Tue, 11 Oct 2005 13:26:08 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx2c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 Oct 2005 13:26:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Date: Tue, 11 Oct 2005 13:26:07 +0200 Message-ID: <391E6FBF5E786940B9E2F7CA6376C708DE4495@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXOSfM2DOYvQBjyTn+Jli9v2N+HLwACrewg From: "Kappler, Cornelia" To: "Georgios Karagiannis" X-OriginalArrivalTime: 11 Oct 2005 11:26:08.0486 (UTC) FILETIME=[935E3060:01C5CE56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios,=20 when including two or more packet filters, how do we make sure that for a single QoS NSLP session, it is always the same set of packets which is receiving the reservation benefits? If filtering is based on DSCP/source address in one domain, and based on the flow ID in another domain, it might well happen that a specific packet receives QoS only in one domain.=20 Do we want that? Or am I missing something? Cornelia > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Dienstag, 11. Oktober 2005 11:55 > To: Kappler, Cornelia > Cc: nsis@ietf.org > Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 > Hi Cornelia >=20 > Please see in line! >=20 > ----- Original Message -----=20 > From: "Kappler, Cornelia" > To: "Georgios Karagiannis" > Cc: > Sent: Tuesday, October 11, 2005 11:42 AM > Subject: FW: [NSIS] remove packet_classifier object from QoS-NSLP >=20 >=20 > > Hi Georgios, > > > > if indeed the packet classifier is QSPEC / QoS Model=20 > dependent, and we > > would need stacked packet classifiers as well as stacked=20 > QSPECs it would > > make sense to include it in the QSPEC. > > > > However I dont understand why you would use separate packet=20 > classfiers > > for stacked QSPECs (one of them e.g. e2e QSPEC, the other a > > domain-specific RMD QSPEC). The packet classfier specifies=20 > what packets > > receive the treatment described in the QSPEC. >=20 > Georgios: Please note that this does not apply to RMD. > Regarding the packet classifier, the packet classifier should=20 > know what kind > of filtering should use on the user data packets. > For example: > * in a Intserv based model, the flow ID will be used to=20 > filter the user > data packest and associate them with the > Intserv based RMF reservation state > * in another QoS model, the combination of IP source address=20 > and DSCP might=20 > be > used to filter the user data > packets and associate them with the RMF reservation state >=20 > The packet classifier can get this knowledge by: > * local policy, configuring the node to associate the RMF=20 > reservation > state with all user data packets that are filtered > based on a predefined and configured rule > * using signaling, where the QNE that activates the signaling=20 > related to a > QoS model, for example QoS model A, > and if needed stacks a QSPEC (for QoS model A, > is also including the type of the filter that all QNE's using=20 > the QoS model > A, will have to use! >=20 >=20 > > I'd rather expect that for > > a given QoS NSLP message, the packets being singled out for=20 > treatment > > are always the same (no matter what QoS Model is used to reserve > > resources). > > > > Can you make your example more concrete? >=20 >=20 > Georgios: The filtering/packet classification of the user data packets > depends on the QoS model used, see above! > When for the same session, a e2e QoS model is used in=20 > combination with a > local QoS model, > that use stacking of QSPECs, a problem will ocuur > if the PACKET_CLASSIFIER will either not be stacked or=20 > included in the QSPEC > (it this way relating each QSPEC to one PACKET CLASSIFIER). >=20 > Best regards, > Georgios >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 08:43:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJTC-0000cz-S1; Tue, 11 Oct 2005 08:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJTA-0000cT-Ob for nsis@megatron.ietf.org; Tue, 11 Oct 2005 08:43:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20328 for ; Tue, 11 Oct 2005 08:42:58 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPJdE-0007bM-QF for nsis@ietf.org; Tue, 11 Oct 2005 08:53:27 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 11 Oct 2005 08:42:47 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101108424727582 ; Tue, 11 Oct 2005 08:42:47 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Tue, 11 Oct 2005 08:42:47 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Oct 2005 08:46:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Date: Tue, 11 Oct 2005 08:46:04 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8667264D2@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXNjiBvnn/CxKhUQLKOXYbVik+YCQAsQXkAAAI1zPAABVlQaA== From: "Roy, Radhika \(AEAD\)" To: "Georgios Karagiannis" X-OriginalArrivalTime: 11 Oct 2005 12:46:24.0453 (UTC) FILETIME=[C9E86F50:01C5CE61] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697241837==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0697241837== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CE61.BE1F68EA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CE61.BE1F68EA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all: =20 QSEPC is the "generalized" QoS templates and does not deal with anything = beyond that per charter of NSIS protocol. There should be nothing beyond = that. For example, NSIS signaling protocol does not deal with any domain = or restrictions on values on QoS parameters. There is nothing e2e QSPEC = vs domain-specific QSPEC. =20 The "use" of QoS models is a separate thing, and it has created = confusions for NSIS signaling protocols, like RSVP or DiffServ, are = "generic" and does not deal with implementation specific QoS models that = are limited by specific values and/or domains. =20 It is interesting to see that the co-authors of the QSPEC have come = forward to defend their wisdom for using of implementation-specific, = incomplete QoS models extensions described in "generalized" QSPEC. Now, = they are saying Georgios, why he is proposing e2e QSPEC vs domain = specific QSPEC. =20 The answer is as follows: 1.=09 The use of QSPEC will be treated in the context of the generalized NSIS = signaling protocol that does not restrict with e2e or domain. 2.=09 Any implementations can be any QoS model specific and/or Domain = specific. 3.=09 Confusions come when people mix item 1 with item 2. 4.=09 Present (latest version) QSPEC draft itself is source of all = confusions. Present QSPEC draft mixes item 1 with item 2. So, this draft = needs to delete any references to item 2. Item 2 needs to have separate = drafts how to deal with specific implementations of QoS signaling models = using the generalized QSPEC templates. 5.=09 In implementations, there can be a combination of many things: a. e2e = (codec-to-codec from application point of view), b. edge-to-edge, c. = Backbone network (excluding access networks), and/or others. Here comes = all sorts of implementation complexities. Item 5 shows why e2e NSIS protocol may need to deal with different = things that may consist of both e2e and non-e2e.=20 In the discussions, let us focus on what we are going to deal with. Let = us NOT confuse ourselves like the latest QSPEC draft that deals with = both generalized QSPEC and implementation-specific QoS models. Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Kappler, Cornelia Sent: Tue 10/11/2005 5:42 AM To: Georgios Karagiannis Cc: nsis@ietf.org Subject: FW: [NSIS] remove packet_classifier object from QoS-NSLP Hi Georgios, if indeed the packet classifier is QSPEC / QoS Model dependent, and we would need stacked packet classifiers as well as stacked QSPECs it would make sense to include it in the QSPEC. However I dont understand why you would use separate packet classfiers for stacked QSPECs (one of them e.g. e2e QSPEC, the other a domain-specific RMD QSPEC). The packet classfier specifies what packets receive the treatment described in the QSPEC. I'd rather expect that for a given QoS NSLP message, the packets being singled out for treatment are always the same (no matter what QoS Model is used to reserve resources). Can you make your example more concrete? Cornelia > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Montag, 10. Oktober 2005 13:28 > To: john.loughney@nokia.com; robert.hancock@roke.co.uk; > Tschofenig, Hannes; jmanner@cs.Helsinki.FI > Cc: nsis@ietf.org > Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP > > > Hi John > > I do not have any problem on including this object in the QSPEC. > > Please note that the packet classifier functionality is strict > associated with a QoS model. A PACKET_CLASSIFIER object > specifies which > filter should be used by the packet classifier functionlaity on > filtering the user data packets. > Suppose now that for the same session two qos models are > used, one that > goes end-to-end and the other one that goes edge to edge within a > domain. Note that this is the case when stacking of QSPEC's is used. > If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter > information should this object contain, the filter > information required > by the end-to-end QoS model or the edge-to-edge QoS model? > > In this case this problem can be solved by making the > PACKET_CLASSIFIER > object in the > stackable! > Do we want this? > > Another solution is to introduce the PACKET_CLASSIFIER object > into the > QSPEC. > > Best regards, > Georgios > > ----- Original Message ----- > From: > To: ; ; > ; > Cc: > Sent: Monday, October 10, 2005 12:46 PM > Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > > > > whether this data should be in the qos-nslp or qspec is less > > clear to me. the concept in my head has always been that the > > qos-nslp carried everything about *what* resource reservation > > action you wanted to carry out, and the qspec was about how > > much "stuff" you actually wanted to reserve. the packet classifier > > needs to be given in every message about a transaction, whereas > > the "how much" information only in some; and the classifier can > > probably be universal, whereas the qspec need not be. I don't > > see why having it in the qos-nslp is hard. > > > > This is where I thought we left it after the interim > meeting. I guess > > if we remove it, I'd like to have some more reasoning behind the > > removal. > > > > John ------_=_NextPart_001_01C5CE61.BE1F68EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= FW: [NSIS] remove packet_classifier object from QoS-NSLP=0A= =0A= =0A=
Hi, = all:
=0A=
 
=0A=
QSEPC is the "generalized" = QoS templates =0A= and does not deal with anything beyond that per charter = of NSIS =0A= protocol. There should be nothing beyond that. For example, = NSIS =0A= signaling protocol does not deal with any domain or restrictions on = values on =0A= QoS parameters. There is nothing e2e QSPEC vs domain-specific =0A= QSPEC.
=0A=
 
=0A=
The "use" of QoS models is a = separate =0A= thing, and it has created confusions for NSIS signaling protocols, like = RSVP or =0A= DiffServ, are "generic" and does not deal with implementation specific = QoS =0A= models that are limited by specific values and/or domains.
=0A=
 
=0A=
It is interesting to see that = the =0A= co-authors of the QSPEC have come forward to defend their wisdom for = using of =0A= implementation-specific, incomplete QoS models extensions described = in =0A= "generalized" QSPEC. Now, they are saying Georgios, why he is proposing = e2e =0A= QSPEC vs domain specific QSPEC.
=0A=
 
=0A=
The answer is as = follows:
=0A=
=0A=
    =0A=
  1. =0A=
    The use of QSPEC will be treated in = the context =0A= of the generalized NSIS signaling protocol that does not restrict = with =0A= e2e or domain.
    2. =0A=
  2. =0A=
    Any implementations can be any QoS = model specific =0A= and/or Domain specific.
    3. =0A=
  3. =0A=
    Confusions come when people mix = item 1 with =0A= item 2.
    4. =0A=
  4. =0A=
    Present (latest version) QSPEC = draft itself =0A= is source of all confusions. Present QSPEC draft mixes item 1 with = item 2. So, =0A= this draft needs to delete any references to item 2. Item 2 needs to = have =0A= separate drafts how to deal with specific implementations of QoS = signaling =0A= models using the generalized QSPEC templates.
    5. =0A=
  5. =0A=
    In implementations, there can be a = combination of =0A= many things: a. e2e (codec-to-codec from application point of view), = b. =0A= edge-to-edge, c. Backbone network (excluding access networks), and/or = others. =0A= Here comes all sorts of implementation =0A= complexities.
=0A=

Item 5 shows why e2e NSIS protocol may = need to deal =0A= with different things that may consist of both e2e and non-e2e. =

=0A=

In the discussions, let us focus on what = we are going =0A= to deal with. Let us NOT confuse ourselves like the latest QSPEC draft = that =0A= deals with both generalized QSPEC and implementation-specific QoS =0A= models.

=0A=

Best regards,

=0A=

Radhika

=0A=

=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on =0A= behalf of Kappler, Cornelia
Sent: Tue 10/11/2005 5:42 = AM
To: =0A= Georgios Karagiannis
Cc: nsis@ietf.org
Subject: FW: = [NSIS] =0A= remove packet_classifier object from QoS-NSLP

=0A=
=0A=

Hi Georgios,

if indeed the packet classifier is = QSPEC / =0A= QoS Model dependent, and we
would need stacked packet classifiers as = well as =0A= stacked QSPECs it would
make sense to include it in the = QSPEC.

However =0A= I dont understand why you would use separate packet classfiers
for = stacked =0A= QSPECs (one of them e.g. e2e QSPEC, the other a
domain-specific RMD = QSPEC). =0A= The packet classfier specifies what packets
receive the treatment = described =0A= in the QSPEC. I'd rather expect that for
a given QoS NSLP message, = the =0A= packets being singled out for treatment
are always the same (no = matter what =0A= QoS Model is used to reserve
resources).

Can you make your = example =0A= more concrete?

Cornelia

> -----Original = Message-----
> =0A= From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> =0A= Behalf Of Georgios Karagiannis
> Sent: Montag, 10. Oktober 2005 =0A= 13:28
> To: john.loughney@nokia.com; = robert.hancock@roke.co.uk;
> =0A= Tschofenig, Hannes; jmanner@cs.Helsinki.FI
> Cc: = nsis@ietf.org
> =0A= Subject: Re: [NSIS] remove packet_classifier object from =0A= QoS-NSLP
>
>
> Hi John
>
> I do not have = any =0A= problem on including this object in the QSPEC.
>
> Please = note that =0A= the packet classifier functionality is strict
> associated with a = QoS =0A= model. A PACKET_CLASSIFIER object
> specifies which
> filter = should =0A= be used by the packet classifier functionlaity on
> filtering the = user =0A= data packets.
> Suppose now that for the same session two qos = models =0A= are
> used, one that
> goes end-to-end and the other one = that goes =0A= edge to edge within a
> domain. Note that this is the case when = stacking =0A= of QSPEC's is used.
> If the PACKET_CLASSIFIER object is a = QOS-NSLP =0A= object, which filter
> information should this object contain, the =0A= filter
> information required
> by the end-to-end QoS model = or the =0A= edge-to-edge QoS model?
>
> In this case this problem can be = solved =0A= by making the
> PACKET_CLASSIFIER
> object in  = the
> =0A= stackable!
> Do we want this?
>
> Another solution is = to =0A= introduce the PACKET_CLASSIFIER object
> into the
> =0A= QSPEC.
>
> Best regards,
> Georgios
>
> = ----- =0A= Original Message -----
> From: = <john.loughney@nokia.com>
> To: =0A= <robert.hancock@roke.co.uk>; =0A= <hannes.tschofenig@siemens.com>;
> = <jmanner@cs.Helsinki.FI>; =0A= <karagian@cs.utwente.nl>
> Cc: <nsis@ietf.org>
> = Sent: =0A= Monday, October 10, 2005 12:46 PM
> Subject: RE: [NSIS] remove =0A= packet_classifier object from QoS-NSLP
>
>
> > = whether this =0A= data should be in the qos-nslp or qspec is less
> > clear to = me. the =0A= concept in my head has always been that the
> > qos-nslp = carried =0A= everything about *what* resource reservation
> > action you = wanted to =0A= carry out, and the qspec was about how
> > much "stuff" you = actually =0A= wanted to reserve. the packet classifier
> > needs to be given = in every =0A= message about a transaction, whereas
> > the "how much" = information =0A= only in some; and the classifier can
> > probably be universal, = whereas =0A= the qspec need not be. I don't
> > see why having it in the = qos-nslp is =0A= hard.
> >
> > This is where I thought we left it after = the =0A= interim
> meeting. I guess
> > if we remove it, I'd like = to have =0A= some more reasoning behind the
> > removal.
> = >
> > =0A= John

=0A= =0A= =0A= ------_=_NextPart_001_01C5CE61.BE1F68EA-- --===============0697241837== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0697241837==-- From nsis-bounces@ietf.org Tue Oct 11 08:53:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJcq-00039g-53; Tue, 11 Oct 2005 08:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJco-00039N-6M for nsis@megatron.ietf.org; Tue, 11 Oct 2005 08:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21159 for ; Tue, 11 Oct 2005 08:52:56 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPJmu-0007zl-02 for nsis@ietf.org; Tue, 11 Oct 2005 09:03:25 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9BCqr4m002281; Tue, 11 Oct 2005 14:52:53 +0200 (MEST) Message-ID: <00d201c5ce62$b28d9ff0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Kappler, Cornelia" References: <391E6FBF5E786940B9E2F7CA6376C708DE4495@blns00fa.ww002.siemens.net> Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP Date: Tue, 11 Oct 2005 14:52:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.521 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 11 Oct 2005 14:52:54 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cornelia Please see in line! ----- Original Message ----- From: "Kappler, Cornelia" To: "Georgios Karagiannis" Cc: Sent: Tuesday, October 11, 2005 1:26 PM Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > Hi Georgios, > > when including two or more packet filters, how do we make sure that for > a single QoS NSLP session, it is always the same set of packets which > is receiving the reservation benefits? Georgios: In a domain that supports a QoS model we should use only one filter/packet classifier. > If filtering is based on DSCP/source address in one domain, and based on > the flow ID in another domain, it might well happen that a specific > packet receives QoS only in one domain. Georgios: this occurs in the case when during an end to end path more than one heterogeneous QoS models are used. If a QoS model supports aggregation and another does not then a different type of filtering/packet classification must be used. This means that different filters/packet classifiers should be used per QoS model! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 09:13:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJx3-0000bI-S4; Tue, 11 Oct 2005 09:13:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJx2-0000b3-7A for nsis@megatron.ietf.org; Tue, 11 Oct 2005 09:13:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22335 for ; Tue, 11 Oct 2005 09:13:50 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPK78-00007z-QW for nsis@ietf.org; Tue, 11 Oct 2005 09:24:19 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9BDD1L5026107; Tue, 11 Oct 2005 14:13:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSLP-Data in intial GIST-Query Date: Tue, 11 Oct 2005 14:13:01 +0100 Message-ID: Thread-Topic: [NSIS] NSLP-Data in intial GIST-Query Thread-Index: AcXOQ7JsGX/Yod6PTISCAw/kKEGuIwAIEYcA From: "Hancock, Robert" To: "Georgios Karagiannis" , "Martin Stiemerling" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 1.1 (+) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: s0076309@student.utwente.nl, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all, there will be a separate answer to Martin's original point (in fact, in an answer to Thomas's answer ...). But there are some specific points here too. Inline: > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 11 October 2005 10:07 > To: Martin Stiemerling; Hancock, Robert > Cc: nsis; s0076309@student.utwente.nl > Subject: Re: [NSIS] NSLP-Data in intial GIST-Query >=20 >=20 > Hi Martin >=20 > I think that your example is not very clear! > Please note that during the discovery phase it is assumed that the > querying and responding node do not have to create the GIST=20 > routing state. In the discovery phase (if discovery is happening), the Querying node *has* to create state at the start; the Responding node can do so in a delayed way (as we all know). >=20 > Thus your example is valid for both GIST stateless and GIST stateful=20 > responding nodes. > Please note however, that the sending node will wait for a=20 > timeout, and if=20 > no GIST-Response arrives in time, > then it will resend the complete GIST QUERY message=20 > including the payload. > Please also note that if the GIST responding node receives=20 > the GIST_QUERY=20 > message, > it will send the payload to the appropriate NSLP. Thus even=20 > during the first=20 > GIST-QUERY the NSLP-DATA > will be forwarded to the NSLP. This is true. >=20 > But anyway, you raised a good point! > The real problem that occurs due to the stateless GIST=20 > responding node is=20 > that the > GIST queying node will keep retransmiting the GIST-QUERY message! This is not quite true. >=20 > Therefore, I think that it is needed to specify a way such that the=20 > stateless GIST responding node > will inform the GIST querying node that the GIST responding node is a=20 > stateless node. This is definitely not true. The situation is described in 4.3.2: a GIST node which is stateless in this way will forward the Query downstream, possibly with a revised payload; when this hits a stateful node, the Response will come back. The stateless node MUST NOT send anything back saying 'I am stateless' because then the Querying node would see two (or in general 1+N) replies to its message, all but one of them being failures. The querying node doesn't care about the existence of the stateless nodes anyway (at the GIST level). If the Query is lost before it gets to the stateful Responder, or if the Response is lost on the way back, or if there is no stateful Responder in the first place, the original Query will be resent. r. >=20 > Best Regards, > Mayi and Georgios >=20 >=20 > ----- Original Message -----=20 > From: "Martin Stiemerling" > To: "nsis" > Sent: Tuesday, October 11, 2005 10:08 AM > Subject: [NSIS] NSLP-Data in intial GIST-Query >=20 >=20 > > Hi, > > > > GIST-Query messages may carry a NSLP-Data object containing=20 > information=20 > > for the NSLP. I'm now assuming an initial GIST-Query send=20 > downstream=20 > > looking for the next peer., carrying NSLP-Data, and a GIST=20 > downstream node=20 > > using a stateless approach (delayed state setup, using a responder=20 > > cookie ). In this case, the NSLP data would be lost, if not=20 > re-transmitted=20 > > in the GIST-Confirm/GIST-Data later, since the downstream=20 > peer does not=20 > > keep any state about the initial GIST-Query. There is no=20 > text (as far as I=20 > > know) describing what the sending GIST-peer should do in=20 > this case. In the=20 > > case of a "stateless" downstream peer (querying node sees=20 > response with=20 > > responder cookie and R-flag set), the querying must re-send=20 > the NSLP-data=20 > > in the next message. > > > > I may have missed something while reading the draft, but=20 > this issue was=20 > > coming to mind afterwards. > > > > With best regards, > > > > Martin > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 09:17:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPK0z-0001gp-6f; Tue, 11 Oct 2005 09:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPK0w-0001Zl-TH for nsis@megatron.ietf.org; Tue, 11 Oct 2005 09:17:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22624 for ; Tue, 11 Oct 2005 09:17:52 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKB3-0000G2-Sh for nsis@ietf.org; Tue, 11 Oct 2005 09:28:22 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 11 Oct 2005 09:16:52 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101109165127213 ; Tue, 11 Oct 2005 09:16:52 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Tue, 11 Oct 2005 09:16:51 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Oct 2005 09:20:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP Date: Tue, 11 Oct 2005 09:20:08 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8660898E5@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] remove packet_classifier object from QoS-NSLP Thread-Index: AcXOY41Qc6oXBuoFS9eZ8n+DN9XIVwAAjzAA From: "Roy, Radhika \(AEAD\)" To: "Georgios Karagiannis" , "Kappler, Cornelia" X-OriginalArrivalTime: 11 Oct 2005 13:20:28.0281 (UTC) FILETIME=[8C1FD690:01C5CE66] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298690908==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1298690908== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CE66.80605E74" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CE66.80605E74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Georgios: You are right. Then the basic question comes: Can we have a "generalize" QoS model like generalized QSPEC template through which proper packet-classifiers can be used? If not, can coauthors of the QSPEC draft defend their wisdom why they have included implementation-specific QoS models in the generalized QSPEC draft and creating confusions for all of us? Best regards, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, October 11, 2005 8:53 AM To: Kappler, Cornelia Cc: nsis@ietf.org Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP Hi Cornelia Please see in line! ----- Original Message -----=20 From: "Kappler, Cornelia" To: "Georgios Karagiannis" Cc: Sent: Tuesday, October 11, 2005 1:26 PM Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP > Hi Georgios, > > when including two or more packet filters, how do we make sure that for > a single QoS NSLP session, it is always the same set of packets which > is receiving the reservation benefits? Georgios: In a domain that supports a QoS model we should use only one=20 filter/packet classifier. > If filtering is based on DSCP/source address in one domain, and based on > the flow ID in another domain, it might well happen that a specific > packet receives QoS only in one domain. Georgios: this occurs in the case when during an end to end path more than=20 one heterogeneous QoS models are used. If a QoS model supports aggregation and another does not then a different=20 type of filtering/packet classification must be used. This means that different filters/packet classifiers should be used per QoS=20 model! Best Regards, Georgios ------_=_NextPart_001_01C5CE66.80605E74 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [NSIS] remove packet_classifier object from QoS-NSLP

Hi, Georgios:

You are right.

Then the basic question comes: Can we have a "generalize" QoS = model like generalized = QSPEC template through which = proper packet-classifiers can be used?

If not, can coauthors of the QSPEC draft defend their wisdom why = they have included = implementation-specific QoS = models in the generalized QSPEC draft and creating confusions for all of = us?

Best regards,

Radhika

-----Original Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of Georgios Karagiannis
Sent: Tuesday, October 11, 2005 8:53 AM
To: Kappler, Cornelia
Cc: nsis@ietf.org
Subject: Re: [NSIS] remove packet_classifier object from = QoS-NSLP

Hi Cornelia

Please see in line!

----- Original Message -----

From: "Kappler, Cornelia" = <cornelia.kappler@siemens.com>

To: "Georgios Karagiannis" = <karagian@cs.utwente.nl>

Cc: <nsis@ietf.org>

Sent: Tuesday, October 11, 2005 1:26 PM

Subject: RE: [NSIS] remove packet_classifier object from = QoS-NSLP


> Hi Georgios,

>

> when including two or more packet filters, how do we make = sure that for

> a single QoS NSLP  session, it is always the same set = of packets which

> is receiving the reservation benefits?

Georgios: In a domain that supports a QoS model we should use = only one

filter/packet classifier.

> If filtering is based on DSCP/source address in one domain, = and based on

> the flow ID in another domain, it might well happen that a = specific

> packet receives QoS only in one domain.


Georgios: this occurs in the case when during an end to end path = more than

one heterogeneous

QoS models are used.

If a QoS model supports aggregation and another does not then a = different

type of filtering/packet classification

must be used.

This means that different filters/packet classifiers should be = used per QoS

model!

Best Regards,

Georgios

------_=_NextPart_001_01C5CE66.80605E74-- --===============1298690908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1298690908==-- From nsis-bounces@ietf.org Tue Oct 11 09:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKXs-0002ga-G1; Tue, 11 Oct 2005 09:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKXq-0002gK-VG for nsis@megatron.ietf.org; Tue, 11 Oct 2005 09:51:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24503 for ; Tue, 11 Oct 2005 09:51:52 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKhx-0001E5-LK for nsis@ietf.org; Tue, 11 Oct 2005 10:02:22 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9BDosL5004872; Tue, 11 Oct 2005 14:50:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSLP-Data in intial GIST-Query Date: Tue, 11 Oct 2005 14:50:51 +0100 Message-ID: Thread-Topic: [NSIS] NSLP-Data in intial GIST-Query Thread-Index: AcXOUiBW+wFFnzgAQxWbsYywOOyjpQAE3fqg From: "Hancock, Robert" To: "Thomas Herzog" , "Georgios Karagiannis" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 1.1 (+) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Content-Transfer-Encoding: quoted-printable Cc: Martin Stiemerling , s0076309@student.utwente.nl, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Thomas, Martin, all, I think I claim that the answers to these questions are in the=20 specification, but that you have to read very carefully to find them. In particular, more detail could be added to 4.3.2 and/or 6 and/or B.2 to say exactly what is done with the NSLP payloads under the various circumstances, and perhaps some more examples (or development of the text in section 3) would also be helpful. I've tried below to explain what the various answers are; it would be really good to know if=20 - the answers themselves make sense - what would be the most accessible way to reflect them better in the specification. Cheers, robert h. ps for some related discussion, see the thread around http://www.ietf.org/mail-archive/web/nsis/current/msg04765.html > -----Original Message----- > From: Thomas Herzog [mailto:thomas.herzog@gmx.li]=20 > Sent: 11 October 2005 11:54 > To: Georgios Karagiannis > Cc: Martin Stiemerling; Hancock, Robert;=20 > s0076309@student.utwente.nl; nsis > Subject: Re: [NSIS] NSLP-Data in intial GIST-Query >=20 >=20 > Hi, Georgios, >=20 > I think Martin referred to a stateful responder node which is=20 > set up for=20 > late state installation. > In this case, the responder node will not keep *ANY* state and only=20 > dispatch a Response which contains the responder cookie and=20 > R-flag set=20 > to request a Confirm. The question now arisen was rather: Would the=20 > Responder node pass the NSLP data payload which MAY be =20 > included in the Query to it's NSLP?=20 Yes: 4.3.2 indicates, at least to me ;-) that any payload carried in a GIST message is delivered to the NSLP if the NSLP exists. This could be made more explicit in 4.3.2 or in 6. I agree it's a bit awkward that the rules in 6 say what to do with the payload for some message types but not others, but it gets a bit dull saying 'deliver NSLP payload' in every rule ... i am open to suggestions about what would be clear. > Let's look at the state machine=20 > definitions in=20 > Draft-08: >=20 > For the stateless responder node approach, draft-08 includes=20 > a rule in=20 > the Node State Machine (6.1), that incoming GIST DATA=20 > messages should be=20 > passed to the appropriate NSLP instance, if there is no state=20 > associated=20 > with the message peer: >=20 > Rule 4 (rx_Data): pass directly to NSLP >=20 > In the case of a stateless responder node, it would in my=20 > opinion always=20 > dispatch at least a response, even if it keeps no state, so=20 > the querying=20 > Node would stop transmitting queries: Not the case; see my earlier reply to Georgios. >=20 > Rule 1 (rx_Query): >=20 > if (routing state can be created without a full 3-way handshake) then > create R-SM and pass message to it > else > send Response >=20 >=20 > However, maybe one should include here "routing state to be=20 > set up and=20 > this can be created without a full 3-way handshake" in the=20 > "if" instruction. In fact, the issue here is that the rule misses the 'stateless=20 handling of a Query' case. I was never sure whether including this in the state machine description was useful, since (by definition) it only shows up in the Node state machine for which most of the=20 details are in the text in the remainder of the document. But it's true that the level of detail is not consistent, so maybe that should be fixed. >=20 > So finally: it is not stated that the POSSIBLE payload in a Query is=20 > passed to the NSLP instance in the State Machine definitions.=20 > Responder=20 > Node State Machine rules 1 and 5 do not specify that there is=20 > something=20 > to do with included payload in Query Messages. True. You have to infer it from more general text elsewhere.=20 Possibly the 'deliver payload' rule should be added to all message rules where a payload is possible. >=20 > However, it is allowed to include NSLP data payload in initial GIST=20 > QUERY and also RESPONSE/CONFIRM messages. The draft does not=20 > state what=20 > to do with this payload in the state machine definitions. The state machines leave it out. The text in 4.3.2 is supposed to=20 apply to all message types (but maybe this is not clear). >=20 > In another section, the draft states, that GIST MAY do this or that=20 > (check with NSLP in case of ongoing Message Association setup and=20 > include NSLP data in the response). I think (if you are referring to 4.3.2) that the MAY language applies to what the NSLP is allowed to do. (There are two MAY options; it might need to be clearer that the NSLP MUST do one or the other.)=20 What GIST is allowed to do is (intended to be) more precise: it=20 MUST deliver the payload and MUST do what the application indicates=20 in response. >=20 > A node which is set up stateful and for late state setup=20 > could even send=20 > the NSLP data payload back in the response so the Querying Node could=20 > include it in the Confirm without remembering it.... That is not the intention. The basic rule is that GIST only sends an NSLP payload that an NSLP has provided to it through the API: so, the payload in the Response must be something provided by the NSLP at the Responder, or must be absent. The payload in the Confirm must be a (new) payload provided by the NSLP at the Querying node. (If it was a repetition of the original payload, than the message sequence at the NSLP level would start to look very strange.) Coupled with the rule that the payload is always delivered to the NSLP, I think this answers Martin's original question, i.e.: - if the Responding node NSLP decided to drop the payload, it=20 can indicate this in the payload in the Response. It's then up to the Q-node NSLP to decide whether to generate another payload or resend the original one. That payload might get carried in the=20 Confirm or a later message. - if the Responding node NSLP decided to keep the payload, it can also indicate this in the payload in the Response. The Q-Node NSLP can then move to the next stage in the transaction. Whether the retransmitted Query should include the payload is left open. Strictly it shouldn't matter either way: the payload must have been sent with the unreliable transfer attribute, in which case=20 applications must be prepared for it to be delivered 0/1/many times. I think it would typically be reasonable for a node to include the payload in retransmissions, but I'd be interested to see if people thought that behaviour was a MUST. > I think the state=20 > machine definitions are somewhat lacking to as what to=20 > exactly do with=20 > NSLP data payload in Messages other than GIST DATA. (an=20 > implementation=20 > could even decide to totally ignore NSLP data payload in=20 > these Messages=20 > and not to use it for it's own processing at all?!?!?) Strictly yes: it's all unreliable. But I think that would count as a low-quality implementation. cheers, robert h. >=20 > Cheers, > Thomas >=20 >=20 >=20 > Georgios Karagiannis wrote: > > Hi Martin > > > > I think that your example is not very clear! > > Please note that during the discovery phase it is assumed that the > > querying and responding node do not have to create the GIST routing=20 > > state. > > > > Thus your example is valid for both GIST stateless and GIST=20 > stateful=20 > > responding nodes. > > Please note however, that the sending node will wait for a timeout,=20 > > and if no GIST-Response arrives in time, > > then it will resend the complete GIST QUERY message including the=20 > > payload. > > Please also note that if the GIST responding node receives the=20 > > GIST_QUERY message, > > it will send the payload to the appropriate NSLP. Thus even=20 > during the=20 > > first GIST-QUERY the NSLP-DATA > > will be forwarded to the NSLP. > > > > But anyway, you raised a good point! > > The real problem that occurs due to the stateless GIST=20 > responding node=20 > > is that the > > GIST queying node will keep retransmiting the GIST-QUERY message! > > > > Therefore, I think that it is needed to specify a way such that the=20 > > stateless GIST responding node > > will inform the GIST querying node that the GIST responding=20 > node is a=20 > > stateless node. > > > > Best Regards, > > Mayi and Georgios > > > > > > ----- Original Message ----- From: "Martin Stiemerling"=20 > > > > To: "nsis" > > Sent: Tuesday, October 11, 2005 10:08 AM > > Subject: [NSIS] NSLP-Data in intial GIST-Query > > > > > >> Hi, > >> > >> GIST-Query messages may carry a NSLP-Data object containing=20 > >> information for the NSLP. I'm now assuming an initial=20 > GIST-Query send=20 > >> downstream looking for the next peer., carrying NSLP-Data,=20 > and a GIST=20 > >> downstream node using a stateless approach (delayed state setup,=20 > >> using a responder cookie ). In this case, the NSLP data would be=20 > >> lost, if not re-transmitted in the GIST-Confirm/GIST-Data later,=20 > >> since the downstream peer does not keep any state about=20 > the initial=20 > >> GIST-Query. There is no text (as far as I know) describing=20 > what the=20 > >> sending GIST-peer should do in this case. In the case of a=20 > >> "stateless" downstream peer (querying node sees response with=20 > >> responder cookie and R-flag set), the querying must re-send the=20 > >> NSLP-data in the next message. > >> > >> I may have missed something while reading the draft, but=20 > this issue=20 > >> was coming to mind afterwards. > >> > >> With best regards, > >> > >> Martin >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 10:06:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKlv-0005rK-Th; Tue, 11 Oct 2005 10:06:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKlu-0005r6-7T for nsis@megatron.ietf.org; Tue, 11 Oct 2005 10:06:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25488 for ; Tue, 11 Oct 2005 10:06:23 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPKw1-0001bv-D5 for nsis@ietf.org; Tue, 11 Oct 2005 10:16:53 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9BE6KU3006903; Tue, 11 Oct 2005 16:06:20 +0200 (MEST) Message-ID: <00fd01c5ce6c$f5d84b70$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , "Martin Stiemerling" References: Subject: Re: [NSIS] NSLP-Data in intial GIST-Query Date: Tue, 11 Oct 2005 16:06:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.52 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 11 Oct 2005 16:06:22 +0200 (MEST) X-Spam-Score: 1.1 (+) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Cc: s0076309@student.utwente.nl, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert I think that you are right! Please see inline! ----- Original Message ----- From: "Hancock, Robert" To: "Georgios Karagiannis" ; "Martin Stiemerling" Cc: ; "nsis" Sent: Tuesday, October 11, 2005 3:13 PM Subject: RE: [NSIS] NSLP-Data in intial GIST-Query > hi all, > > there will be a separate answer to Martin's original point > (in fact, in an answer to Thomas's answer ...). But there are > some specific points here too. Inline: > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 11 October 2005 10:07 >> To: Martin Stiemerling; Hancock, Robert >> Cc: nsis; s0076309@student.utwente.nl >> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query >> >> >> Hi Martin >> >> I think that your example is not very clear! >> Please note that during the discovery phase it is assumed that the >> querying and responding node do not have to create the GIST >> routing state. > > In the discovery phase (if discovery is happening), the Querying > node *has* to create state at the start; the Responding node > can do so in a delayed way (as we all know). > >> >> Thus your example is valid for both GIST stateless and GIST stateful >> responding nodes. >> Please note however, that the sending node will wait for a >> timeout, and if >> no GIST-Response arrives in time, >> then it will resend the complete GIST QUERY message >> including the payload. >> Please also note that if the GIST responding node receives >> the GIST_QUERY >> message, >> it will send the payload to the appropriate NSLP. Thus even >> during the first >> GIST-QUERY the NSLP-DATA >> will be forwarded to the NSLP. > > This is true. > >> >> But anyway, you raised a good point! >> The real problem that occurs due to the stateless GIST >> responding node is >> that the >> GIST queying node will keep retransmiting the GIST-QUERY message! > > This is not quite true. Georgios: What do you mean? >> >> Therefore, I think that it is needed to specify a way such that the >> stateless GIST responding node >> will inform the GIST querying node that the GIST responding node is a >> stateless node. > > This is definitely not true. The situation is described in 4.3.2: > a GIST node which is stateless in this way will forward the Query > downstream, possibly with a revised payload; when this hits a stateful > node, the Response will come back. The stateless node MUST NOT send > anything back saying 'I am stateless' because then the Querying node > would see two (or in general 1+N) replies to its message, all but one > of them being failures. The querying node doesn't care about the > existence of the stateless nodes anyway (at the GIST level). Georgios: You are right! > If the Query is lost before it gets to the stateful Responder, or > if the Response is lost on the way back, or if there is no stateful > Responder in the first place, the original Query will be resent. > Georgios: But what happens if after the GIST quering node there is no statefull node in the whole end to end path? The GIST quering node will keep retransmitting the GIST QUERY or? Best Regards, Georgios > >> >> Best Regards, >> Mayi and Georgios >> >> >> ----- Original Message ----- >> From: "Martin Stiemerling" >> To: "nsis" >> Sent: Tuesday, October 11, 2005 10:08 AM >> Subject: [NSIS] NSLP-Data in intial GIST-Query >> >> >> > Hi, >> > >> > GIST-Query messages may carry a NSLP-Data object containing >> information >> > for the NSLP. I'm now assuming an initial GIST-Query send >> downstream >> > looking for the next peer., carrying NSLP-Data, and a GIST >> downstream node >> > using a stateless approach (delayed state setup, using a responder >> > cookie ). In this case, the NSLP data would be lost, if not >> re-transmitted >> > in the GIST-Confirm/GIST-Data later, since the downstream >> peer does not >> > keep any state about the initial GIST-Query. There is no >> text (as far as I >> > know) describing what the sending GIST-peer should do in >> this case. In the >> > case of a "stateless" downstream peer (querying node sees >> response with >> > responder cookie and R-flag set), the querying must re-send >> the NSLP-data >> > in the next message. >> > >> > I may have missed something while reading the draft, but >> this issue was >> > coming to mind afterwards. >> > >> > With best regards, >> > >> > Martin >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 10:11:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKqd-0007fj-Jq; Tue, 11 Oct 2005 10:11:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKqc-0007fe-1I for nsis@megatron.ietf.org; Tue, 11 Oct 2005 10:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26083 for ; Tue, 11 Oct 2005 10:11:15 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPL0i-0001ll-8x for nsis@ietf.org; Tue, 11 Oct 2005 10:21:45 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9BEAML5010938; Tue, 11 Oct 2005 15:10:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSLP-Data in intial GIST-Query Date: Tue, 11 Oct 2005 15:10:16 +0100 Message-ID: Thread-Topic: [NSIS] NSLP-Data in intial GIST-Query Thread-Index: AcXObQnDID1t2Rf0Try6jDoLtVoaRQAADRQg From: "Hancock, Robert" To: "Georgios Karagiannis" , "Martin Stiemerling" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable Cc: s0076309@student.utwente.nl, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi georgios, > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 11 October 2005 15:06 > To: Hancock, Robert; Martin Stiemerling > Cc: s0076309@student.utwente.nl; nsis > Subject: Re: [NSIS] NSLP-Data in intial GIST-Query >=20 >=20 > Hi Robert >=20 > I think that you are right! > Please see inline! >=20 > ----- Original Message -----=20 > From: "Hancock, Robert" > To: "Georgios Karagiannis" ; "Martin=20 > Stiemerling"=20 > > Cc: ; "nsis" > Sent: Tuesday, October 11, 2005 3:13 PM > Subject: RE: [NSIS] NSLP-Data in intial GIST-Query >=20 >=20 > > hi all, > > > > there will be a separate answer to Martin's original point > > (in fact, in an answer to Thomas's answer ...). But there are > > some specific points here too. Inline: > > > >> -----Original Message----- > >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Sent: 11 October 2005 10:07 > >> To: Martin Stiemerling; Hancock, Robert > >> Cc: nsis; s0076309@student.utwente.nl > >> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query > >> > >> > >> Hi Martin > >> > >> I think that your example is not very clear! > >> Please note that during the discovery phase it is assumed that the > >> querying and responding node do not have to create the GIST > >> routing state. > > > > In the discovery phase (if discovery is happening), the Querying > > node *has* to create state at the start; the Responding node > > can do so in a delayed way (as we all know). > > > >> > >> Thus your example is valid for both GIST stateless and=20 > GIST stateful > >> responding nodes. > >> Please note however, that the sending node will wait for a > >> timeout, and if > >> no GIST-Response arrives in time, > >> then it will resend the complete GIST QUERY message > >> including the payload. > >> Please also note that if the GIST responding node receives > >> the GIST_QUERY > >> message, > >> it will send the payload to the appropriate NSLP. Thus even > >> during the first > >> GIST-QUERY the NSLP-DATA > >> will be forwarded to the NSLP. > > > > This is true. > > > >> > >> But anyway, you raised a good point! > >> The real problem that occurs due to the stateless GIST > >> responding node is > >> that the > >> GIST queying node will keep retransmiting the GIST-QUERY message! > > > > This is not quite true. >=20 > Georgios: What do you mean? I mean: it will keep retransmitting the Query if there is no stateful node further downstream. >=20 > >> > >> Therefore, I think that it is needed to specify a way such that the > >> stateless GIST responding node > >> will inform the GIST querying node that the GIST=20 > responding node is a > >> stateless node. > > > > This is definitely not true. The situation is described in 4.3.2: > > a GIST node which is stateless in this way will forward the Query > > downstream, possibly with a revised payload; when this hits=20 > a stateful > > node, the Response will come back. The stateless node MUST NOT send > > anything back saying 'I am stateless' because then the Querying node > > would see two (or in general 1+N) replies to its message,=20 > all but one > > of them being failures. The querying node doesn't care about the > > existence of the stateless nodes anyway (at the GIST level). >=20 > Georgios: You are right! >=20 > > If the Query is lost before it gets to the stateful Responder, or > > if the Response is lost on the way back, or if there is no stateful > > Responder in the first place, the original Query will be resent. > > > Georgios: But what happens if after the GIST quering node > there is no statefull node in the whole end to end path? > The GIST quering node will keep retransmitting the GIST QUERY or? It will keep retransmitting until it decides to give up. See=20 section 5.3.3 (esp. the second paragraph). robert h. >=20 >=20 > Best Regards, > Georgios >=20 >=20 >=20 > > > >> > >> Best Regards, > >> Mayi and Georgios > >> > >> > >> ----- Original Message -----=20 > >> From: "Martin Stiemerling" > >> To: "nsis" > >> Sent: Tuesday, October 11, 2005 10:08 AM > >> Subject: [NSIS] NSLP-Data in intial GIST-Query > >> > >> > >> > Hi, > >> > > >> > GIST-Query messages may carry a NSLP-Data object containing > >> information > >> > for the NSLP. I'm now assuming an initial GIST-Query send > >> downstream > >> > looking for the next peer., carrying NSLP-Data, and a GIST > >> downstream node > >> > using a stateless approach (delayed state setup, using a=20 > responder > >> > cookie ). In this case, the NSLP data would be lost, if not > >> re-transmitted > >> > in the GIST-Confirm/GIST-Data later, since the downstream > >> peer does not > >> > keep any state about the initial GIST-Query. There is no > >> text (as far as I > >> > know) describing what the sending GIST-peer should do in > >> this case. In the > >> > case of a "stateless" downstream peer (querying node sees > >> response with > >> > responder cookie and R-flag set), the querying must re-send > >> the NSLP-data > >> > in the next message. > >> > > >> > I may have missed something while reading the draft, but > >> this issue was > >> > coming to mind afterwards. > >> > > >> > With best regards, > >> > > >> > Martin > >> > > >> > _______________________________________________ > >> > 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 > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 11 10:13:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKsZ-00085e-FW; Tue, 11 Oct 2005 10:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPKsX-00085W-IK for nsis@megatron.ietf.org; Tue, 11 Oct 2005 10:13:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26269 for ; Tue, 11 Oct 2005 10:13:15 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPL2e-0001pH-VW for nsis@ietf.org; Tue, 11 Oct 2005 10:23:45 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9BEDCmA007277; Tue, 11 Oct 2005 16:13:12 +0200 (MEST) Message-ID: <010401c5ce6d$eb173150$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , "Martin Stiemerling" References: Date: Tue, 11 Oct 2005 16:13:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.519 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 11 Oct 2005 16:13:14 +0200 (MEST) X-Spam-Score: 1.1 (+) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: s0076309@student.utwente.nl, nsis Subject: [NSIS] possible clarification needed for Section 4.3.2 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert Could you please clarify the text in Section 4.3.2, which is related to the bypassing functionality. The clarification should actually include the semantics of the text that has been provided by you in the previous e-mail, see below: > This is definitely not true. The situation is described in 4.3.2: > a GIST node which is stateless in this way will forward the Query > downstream, possibly with a revised payload; when this hits a stateful > node, the Response will come back. The stateless node MUST NOT send > anything back saying 'I am stateless' because then the Querying node > would see two (or in general 1+N) replies to its message, all but one > of them being failures. The querying node doesn't care about the > existence of the stateless nodes anyway (at the GIST level). Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "Georgios Karagiannis" ; "Martin Stiemerling" Cc: ; "nsis" Sent: Tuesday, October 11, 2005 3:13 PM Subject: RE: [NSIS] NSLP-Data in intial GIST-Query > hi all, > > there will be a separate answer to Martin's original point > (in fact, in an answer to Thomas's answer ...). But there are > some specific points here too. Inline: > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 11 October 2005 10:07 >> To: Martin Stiemerling; Hancock, Robert >> Cc: nsis; s0076309@student.utwente.nl >> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query >> >> >> Hi Martin >> >> I think that your example is not very clear! >> Please note that during the discovery phase it is assumed that the >> querying and responding node do not have to create the GIST >> routing state. > > In the discovery phase (if discovery is happening), the Querying > node *has* to create state at the start; the Responding node > can do so in a delayed way (as we all know). > >> >> Thus your example is valid for both GIST stateless and GIST stateful >> responding nodes. >> Please note however, that the sending node will wait for a >> timeout, and if >> no GIST-Response arrives in time, >> then it will resend the complete GIST QUERY message >> including the payload. >> Please also note that if the GIST responding node receives >> the GIST_QUERY >> message, >> it will send the payload to the appropriate NSLP. Thus even >> during the first >> GIST-QUERY the NSLP-DATA >> will be forwarded to the NSLP. > > This is true. > >> >> But anyway, you raised a good point! >> The real problem that occurs due to the stateless GIST >> responding node is >> that the >> GIST queying node will keep retransmiting the GIST-QUERY message! > > This is not quite true. > >> >> Therefore, I think that it is needed to specify a way such that the >> stateless GIST responding node >> will inform the GIST querying node that the GIST responding node is a >> stateless node. > > This is definitely not true. The situation is described in 4.3.2: > a GIST node which is stateless in this way will forward the Query > downstream, possibly with a revised payload; when this hits a stateful > node, the Response will come back. The stateless node MUST NOT send > anything back saying 'I am stateless' because then the Querying node > would see two (or in general 1+N) replies to its message, all but one > of them being failures. The querying node doesn't care about the > existence of the stateless nodes anyway (at the GIST level). > > If the Query is lost before it gets to the stateful Responder, or > if the Response is lost on the way back, or if there is no stateful > Responder in the first place, the original Query will be resent. > > r. > >> >> Best Regards, >> Mayi and Georgios >> >> >> ----- Original Message ----- >> From: "Martin Stiemerling" >> To: "nsis" >> Sent: Tuesday, October 11, 2005 10:08 AM >> Subject: [NSIS] NSLP-Data in intial GIST-Query >> >> >> > Hi, >> > >> > GIST-Query messages may carry a NSLP-Data object containing >> information >> > for the NSLP. I'm now assuming an initial GIST-Query send >> downstream >> > looking for the next peer., carrying NSLP-Data, and a GIST >> downstream node >> > using a stateless approach (delayed state setup, using a responder >> > cookie ). In this case, the NSLP data would be lost, if not >> re-transmitted >> > in the GIST-Confirm/GIST-Data later, since the downstream >> peer does not >> > keep any state about the initial GIST-Query. There is no >> text (as far as I >> > know) describing what the sending GIST-peer should do in >> this case. In the >> > case of a "stateless" downstream peer (querying node sees >> response with >> > responder cookie and R-flag set), the querying must re-send >> the NSLP-data >> > in the next message. >> > >> > I may have missed something while reading the draft, but >> this issue was >> > coming to mind afterwards. >> > >> > With best regards, >> > >> > Martin >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 12 05:29:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPcv2-0008J6-3c; Wed, 12 Oct 2005 05:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPcuz-0008IP-DM for nsis@megatron.ietf.org; Wed, 12 Oct 2005 05:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09267 for ; Wed, 12 Oct 2005 05:28:58 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPd5G-00046E-W1 for nsis@ietf.org; Wed, 12 Oct 2005 05:39:39 -0400 Received: from venus.office (venus.office [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5BABFDC40; Wed, 12 Oct 2005 11:28:46 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 11:28:46 +0200 Date: Wed, 12 Oct 2005 11:28:42 +0200 From: Martin Stiemerling To: "Hancock, Robert" , Thomas Herzog , Georgios Karagiannis Subject: RE: [NSIS] NSLP-Data in intial GIST-Query Message-ID: <80A8D2305F2CFBB118DD14A0@[10.1.1.109]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 12 Oct 2005 09:28:46.0289 (UTC) FILETIME=[584DF410:01C5CF0F] X-Spam-Score: 1.1 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: s0076309@student.utwente.nl, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, all, --On Dienstag, 11. Oktober 2005 14:50 Uhr +0100 "Hancock, Robert" wrote: | Hi Thomas, Martin, all, | | I think I claim that the answers to these questions are in the | specification, but that you have to read very carefully to find | them. In particular, more detail could be added to 4.3.2 and/or | 6 and/or B.2 to say exactly what is done with the NSLP payloads | under the various circumstances, and perhaps some more examples | (or development of the text in section 3) would also be helpful. After re-thinking it I do not see any problem anymore, considering the text in Section 3.5 (point 5.) and Section B.2. Reading this, it is clear that the NSLP level must take care about the described case of state setup delay. However, this may require some text in the NSLP sections describing the inter-working with the NTLP. | | I've tried below to explain what the various answers are; it would | be really good to know if | - the answers themselves make sense | - what would be the most accessible way to reflect them better | in the specification. | | Cheers, | | robert h. | | ps for some related discussion, see the thread around | http://www.ietf.org/mail-archive/web/nsis/current/msg04765.html | |> -----Original Message----- |> From: Thomas Herzog [mailto:thomas.herzog@gmx.li] |> Sent: 11 October 2005 11:54 |> To: Georgios Karagiannis |> Cc: Martin Stiemerling; Hancock, Robert; |> s0076309@student.utwente.nl; nsis |> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query |> |> |> Hi, Georgios, |> |> I think Martin referred to a stateful responder node which is |> set up for |> late state installation. |> In this case, the responder node will not keep *ANY* state and only |> dispatch a Response which contains the responder cookie and |> R-flag set |> to request a Confirm. The question now arisen was rather: Would the |> Responder node pass the NSLP data payload which MAY be |> included in the Query to it's NSLP? | | Yes: 4.3.2 indicates, at least to me ;-) that any payload carried | in a GIST message is delivered to the NSLP if the NSLP exists. | This could be made more explicit in 4.3.2 or in 6. I agree it's | a bit awkward that the rules in 6 say what to do with the payload | for some message types but not others, but it gets a bit dull saying | 'deliver NSLP payload' in every rule ... i am open to suggestions | about what would be clear. I see the text as being fine. If NSLP-Data is provided as NTLP payload it is handled over to the particular NSLP. | |> Let's look at the state machine |> definitions in |> Draft-08: |> |> For the stateless responder node approach, draft-08 includes |> a rule in |> the Node State Machine (6.1), that incoming GIST DATA |> messages should be |> passed to the appropriate NSLP instance, if there is no state |> associated |> with the message peer: |> |> Rule 4 (rx_Data): pass directly to NSLP |> |> In the case of a stateless responder node, it would in my |> opinion always |> dispatch at least a response, even if it keeps no state, so |> the querying |> Node would stop transmitting queries: | | Not the case; see my earlier reply to Georgios. | |> |> Rule 1 (rx_Query): |> |> if (routing state can be created without a full 3-way handshake) then |> create R-SM and pass message to it |> else |> send Response |> |> |> However, maybe one should include here "routing state to be |> set up and |> this can be created without a full 3-way handshake" in the |> "if" instruction. | | In fact, the issue here is that the rule misses the 'stateless | handling of a Query' case. I was never sure whether including this | in the state machine description was useful, since (by definition) | it only shows up in the Node state machine for which most of the | details are in the text in the remainder of the document. But it's | true that the level of detail is not consistent, so maybe that should | be fixed. Current text is fine since this is stateted in Section 6.3: " In cases 1 and 3 the R-SM is created already in the Established state." | |> |> So finally: it is not stated that the POSSIBLE payload in a Query is |> passed to the NSLP instance in the State Machine definitions. |> Responder |> Node State Machine rules 1 and 5 do not specify that there is |> something |> to do with included payload in Query Messages. | | True. You have to infer it from more general text elsewhere. | Possibly the 'deliver payload' rule should be added to all message | rules where a payload is possible. I would suggest a small note before the rules indicating again that the NTLP passes always a call to the NSLP when receiving a message, even with a NSLP null payload. Basically repeating the part out of Section 3.5 (point 5). With best regards, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 12 05:45:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPdBA-0004Ze-Mm; Wed, 12 Oct 2005 05:45:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPdB6-0004ZW-Nk for nsis@megatron.ietf.org; Wed, 12 Oct 2005 05:45:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09861 for ; Wed, 12 Oct 2005 05:45:37 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPdLN-0004Sz-Fa for nsis@ietf.org; Wed, 12 Oct 2005 05:56:18 -0400 Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5D483DC49; Wed, 12 Oct 2005 11:45:30 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 11:45:30 +0200 Date: Wed, 12 Oct 2005 11:45:28 +0200 From: Martin Stiemerling To: Sung-Hyuck Lee , nsis@ietf.org Subject: Re: [NSIS] NSIS mobility issues Message-ID: <696F8FADE70AB3C5A9C05DD2@[10.1.1.109]> In-Reply-To: <001001c5cda2$e1326720$ef2b024b@LocalHost> References: <001001c5cda2$e1326720$ef2b024b@LocalHost> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-OriginalArrivalTime: 12 Oct 2005 09:45:30.0285 (UTC) FILETIME=[AEBB95D0:01C5CF11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Find my comments inline. --On Montag, 10. Oktober 2005 22:59 Uhr +0900 Sung-Hyuck Lee=20 wrote: | Hi all, | | As you know, NSIS mobility authors have established the NSIS mobility | issue tracker': http://www.tschofenig.priv.at:8080/nsismob/. Also, the | authors would like to address the following issues to further discuss | those issues on the mailing list. It would be very much appreciated if | NSIS folks give some guides and comments on the following issues | addressed in | http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobilit | y-signaling-02.txt. The more detailed issues can be found in NSIS | mobility issue tracker. | | * Closed | - #4: Authorization-related issues with teardown | solved by disabling of "reverse removal" | | - #7: Priority of signaling messages | It is difficult for the signaling priority to be used due to | security issues | | * Remaining issues to be resolved: | | - #1: CRN discovery | the pros and cons of two discovery mechanisms on CRN was | described in more details: either at NTLP layer or NSLP layer. I thought to remember that this issue has been solved at the last meeting. The NTLP will discover the CRN "automatically": Only a NTLP being already involved in the signaling session (i.e., having stored state for that session) will discover the cross-over. This NTLP, by definition, will have the right NSLP installed locally. This result of "only NTLP nodes with the corresponding NSLP will intercept and process messages". Martin | | - #2: Mobile IP specific API | This issue is a little implementation-specific, but the usage of | an API needs to be described. | | -#3: Invalid NSIS Responder problem | Some possible proposals to solve the 'invalid NR' problem in | mobility scenarios was described (e.g., hint information: | handover_init (HI)). This issue is pertinent to #11. | | - #5: Optimal refresh timer value for mobile environment | It is difficult to provide generic mechanism, but provide | specific values (for specific scenarios) if possible. | | - #6: CRN discovery and Path Update on the IP-tunneling path | possible issues in NSIS-mobility draft (-02) were described. | Suggest solutions in separate drafts. | | - #8: Localized Path Update | Identify the difference b/w the localized mobility and micro | mobility management protocols in case of interaction with NSIS | protocols. Consider signaling optimization in the vertical | handover scenarios. | | - #9: Dead Peer Discovery | Dead peers (e.g., AR (or FA), CRN, HA or MN ) can occur | either because a link or a network node failed, or MN moved away | without informing NTLP/NSLP (e.g., QoS- or NAT/FW-NSLP). | GIMPS discovery will detect the problem after some time: it says | that GIMPS discovery might be too slow. | | - Questions for #9: | How can dead peers be detected in a fast and efficient manner | in mobility scenarios? Do some "dead peer" cases need to be | identified? (e.g., MN=A1=AF moving-away, CRN failure, CARs=A1=AF failure, | FA/HA=A1=AFs failure, and so on) | | - #10: Multihoming issues | An NSIS-aware node (e.g., MN, HA, CN, etc.) may be | multihomed. NSIS signaling can be used in such multihomed | environments. In this case, which NxLP functionality is needed | in various multihoming scenarios (e.g., bandwidth increase, | load balancing, bi-casting, resilience, etc.) is an open | question. An overall coordination for interworking between the | NSIS protocol suite and multihoming capability needs to be | discussed further. | | - Questions for #10: | How should multiple CRNs differentiate the Path Update for | multihoming from the generic Path Update? How do CRNs authorize | multiple flows with different flow identifiers for the same | session? | - #11 Mobility Object | The Mobility objects such as 'Mobility_Event_Counter (MEC)' and | 'Handover_Init (HI)' can be used to solve the ping-pong type | handover and the Invalid NR problem, respectively. The MEC field | can inform the CRN of which incoming message is the latest. The | HI field can explicitly inform AR (or CRN) that a handover is now | initiated. | | - Question for #11: | Do those mobility objects need to be included in NxLP messages? | | - #12 Terminology: Path Update | The term, "Path Update" has been chosen with the initial mobility | manyfolks-draft. Some folks think that the term does not | appropriately represent the meaning of NSIS state recovery. | Currently, the candidates for substitution of the term are | | i) "State Recovery" and ii) "State Update". Any suggestion? | | | * Some overlapped issues between QoS-NSLP and NSIS-mobility drafts | | - QoS-NSLP #29: Make-before-break handovers (including | Seamoby-related issues) were addressed at the initial NSIS-mobility | draft. Was this issue closed? | | - QoS-NSLP #32: Last node problem is similar to the "Invalid NR | problem (#3)" | | - QoS-NSLP #33: Priority of signaling messages to GIMPS-NSLP API | & #39 Explicit indication of refresh are related to the "priority | of signaling messages (#7)" | | - QoS-NSLP #17: Node failure and restart handling | "Dead peer discovery (#9)" | | - Questions: How should we resolve the conflict? Also, who | describes what? | | | Thanks, | | Sung-Hyuck Lee _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 12 05:50:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPdGC-0005vq-U9; Wed, 12 Oct 2005 05:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPdGA-0005vU-KN for nsis@megatron.ietf.org; Wed, 12 Oct 2005 05:50:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10009 for ; Wed, 12 Oct 2005 05:50:51 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPdQP-0004bD-GY for nsis@ietf.org; Wed, 12 Oct 2005 06:01:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9C9oivJ004843; Wed, 12 Oct 2005 12:50:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 12:50:39 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 12:50:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS mobility issues Date: Wed, 12 Oct 2005 12:50:16 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D011423AA@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] NSIS mobility issues Thread-Index: AcXPEhh7paftXZeFRE6BjZFxRAxqPQAACg6A To: , , X-OriginalArrivalTime: 12 Oct 2005 09:50:18.0069 (UTC) FILETIME=[5A43F050:01C5CF12] X-Spam-Score: 0.4 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, >| - #1: CRN discovery >| the pros and cons of two discovery mechanisms on CRN was >| described in more details: either at NTLP layer or NSLP layer. > >I thought to remember that this issue has been solved at the last meeting. >The NTLP will discover the CRN "automatically": Only a NTLP=20 >being already involved in the signaling session (i.e., having=20 >stored state for that session) will discover the cross-over.=20 >This NTLP, by definition, will have the right NSLP installed=20 >locally. This result of "only NTLP nodes with the=20 >corresponding NSLP will intercept and process messages". I think that this might be good enough for now as well. I think we shouldn't try to do more until we actually have a bit more experience with the protocols. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 12 13:09:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPk6t-0007nJ-TL; Wed, 12 Oct 2005 13:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPk6q-0007nD-Mh for nsis@megatron.ietf.org; Wed, 12 Oct 2005 13:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05769 for ; Wed, 12 Oct 2005 13:09:40 -0400 (EDT) Received: from pfwhqs1.ncr.disa.mil ([209.22.99.17] helo=pfwhqs101.ncr.disa.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPkHC-0000wM-HM for nsis@ietf.org; Wed, 12 Oct 2005 13:20:26 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0E520796@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'David R Oran'" , "Tschofenig, Hannes" Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Wed, 12 Oct 2005 13:09:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org David, Just a question: Do we need to enhance http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-09.txt to include QSPEC if you we decide to use DIAMETER to perform the authorization for users' resources? Thanks, An -----Original Message----- From: David R Oran [mailto:oran@cisco.com] Sent: Monday, October 10, 2005 10:52 AM To: Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: Re: AW: [NSIS] Re: authorizing query messages Do you think it makes sense to have the authorization response to the query return a QSPEC with the user's authorized resources so that can be returned along with the available resources (or alternatively used by the NSLP to reduce the reported available resources to only the amount authorized? On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote: > hi jukka, > > thanks for your feedback. here is a proposal how to handle > authorization > for the query message: > > the query message triggers a QAR with the authentication info but > without any QoS-Resources. > it might be necessary to indicate (somewhere) that this is only a > query > without the need to enable accounting and charging. > > as such, the response in the QAA is also limited to the result rather > than returning information like avps like CC-Time,Cost, > QoS-Resources,Authz-time). > > here is the figure: > > End-Host Network Element Entity > requesting QoS ( Diameter ( Diameter > QoS Client) QoS Server) > | | | > +---QoS-Query------>| | > | +- - - - - QAR - - - - - >| > | |(QoS-Resources=NULL, | > | | QoS-Auth-Data,User-ID)| > | | +--------+--------------+ > | | | Authorize request | > | | | Keep no session data | > | | | | > | | +--------+--------------+ > | |< - - - - QAA - - - - - -+ > | |(Result-Code) | > | | | > | +-------+---------+ > | |Proceeed with | > | |QoS signaling | > | |exchange | > | +-------+---------+ > | | > | +----------QoS-Reserve---------------> > | | > | |<---------QoS-Response--------------- > |<--QoS-Response----+ > > > ciao > hannes > > > >> Hi, >> >> I would expect that in certain networks, not everybody may query the >> network of available resources. Thus, there could be need to >> include an >> auhtorization token, or ask from a Diameter server whether the node >> sending the query is allowed to do that. >> >> Cheers, >> Jukka >> >> >> On Thu, 6 Oct 2005, Hannes Tschofenig wrote: >> >> >> >>> hi all, >>> >>> as part of our work on the diameter-qos application and the >>> >>> >> radius-qos draft >> >> >>> we came across the aspect of authorizing individual types >>> >>> >> of actions taken by >> >> >>> the qos signaling protocol. from discussions in the past i >>> >>> >> remember that >> >> >>> people wanted to authorize query messages as well. when we >>> >>> >> come to the >> >> >>> concrete details we are not quite sure what it actually >>> >>> >> means. what would be >> >> >>> the authorization decision regarding the query message >>> >>> >> people have in mind? >> >> >>> >>> ciao >>> hannes >>> >>> >>> >>> >>> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 12 13:58:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPksP-0004Lw-9w; Wed, 12 Oct 2005 13:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPksN-0004KZ-Md for nsis@megatron.ietf.org; Wed, 12 Oct 2005 13:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08086 for ; Wed, 12 Oct 2005 13:58:47 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPl2f-00028t-UY for nsis@ietf.org; Wed, 12 Oct 2005 14:09:34 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9CHwEL5029266; Wed, 12 Oct 2005 18:58:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSLP-Data in intial GIST-Query Date: Wed, 12 Oct 2005 18:58:07 +0100 Message-ID: Thread-Topic: [NSIS] NSLP-Data in intial GIST-Query Thread-Index: AcXPD2mHzyOSYN3bS7i5RCtIoHbSIwARvrYQ From: "Hancock, Robert" To: "Martin Stiemerling" , "Thomas Herzog" , "Georgios Karagiannis" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 1.1 (+) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: s0076309@student.utwente.nl, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Martin, thanks for the review. I've added http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74 to cover the proposed clarification in section 6. Is more needed? robert h. > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: 12 October 2005 10:29 > To: Hancock, Robert; Thomas Herzog; Georgios Karagiannis > Cc: s0076309@student.utwente.nl; nsis > Subject: RE: [NSIS] NSLP-Data in intial GIST-Query >=20 >=20 > Hi Robert, all, >=20 > --On Dienstag, 11. Oktober 2005 14:50 Uhr +0100 "Hancock, Robert"=20 > wrote: >=20 > | Hi Thomas, Martin, all, > | > | I think I claim that the answers to these questions are in the > | specification, but that you have to read very carefully to find > | them. In particular, more detail could be added to 4.3.2 and/or > | 6 and/or B.2 to say exactly what is done with the NSLP payloads > | under the various circumstances, and perhaps some more examples > | (or development of the text in section 3) would also be helpful. >=20 > After re-thinking it I do not see any problem anymore, considering > the text in Section 3.5 (point 5.) and Section B.2. Reading=20 > this, it is > clear that the NSLP level must take care about the described case > of state setup delay. However, this may require some text in the > NSLP sections describing the inter-working with the NTLP. >=20 > | > | I've tried below to explain what the various answers are; it would > | be really good to know if > | - the answers themselves make sense > | - what would be the most accessible way to reflect them better > | in the specification. > | > | Cheers, > | > | robert h. > | > | ps for some related discussion, see the thread around > | http://www.ietf.org/mail-archive/web/nsis/current/msg04765.html > | > |> -----Original Message----- > |> From: Thomas Herzog [mailto:thomas.herzog@gmx.li] > |> Sent: 11 October 2005 11:54 > |> To: Georgios Karagiannis > |> Cc: Martin Stiemerling; Hancock, Robert; > |> s0076309@student.utwente.nl; nsis > |> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query > |> > |> > |> Hi, Georgios, > |> > |> I think Martin referred to a stateful responder node which is > |> set up for > |> late state installation. > |> In this case, the responder node will not keep *ANY* state and only > |> dispatch a Response which contains the responder cookie and > |> R-flag set > |> to request a Confirm. The question now arisen was rather: Would the > |> Responder node pass the NSLP data payload which MAY be > |> included in the Query to it's NSLP? > | > | Yes: 4.3.2 indicates, at least to me ;-) that any payload carried > | in a GIST message is delivered to the NSLP if the NSLP exists. > | This could be made more explicit in 4.3.2 or in 6. I agree it's > | a bit awkward that the rules in 6 say what to do with the payload > | for some message types but not others, but it gets a bit dull saying > | 'deliver NSLP payload' in every rule ... i am open to suggestions > | about what would be clear. >=20 > I see the text as being fine. If NSLP-Data is provided as=20 > NTLP payload it > is handled over to the particular NSLP. >=20 > | > |> Let's look at the state machine > |> definitions in > |> Draft-08: > |> > |> For the stateless responder node approach, draft-08 includes > |> a rule in > |> the Node State Machine (6.1), that incoming GIST DATA > |> messages should be > |> passed to the appropriate NSLP instance, if there is no state > |> associated > |> with the message peer: > |> > |> Rule 4 (rx_Data): pass directly to NSLP > |> > |> In the case of a stateless responder node, it would in my > |> opinion always > |> dispatch at least a response, even if it keeps no state, so > |> the querying > |> Node would stop transmitting queries: > | > | Not the case; see my earlier reply to Georgios. > | > |> > |> Rule 1 (rx_Query): > |> > |> if (routing state can be created without a full 3-way=20 > handshake) then > |> create R-SM and pass message to it > |> else > |> send Response > |> > |> > |> However, maybe one should include here "routing state to be > |> set up and > |> this can be created without a full 3-way handshake" in the > |> "if" instruction. > | > | In fact, the issue here is that the rule misses the 'stateless > | handling of a Query' case. I was never sure whether including this > | in the state machine description was useful, since (by definition) > | it only shows up in the Node state machine for which most of the > | details are in the text in the remainder of the document. But it's > | true that the level of detail is not consistent, so maybe=20 > that should > | be fixed. >=20 > Current text is fine since this is stateted in Section 6.3: > " In cases 1 and 3 the R-SM is created already in the=20 > Established state." >=20 > | > |> > |> So finally: it is not stated that the POSSIBLE payload in=20 > a Query is > |> passed to the NSLP instance in the State Machine definitions. > |> Responder > |> Node State Machine rules 1 and 5 do not specify that there is > |> something > |> to do with included payload in Query Messages. > | > | True. You have to infer it from more general text elsewhere. > | Possibly the 'deliver payload' rule should be added to all message > | rules where a payload is possible. >=20 > I would suggest a small note before the rules indicating again that > the NTLP passes always a call to the NSLP when receiving a > message, even with a NSLP null payload. Basically repeating the > part out of Section 3.5 (point 5). >=20 > With best regards, >=20 > Martin >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 12 14:12:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPl5e-0008Bx-Ik; Wed, 12 Oct 2005 14:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPl5d-0008AF-Jn for nsis@megatron.ietf.org; Wed, 12 Oct 2005 14:12:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08705 for ; Wed, 12 Oct 2005 14:12:29 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPlFy-0002Ut-9W for nsis@ietf.org; Wed, 12 Oct 2005 14:23:16 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9CIC4L5032601; Wed, 12 Oct 2005 19:12:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2005 19:11:55 +0100 Message-ID: Thread-Topic: possible clarification needed for Section 4.3.2 Thread-Index: AcXObfVTZg0djScRRFaCzUPZ+Pme+AA6mkHQ From: "Hancock, Robert" To: "Georgios Karagiannis" , "Martin Stiemerling" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 1.1 (+) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: s0076309@student.utwente.nl, nsis Subject: [NSIS] RE: possible clarification needed for Section 4.3.2 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi georgios, i've created=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue75 to cover this and other aspects of the same clarification. cheers, robert h. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: 11 October 2005 15:13 > To: Hancock, Robert; Martin Stiemerling > Cc: s0076309@student.utwente.nl; nsis > Subject: possible clarification needed for Section 4.3.2 >=20 >=20 > Hi Robert >=20 > Could you please clarify the text in Section 4.3.2, which is=20 > related to the=20 > bypassing functionality. > The clarification should actually include the semantics of=20 > the text that has=20 > been provided by > you in the previous e-mail, see below: >=20 >=20 > > This is definitely not true. The situation is described in 4.3.2: > > a GIST node which is stateless in this way will forward the Query > > downstream, possibly with a revised payload; when this hits=20 > a stateful > > node, the Response will come back. The stateless node MUST NOT send > > anything back saying 'I am stateless' because then the Querying node > > would see two (or in general 1+N) replies to its message,=20 > all but one > > of them being failures. The querying node doesn't care about the > > existence of the stateless nodes anyway (at the GIST level). >=20 >=20 > Best Regards, > Georgios >=20 > ----- Original Message -----=20 > From: "Hancock, Robert" > To: "Georgios Karagiannis" ; "Martin=20 > Stiemerling"=20 > > Cc: ; "nsis" > Sent: Tuesday, October 11, 2005 3:13 PM > Subject: RE: [NSIS] NSLP-Data in intial GIST-Query >=20 >=20 > > hi all, > > > > there will be a separate answer to Martin's original point > > (in fact, in an answer to Thomas's answer ...). But there are > > some specific points here too. Inline: > > > >> -----Original Message----- > >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Sent: 11 October 2005 10:07 > >> To: Martin Stiemerling; Hancock, Robert > >> Cc: nsis; s0076309@student.utwente.nl > >> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query > >> > >> > >> Hi Martin > >> > >> I think that your example is not very clear! > >> Please note that during the discovery phase it is assumed that the > >> querying and responding node do not have to create the GIST > >> routing state. > > > > In the discovery phase (if discovery is happening), the Querying > > node *has* to create state at the start; the Responding node > > can do so in a delayed way (as we all know). > > > >> > >> Thus your example is valid for both GIST stateless and=20 > GIST stateful > >> responding nodes. > >> Please note however, that the sending node will wait for a > >> timeout, and if > >> no GIST-Response arrives in time, > >> then it will resend the complete GIST QUERY message > >> including the payload. > >> Please also note that if the GIST responding node receives > >> the GIST_QUERY > >> message, > >> it will send the payload to the appropriate NSLP. Thus even > >> during the first > >> GIST-QUERY the NSLP-DATA > >> will be forwarded to the NSLP. > > > > This is true. > > > >> > >> But anyway, you raised a good point! > >> The real problem that occurs due to the stateless GIST > >> responding node is > >> that the > >> GIST queying node will keep retransmiting the GIST-QUERY message! > > > > This is not quite true. > > > >> > >> Therefore, I think that it is needed to specify a way such that the > >> stateless GIST responding node > >> will inform the GIST querying node that the GIST=20 > responding node is a > >> stateless node. > > > > This is definitely not true. The situation is described in 4.3.2: > > a GIST node which is stateless in this way will forward the Query > > downstream, possibly with a revised payload; when this hits=20 > a stateful > > node, the Response will come back. The stateless node MUST NOT send > > anything back saying 'I am stateless' because then the Querying node > > would see two (or in general 1+N) replies to its message,=20 > all but one > > of them being failures. The querying node doesn't care about the > > existence of the stateless nodes anyway (at the GIST level). > > > > If the Query is lost before it gets to the stateful Responder, or > > if the Response is lost on the way back, or if there is no stateful > > Responder in the first place, the original Query will be resent. > > > > r. > > > >> > >> Best Regards, > >> Mayi and Georgios > >> > >> > >> ----- Original Message -----=20 > >> From: "Martin Stiemerling" > >> To: "nsis" > >> Sent: Tuesday, October 11, 2005 10:08 AM > >> Subject: [NSIS] NSLP-Data in intial GIST-Query > >> > >> > >> > Hi, > >> > > >> > GIST-Query messages may carry a NSLP-Data object containing > >> information > >> > for the NSLP. I'm now assuming an initial GIST-Query send > >> downstream > >> > looking for the next peer., carrying NSLP-Data, and a GIST > >> downstream node > >> > using a stateless approach (delayed state setup, using a=20 > responder > >> > cookie ). In this case, the NSLP data would be lost, if not > >> re-transmitted > >> > in the GIST-Confirm/GIST-Data later, since the downstream > >> peer does not > >> > keep any state about the initial GIST-Query. There is no > >> text (as far as I > >> > know) describing what the sending GIST-peer should do in > >> this case. In the > >> > case of a "stateless" downstream peer (querying node sees > >> response with > >> > responder cookie and R-flag set), the querying must re-send > >> the NSLP-data > >> > in the next message. > >> > > >> > I may have missed something while reading the draft, but > >> this issue was > >> > coming to mind afterwards. > >> > > >> > With best regards, > >> > > >> > Martin > >> > > >> > _______________________________________________ > >> > 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 > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 04:43:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPyge-0007Lf-Jr; Thu, 13 Oct 2005 04:43:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPygc-0007LX-6z for nsis@megatron.ietf.org; Thu, 13 Oct 2005 04:43:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02792 for ; Thu, 13 Oct 2005 04:43:34 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPyr5-0003zt-Uo for nsis@ietf.org; Thu, 13 Oct 2005 04:54:28 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9D8gu4P000436; Thu, 13 Oct 2005 10:42:57 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9D8guxw011406; Thu, 13 Oct 2005 10:42:56 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Oct 2005 10:42:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [NSIS] Re: authorizing query messages Date: Thu, 13 Oct 2005 10:42:54 +0200 Message-ID: Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXPT7yj8ePZgGgMSp29zr/zQf1xngACxQHQ From: "Tschofenig, Hannes" To: "Nguyen, An" , "David R Oran" X-OriginalArrivalTime: 13 Oct 2005 08:42:55.0923 (UTC) FILETIME=[1B5F2830:01C5CFD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: quoted-printable Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi an,=20 let me tell you my view on this issue.=20 carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at.=20 in the past we had a few discussions discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information.=20 as such, it was difficult to show a good mapping by investigating only the ietf work.=20 ciao hannes > David, >=20 > Just a question: Do we need to enhance > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si > p-app-09.txt > to include QSPEC if you we decide to use DIAMETER to perform the > authorization for users' resources? >=20 > Thanks, >=20 > An > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Monday, October 10, 2005 10:52 AM > To: Tschofenig, Hannes > Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; > nsis@ietf.org > Subject: Re: AW: [NSIS] Re: authorizing query messages >=20 >=20 > Do you think it makes sense to have the authorization=20 > response to the =20 > query return a QSPEC with the user's authorized resources so=20 > that can =20 > be returned along with the available resources (or=20 > alternatively used =20 > by the NSLP to reduce the reported available resources to only the =20 > amount authorized? >=20 > On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote: >=20 >=20 > > hi jukka, > > > > thanks for your feedback. here is a proposal how to handle =20 > > authorization > > for the query message: > > > > the query message triggers a QAR with the authentication info but > > without any QoS-Resources. > > it might be necessary to indicate (somewhere) that this is only a =20 > > query > > without the need to enable accounting and charging. > > > > as such, the response in the QAA is also limited to the=20 > result rather > > than returning information like avps like CC-Time,Cost, > > QoS-Resources,Authz-time). > > > > here is the figure: > > > > End-Host Network Element Entity > > requesting QoS ( Diameter ( Diameter > > QoS Client) QoS Server) > > | | | > > +---QoS-Query------>| | > > | +- - - - - QAR - - - - - >| > > | |(QoS-Resources=3DNULL, | > > | | QoS-Auth-Data,User-ID)| > > | | +--------+--------------+ > > | | | Authorize request | > > | | | Keep no session data | > > | | | | > > | | +--------+--------------+ > > | |< - - - - QAA - - - - - -+ > > | |(Result-Code) | > > | | | > > | +-------+---------+ > > | |Proceeed with | > > | |QoS signaling | > > | |exchange | > > | +-------+---------+ > > | | > > | +----------QoS-Reserve---------------> > > | | > > | |<---------QoS-Response--------------- > > |<--QoS-Response----+ > > > > > > ciao > > hannes > > > > > > > >> Hi, > >> > >> I would expect that in certain networks, not everybody may=20 > query the > >> network of available resources. Thus, there could be need to > >> include an > >> auhtorization token, or ask from a Diameter server whether the node > >> sending the query is allowed to do that. > >> > >> Cheers, > >> Jukka > >> > >> > >> On Thu, 6 Oct 2005, Hannes Tschofenig wrote: > >> > >> > >> > >>> hi all, > >>> > >>> as part of our work on the diameter-qos application and the > >>> > >>> > >> radius-qos draft > >> > >> > >>> we came across the aspect of authorizing individual types > >>> > >>> > >> of actions taken by > >> > >> > >>> the qos signaling protocol. from discussions in the past i > >>> > >>> > >> remember that > >> > >> > >>> people wanted to authorize query messages as well. when we > >>> > >>> > >> come to the > >> > >> > >>> concrete details we are not quite sure what it actually > >>> > >>> > >> means. what would be > >> > >> > >>> the authorization decision regarding the query message > >>> > >>> > >> people have in mind? > >> > >> > >>> > >>> ciao > >>> hannes > >>> > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 04:44:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPyhL-0007Ql-5w; Thu, 13 Oct 2005 04:44:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPyhJ-0007QV-AQ for nsis@megatron.ietf.org; Thu, 13 Oct 2005 04:44:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02864 for ; Thu, 13 Oct 2005 04:44:17 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPyrn-000423-0J for nsis@ietf.org; Thu, 13 Oct 2005 04:55:11 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9D8gu2A019763; Thu, 13 Oct 2005 10:42:56 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9D8gtnt011394; Thu, 13 Oct 2005 10:42:55 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Oct 2005 10:42:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [NSIS] Re: authorizing query messages Date: Thu, 13 Oct 2005 10:42:01 +0200 Message-ID: Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXN2NgkT9W1AQ+/RKKr9Njmf3wLBgB+IbDw From: "Tschofenig, Hannes" To: "David R Oran" X-OriginalArrivalTime: 13 Oct 2005 08:42:55.0079 (UTC) FILETIME=[1ADE5F70:01C5CFD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi david,=20 > Do you think it makes sense to have the authorization=20 > response to the =20 > query return a QSPEC with the user's authorized resources so=20 > that can =20 > be returned along with the available resources (or=20 > alternatively used =20 > by the NSLP to reduce the reported available resources to only the =20 > amount authorized? if the query message triggers a diameter interaction then it might be useful to provide this type of information.=20 does not sound like a bad idea. it might, however, raise some additional questions:=20 - should the diameter client cache this information to shorten the authorization protocol interaction for a subsequently received reserve message?=20 - how long should the diameter client cache a response (if at all)? =20 - is the response related to a particular flow only or also valid for other flows?=20 ciao hannes >=20 > On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote: >=20 >=20 > > hi jukka, > > > > thanks for your feedback. here is a proposal how to handle =20 > > authorization > > for the query message: > > > > the query message triggers a QAR with the authentication info but > > without any QoS-Resources. > > it might be necessary to indicate (somewhere) that this is only a =20 > > query > > without the need to enable accounting and charging. > > > > as such, the response in the QAA is also limited to the=20 > result rather > > than returning information like avps like CC-Time,Cost, > > QoS-Resources,Authz-time). > > > > here is the figure: > > > > End-Host Network Element Entity > > requesting QoS ( Diameter ( Diameter > > QoS Client) QoS Server) > > | | | > > +---QoS-Query------>| | > > | +- - - - - QAR - - - - - >| > > | |(QoS-Resources=3DNULL, | > > | | QoS-Auth-Data,User-ID)| > > | | +--------+--------------+ > > | | | Authorize request | > > | | | Keep no session data | > > | | | | > > | | +--------+--------------+ > > | |< - - - - QAA - - - - - -+ > > | |(Result-Code) | > > | | | > > | +-------+---------+ > > | |Proceeed with | > > | |QoS signaling | > > | |exchange | > > | +-------+---------+ > > | | > > | +----------QoS-Reserve---------------> > > | | > > | |<---------QoS-Response--------------- > > |<--QoS-Response----+ > > > > > > ciao > > hannes > > > > > > > >> Hi, > >> > >> I would expect that in certain networks, not everybody may=20 > query the > >> network of available resources. Thus, there could be need to > >> include an > >> auhtorization token, or ask from a Diameter server whether the node > >> sending the query is allowed to do that. > >> > >> Cheers, > >> Jukka > >> > >> > >> On Thu, 6 Oct 2005, Hannes Tschofenig wrote: > >> > >> > >> > >>> hi all, > >>> > >>> as part of our work on the diameter-qos application and the > >>> > >>> > >> radius-qos draft > >> > >> > >>> we came across the aspect of authorizing individual types > >>> > >>> > >> of actions taken by > >> > >> > >>> the qos signaling protocol. from discussions in the past i > >>> > >>> > >> remember that > >> > >> > >>> people wanted to authorize query messages as well. when we > >>> > >>> > >> come to the > >> > >> > >>> concrete details we are not quite sure what it actually > >>> > >>> > >> means. what would be > >> > >> > >>> the authorization decision regarding the query message > >>> > >>> > >> people have in mind? > >> > >> > >>> > >>> ciao > >>> hannes > >>> > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 05:20:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPzGZ-0000dN-BI; Thu, 13 Oct 2005 05:20:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPzGY-0000dF-5X for nsis@megatron.ietf.org; Thu, 13 Oct 2005 05:20:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04996 for ; Thu, 13 Oct 2005 05:20:42 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPzR1-0005Ao-Fk for nsis@ietf.org; Thu, 13 Oct 2005 05:31:36 -0400 Received: from [192.168.178.22] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C1A461BAC4D for ; Thu, 13 Oct 2005 11:20:34 +0200 (CEST) Date: Thu, 13 Oct 2005 11:20:31 +0200 From: Martin Stiemerling To: nsis Message-ID: <893C2626D551D64B30A12668@[10.1.1.109]> X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, Draft -07 of the NATFW NSLP describes a query and diagnosis capability in Section 3.3.6. These capabilities have been in the draft for while but no real usage scenarios have been described so far (see issue 30 in the tracker ). The general feeling of the WG about these query and diagnosis capabilities were quite mixed (as expressed during the last interim in Munich). Since then I have not received any further comments about this issue. Personally, I do not see any good use cases for such a capability in the NATFW NSLP and I'm in favour of removing it completely. I'm soliciting the WG to give feedback on this issue, whether it is considered a useful feature or not. If you consider it a useful feature, you should give some use cases. Thanks in advance, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 05:34:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPzU2-0004BZ-92; Thu, 13 Oct 2005 05:34:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPzU0-0004BJ-Mp for nsis@megatron.ietf.org; Thu, 13 Oct 2005 05:34:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05568 for ; Thu, 13 Oct 2005 05:34:37 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPzeU-0005Xf-6r for nsis@ietf.org; Thu, 13 Oct 2005 05:45:31 -0400 Received: from [192.168.178.22] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3F8B61BAC4D for ; Thu, 13 Oct 2005 11:34:30 +0200 (CEST) Date: Thu, 13 Oct 2005 11:34:27 +0200 From: Martin Stiemerling To: nsis Message-ID: <434EB5A245CF4F4C1DD83F9E@[10.1.1.109]> X-Mailer: Mulberry/3.1.6 (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-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [NSIS] NATFW issue 39: REA-PROXY race condition between RESPONSE and requested CREATE X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I suggest to close issue 39 (REA-PROXY race condition between RESPONSE and requested CREATE, ). Proposed text is: There is a possible race condition between the RESPONSE message to the REA- PROXY and the CREATE message generated by the edge-NAT. The CREATE message can arrive earlier than the RESPONSE message. An NI+ MUST accept CREATE messages generated by the edge-NAT even if the RESPONSE message to the REA-PROXY request was not received. Note: The NI+ is able to recognize an edge-NAT generated CREATE through the presence of the NATFW_NONCE object. The NATFW_NONCE object echoes a value chosen by the NI+. The proposed text has been already included in draft -07 of the NATFW NSLP. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 09:06:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2mY-0000BX-84; Thu, 13 Oct 2005 09:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2mW-0000B7-UE for nsis@megatron.ietf.org; Thu, 13 Oct 2005 09:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16181 for ; Thu, 13 Oct 2005 09:05:56 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ2x3-0002nx-1V for nsis@ietf.org; Thu, 13 Oct 2005 09:16:53 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9DD40vs007579 for ; Thu, 13 Oct 2005 16:04:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 16:05:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 16:05:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2005 16:05:59 +0300 Message-ID: Thread-Topic: TLS in the GIST draft Thread-Index: AcXP9tsEj0AHJRnGQYWv3TVJCAPgUg== To: X-OriginalArrivalTime: 13 Oct 2005 13:05:58.0244 (UTC) FILETIME=[DA5E3A40:01C5CFF6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] TLS in the GIST draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org The current GIST draft has very little text about how TLS is actually used with GIST. I think there are a couple of issues that need to be handled somehow. First, other protocols that have mandated the use of TLS have often specified exactly what subset of TLS features must be supported. For instance, RFC 3588 Section 13.2 says A Diameter node that initiates a connection to another Diameter node acts as a TLS client according to [TLS], and a Diameter node that accepts a connection acts as a TLS server. Diameter nodes implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, the Diameter node acting as TLS server must request a certificate from the Diameter node acting as TLS client, and the Diameter node acting as TLS client MUST be prepared to supply a certificate on request. Diameter nodes MUST be able to negotiate the following TLS cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Diameter nodes SHOULD be able to negotiate the following TLS cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA Diameter nodes MAY negotiate other TLS cipher suites. Something like this might be useful for the GIST draft as well, since just saying "use TLS" is not sufficient to guarantee any kind of interoperability. Second, the Stack-Proposal negotiation seems to assume that a single bit of information, that TLS is used, is sufficient to get TLS working. This is not necessarily the case. Some TLS authentication mechanisms assume the client (initiating the TLS connection) knows beforehand either what credentials it wants to use itself, and/or what is the expected identity of the server. For instance, in Kerberos ciphersuites for TLS [RFC2712], the client has to obtain a ticket from the KDC/TGS, and put it in the TLS ClientKeyExchange message. But to obtain the ticket, the client has=20 to know the server's PrincipalName -- where exactly does it get this information? (One option would be to send it in Stack-Configuration-Data. Another would be to specify a way to derive it from other information=20 that's already present in the messages, like Network-Layer-Information. Perhaps there are other options too.) To take another example, when using SRP to authenticate TLS [draft-ietf-tls-srp-10], the client sends its SRP user name in the ClientHello message. If the client has multiple secrets (SRP password), it has to decide beforehand which of them to use. Presumably, the identity of the TLS server is a major factor in=20 this decision. In fact, public-key certificates seem to be pretty much the only=20 TLS case where no prior knowledge is required by the client (mainly because the server sends its certificate first). Best regards, Pasi _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 09:35:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3F7-0007sz-8k; Thu, 13 Oct 2005 09:35:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3F5-0007sh-Gn for nsis@megatron.ietf.org; Thu, 13 Oct 2005 09:35:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17758 for ; Thu, 13 Oct 2005 09:35:28 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ3Pb-0003cz-FV for nsis@ietf.org; Thu, 13 Oct 2005 09:46:24 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Thu, 13 Oct 2005 09:35:24 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101309352402270 ; Thu, 13 Oct 2005 09:35:24 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP; Thu, 13 Oct 2005 09:35:24 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 09:39:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Thu, 13 Oct 2005 09:38:43 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8667264D7@bh-exchange02.saic-abingdon.com> Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXPUKLfkBvvP6+1QrqWtcJBlPidlQAE8wGZ From: "Roy, Radhika \(AEAD\)" To: "Nguyen, An" , "Tschofenig, Hannes" X-OriginalArrivalTime: 13 Oct 2005 13:39:06.0203 (UTC) FILETIME=[7B48B2B0:01C5CFFB] X-Spam-Score: 0.8 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1405043372==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1405043372== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CFFB.6DECBEE0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CFFB.6DECBEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An: =20 I do NOT think that Diameter SIP application is the right place to do = so. There are several steps to do so as follows: =20 1.=09 QSPEC is not an application per se. It is mere couple of QoS parameters = (please note that it is NOT QoS model - it is extremely technically = confusing as well as technically inconsistent to mix QSPEC and QoS Model = in the same breath/place). 2.=09 A QSPEC cannot independently sent in the middle of something unless it = is coupled with to meet any application's needs. 3.=09 SIP is only ONE real-time application, and however, QSPEC is good for = all applications including both real-time and non-real-time = applications. 4.=09 Diameter QoS Application is the right place for extending this using = QSPEC (again NOT QoS models). 5.=09 If item 3 can use item 4, it will then prove all standards = Diameter-based standards are consistent. 6.=09 With respect to NSIS signaling protocol, item 5 will also test whether = or not NSIS protocol is good or not. Hope this clarifies your question. If you have any more questions, please let me know. Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Nguyen, An Sent: Wed 10/12/2005 1:09 PM To: 'David R Oran'; Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages David, Just a question: Do we need to enhance http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-09.tx= t to include QSPEC if you we decide to use DIAMETER to perform the authorization for users' resources? Thanks, An -----Original Message----- From: David R Oran [mailto:oran@cisco.com] Sent: Monday, October 10, 2005 10:52 AM To: Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: Re: AW: [NSIS] Re: authorizing query messages Do you think it makes sense to have the authorization response to the=20 query return a QSPEC with the user's authorized resources so that can=20 be returned along with the available resources (or alternatively used=20 by the NSLP to reduce the reported available resources to only the=20 amount authorized? On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote: > hi jukka, > > thanks for your feedback. here is a proposal how to handle=20 > authorization > for the query message: > > the query message triggers a QAR with the authentication info but > without any QoS-Resources. > it might be necessary to indicate (somewhere) that this is only a=20 > query > without the need to enable accounting and charging. > > as such, the response in the QAA is also limited to the result rather > than returning information like avps like CC-Time,Cost, > QoS-Resources,Authz-time). > > here is the figure: > > End-Host Network Element Entity > requesting QoS ( Diameter ( Diameter > QoS Client) QoS Server) > | | | > +---QoS-Query------>| | > | +- - - - - QAR - - - - - >| > | |(QoS-Resources=3DNULL, | > | | QoS-Auth-Data,User-ID)| > | | +--------+--------------+ > | | | Authorize request | > | | | Keep no session data | > | | | | > | | +--------+--------------+ > | |< - - - - QAA - - - - - -+ > | |(Result-Code) | > | | | > | +-------+---------+ > | |Proceeed with | > | |QoS signaling | > | |exchange | > | +-------+---------+ > | | > | +----------QoS-Reserve---------------> > | | > | |<---------QoS-Response--------------- > |<--QoS-Response----+ > > > ciao > hannes > > > >> Hi, >> >> I would expect that in certain networks, not everybody may query the >> network of available resources. Thus, there could be need to >> include an >> auhtorization token, or ask from a Diameter server whether the node >> sending the query is allowed to do that. >> >> Cheers, >> Jukka >> >> >> On Thu, 6 Oct 2005, Hannes Tschofenig wrote: >> >> >> >>> hi all, >>> >>> as part of our work on the diameter-qos application and the >>> >>> >> radius-qos draft >> >> >>> we came across the aspect of authorizing individual types >>> >>> >> of actions taken by >> >> >>> the qos signaling protocol. from discussions in the past i >>> >>> >> remember that >> >> >>> people wanted to authorize query messages as well. when we >>> >>> >> come to the >> >> >>> concrete details we are not quite sure what it actually >>> >>> >> means. what would be >> >> >>> the authorization decision regarding the query message >>> >>> >> people have in mind? >> >> >>> >>> ciao >>> hannes >>> >>> >>> >>> >>> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C5CFFB.6DECBEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: AW: [NSIS] Re: authorizing query messages=0A= =0A= =0A=
An:
=0A=
 
=0A=
I do NOT think that Diameter = SIP =0A= application is the right place to do so. There are several steps to do = so as =0A= follows:
=0A=
 
=0A=
=0A=
    =0A=
  1. =0A=
    QSPEC is not an application per se. = It is mere =0A= couple of QoS parameters (please note that it is NOT QoS model - it is =0A= extremely technically confusing as well as technically inconsistent to = mix =0A= QSPEC and QoS Model in the same breath/place).
    =0A=
  2. =0A=
    A QSPEC cannot independently sent in = the middle =0A= of something unless it is coupled with to meet any application's =0A= needs.
    =0A=
  3. =0A=
    SIP is only ONE real-time = application, =0A= and however, QSPEC is good for all applications including both = real-time and =0A= non-real-time applications.
    =0A=
  4. =0A=
    Diameter QoS Application is the right = place for =0A= extending this using QSPEC (again NOT QoS models).
    =0A=
  5. =0A=
    If item 3 can use item 4, it will = then prove all =0A= standards Diameter-based standards are consistent.
    =0A=
  6. =0A=
    With respect to NSIS signaling = protocol, item 5 =0A= will also test whether or not NSIS protocol is good or =0A= not.
=0A=

Hope this clarifies your = question.

=0A=

If you have any more questions, please = let me =0A= know.

=0A=
Best regards,
=0A=
Radhika
=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on =0A= behalf of Nguyen, An
Sent: Wed 10/12/2005 1:09 = PM
To: 'David =0A= R Oran'; Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios =0A= Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: RE: AW: = [NSIS] =0A= Re: authorizing query messages

=0A=
=0A=

David,

Just a question: Do we need to = enhance
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si= p-app-09.txt
to =0A= include QSPEC if you we decide to use DIAMETER to perform = the
authorization =0A= for users' resources?

Thanks,

An
-----Original =0A= Message-----
From: David R Oran [mailto:oran@cisco.com]
Sent: = Monday, October =0A= 10, 2005 10:52 AM
To: Tschofenig, Hannes
Cc: McDonald, Andrew; = Georgios =0A= Karagiannis; Jukka MJ Manner;
nsis@ietf.org
Subject: Re: AW: = [NSIS] Re: =0A= authorizing query messages


Do you think it makes sense to = have the =0A= authorization response to the 
query return a QSPEC with the = user's =0A= authorized resources so that can 
be returned along with the = available =0A= resources (or alternatively used 
by the NSLP to reduce the = reported =0A= available resources to only the 
amount authorized?

On = Oct 6, =0A= 2005, at 11:37 AM, Tschofenig, Hannes wrote:


> hi =0A= jukka,
>
> thanks for your feedback. here is a proposal how = to =0A= handle 
> authorization
> for the query =0A= message:
>
> the query message triggers a QAR with the =0A= authentication info but
> without any QoS-Resources.
> it = might be =0A= necessary to indicate (somewhere) that this is only a 
> =0A= query
> without the need to enable accounting and =0A= charging.
>
> as such, the response in the QAA is also = limited to =0A= the result rather
> than returning information like avps like =0A= CC-Time,Cost,
> QoS-Resources,Authz-time).
>
> here is = the =0A= figure:
>
>    =0A= End-Host         Network =0A= Element           =   =0A= Entity
>   requesting QoS      = ( =0A= Diameter           = ;   =0A= ( =0A= Diameter
>         &nb= sp;           &nbs= p;  =0A= QoS =0A= Client)           =   =0A= QoS Server)
>       =0A= |            =        =0A= |            =              =0A= |
>       =0A= +---QoS-Query------>|        &= nbsp;           &n= bsp;    =0A= |
>       =0A= |            =        =0A= +- - - - - QAR - - - - - = >|
>       =0A= |            =        =0A= |(QoS-Resources=3DNULL,     =0A= |
>       =0A= |            =        =0A= |   =0A= QoS-Auth-Data,User-ID)|
>       =0A= |            =        =0A= |            =     =0A= +--------+--------------+
>       =0A= |            =        =0A= |            =     =0A= |  Authorize request    =0A= |
>       =0A= |            =        =0A= |            =     =0A= |  Keep no session data = |
>       =0A= |            =        =0A= |            =     =0A= |            =            =0A= |
>       =0A= |            =        =0A= |            =     =0A= +--------+--------------+
>       =0A= |            =        =0A= |< - - - - QAA - - - - - = -+
>       =0A= |            =        =0A= |(Result-Code)          = ;  =0A= |
>       =0A= |            =        =0A= |            =              =0A= |
>       =0A= |           =0A= +-------+---------+
>       =0A= |           |Proceeed =0A= with    |
>       =0A= |           |QoS =0A= signaling    = |
>       =0A= |           =0A= |exchange         =0A= |
>       =0A= |           =0A= +-------+---------+
>       =0A= |            =        =0A= |
>       =0A= |            =        =0A= +----------QoS-Reserve--------------->
>    =    =0A= |            =        =0A= |
>       =0A= |            =        =0A= |<---------QoS-Response---------------
>    =    =0A= |<--QoS-Response----+
>
>
> ciao
> =0A= hannes
>
>
>
>> Hi,
>>
>> I = would =0A= expect that in certain networks, not everybody may query the
>> = network =0A= of available resources. Thus, there could be need to
>> include =0A= an
>> auhtorization token, or ask from a Diameter server = whether the =0A= node
>> sending the query is allowed to do =0A= that.
>>
>> Cheers,
>> =0A= Jukka
>>
>>
>> On Thu, 6 Oct 2005, Hannes = Tschofenig =0A= wrote:
>>
>>
>>
>>> hi =0A= all,
>>>
>>> as part of our work on the = diameter-qos =0A= application and the
>>>
>>>
>> = radius-qos =0A= draft
>>
>>
>>> we came across the aspect = of =0A= authorizing individual types
>>>
>>>
>> = of =0A= actions taken by
>>
>>
>>> the qos = signaling =0A= protocol. from discussions in the past =0A= i
>>>
>>>
>> remember =0A= that
>>
>>
>>> people wanted to authorize = query =0A= messages as well. when we
>>>
>>>
>> = come to =0A= the
>>
>>
>>> concrete details we are not = quite =0A= sure what it actually
>>>
>>>
>> means. = what =0A= would be
>>
>>
>>> the authorization = decision =0A= regarding the query message
>>>
>>>
>> = people =0A= have in mind?
>>
>>
>>>
>>> =0A= ciao
>>> =0A= hannes
>>>
>>>
>>>
>>>>>>
>>
>> =0A= _______________________________________________
>> nsis mailing =0A= list
>> nsis@ietf.org
>> https://www1.ietf.or= g/mailman/listinfo/nsis
>>
>>
>>
>> =0A= _______________________________________________
> nsis mailing =0A= list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>
>


__________________= _____________________________
nsis =0A= mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

______________________________________= _________
nsis =0A= mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

=0A= =0A= =0A= ------_=_NextPart_001_01C5CFFB.6DECBEE0-- --===============1405043372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1405043372==-- From nsis-bounces@ietf.org Thu Oct 13 09:42:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3MJ-0001hp-Jm; Thu, 13 Oct 2005 09:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3MH-0001gc-Mi for nsis@megatron.ietf.org; Thu, 13 Oct 2005 09:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18258 for ; Thu, 13 Oct 2005 09:42:54 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ3Wo-0003rf-AD for nsis@ietf.org; Thu, 13 Oct 2005 09:53:50 -0400 Received: from [192.168.178.22] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 51BBB1BAC99 for ; Thu, 13 Oct 2005 15:42:48 +0200 (CEST) Date: Thu, 13 Oct 2005 15:42:46 +0200 From: Martin Stiemerling To: nsis Message-ID: <71013D9839AB4140F6176563@[10.1.1.109]> X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [NSIS] NATFW issue 28: Keep Port Parity field/semantics X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org >From the NATFW issue tracker: "Nodes may request NATs to keep the parity of the transport layer ports" My suggestion: >From issue 29: Dave Oran said in an email on 15 July 2005: "The alternative is to not worry about this at all and assume everybody will have implemented RFC3605 by now." My recommendation: Same here as in issue 29, do not include Port Parity Field and use RFC 3605. Anybody objections to close issue 28? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 09:43:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3MK-0001iL-8c; Thu, 13 Oct 2005 09:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3MI-0001h0-Ej for nsis@megatron.ietf.org; Thu, 13 Oct 2005 09:42:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18261 for ; Thu, 13 Oct 2005 09:42:55 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ3Wo-0003re-2R for nsis@ietf.org; Thu, 13 Oct 2005 09:53:51 -0400 Received: from [192.168.178.22] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A57BB1BAC4D for ; Thu, 13 Oct 2005 15:42:47 +0200 (CEST) Date: Thu, 13 Oct 2005 15:42:44 +0200 From: Martin Stiemerling To: nsis Message-ID: <26D0BF4C61584A4D7272BBE1@[10.1.1.109]> X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [NSIS] NATFW issue 29: Port Range Parameter Field X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This issue has been already discussed in July 2005. My suggestion is to close this issue. From the tracker: Dave Oran said in an email on 15 July 2005: "The alternative is to not worry about this at all and assume everybody will have implemented RFC3605 by now." My recommendation: Do not include Port Range Parameter Field and use RFC 3605. Anybody objections to close issue 29? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 13 15:34:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8q9-0006nE-34; Thu, 13 Oct 2005 15:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8q7-0006n8-Mm for nsis@megatron.ietf.org; Thu, 13 Oct 2005 15:34:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06993 for ; Thu, 13 Oct 2005 15:34:02 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ90h-0004uR-6z for nsis@ietf.org; Thu, 13 Oct 2005 15:45:03 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Thu, 13 Oct 2005 15:33:48 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101315334718366 ; Thu, 13 Oct 2005 15:33:47 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Thu, 13 Oct 2005 15:33:48 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 15:37:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Thu, 13 Oct 2005 15:37:07 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8667264DA@bh-exchange02.saic-abingdon.com> Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXPT7yj8ePZgGgMSp29zr/zQf1xngACxQHQADOp9sE= From: "Roy, Radhika \(AEAD\)" To: "Tschofenig, Hannes" , "Nguyen, An" X-OriginalArrivalTime: 13 Oct 2005 19:37:30.0046 (UTC) FILETIME=[8C92BDE0:01C5D02D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0694875949==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0694875949== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D02D.7F001146" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D02D.7F001146 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An and Hannes: =20 Kindly see my earlier email related to this. =20 In addition, I like to add couple of points related to Hannes comments = as follows: 1.=09 It is desirable to have all the QoS parameters of QSPEC to be = authorized. If something is missing in Diameter QoS application or vice = versa, we need to augment those. 2.=09 Diameter QoS application does not need to use QSPEC per se. It needs to = carry the abstract of QSPEC QoS parameters within the Diameter QoS = application protocol. If any QoS parameters or exact semantics are = missing in Dia QoS, Dia QoS needs to be extended for only those. 3.=09 Once items 1 and 2 are taken care of, authorization/authentication will = be taken care of by basic Diameter protocol (depending on which = application [e.g., SIP, FTP, etc.] will invoke QoS. 4.=09 With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, = we do not need to worry about this. All we need to see whether all the = QoS parameters expressed in SDP have the place holder in Dia QoS = (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth = is there. If it is so, we are on the safe side because Dia QoS/QSPEC can = support this. In the future, we hope that SDP QoS parameters can be = extended to delay, jitter, packet loss, etc. based on the QoS needs of = each codec type. Until that happens, let us wait. 5.=09 By the way, I would like to later how SIP, NSIS signaling protocol, and = Diameter SIP application and Diameter QoS application are integrated on = end-to-end basis. (Note: We have done our home work for probable = implementation after studying the modeling and simulations results = [sorry - not to be publicly released] and test-bed [NSIS protocol NOT = yet] in controlled environments, but I am waiting how the standard works = progress. Later on, we hope to implement for the worldwide network that = will include MANET as the access network.) The point that I like to make is this: QSPEC = Authorization/Authentication is NOT a big deal. It is straight forward = as describe above. If An has any problems, let me know. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, let me tell you my view on this issue. carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. ciao hannes ------_=_NextPart_001_01C5D02D.7F001146 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= AW: AW: [NSIS] Re: authorizing query messages=0A= =0A= =0A=
An and = Hannes:
=0A=
 
=0A=
Kindly see my earlier email = related to =0A= this.
=0A=
 
=0A=
In addition, I like to add = couple of points =0A= related to Hannes comments as follows:
=0A=
=0A=
    =0A=
  1. =0A=
    It is desirable to have all the QoS = parameters of =0A= QSPEC to be authorized. If something is missing in Diameter QoS = application or =0A= vice versa, we need to augment those.
    2. =0A=
  2. =0A=
    Diameter QoS application does not = need to use =0A= QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters = within =0A= the Diameter QoS application protocol. If any QoS parameters or exact =0A= semantics are missing in Dia QoS, Dia QoS needs to be extended for = only =0A= those.
    3. =0A=
  3. =0A=
    Once items 1 and 2 are taken care of, =0A= authorization/authentication will be taken care of by basic Diameter = protocol =0A= (depending on which application [e.g., SIP, FTP, etc.] will invoke =0A= QoS.
    4. =0A=
  4. =0A=
    With respect to mapping of SIP/SDP = QoS parameters =0A= mapping into Dia QoS, we do not need to worry about this. All we need = to see =0A= whether all the QoS parameters expressed in SDP have the place holder = in Dia =0A= QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only = bandwidth is =0A= there. If it is so, we are on the safe side because Dia QoS/QSPEC can = support =0A= this. In the future, we hope that SDP QoS parameters can be extended = to delay, =0A= jitter, packet loss, etc. based on the QoS needs of each codec type. = Until =0A= that happens, let us wait.
    5. =0A=
  5. =0A=
    By the way, I would like to later how = SIP, NSIS =0A= signaling protocol, and Diameter SIP application and Diameter QoS = application =0A= are integrated on end-to-end basis. (Note: We have done our home = work for =0A= probable implementation after studying the modeling and simulations = results =0A= [sorry - not to be publicly released] and test-bed [NSIS protocol NOT = yet] in =0A= controlled environments, but I am waiting how the standard works = progress. =0A= Later on, we hope to implement for the worldwide network that will = include =0A= MANET as the access network.)
=0A=
The point that I like to make = is this: =0A= QSPEC Authorization/Authentication is NOT a big deal. It is straight = forward as =0A= describe above.
=0A=
If An has any problems, let = me =0A= know.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on =0A= behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42 =0A= AM
To: Nguyen, An; David R Oran
Cc: McDonald, = Andrew; =0A= Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: = AW: AW: =0A= [NSIS] Re: authorizing query messages

=0A=
=0A=

hi an,

let me tell you my view on this =0A= issue.

carrying only the qspec parameter is not sufficient for =0A= the
authorization decision. you need todo more as you see in the =0A= document
(and more stuff will certainly follow -- based on the = reviewers =0A= feedback
we recently received). you might not want to dump almost =0A= all
diameter-qos parameters into the diameter-sip document. instead, =0A= it
might be better to see how they interwork just like the =0A= diameter-sip
application needs to interwork with other diameter = applications =0A= as well.
this is a bit more complex compared to radius where you can = just =0A= dump
the desired parameter into a message since the concept of an =0A= application
is not defined. for the diameter-qos application we = investigated =0A= the
interworking with other applications, such as nasreq and credit =0A= control.
this might be another application to take a look = at.

in the =0A= past we had a few discussions how to map the qos
specific parameters = in the =0A= sdp to the qspec. within the sdp payloads
only bandwidth parameters = are =0A= carried. the 3gpp additionally uses
further parameters in addition to = the =0A= bandwidth parameters but they are
determined based on codec = information and =0A= bearer information.
as such, it was difficult to show a good mapping = by =0A= investigating only
the ietf =0A= work.

ciao
hannes

=0A= =0A= =0A= ------_=_NextPart_001_01C5D02D.7F001146-- --===============0694875949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0694875949==-- From nsis-bounces@ietf.org Thu Oct 13 16:21:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9VL-0006aR-RO; Thu, 13 Oct 2005 16:16:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9VJ-0006Y0-MI for nsis@megatron.ietf.org; Thu, 13 Oct 2005 16:16:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14758 for ; Thu, 13 Oct 2005 16:16:38 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9ft-00089v-Db for nsis@ietf.org; Thu, 13 Oct 2005 16:27:37 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Thu, 13 Oct 2005 16:16:27 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101316162726254 ; Thu, 13 Oct 2005 16:16:27 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Thu, 13 Oct 2005 16:16:27 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 16:20:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Thu, 13 Oct 2005 16:19:46 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8667264DB@bh-exchange02.saic-abingdon.com> Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXPT7yj8ePZgGgMSp29zr/zQf1xngACxQHQADOp9sEAAlFX1Q== From: "Roy, Radhika \(AEAD\)" To: "Nguyen, An" X-OriginalArrivalTime: 13 Oct 2005 20:20:09.0234 (UTC) FILETIME=[81F7D720:01C5D033] X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1273362773==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1273362773== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D033.748D9EF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D033.748D9EF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, An: =20 I also see that there is no direct work on Diameter QoS application = unless something new is started in this area. Or, am I missing = something? =20 The other thing is that we can assume that QSPEC is authorized using AAA = (e.g., Diameter) protocol. In this cae, the standards development for = authorization of QSPEC using AAA protocl falls under the charter of AAA = WG, not a part of NSIS. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Roy, Radhika (AEAD) Sent: Thu 10/13/2005 3:37 PM To: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages An and Hannes: =20 Kindly see my earlier email related to this. =20 In addition, I like to add couple of points related to Hannes comments = as follows: 1.=09 It is desirable to have all the QoS parameters of QSPEC to be = authorized. If something is missing in Diameter QoS application or vice = versa, we need to augment those. 2.=09 Diameter QoS application does not need to use QSPEC per se. It needs to = carry the abstract of QSPEC QoS parameters within the Diameter QoS = application protocol. If any QoS parameters or exact semantics are = missing in Dia QoS, Dia QoS needs to be extended for only those. 3.=09 Once items 1 and 2 are taken care of, authorization/authentication will = be taken care of by basic Diameter protocol (depending on which = application [e.g., SIP, FTP, etc.] will invoke QoS. 4.=09 With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, = we do not need to worry about this. All we need to see whether all the = QoS parameters expressed in SDP have the place holder in Dia QoS = (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth = is there. If it is so, we are on the safe side because Dia QoS/QSPEC can = support this. In the future, we hope that SDP QoS parameters can be = extended to delay, jitter, packet loss, etc. based on the QoS needs of = each codec type. Until that happens, let us wait. 5.=09 By the way, I would like to later how SIP, NSIS signaling protocol, and = Diameter SIP application and Diameter QoS application are integrated on = end-to-end basis. (Note: We have done our home work for probable = implementation after studying the modeling and simulations results = [sorry - not to be publicly released] and test-bed [NSIS protocol NOT = yet] in controlled environments, but I am waiting how the standard works = progress. Later on, we hope to implement for the worldwide network that = will include MANET as the access network.) The point that I like to make is this: QSPEC = Authorization/Authentication is NOT a big deal. It is straight forward = as describe above. If An has any problems, let me know. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, let me tell you my view on this issue. carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. ciao hannes ------_=_NextPart_001_01C5D033.748D9EF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= AW: AW: [NSIS] Re: authorizing query messages=0A= =0A= =0A=
=0A=
Hi, = An:
=0A=
 
=0A=
I also see that there is no direct work on Diameter QoS = application =0A= unless something new is started in this area. Or, am I missing = something?
=0A=
 
=0A=
The other thing is that we can assume that QSPEC is = authorized =0A= using AAA (e.g., Diameter) protocol. In this cae, the standards = development for =0A= authorization of QSPEC using AAA protocl falls under the charter of AAA = WG, not =0A= a part of NSIS.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on =0A= behalf of Roy, Radhika (AEAD)
Sent: Thu 10/13/2005 3:37 =0A= PM
To: Tschofenig, Hannes; Nguyen, An
Cc: McDonald, = Andrew; =0A= Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: = RE: AW: =0A= [NSIS] Re: authorizing query messages

=0A=
=0A=
An and = Hannes:
=0A=
 
=0A=
Kindly see my earlier email = related to =0A= this.
=0A=
 
=0A=
In addition, I like to add = couple of points =0A= related to Hannes comments as follows:
=0A=
=0A=
    =0A=
  1. =0A=
    It is desirable to have all the QoS = parameters of =0A= QSPEC to be authorized. If something is missing in Diameter QoS = application or =0A= vice versa, we need to augment those.
    =0A=
  2. =0A=
    Diameter QoS application does not = need to use =0A= QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters = within =0A= the Diameter QoS application protocol. If any QoS parameters or exact =0A= semantics are missing in Dia QoS, Dia QoS needs to be extended for = only =0A= those.
    =0A=
  3. =0A=
    Once items 1 and 2 are taken care of, =0A= authorization/authentication will be taken care of by basic Diameter = protocol =0A= (depending on which application [e.g., SIP, FTP, etc.] will invoke =0A= QoS.
    =0A=
  4. =0A=
    With respect to mapping of SIP/SDP = QoS parameters =0A= mapping into Dia QoS, we do not need to worry about this. All we need = to see =0A= whether all the QoS parameters expressed in SDP have the place holder = in Dia =0A= QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only = bandwidth is =0A= there. If it is so, we are on the safe side because Dia QoS/QSPEC can = support =0A= this. In the future, we hope that SDP QoS parameters can be extended = to delay, =0A= jitter, packet loss, etc. based on the QoS needs of each codec type. = Until =0A= that happens, let us wait.
    =0A=
  5. =0A=
    By the way, I would like to later how = SIP, NSIS =0A= signaling protocol, and Diameter SIP application and Diameter QoS = application =0A= are integrated on end-to-end basis. (Note: We have done our home = work for =0A= probable implementation after studying the modeling and simulations = results =0A= [sorry - not to be publicly released] and test-bed [NSIS protocol NOT = yet] in =0A= controlled environments, but I am waiting how the standard works = progress. =0A= Later on, we hope to implement for the worldwide network that will = include =0A= MANET as the access network.)
=0A=
The point that I like to make = is this: =0A= QSPEC Authorization/Authentication is NOT a big deal. It is straight = forward as =0A= describe above.
=0A=
If An has any problems, let = me =0A= know.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on =0A= behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42 =0A= AM
To: Nguyen, An; David R Oran
Cc: McDonald, = Andrew; =0A= Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: = AW: AW: =0A= [NSIS] Re: authorizing query messages

=0A=
=0A=

hi an,

let me tell you my view on this =0A= issue.

carrying only the qspec parameter is not sufficient for =0A= the
authorization decision. you need todo more as you see in the =0A= document
(and more stuff will certainly follow -- based on the = reviewers =0A= feedback
we recently received). you might not want to dump almost =0A= all
diameter-qos parameters into the diameter-sip document. instead, =0A= it
might be better to see how they interwork just like the =0A= diameter-sip
application needs to interwork with other diameter = applications =0A= as well.
this is a bit more complex compared to radius where you can = just =0A= dump
the desired parameter into a message since the concept of an =0A= application
is not defined. for the diameter-qos application we = investigated =0A= the
interworking with other applications, such as nasreq and credit =0A= control.
this might be another application to take a look = at.

in the =0A= past we had a few discussions how to map the qos
specific parameters = in the =0A= sdp to the qspec. within the sdp payloads
only bandwidth parameters = are =0A= carried. the 3gpp additionally uses
further parameters in addition to = the =0A= bandwidth parameters but they are
determined based on codec = information and =0A= bearer information.
as such, it was difficult to show a good mapping = by =0A= investigating only
the ietf =0A= work.

ciao
hannes

=0A= =0A= =0A= ------_=_NextPart_001_01C5D033.748D9EF8-- --===============1273362773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1273362773==-- From nsis-bounces@ietf.org Thu Oct 13 16:30:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9iy-0005GR-G0; Thu, 13 Oct 2005 16:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9iv-0005Cr-UX for nsis@megatron.ietf.org; Thu, 13 Oct 2005 16:30:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15656 for ; Thu, 13 Oct 2005 16:30:42 -0400 (EDT) Received: from mtassp3.ncr.disa.mil ([164.117.82.26] helo=mtassp3.disanet.disa-u.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9tV-00008Q-W6 for nsis@ietf.org; Thu, 13 Oct 2005 16:41:42 -0400 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id <4XSQHVB3>; Thu, 13 Oct 2005 16:30:31 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0E5207AB@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Roy, Radhika (AEAD)'" , "Tschofenig, Hannes" Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Thu, 13 Oct 2005 16:30:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: "McDonald, Andrew" , Georgios Karagiannis , "Nguyen, An" , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1146051664==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1146051664== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D034.F216E270" 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_01C5D034.F216E270 Content-Type: text/plain; charset="iso-8859-1" Roy, No, I don't have any problems. By the way, I would like to see how SIP, NSIS signaling protocol , Diameter SIP application and Diameter QoS application whill be integrated to provide end-to-end QoS also. Regards, An -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: Thursday, October 13, 2005 3:37 PM To: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages An and Hannes: Kindly see my earlier email related to this. In addition, I like to add couple of points related to Hannes comments as follows: 1. It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those. 2. Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those. 3. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS. 4. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait. 5. By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.) The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above. If An has any problems, let me know. Best regards, Radhika _____ From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, let me tell you my view on this issue. carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. ciao hannes ------_=_NextPart_001_01C5D034.F216E270 Content-Type: text/html; charset="iso-8859-1" AW: AW: [NSIS] Re: authorizing query messages
Roy,
 
No, I don't have any problems. By the way, I would like to see how SIP, NSIS signaling protocol , Diameter SIP application and Diameter QoS application whill be integrated to provide end-to-end QoS also.
 
Regards,
 
An
 
 
 
-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]
Sent: Thursday, October 13, 2005 3:37 PM
To: Tschofenig, Hannes; Nguyen, An
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: RE: AW: [NSIS] Re: authorizing query messages

An and Hannes:
 
Kindly see my earlier email related to this.
 
In addition, I like to add couple of points related to Hannes comments as follows:
  1. It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those.
  2. Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those.
  3. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS.
  4. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait.
  5. By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.)
The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above.
If An has any problems, let me know.
 
Best regards,
Radhika
From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42 AM
To: Nguyen, An; David R Oran
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: AW: AW: [NSIS] Re: authorizing query messages

hi an,

let me tell you my view on this issue.

carrying only the qspec parameter is not sufficient for the
authorization decision. you need todo more as you see in the document
(and more stuff will certainly follow -- based on the reviewers feedback
we recently received). you might not want to dump almost all
diameter-qos parameters into the diameter-sip document. instead, it
might be better to see how they interwork just like the diameter-sip
application needs to interwork with other diameter applications as well.
this is a bit more complex compared to radius where you can just dump
the desired parameter into a message since the concept of an application
is not defined. for the diameter-qos application we investigated the
interworking with other applications, such as nasreq and credit control.
this might be another application to take a look at.

in the past we had a few discussions how to map the qos
specific parameters in the sdp to the qspec. within the sdp payloads
only bandwidth parameters are carried. the 3gpp additionally uses
further parameters in addition to the bandwidth parameters but they are
determined based on codec information and bearer information.
as such, it was difficult to show a good mapping by investigating only
the ietf work.

ciao
hannes

------_=_NextPart_001_01C5D034.F216E270-- --===============1146051664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1146051664==-- From nsis-bounces@ietf.org Thu Oct 13 18:17:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBO1-0004pb-0C; Thu, 13 Oct 2005 18:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBNy-0004pW-Ky for nsis@megatron.ietf.org; Thu, 13 Oct 2005 18:17:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21553 for ; Thu, 13 Oct 2005 18:17:10 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBYZ-000340-Fj for nsis@ietf.org; Thu, 13 Oct 2005 18:28:12 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Thu, 13 Oct 2005 18:16:58 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101318165811260 ; Thu, 13 Oct 2005 18:16:58 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Thu, 13 Oct 2005 18:16:58 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 18:20:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Thu, 13 Oct 2005 18:17:22 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8667264DF@bh-exchange02.saic-abingdon.com> Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXQNXXlw1v8F5GURISyMfgyCLT1BAADmw6+ From: "Roy, Radhika \(AEAD\)" To: "Nguyen, An" , "Tschofenig, Hannes" X-OriginalArrivalTime: 13 Oct 2005 22:20:40.0203 (UTC) FILETIME=[57F625B0:01C5D044] X-Spam-Score: 0.6 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0259741405==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0259741405== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D044.4A766E9A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D044.4A766E9A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, An: =20 OK, let us start working on this item - how NSIS signaling protocol, = Diameter SIP application and Diameter QoS application work in an = integrated way. =20 By the way, do you have any clue about the Diameter QoS application as I = indicate in my earlier email? =20 Best regards, Radhika ________________________________ From: Nguyen, An [mailto:an.p.nguyen@dhs.gov] Sent: Thu 10/13/2005 4:30 PM To: Roy, Radhika (AEAD); Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org; Nguyen, An Subject: RE: AW: [NSIS] Re: authorizing query messages Roy, =20 No, I don't have any problems. By the way, I would like to see how SIP, = NSIS signaling protocol , Diameter SIP application and Diameter QoS = application whill be integrated to provide end-to-end QoS also. =20 Regards, =20 An =20 =20 =20 -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: Thursday, October 13, 2005 3:37 PM To: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages =09 =09 An and Hannes: =20 Kindly see my earlier email related to this. =20 In addition, I like to add couple of points related to Hannes comments = as follows: 1.=09 It is desirable to have all the QoS parameters of QSPEC to be = authorized. If something is missing in Diameter QoS application or vice = versa, we need to augment those. 2.=09 Diameter QoS application does not need to use QSPEC per se. It needs = to carry the abstract of QSPEC QoS parameters within the Diameter QoS = application protocol. If any QoS parameters or exact semantics are = missing in Dia QoS, Dia QoS needs to be extended for only those. 3.=09 Once items 1 and 2 are taken care of, authorization/authentication = will be taken care of by basic Diameter protocol (depending on which = application [e.g., SIP, FTP, etc.] will invoke QoS. 4.=09 With respect to mapping of SIP/SDP QoS parameters mapping into Dia = QoS, we do not need to worry about this. All we need to see whether all = the QoS parameters expressed in SDP have the place holder in Dia QoS = (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth = is there. If it is so, we are on the safe side because Dia QoS/QSPEC can = support this. In the future, we hope that SDP QoS parameters can be = extended to delay, jitter, packet loss, etc. based on the QoS needs of = each codec type. Until that happens, let us wait. 5.=09 By the way, I would like to later how SIP, NSIS signaling protocol, = and Diameter SIP application and Diameter QoS application are integrated = on end-to-end basis. (Note: We have done our home work for probable = implementation after studying the modeling and simulations results = [sorry - not to be publicly released] and test-bed [NSIS protocol NOT = yet] in controlled environments, but I am waiting how the standard works = progress. Later on, we hope to implement for the worldwide network that = will include MANET as the access network.) The point that I like to make is this: QSPEC = Authorization/Authentication is NOT a big deal. It is straight forward = as describe above. =09 If An has any problems, let me know. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages =09 =09 hi an, =09 let me tell you my view on this issue. =09 carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers = feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as = well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an = application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit = control. this might be another application to take a look at. =09 in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. =09 ciao hannes =09 =09 ------_=_NextPart_001_01C5D044.4A766E9A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= AW: AW: [NSIS] Re: authorizing query messages=0A= =0A= =0A= =0A=
=0A=
Hi, = An:
=0A=
 
=0A=
OK, let us start working on = this item - how =0A= NSIS signaling protocol, Diameter SIP application and Diameter QoS = application =0A= work in an integrated way.
=0A=
 
=0A=
By the way, do you have any = clue about the =0A= Diameter QoS application as I indicate in my earlier email?
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: Nguyen, An =0A= [mailto:an.p.nguyen@dhs.gov]
Sent: Thu 10/13/2005 4:30 =0A= PM
To: Roy, Radhika (AEAD); Tschofenig, Hannes
Cc: = McDonald, =0A= Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Nguyen, =0A= An
Subject: RE: AW: [NSIS] Re: authorizing query =0A= messages

=0A=
=0A=
Roy,
=0A=
 
=0A=
No, I =0A= don't have any problems. By the way, I would like to see how SIP, NSIS = signaling =0A= protocol , Diameter SIP application and Diameter QoS application = whill be =0A= integrated to provide end-to-end QoS also.
=0A=
 
=0A=
Regards,
=0A=
 
=0A=
An
=0A=
 
=0A=
 
=0A=
 
=0A=
=0A=
-----Original Message-----
From: Roy, Radhika = (AEAD) =0A= [mailto:RoyR@saic-abingdon.com]
Sent: Thursday, October 13, = 2005 =0A= 3:37 PM
To: Tschofenig, Hannes; Nguyen, An
Cc: = McDonald, =0A= Andrew; Georgios Karagiannis; Jukka MJ Manner; =0A= nsis@ietf.org
Subject: RE: AW: [NSIS] Re: authorizing query =0A= messages

=0A=
An and = Hannes:
=0A=
 
=0A=
Kindly see my earlier email = related to =0A= this.
=0A=
 
=0A=
In addition, I like to add = couple of =0A= points related to Hannes comments as follows:
=0A=
=0A=
    =0A=
  1. =0A=
    It is desirable to have all the QoS = parameters =0A= of QSPEC to be authorized. If something is missing in Diameter QoS =0A= application or vice versa, we need to augment those.
    =0A=
  2. =0A=
    Diameter QoS application does not = need to use =0A= QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters = within =0A= the Diameter QoS application protocol. If any QoS parameters or = exact =0A= semantics are missing in Dia QoS, Dia QoS needs to be extended for = only =0A= those.
    =0A=
  3. =0A=
    Once items 1 and 2 are taken care = of, =0A= authorization/authentication will be taken care of by basic Diameter =0A= protocol (depending on which application [e.g., SIP, FTP, etc.] will = invoke =0A= QoS.
    =0A=
  4. =0A=
    With respect to mapping of SIP/SDP = QoS =0A= parameters mapping into Dia QoS, we do not need to worry about this. = All we =0A= need to see whether all the QoS parameters expressed in SDP have the = place =0A= holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes = mentioned, =0A= only bandwidth is there. If it is so, we are on the safe side = because Dia =0A= QoS/QSPEC can support this. In the future, we hope that SDP QoS = parameters =0A= can be extended to delay, jitter, packet loss, etc. based on the QoS = needs =0A= of each codec type. Until that happens, let us wait.
    =0A=
  5. =0A=
    By the way, I would like to later = how SIP, NSIS =0A= signaling protocol, and Diameter SIP application and Diameter QoS =0A= application are integrated on end-to-end basis. (Note: We have = done our =0A= home work for probable implementation after studying the modeling = and =0A= simulations results [sorry - not to be publicly released] and = test-bed [NSIS =0A= protocol NOT yet] in controlled environments, but I am waiting how = the =0A= standard works progress. Later on, we hope to implement for the = worldwide =0A= network that will include MANET as the access =0A= network.)
=0A=
The point that I like to = make is this: =0A= QSPEC Authorization/Authentication is NOT a big deal. It is straight = forward =0A= as describe above.
=0A=
If An has any problems, let = me =0A= know.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on =0A= behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42 =0A= AM
To: Nguyen, An; David R Oran
Cc: McDonald, = Andrew; =0A= Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org
Subject: AW: =0A= AW: [NSIS] Re: authorizing query messages

=0A=
=0A=

hi an,

let me tell you my view on this =0A= issue.

carrying only the qspec parameter is not sufficient for =0A= the
authorization decision. you need todo more as you see in the =0A= document
(and more stuff will certainly follow -- based on the = reviewers =0A= feedback
we recently received). you might not want to dump almost =0A= all
diameter-qos parameters into the diameter-sip document. = instead, =0A= it
might be better to see how they interwork just like the =0A= diameter-sip
application needs to interwork with other diameter =0A= applications as well.
this is a bit more complex compared to radius = where =0A= you can just dump
the desired parameter into a message since the = concept of =0A= an application
is not defined. for the diameter-qos application we =0A= investigated the
interworking with other applications, such as = nasreq and =0A= credit control.
this might be another application to take a look =0A= at.

in the past we had a few discussions how to map the = qos
specific =0A= parameters in the sdp to the qspec. within the sdp payloads
only = bandwidth =0A= parameters are carried. the 3gpp additionally uses
further = parameters in =0A= addition to the bandwidth parameters but they are
determined based = on codec =0A= information and bearer information.
as such, it was difficult to = show a =0A= good mapping by investigating only
the ietf =0A= = work.

ciao
hannes

=0A= ------_=_NextPart_001_01C5D044.4A766E9A-- --===============0259741405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0259741405==-- From nsis-bounces@ietf.org Fri Oct 14 03:04:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJc1-0005sY-GS; Fri, 14 Oct 2005 03:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJbz-0005sT-NZ for nsis@megatron.ietf.org; Fri, 14 Oct 2005 03:04:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21793 for ; Fri, 14 Oct 2005 03:04:10 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJme-0001jc-A5 for nsis@ietf.org; Fri, 14 Oct 2005 03:15:17 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E71661007979; Fri, 14 Oct 2005 10:01:06 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:04:08 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:04:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW issue 29: Port Range Parameter Field Date: Fri, 14 Oct 2005 10:04:07 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D0128912F@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] NATFW issue 29: Port Range Parameter Field Thread-Index: AcXP/ELcc0Mb7gfxRgWH35g+dsgPhgAkSw7w To: , X-OriginalArrivalTime: 14 Oct 2005 07:04:08.0670 (UTC) FILETIME=[78DDDFE0:01C5D08D] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org >This issue has been already discussed in July 2005. > >My suggestion is to close this issue. From the tracker: > >Dave Oran said in an email on 15 July 2005: >"The alternative is to not worry about this at all and assume=20 >everybody will have implemented RFC3605 by now." > >My recommendation: Do not include Port Range Parameter Field=20 >and use RFC 3605. > >Anybody objections to close issue 29? I agree with the recommendation. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 14 03:04:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJcK-0005ym-4D; Fri, 14 Oct 2005 03:04:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJcI-0005x0-Uf for nsis@megatron.ietf.org; Fri, 14 Oct 2005 03:04:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21805 for ; Fri, 14 Oct 2005 03:04:29 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJmx-0001jv-LI for nsis@ietf.org; Fri, 14 Oct 2005 03:15:37 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E71OKX008237; Fri, 14 Oct 2005 10:01:26 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:04:31 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:04:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW issue 28: Keep Port Parity field/semantics Date: Fri, 14 Oct 2005 10:04:30 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289130@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] NATFW issue 28: Keep Port Parity field/semantics Thread-Index: AcXP/E3SXtjodPiKSRm+9CXaEzzFeAAkTEww To: , X-OriginalArrivalTime: 14 Oct 2005 07:04:32.0165 (UTC) FILETIME=[86DEED50:01C5D08D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org >>From the NATFW issue tracker: >"Nodes may request NATs to keep the parity of the transport=20 >layer ports" > >My suggestion: >>From issue 29: >Dave Oran said in an email on 15 July 2005: >"The alternative is to not worry about this at all and assume=20 >everybody will have implemented RFC3605 by now." > >My recommendation: Same here as in issue 29, do not include=20 >Port Parity Field and use RFC 3605. > >Anybody objections to close issue 28? I agree with the resolution. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 14 03:08:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJgV-0007Mh-LQ; Fri, 14 Oct 2005 03:08:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJgT-0007L4-G6 for nsis@megatron.ietf.org; Fri, 14 Oct 2005 03:08:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22022 for ; Fri, 14 Oct 2005 03:08:48 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJr8-0001sT-4w for nsis@ietf.org; Fri, 14 Oct 2005 03:19:55 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E78o7X025472; Fri, 14 Oct 2005 10:08:50 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:08:49 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:08:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Date: Fri, 14 Oct 2005 10:08:47 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289133@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Thread-Index: AcXP2H0luwla9hfgQoyJWx1cSYKi/AAtXpmg To: , X-OriginalArrivalTime: 14 Oct 2005 07:08:49.0061 (UTC) FILETIME=[1FFE2550:01C5D08E] X-Spam-Score: 0.4 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Martin, >Draft -07 of the NATFW NSLP describes a query and diagnosis=20 >capability in Section 3.3.6. These capabilities have been in=20 >the draft for while but no real usage scenarios have been=20 >described so far (see issue 30 in the tracker=20 >). > >The general feeling of the WG about these query and diagnosis=20 >capabilities were quite mixed (as expressed during the last=20 >interim in Munich). Since then I have not received any further=20 >comments about this issue. > >Personally, I do not see any good use cases for such a=20 >capability in the NATFW NSLP and I'm in favour of removing it=20 >completely. > >I'm soliciting the WG to give feedback on this issue, whether=20 >it is considered a useful feature or not. If you consider it a=20 >useful feature, you should give some use cases. I am leaning towards dropping this feature. I think that this is extra functionality without defined use - this will make the implementatino & usage more difficult. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 14 03:09:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJh8-0007SS-D4; Fri, 14 Oct 2005 03:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJh7-0007SE-N8 for nsis@megatron.ietf.org; Fri, 14 Oct 2005 03:09:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22045 for ; Fri, 14 Oct 2005 03:09:28 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJrm-0001tb-Eh for nsis@ietf.org; Fri, 14 Oct 2005 03:20:35 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E76MaY013322; Fri, 14 Oct 2005 10:06:25 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:09:30 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:09:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW issue 39: REA-PROXY race condition between RESPONSE and requested CREATE Date: Fri, 14 Oct 2005 10:09:29 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289134@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] NATFW issue 39: REA-PROXY race condition between RESPONSE and requested CREATE Thread-Index: AcXP2aWaQ4kj/QVZSLGUgUKxgbWqzAAtJBFw To: , X-OriginalArrivalTime: 14 Oct 2005 07:09:31.0028 (UTC) FILETIME=[3901CD40:01C5D08E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org I agree. John=20 >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Martin Stiemerling >Sent: 13 October, 2005 12:34 >To: nsis >Subject: [NSIS] NATFW issue 39: REA-PROXY race condition=20 >between RESPONSE and requested CREATE > >Hi, > >I suggest to close issue 39 (REA-PROXY race condition between=20 >RESPONSE and requested CREATE,=20 >). > >Proposed text is: >There is a possible race condition between the RESPONSE=20 >message to the REA- PROXY and the CREATE message generated by=20 >the edge-NAT. The CREATE message can arrive earlier than the=20 >RESPONSE message. An NI+ MUST accept CREATE messages generated=20 >by the edge-NAT even if the RESPONSE message to the REA-PROXY=20 >request was not received. > >Note: The NI+ is able to recognize an edge-NAT generated=20 >CREATE through the presence of the NATFW_NONCE object. The=20 >NATFW_NONCE object echoes a value chosen by the NI+. > >The proposed text has been already included in draft -07 of=20 >the NATFW NSLP. > > Martin > >_______________________________________________ >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 nsis-bounces@ietf.org Fri Oct 14 03:11:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJjP-0008ML-Ll; Fri, 14 Oct 2005 03:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJjO-0008JV-DY; Fri, 14 Oct 2005 03:11:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22126; Fri, 14 Oct 2005 03:11:49 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJu4-0001x7-3d; Fri, 14 Oct 2005 03:22:56 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E78h5a016395; Fri, 14 Oct 2005 10:08:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:11:50 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:11:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] TLS in the GIST draft Date: Fri, 14 Oct 2005 10:11:17 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289136@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] TLS in the GIST draft Thread-Index: AcXP9tsEj0AHJRnGQYWv3TVJCAPgUgAl2bsg To: , X-OriginalArrivalTime: 14 Oct 2005 07:11:18.0830 (UTC) FILETIME=[794314E0:01C5D08E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Pasi, Do you think that the Diameter text would be useful for GIST, or do you have other suggestions on what is currently common practice for TLS features? For your second point, I agree with your analysis, but do you have a suggestion on the best way to handle the TLS negotiation? John >The current GIST draft has very little text about how TLS is=20 >actually used with GIST. I think there are a couple of issues=20 >that need to be handled somehow. > >First, other protocols that have mandated the use of TLS have=20 >often specified exactly what subset of TLS features must be supported. >For instance, RFC 3588 Section 13.2 says > > A Diameter node that initiates a connection to another Diameter > node acts as a TLS client according to [TLS], and a Diameter node > that accepts a connection acts as a TLS server. Diameter nodes > implementing TLS for security MUST mutually authenticate as part of > TLS session establishment. In order to ensure mutual > authentication, the Diameter node acting as TLS server must request > a certificate from the Diameter node acting as TLS client, and the > Diameter node acting as TLS client MUST be prepared to supply a > certificate on request. > > Diameter nodes MUST be able to negotiate the following TLS cipher > suites: > > TLS_RSA_WITH_RC4_128_MD5 > TLS_RSA_WITH_RC4_128_SHA > TLS_RSA_WITH_3DES_EDE_CBC_SHA > > Diameter nodes SHOULD be able to negotiate the following TLS cipher > suite: > > TLS_RSA_WITH_AES_128_CBC_SHA > > Diameter nodes MAY negotiate other TLS cipher suites. > >Something like this might be useful for the GIST draft as=20 >well, since just saying "use TLS" is not sufficient to=20 >guarantee any kind of interoperability. > > >Second, the Stack-Proposal negotiation seems to assume that a=20 >single bit of information, that TLS is used, is sufficient to get TLS working. > >This is not necessarily the case. Some TLS authentication=20 >mechanisms assume the client (initiating the TLS connection)=20 >knows beforehand either what credentials it wants to use=20 >itself, and/or what is the expected identity of the server. > >For instance, in Kerberos ciphersuites for TLS [RFC2712], the=20 >client has to obtain a ticket from the KDC/TGS, and put it in=20 >the TLS ClientKeyExchange message. But to obtain the ticket,=20 >the client has to know the server's PrincipalName -- where=20 >exactly does it get this information? > >(One option would be to send it in Stack-Configuration-Data. >Another would be to specify a way to derive it from other=20 >information that's already present in the messages, like=20 >Network-Layer-Information. >Perhaps there are other options too.) > >To take another example, when using SRP to authenticate TLS=20 >[draft-ietf-tls-srp-10], the client sends its SRP user name in=20 >the ClientHello message. If the client has multiple secrets=20 >(SRP password), it has to decide beforehand which of them to use. >Presumably, the identity of the TLS server is a major factor=20 >in this decision. > >In fact, public-key certificates seem to be pretty much the=20 >only TLS case where no prior knowledge is required by the=20 >client (mainly because the server sends its certificate first). > >Best regards, >Pasi > >_______________________________________________ >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 nsis-bounces@ietf.org Fri Oct 14 03:13:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJlO-0000d2-73; Fri, 14 Oct 2005 03:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJlM-0000cr-Pz for nsis@megatron.ietf.org; Fri, 14 Oct 2005 03:13:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22264 for ; Fri, 14 Oct 2005 03:13:51 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJw1-00021M-HP for nsis@ietf.org; Fri, 14 Oct 2005 03:24:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E7Doj0030641; Fri, 14 Oct 2005 10:13:52 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:13:52 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:13:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Fri, 14 Oct 2005 10:13:50 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289138@esebe100.NOE.Nokia.com> Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXPUEYRuoaHRPSFQxuVlbNT2KrbbABPkD2w To: X-OriginalArrivalTime: 14 Oct 2005 07:13:51.0940 (UTC) FILETIME=[D485D040:01C5D08E] X-Spam-Score: 0.4 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org An, >Just a question: Do we need to enhance >http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-09. txt >to include QSPEC if you we decide to use DIAMETER to perform=20 >the authorization for users' resources? Authorizing QoS reservations is something that is a work-in-progress. There have been some discussions of this topic in both the AAA and RADext working group. =20 At a highlevel, it would be good to have some common format for coding QoS reservations which can be reused for AAA-systems for Authorization & Accounting purposes, but this is very much a work-in-progress. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 14 06:48:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQN7R-000865-8O; Fri, 14 Oct 2005 06:48:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQN7Q-00084p-3g; Fri, 14 Oct 2005 06:48:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01698; Fri, 14 Oct 2005 06:48:51 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQNI6-0007cU-MR; Fri, 14 Oct 2005 07:00:00 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9EAmnb9008674; Fri, 14 Oct 2005 13:48:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 13:48:50 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 13:48:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2005 13:48:48 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D012891F0@esebe100.NOE.Nokia.com> Thread-Topic: Second call: IETF 56 - NSIS agenda Thread-Index: AcXORMJCWt8t+WAkTy2ZdK30FUiYgwCaAnvQ To: , X-OriginalArrivalTime: 14 Oct 2005 10:48:50.0601 (UTC) FILETIME=[DCB94990:01C5D0AC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Second call: IETF 56 - NSIS agenda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org At this rate, we will have a very quick meeting, as noone has replied. John=20 >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 >Sent: 11 October, 2005 12:19 >To: nsis@ietf.org >Subject: [NSIS] IETF 56 - NSIS agenda > >Hi all, > >This is an open call for meeting items for the IETF meeting in=20 >Vancouver. I have a strong preference for giving time to=20 >existing wg items, to make sure we make forward progress on=20 >them. For non-working group drafts, please send me a request=20 >with some explaination on why meeting time is useful for=20 >discussion the draft. > >Send to me: >Draft name >Presenter name >time needed. > >thanks, >JOhn > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 14 07:02:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNKf-0003xG-TW; Fri, 14 Oct 2005 07:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNKe-0003xA-I9 for nsis@megatron.ietf.org; Fri, 14 Oct 2005 07:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02189 for ; Fri, 14 Oct 2005 07:02:31 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQNVL-0007v1-6m for nsis@ietf.org; Fri, 14 Oct 2005 07:13:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9EB2VYj030554 for ; Fri, 14 Oct 2005 14:02:33 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 14:02:33 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 14:02:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] TLS in the GIST draft Date: Fri, 14 Oct 2005 14:02:35 +0300 Message-ID: Thread-Topic: [NSIS] TLS in the GIST draft Thread-Index: AcXP9tsEj0AHJRnGQYWv3TVJCAPgUgAl2bsgAAdbufA= To: X-OriginalArrivalTime: 14 Oct 2005 11:02:33.0413 (UTC) FILETIME=[C7286F50:01C5D0AE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org John Loughney wrote: > Pasi, >=20 > Do you think that the Diameter text would be useful for GIST, or > do you have other suggestions on what is currently common practice=20 > for TLS features? This really depends on what is the goal of specifying the use of=20 TLS in the GIST draft.. Something like the Diameter text is fine if the main goal is to provide one plausible way to secure the GIST messaging (and pass the security area review :-) But between the lines you can certainly read that "we wrote this just because we had to, not because we think that this is the way NSIS+TLS will actually be used in real deployments"... But then again, writing correct text to cover all possible real-world deployment scenarios is certainly quite impossible. And for NSIS, probably we don't quite yet know how it will be actually used and deployed.. > For your second point, I agree with your analysis, but do you=20 > have a suggestion on the best way to handle the TLS negotiation? The current text seems to cover the "TLS authenticated with certificates" case reasonably well, so one option would be just to say so, and explicitly say that Kerberos etc. are beyond the=20 scope of this document. (If nobody plans to use Kerberos and=20 RFC2712 with NSIS, spending a lot of effort to figure out how=20 exactly it would work is probably not that great idea.) Best regards, Pasi _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Oct 16 12:50:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBis-0001ra-Fh; Sun, 16 Oct 2005 12:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBiq-0001pm-AW for nsis@megatron.ietf.org; Sun, 16 Oct 2005 12:50:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10257 for ; Sun, 16 Oct 2005 12:50:48 -0400 (EDT) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERBu0-0007gJ-Fx for nsis@ietf.org; Sun, 16 Oct 2005 13:02:28 -0400 Received: from [84.132.133.107] (p5484856B.dip0.t-ipconnect.de [::ffff:84.132.133.107]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Sun, 16 Oct 2005 18:50:54 +0200 id 000100FC.435284EE.00005A4B Message-ID: <435284EC.4070304@cs.uni-goettingen.de> Date: Sun, 16 Oct 2005 18:50:52 +0200 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Jon Crowcroft Subject: [NSIS] new draft "GIST over SCTP" and some comments to GIST X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, We have submitted a new Internet draft on running GIST over SCTP, with the following abstract: Abstract: The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP). The use of SCTP can take the advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, and the support of multi-homing to provide network level fault tolerance. Additionally, the support for some extensions of SCTP is also discussed, namely its Partial Reliability Extension and the usage of TLS over SCTP. Before it appears in IETF I-D repository, you can find it in the following URL: http://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sctp/draft-fu-nsis-ntlp-sctp-00.txt We would appreciate it if you would review and comment on the draft. We have also performed a prototype implementation for the basic SCTP support in GIST which we plan to include in the next release. In addition, we would like to point to some observations/questions about GIST thru this work: - Multi-homing: our analysis show that any multi-homing scenario (e.g., host multihoming or AS level multihoming) may involve non-marginal consideration in GIST level state management and likely additional objects or readapted Stack-Proposal/Stack-Config-Data may be necessary. See some preliminary discussions in Section 3.4. - API: should Transfer Attribute be constrained to only two values (Reliability, Unreliability)? What if the NSLP requires partial reliability? See more discussions in Section 3.4.1 in this I-D. - In general, what if the two GIST peers do support a same type of transport mechanism, but not the same protocol version (e.g., TLS1.0 v.s. 1.1, TCP with Reno v.s. with NewReno, as well as above-mentioned standard SCTP v.s. PR-SCTP, and so on). Thanks, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Oct 16 13:09:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERC1G-0006qj-2b; Sun, 16 Oct 2005 13:09:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERC1B-0006qd-Dc for nsis@megatron.ietf.org; Sun, 16 Oct 2005 13:09:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10999 for ; Sun, 16 Oct 2005 13:09:47 -0400 (EDT) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERCCK-000868-QH for nsis@ietf.org; Sun, 16 Oct 2005 13:21:26 -0400 Received: from [84.132.133.107] (p5484856B.dip0.t-ipconnect.de [::ffff:84.132.133.107]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Sun, 16 Oct 2005 19:09:50 +0200 id 000100FC.4352895E.000069D9 Message-ID: <4352895B.3030208@cs.uni-goettingen.de> Date: Sun, 16 Oct 2005 19:09:47 +0200 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "Kappler, Cornelia" Subject: [NSIS] Update draft "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, We have submitted an updated version of the Internet draft "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS". It is available in http://user.informatik.uni-goettingen.de/~fu/nsis/cls_qosm/draft-kappler-nsis-qosmodel-controlledload-03.txt This draft describes a QoS model to signal the IntServ Controlled Service with QoS NSLP, including its QSPEC and processing rules, and provides information about interoperation with the RSVP/IntServ signaling model. The main change to version 02 is that we now included a complete set of "RSVP-style reservation" QSPECs (Appendix A) and updated text on mapping/interoperation between RSVP/CLS and QOS-NSLP/CLS (Section 6). In addition to the issues listed in Section 9, we would like to point to B.1 for your comments, further discussions. Your suggestions, comments, reviews are very appreciated. Thanks, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Oct 16 13:39:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCTf-0006qp-8t; Sun, 16 Oct 2005 13:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCTd-0006qk-Ju for nsis@megatron.ietf.org; Sun, 16 Oct 2005 13:39:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12121 for ; Sun, 16 Oct 2005 13:39:11 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERCel-0000HU-2J for nsis@ietf.org; Sun, 16 Oct 2005 13:50:50 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9GHcSWA019747; Sun, 16 Oct 2005 18:38:28 +0100 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 49WV78TK; Sun, 16 Oct 2005 18:42:47 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST Date: Sun, 16 Oct 2005 18:38:12 +0100 Message-ID: <00fe01c5d278$61f93e40$0302a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXSeQX4Oz00GIlgRiO/UGwB5NSlPQ== From: "Hancock, Robert" To: "Xiaoming Fu" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: Jon Crowcroft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1203510988==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1203510988== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D279.05328580" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D279.05328580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, a very interesting draft. i'm glad to see that SCTP can be added to GIST with such a small draft ;-) some comments (trivial) in 3.1: IIRC the order of layered proposals is top->bottom, i.e. the other way round. (there is discussion of that at http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68.) (non-trivial) 3.3: i didn't really understand this section. multi-homing=20 (or any multi-interface) issues have their impact in D mode only (in fact, query mode messages and NLI payloads), which are unchanged; the linkage to MAs is done by cookie matching, which is also unchanged. so I don't see why the fact that the MA can use a multi-homing transport protocol should make any difference. 3.4.1: one of the fundamental goals of the API is precisely that it should *not* change to allow the use of SCTP. (this was extensively discussed at the 2004 interim and was stated as a goal in the spec.) so it's unclear what API changes should be needed. But in fact, I can't tell what changes 3.4.1 actually proposes - it describes how to map SCTP features on to the=20 API (which is reasonable), but the API itself seems unchanged. cheers, robert h. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Xiaoming Fu > Sent: 16 October 2005 17:51 > To: nsis@ietf.org > Cc: Jon Crowcroft > Subject: [NSIS] new draft "GIST over SCTP" and some comments to GIST >=20 >=20 > Hi all, >=20 > We have submitted a new Internet draft on running GIST over=20 > SCTP, with=20 > the following abstract: >=20 > Abstract: > The General Internet Signaling Transport (GIST) protocol=20 > currently=20 > uses TCP or TLS over TCP for connection mode operation. This=20 > document=20 > describes the usage of GIST over the Stream Control Transmission=20 > Protocol (SCTP). The use of SCTP can take the advantage of features=20 > provided by SCTP, namely streaming-based transport, support=20 > of multiple=20 > streams to avoid head of line blocking, and the support of=20 > multi-homing=20 > to provide network level fault tolerance. Additionally, the=20 > support for=20 > some extensions of SCTP is also discussed, namely its Partial=20 > Reliability Extension and the usage of TLS over SCTP. >=20 > Before it appears in IETF I-D repository, you can find it in the=20 > following URL:=20 > http://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sc tp/draft-fu-nsis-ntlp-sctp-00.txt We would appreciate it if you would review and comment on the draft. We have also performed a prototype implementation for the basic SCTP=20 support in GIST which we plan to include in the next release. In=20 addition, we would like to point to some observations/questions about=20 GIST thru this work: - Multi-homing: our analysis show that any multi-homing scenario (e.g.,=20 host multihoming or AS level multihoming) may involve non-marginal=20 consideration in GIST level state management and likely additional=20 objects or readapted Stack-Proposal/Stack-Config-Data may be necessary.=20 See some preliminary discussions in Section 3.4. - API: should Transfer Attribute be constrained to only two values=20 (Reliability, Unreliability)? What if the NSLP requires partial=20 reliability? See more discussions in Section 3.4.1 in this I-D. - In general, what if the two GIST peers do support a same type of=20 transport mechanism, but not the same protocol version (e.g., TLS1.0=20 v.s. 1.1, TCP with Reno v.s. with NewReno, as well as above-mentioned=20 standard SCTP v.s. PR-SCTP, and so on). Thanks, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C5D279.05328580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] new draft "GIST over SCTP" and some comments = to GIST

hi,

a very interesting draft. i'm glad to see that SCTP = can be
added to GIST with such a small draft ;-)

some comments

(trivial)
in 3.1: IIRC the order of layered proposals is = top->bottom,
i.e. the other way round. (there is discussion of = that at
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68.)

(non-trivial)
3.3: i didn't really understand this section. = multi-homing
(or any multi-interface) issues have their impact in = D mode
only (in fact, query mode messages and NLI payloads), = which
are unchanged; the linkage to MAs is done by cookie = matching,
which is also unchanged. so I don't see why the fact = that the
MA can use a multi-homing transport protocol should = make any
difference.

3.4.1: one of the fundamental goals of the API is = precisely
that it should *not* change to allow the use of SCTP. = (this
was extensively discussed at the 2004 interim and was = stated
as a goal in the spec.) so it's unclear what API = changes should
be needed. But in fact, I can't tell what changes = 3.4.1 actually
proposes - it describes how to map SCTP features on = to the
API (which is reasonable), but the API itself seems = unchanged.

cheers,

robert h.

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of Xiaoming Fu
> Sent: 16 October 2005 17:51
> To: nsis@ietf.org
> Cc: Jon Crowcroft
> Subject: [NSIS] new draft "GIST over = SCTP" and some comments to GIST
>
>
> Hi all,
>
> We have submitted a new Internet draft on = running GIST over
> SCTP, with
> the following abstract:
>
> Abstract:
>     The General Internet = Signaling Transport (GIST) protocol
> currently
> uses TCP or TLS over TCP for connection mode = operation.  This
> document
> describes the usage of GIST over the Stream = Control Transmission
> Protocol (SCTP). The use of SCTP can take the = advantage of features
> provided by SCTP, namely streaming-based = transport, support
> of multiple
> streams to avoid head of line blocking, and the = support of
> multi-homing
> to provide network level fault tolerance. = Additionally, the
> support for
> some extensions of SCTP is also discussed, = namely its Partial
> Reliability Extension and the usage of TLS over = SCTP.
>
> Before it appears in IETF I-D repository, you = can find it in the
> following URL:
> h= ttp://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sc
tp/draft-fu-nsis-ntlp-sctp-00.txt

We would appreciate it if you would review and comment = on the draft.

We have also performed a prototype implementation for = the basic SCTP
support in GIST which we plan to include in the next = release. In
addition, we would like to point to some = observations/questions about
GIST thru this work:
- Multi-homing: our analysis show that any = multi-homing scenario (e.g.,
host multihoming or AS level multihoming) may involve = non-marginal
consideration in GIST level state management and = likely additional
objects or readapted Stack-Proposal/Stack-Config-Data = may be necessary.
See some preliminary discussions in Section = 3.4.
- API: should Transfer Attribute be constrained to = only two values
(Reliability, Unreliability)? What if the NSLP = requires partial
reliability? See more discussions in Section 3.4.1 in = this I-D.
- In general, what if the two GIST peers do support a = same type of
transport mechanism, but not the same protocol = version (e.g., TLS1.0
v.s. 1.1, TCP with Reno v.s. with NewReno, as well as = above-mentioned
standard SCTP v.s. PR-SCTP, and so on).

Thanks,
Xiaoming

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

------_=_NextPart_001_01C5D279.05328580-- --===============1203510988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1203510988==-- From nsis-bounces@ietf.org Sun Oct 16 15:28:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EREBO-0003hU-1y; Sun, 16 Oct 2005 15:28:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EREBM-0003hK-Hv for nsis@megatron.ietf.org; Sun, 16 Oct 2005 15:28:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17361 for ; Sun, 16 Oct 2005 15:28:25 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EREMW-0002vN-Og for nsis@ietf.org; Sun, 16 Oct 2005 15:40:06 -0400 Received: from win2003.dickmann2003.home (p548A7183.dip.t-dialin.net [84.138.113.131]) by www.difra-computer.de (Postfix) with ESMTP id 683523E402B for ; Sun, 16 Oct 2005 21:35:02 +0200 (CEST) Received: from dickmann.homeunix.org ([192.168.0.5]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Oct 2005 21:21:06 +0200 MIME-Version: 1.0 Date: Sun, 16 Oct 2005 21:25:02 +0200 From: Christian Dickmann To: "\"Hancock"@www.difra-computer.de, "Robert\"" Subject: Re: [NSIS] new draft "GIST over SCTP" and some comments to GIST In-Reply-To: 00fe01c5d278$61f93e40$0302a8c0@comm.ad.roke.co.uk Message-ID: <26c4c1d03f08b7d11241d29f3b3aa8a3@192.168.0.7> X-Sender: mail@christian-dickmann.de User-Agent: RoundCube Webmail/0.1a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2005 19:21:06.0150 (UTC) FILETIME=[C15D6060:01C5D286] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, > in 3.1: IIRC the order of layered proposals is top->bottom, > i.e. the other way round. (there is discussion of that at > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68.) I will check that again, but IIRC we implemented it in this way and had not problem in the interop ;) > 3.4.1: one of the fundamental goals of the API is precisely > that it should *not* change to allow the use of SCTP. (this > was extensively discussed at the 2004 interim and was stated > as a goal in the spec.) so it's unclear what API changes should > be needed. But in fact, I can't tell what changes 3.4.1 actually > proposes - it describes how to map SCTP features on to the > API (which is reasonable), but the API itself seems unchanged. You are right. The changes are just how parameters are interpreted. So maybe we should rename this section in the next version. Do I understand you correctly, that this kind of "change" is acceptable? Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 04:28:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQMV-0001vL-QL; Mon, 17 Oct 2005 04:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQMU-0001vG-G8 for nsis@megatron.ietf.org; Mon, 17 Oct 2005 04:28:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24684 for ; Mon, 17 Oct 2005 04:28:43 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/zLI1gHgnF0aAfQMOkFF+lUHbXUSgKcUo=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQXl-0005Bd-SR for nsis@ietf.org; Mon, 17 Oct 2005 04:40:31 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ERQM6-0000hz-Dy; Mon, 17 Oct 2005 10:28:28 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 203C7B24C; Mon, 17 Oct 2005 10:28:26 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ERQM5-0003CT-Rk; Mon, 17 Oct 2005 10:28:25 +0200 Message-ID: <435360A9.50602@tm.uka.de> Date: Mon, 17 Oct 2005 10:28:25 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Re: Further open QoS NSLP issues References: <43453AAA.9060407@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: andrew.mcdonald@roke.co.uk, "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jukka, Jukka MJ Manner wrote: > I'll try to answer some of your comments below. Sorry to have missed your > feedback. > On Thu, 6 Oct 2005, Roland Bless wrote: >>[I'm not really sure whether anyone is tracking my QoS NSLP >>issues at all here on this list...e.g., >>http://www1.ietf.org/mail-archive/web/nsis/current/msg05345.html >>http://www1.ietf.org/mail-archive/web/nsis/current/msg05359.html >>I got zero responses from the authors so far to the above message] There were also other QoS NSLP issues in the cited messages. Could you please check them? Thanks, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 04:31:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQOi-0002Pg-No; Mon, 17 Oct 2005 04:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQOh-0002Pb-CY for nsis@megatron.ietf.org; Mon, 17 Oct 2005 04:31:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24778 for ; Mon, 17 Oct 2005 04:31:00 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/UtFKsZHSJBjTNK1k4AxDNyqTFxZBKQ6I=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQZz-0005FM-R0 for nsis@ietf.org; Mon, 17 Oct 2005 04:42:48 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ERQOd-0000pg-DC; Mon, 17 Oct 2005 10:31:05 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 283D586B3; Mon, 17 Oct 2005 10:31:03 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ERQOc-0003Cv-Uq; Mon, 17 Oct 2005 10:31:02 +0200 Message-ID: <43536146.5060001@tm.uka.de> Date: Mon, 17 Oct 2005 10:31:02 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Re-format the QoS-NSLP common header? References: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Jukka MJ Manner schrieb: > Dear all, > > I proposed earlier to re-format the COMMON HEADER > > The format of the COMMON HEADER seems wierd to me. The message type is 16 > bits and can also hold flags? I would change this structure from > > [16-bit message type][16-bit flags] > > to > > [8-bit message type][8-bit message-specific flags][16-bit generic flags] > > Much cleaner to me, easier to parse, and leaves room for further > enhancement through new flags, in my humble opinion. Do we really need > 16-bits, to allow for 65535 different messages? We only have 4 now. > > > AFAIK, Rob and Andrew have commented that this sounds like a good idea, > and Georgios is somewhat against. Thus, currently, 3 people are humming > for "for", and 1 is humming for "against". > > I'd like to hear more "humms". If I don't hear other "humms", I will > deduce that there are no objections to make this change to the next draft. I'm in favor of re-formatting the common-header. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 04:39:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQWw-0005Ds-Ai; Mon, 17 Oct 2005 04:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQWv-0005Dg-0I for nsis@megatron.ietf.org; Mon, 17 Oct 2005 04:39:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25187 for ; Mon, 17 Oct 2005 04:39:29 -0400 (EDT) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQiD-0005UK-Ha for nsis@ietf.org; Mon, 17 Oct 2005 04:51:17 -0400 Received: from [172.22.0.51] (tmg51.tmg.loc [::ffff:172.22.0.51]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 17 Oct 2005 10:39:35 +0200 id 0000FED7.43536347.00003B1E Message-ID: <43536347.1070102@cs.uni-goettingen.de> Date: Mon, 17 Oct 2005 10:39:35 +0200 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] new draft "GIST over SCTP" and some comments to GIST References: <00fe01c5d278$61f93e40$0302a8c0@comm.ad.roke.co.uk> In-Reply-To: <00fe01c5d278$61f93e40$0302a8c0@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hancock, Robert wrote: > > (non-trivial) > 3.3: i didn't really understand this section. multi-homing > (or any multi-interface) issues have their impact in D mode > only (in fact, query mode messages and NLI payloads), which > are unchanged; the linkage to MAs is done by cookie matching, > which is also unchanged. so I don't see why the fact that the > MA can use a multi-homing transport protocol should make any > difference. I think there might be two issues here: - only two end hosts are multihoming. This can have impact on how the MRIs are maintained, using which IP info in MRM of query messages and how to update the MRIs when a primary IP is changed from one to another. - two neighboring GIST peers are multihoming. This may be related to how to represent multiple IP address pairs in the MA entry (or just the "node identifier" of its peer), in connection with SCTP association/chunk relationship. Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 04:40:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQYE-0005K8-4I; Mon, 17 Oct 2005 04:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQYB-0005Jy-QU for nsis@megatron.ietf.org; Mon, 17 Oct 2005 04:40:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25259 for ; Mon, 17 Oct 2005 04:40:48 -0400 (EDT) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQjU-0005WT-Bc for nsis@ietf.org; Mon, 17 Oct 2005 04:52:36 -0400 Received: from [172.22.0.51] (tmg51.tmg.loc [::ffff:172.22.0.51]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Mon, 17 Oct 2005 10:40:54 +0200 id 0000FED7.43536396.00003BC4 Message-ID: <43536396.2010505@cs.uni-goettingen.de> Date: Mon, 17 Oct 2005 10:40:54 +0200 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner , nsis@ietf.org Subject: Re: [NSIS] Re-format the QoS-NSLP common header? References: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> <43536146.5060001@tm.uka.de> In-Reply-To: <43536146.5060001@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Roland Bless X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org i agree too. Xiaoming Roland Bless wrote: > Jukka MJ Manner schrieb: > >>Dear all, >> >>I proposed earlier to re-format the COMMON HEADER >> >>The format of the COMMON HEADER seems wierd to me. The message type is 16 >>bits and can also hold flags? I would change this structure from >> >>[16-bit message type][16-bit flags] >> >>to >> >>[8-bit message type][8-bit message-specific flags][16-bit generic flags] >> >>Much cleaner to me, easier to parse, and leaves room for further >>enhancement through new flags, in my humble opinion. Do we really need >>16-bits, to allow for 65535 different messages? We only have 4 now. >> >> >>AFAIK, Rob and Andrew have commented that this sounds like a good idea, >>and Georgios is somewhat against. Thus, currently, 3 people are humming >>for "for", and 1 is humming for "against". >> >>I'd like to hear more "humms". If I don't hear other "humms", I will >>deduce that there are no objections to make this change to the next draft. > > > I'm in favor of re-formatting the common-header. > Regards, > Roland > > _______________________________________________ > 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 nsis-bounces@ietf.org Mon Oct 17 04:56:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQnM-0001vn-Mh; Mon, 17 Oct 2005 04:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQnL-0001vf-6B for nsis@megatron.ietf.org; Mon, 17 Oct 2005 04:56:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26633 for ; Mon, 17 Oct 2005 04:56:27 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQyc-0006BZ-6a for nsis@ietf.org; Mon, 17 Oct 2005 05:08:16 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9H8tdWA020424; Mon, 17 Oct 2005 09:55:39 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST Date: Mon, 17 Oct 2005 09:55:50 +0100 Message-ID: Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXSh7ZxFwttoty4STWib3UJGNX9QQAb0ypg From: "Hancock, Robert" To: "Christian Dickmann" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Christian, On the API issue, the background to the issue raised at the interim was that people were concerned that variant GIST capabilities might develop, with some NSLPs requiring specific subsets. This would then become a massive deployment headache. (AFAIK SIP has suffered a little from this problem.) So, the design goal of the API has been to be universal,=20 regardless of how GIST is implemented. In fact, you'll find that appendix B doesn't make any reference to how GIST is implemented (use of TCP, TLS, or even C/D mode). That is quite deliberate. So the summary is: you can make any changes you like in the spec to explain how the API is supported, e.g. to make best use of SCTP. However, you shouldn't (we hope) have to change the content of Appendix B. r. > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 16 October 2005 20:25 > To: "\"Hancock"@www.difra-computer.de; Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] new draft "GIST over SCTP" and some=20 > comments to GIST >=20 >=20 > Hi Robert, >=20 > > in 3.1: IIRC the order of layered proposals is top->bottom,=20 > > i.e. the other way round. (there is discussion of that at=20 > >=20 > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68.)=20 >=20 > I will check that again, but IIRC we implemented it in this way and > had not problem in the interop ;) >=20 > > 3.4.1: one of the fundamental goals of the API is precisely=20 > > that it should *not* change to allow the use of SCTP. (this=20 > > was extensively discussed at the 2004 interim and was stated=20 > > as a goal in the spec.) so it's unclear what API changes should=20 > > be needed. But in fact, I can't tell what changes 3.4.1 actually=20 > > proposes - it describes how to map SCTP features on to the=20 > > API (which is reasonable), but the API itself seems unchanged.=20 >=20 > You are right. The changes are just how parameters are interpreted.=20 > So maybe we should rename this section in the next version. > Do I understand you correctly, that this kind of "change" is=20 > acceptable? >=20 > Christian Dickmann >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 05:09:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERR06-0006Jo-NT; Mon, 17 Oct 2005 05:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERR05-0006IN-IY for nsis@megatron.ietf.org; Mon, 17 Oct 2005 05:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27416 for ; Mon, 17 Oct 2005 05:09:38 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERRBN-0006cq-4Q for nsis@ietf.org; Mon, 17 Oct 2005 05:21:26 -0400 Received: from [192.168.178.22] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 78DA31BAC4D; Mon, 17 Oct 2005 11:09:29 +0200 (CEST) Date: Mon, 17 Oct 2005 11:09:27 +0200 From: Martin Stiemerling To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] NATFW issue 29: Port Range Parameter Field Message-ID: <8F7B2F288BC07D3D8CB6E747@[10.1.1.109]> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0128912F@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D0128912F@esebe100.NOE.Nokia.com > X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John and all, The issue has been closed. Martin --On Freitag, 14. Oktober 2005 10:04 Uhr +0300 john.loughney@nokia.com wrote: |> This issue has been already discussed in July 2005. |> |> My suggestion is to close this issue. From the tracker: |> |> Dave Oran said in an email on 15 July 2005: |> "The alternative is to not worry about this at all and assume |> everybody will have implemented RFC3605 by now." |> |> My recommendation: Do not include Port Range Parameter Field |> and use RFC 3605. |> |> Anybody objections to close issue 29? | | I agree with the recommendation. | | John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 05:09:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERR0G-0006Pj-Dx; Mon, 17 Oct 2005 05:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERR0E-0006Pb-RS for nsis@megatron.ietf.org; Mon, 17 Oct 2005 05:09:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27426 for ; Mon, 17 Oct 2005 05:09:47 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERRBW-0006dL-JD for nsis@ietf.org; Mon, 17 Oct 2005 05:21:35 -0400 Received: from [192.168.178.22] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D83201BAC99; Mon, 17 Oct 2005 11:09:39 +0200 (CEST) Date: Mon, 17 Oct 2005 11:09:36 +0200 From: Martin Stiemerling To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] NATFW issue 28: Keep Port Parity field/semantics Message-ID: In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01289130@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01289130@esebe100.NOE.Nokia.com > X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John and all, The issue has been closed. Martin --On Freitag, 14. Oktober 2005 10:04 Uhr +0300 john.loughney@nokia.com wrote: |>> From the NATFW issue tracker: |> "Nodes may request NATs to keep the parity of the transport |> layer ports" |> |> My suggestion: |>> From issue 29: |> Dave Oran said in an email on 15 July 2005: |> "The alternative is to not worry about this at all and assume |> everybody will have implemented RFC3605 by now." |> |> My recommendation: Same here as in issue 29, do not include |> Port Parity Field and use RFC 3605. |> |> Anybody objections to close issue 28? | | I agree with the resolution. | | John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 05:10:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERR1C-0006hU-6R; Mon, 17 Oct 2005 05:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERR1A-0006hH-Cm for nsis@megatron.ietf.org; Mon, 17 Oct 2005 05:10:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27487 for ; Mon, 17 Oct 2005 05:10:45 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERRCP-0006fD-DZ for nsis@ietf.org; Mon, 17 Oct 2005 05:22:33 -0400 Received: from [192.168.178.22] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5A04C1BAC4D; Mon, 17 Oct 2005 11:10:39 +0200 (CEST) Date: Mon, 17 Oct 2005 11:10:36 +0200 From: Martin Stiemerling To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] NATFW issue 39: REA-PROXY race condition between RESPONSE and requested CREATE Message-ID: <46FCE00EA78BAFE5CE4F0F4A@[10.1.1.109]> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01289134@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D01289134@esebe100.NOE.Nokia.com > X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John and all, The issue has been closed. Martin --On Freitag, 14. Oktober 2005 10:09 Uhr +0300 john.loughney@nokia.com wrote: | I agree. | | John | |> -----Original Message----- |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On |> Behalf Of ext Martin Stiemerling |> Sent: 13 October, 2005 12:34 |> To: nsis |> Subject: [NSIS] NATFW issue 39: REA-PROXY race condition |> between RESPONSE and requested CREATE |> |> Hi, |> |> I suggest to close issue 39 (REA-PROXY race condition between |> RESPONSE and requested CREATE, |> ). |> |> Proposed text is: |> There is a possible race condition between the RESPONSE |> message to the REA- PROXY and the CREATE message generated by |> the edge-NAT. The CREATE message can arrive earlier than the |> RESPONSE message. An NI+ MUST accept CREATE messages generated |> by the edge-NAT even if the RESPONSE message to the REA-PROXY |> request was not received. |> |> Note: The NI+ is able to recognize an edge-NAT generated |> CREATE through the presence of the NATFW_NONCE object. The |> NATFW_NONCE object echoes a value chosen by the NI+. |> |> The proposed text has been already included in draft -07 of |> the NATFW NSLP. |> |> Martin |> |> _______________________________________________ |> 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 nsis-bounces@ietf.org Mon Oct 17 05:57:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRk6-0003lo-W5; Mon, 17 Oct 2005 05:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRk3-0003i3-0S for nsis@megatron.ietf.org; Mon, 17 Oct 2005 05:57:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00796 for ; Mon, 17 Oct 2005 05:57:07 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERRvJ-0008Hy-Nv for nsis@ietf.org; Mon, 17 Oct 2005 06:08:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9H9v7PD005402; Mon, 17 Oct 2005 12:57:08 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 12:57:05 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 12:57:05 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Date: Mon, 17 Oct 2005 12:57:04 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D012893F5@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXSh7ZxFwttoty4STWib3UJGNX9QQAb0ypgAAKEITA= To: , X-OriginalArrivalTime: 17 Oct 2005 09:57:05.0796 (UTC) FILETIME=[215AE440:01C5D301] X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org I agree with Robert about the background and the goals of what we are trying to do with the API. John=20 >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Hancock, Robert >Sent: 17 October, 2005 11:56 >To: Christian Dickmann >Cc: nsis@ietf.org >Subject: RE: [NSIS] new draft "GIST over SCTP" and some=20 >comments to GIST > >Hi Christian, > >On the API issue, the background to the issue raised at the=20 >interim was that people were concerned that variant GIST=20 >capabilities might develop, with some NSLPs requiring specific=20 >subsets. This would then become a massive deployment headache.=20 >(AFAIK SIP has suffered a little from this problem.) So, the=20 >design goal of the API has been to be universal, regardless of=20 >how GIST is implemented. In fact, you'll find that appendix B=20 >doesn't make any reference to how GIST is implemented (use of=20 >TCP, TLS, or even C/D mode). That is quite deliberate. > >So the summary is: you can make any changes you like in the=20 >spec to explain how the API is supported, e.g. to make best=20 >use of SCTP. However, you shouldn't (we hope) have to change=20 >the content of Appendix B. > >r. > >> -----Original Message----- >> From: Christian Dickmann [mailto:mail@christian-dickmann.de] >> Sent: 16 October 2005 20:25 >> To: "\"Hancock"@www.difra-computer.de; Hancock, Robert >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] new draft "GIST over SCTP" and some comments to=20 >> GIST >>=20 >>=20 >> Hi Robert, >>=20 >> > in 3.1: IIRC the order of layered proposals is=20 >top->bottom, i.e. the=20 >> > other way round. (there is discussion of that at >> >=20 >> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68.) >>=20 >> I will check that again, but IIRC we implemented it in this way and=20 >> had not problem in the interop ;) >>=20 >> > 3.4.1: one of the fundamental goals of the API is=20 >precisely that it=20 >> > should *not* change to allow the use of SCTP. (this was=20 >extensively=20 >> > discussed at the 2004 interim and was stated as a goal in=20 >the spec.)=20 >> > so it's unclear what API changes should be needed. But in fact, I=20 >> > can't tell what changes 3.4.1 actually proposes - it describes how=20 >> > to map SCTP features on to the API (which is reasonable), but the=20 >> > API itself seems unchanged. >>=20 >> You are right. The changes are just how parameters are interpreted.=20 >> So maybe we should rename this section in the next version. >> Do I understand you correctly, that this kind of "change" is=20 >> acceptable? >>=20 >> Christian Dickmann >>=20 >>=20 >>=20 > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 06:06:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRtM-0006kt-6M; Mon, 17 Oct 2005 06:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRtJ-0006kl-Sz for nsis@megatron.ietf.org; Mon, 17 Oct 2005 06:06:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01168 for ; Mon, 17 Oct 2005 06:06:42 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERS4a-00005Q-QX for nsis@ietf.org; Mon, 17 Oct 2005 06:18:31 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9HA6SOG025625; Mon, 17 Oct 2005 12:06:28 +0200 (MEST) Message-ID: <00ee01c5d302$71a63340$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Xiaoming Fu" , "Jukka MJ Manner" , References: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> <43536146.5060001@tm.uka.de> <43536396.2010505@cs.uni-goettingen.de> Subject: Re: [NSIS] Re-format the QoS-NSLP common header? Date: Mon, 17 Oct 2005 12:06:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.538 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 17 Oct 2005 12:06:29 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Roland Bless X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org I agree too! Best Regards, Georgios ----- Original Message ----- From: "Xiaoming Fu" To: "Jukka MJ Manner" ; Cc: "Roland Bless" Sent: Monday, October 17, 2005 10:40 AM Subject: Re: [NSIS] Re-format the QoS-NSLP common header? >i agree too. > Xiaoming > > Roland Bless wrote: >> Jukka MJ Manner schrieb: >> >>>Dear all, >>> >>>I proposed earlier to re-format the COMMON HEADER >>> The format of the COMMON HEADER seems wierd to me. The message type is >>> 16 >>>bits and can also hold flags? I would change this structure from >>> >>>[16-bit message type][16-bit flags] >>> >>>to >>>[8-bit message type][8-bit message-specific flags][16-bit generic flags] >>> >>>Much cleaner to me, easier to parse, and leaves room for further >>>enhancement through new flags, in my humble opinion. Do we really need >>>16-bits, to allow for 65535 different messages? We only have 4 now. >>> >>> >>>AFAIK, Rob and Andrew have commented that this sounds like a good idea, >>>and Georgios is somewhat against. Thus, currently, 3 people are humming >>>for "for", and 1 is humming for "against". >>> >>>I'd like to hear more "humms". If I don't hear other "humms", I will >>>deduce that there are no objections to make this change to the next >>>draft. >> >> >> I'm in favor of re-formatting the common-header. >> Regards, >> Roland >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 06:11:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRxo-0007ha-Fi; Mon, 17 Oct 2005 06:11:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRxl-0007em-Uc for nsis@megatron.ietf.org; Mon, 17 Oct 2005 06:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01347 for ; Mon, 17 Oct 2005 06:11:18 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERS93-0000D2-AY for nsis@ietf.org; Mon, 17 Oct 2005 06:23:07 -0400 Received: from wrl-40.cs.helsinki.fi (wrl-40.cs.helsinki.fi [128.214.166.160]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 17 Oct 2005 13:11:16 +0300 id 00070110.435378C4.00005F9B Date: Mon, 17 Oct 2005 13:11:16 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: [NSIS] Re-format the QoS-NSLP common header? In-Reply-To: <00ee01c5d302$71a63340$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <01a301c5cb3d$27400dc0$4c0d5982@dynamic.ewi.utwente.nl> <43536146.5060001@tm.uka.de> <43536396.2010505@cs.uni-goettingen.de> <00ee01c5d302$71a63340$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Xiaoming Fu , Georgios Karagiannis , Roland Bless X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, So, it seems that all I have now have are "humms" that support the proposal, no one has raised objections. Thus, this change, too, will be added in the next release of the QoS NSLP. Thank you all. FYI, there will be a lot more changes, too. We have tried very hard to get rid of our list of open issues. ;) Regards, Jukka On Mon, 17 Oct 2005, Georgios Karagiannis wrote: > I agree too! > > Best Regards, > Georgios > ----- Original Message ----- From: "Xiaoming Fu" > To: "Jukka MJ Manner" ; > Cc: "Roland Bless" > Sent: Monday, October 17, 2005 10:40 AM > Subject: Re: [NSIS] Re-format the QoS-NSLP common header? > > > > i agree too. > > Xiaoming > > > > Roland Bless wrote: > > > Jukka MJ Manner schrieb: > > > > > > > Dear all, > > > > > > > > I proposed earlier to re-format the COMMON HEADER > > > > The format of the COMMON HEADER seems wierd to me. The message type is > > > > 16 > > > > bits and can also hold flags? I would change this structure from > > > > > > > > [16-bit message type][16-bit flags] > > > > > > > > to > > > > [8-bit message type][8-bit message-specific flags][16-bit generic flags] > > > > > > > > Much cleaner to me, easier to parse, and leaves room for further > > > > enhancement through new flags, in my humble opinion. Do we really need > > > > 16-bits, to allow for 65535 different messages? We only have 4 now. > > > > > > > > > > > > AFAIK, Rob and Andrew have commented that this sounds like a good idea, > > > > and Georgios is somewhat against. Thus, currently, 3 people are humming > > > > for "for", and 1 is humming for "against". > > > > > > > > I'd like to hear more "humms". If I don't hear other "humms", I will > > > > deduce that there are no objections to make this change to the next > > > > draft. > > > > > > > > > I'm in favor of re-formatting the common-header. > > > Regards, > > > Roland > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 09:01:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUbt-0000zi-2a; Mon, 17 Oct 2005 09:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSc1-0002xB-NR for nsis@megatron.ietf.org; Mon, 17 Oct 2005 06:53:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03363 for ; Mon, 17 Oct 2005 06:52:53 -0400 (EDT) Received: from mta1.cl.cam.ac.uk ([128.232.0.15] ident=[2M6L+DQ+1gH+lxhsPlbZIqA1JsynBINJ]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERSnK-0001IQ-Is for nsis@ietf.org; Mon, 17 Oct 2005 07:04:43 -0400 Received: from nith.cl.cam.ac.uk ([128.232.8.176] helo=cl.cam.ac.uk) by mta1.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1ERSbs-0002zK-00; Mon, 17 Oct 2005 11:52:52 +0100 To: "Hancock, Robert" Subject: Re: [NSIS] new draft "GIST over SCTP" and some comments to GIST In-Reply-To: Message from "Hancock, Robert" of "Sun, 16 Oct 2005 18:38:12 BST." <00fe01c5d278$61f93e40$0302a8c0@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13929.1129546367.1@cl.cam.ac.uk> Date: Mon, 17 Oct 2005 11:52:47 +0100 From: Jon Crowcroft Message-Id: X-Spam-Score: 0.5 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb X-Mailman-Approved-At: Mon, 17 Oct 2005 09:00:59 -0400 Cc: Xiaoming Fu , Jon.Crowcroft@cl.cam.ac.uk, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org thanks for comments - yes, we need more tech detail in the draft - thats why its only a draft:) i take your point on APIs. In missive <00fe01c5d278$61f93e40$0302a8c0@comm.ad.roke.co.uk>, "Hancock, Rober t" typed: >>This is a multi-part message in MIME format. >> >>------_=_NextPart_001_01C5D279.05328580 >>Content-Type: text/plain; >> charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >>hi, >> >>a very interesting draft. i'm glad to see that SCTP can be >>added to GIST with such a small draft ;-) >> >>some comments >> >>(trivial) >>in 3.1: IIRC the order of layered proposals is top->bottom, >>i.e. the other way round. (there is discussion of that at >>http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68.) >> >>(non-trivial) >>3.3: i didn't really understand this section. multi-homing=20 >>(or any multi-interface) issues have their impact in D mode >>only (in fact, query mode messages and NLI payloads), which >>are unchanged; the linkage to MAs is done by cookie matching, >>which is also unchanged. so I don't see why the fact that the >>MA can use a multi-homing transport protocol should make any >>difference. >> >>3.4.1: one of the fundamental goals of the API is precisely >>that it should *not* change to allow the use of SCTP. (this >>was extensively discussed at the 2004 interim and was stated >>as a goal in the spec.) so it's unclear what API changes should >>be needed. But in fact, I can't tell what changes 3.4.1 actually >>proposes - it describes how to map SCTP features on to the=20 >>API (which is reasonable), but the API itself seems unchanged. >> >>cheers, >> >>robert h. >> >>> -----Original Message----- >>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >>> Behalf Of Xiaoming Fu >>> Sent: 16 October 2005 17:51 >>> To: nsis@ietf.org >>> Cc: Jon Crowcroft >>> Subject: [NSIS] new draft "GIST over SCTP" and some comments to GIST >>>=20 >>>=20 >>> Hi all, >>>=20 >>> We have submitted a new Internet draft on running GIST over=20 >>> SCTP, with=20 >>> the following abstract: >>>=20 >>> Abstract: >>> The General Internet Signaling Transport (GIST) protocol=20 >>> currently=20 >>> uses TCP or TLS over TCP for connection mode operation. This=20 >>> document=20 >>> describes the usage of GIST over the Stream Control Transmission=20 >>> Protocol (SCTP). The use of SCTP can take the advantage of features=20 >>> provided by SCTP, namely streaming-based transport, support=20 >>> of multiple=20 >>> streams to avoid head of line blocking, and the support of=20 >>> multi-homing=20 >>> to provide network level fault tolerance. Additionally, the=20 >>> support for=20 >>> some extensions of SCTP is also discussed, namely its Partial=20 >>> Reliability Extension and the usage of TLS over SCTP. >>>=20 >>> Before it appears in IETF I-D repository, you can find it in the=20 >>> following URL:=20 >>> http://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sc >>tp/draft-fu-nsis-ntlp-sctp-00.txt >> >>We would appreciate it if you would review and comment on the draft. >> >>We have also performed a prototype implementation for the basic SCTP=20 >>support in GIST which we plan to include in the next release. In=20 >>addition, we would like to point to some observations/questions about=20 >>GIST thru this work: >>- Multi-homing: our analysis show that any multi-homing scenario (e.g.,=20 >>host multihoming or AS level multihoming) may involve non-marginal=20 >>consideration in GIST level state management and likely additional=20 >>objects or readapted Stack-Proposal/Stack-Config-Data may be necessary.=20 >>See some preliminary discussions in Section 3.4. >>- API: should Transfer Attribute be constrained to only two values=20 >>(Reliability, Unreliability)? What if the NSLP requires partial=20 >>reliability? See more discussions in Section 3.4.1 in this I-D. >>- In general, what if the two GIST peers do support a same type of=20 >>transport mechanism, but not the same protocol version (e.g., TLS1.0=20 >>v.s. 1.1, TCP with Reno v.s. with NewReno, as well as above-mentioned=20 >>standard SCTP v.s. PR-SCTP, and so on). >> >>Thanks, >>Xiaoming >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >>------_=_NextPart_001_01C5D279.05328580 >>Content-Type: text/html; >> charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >>>charset=3Diso-8859-1"> >>>6.5.7232.11"> >>RE: [NSIS] new draft "GIST over SCTP" and some comments = >>to GIST >> >> >> >> >>

hi, >>

>> >>

a very interesting draft. i'm glad to see that SCTP = >>can be >> >>
added to GIST with such a small draft ;-) >>

>> >>

some comments >>

>> >>

(trivial) >> >>
in 3.1: IIRC the order of layered proposals is = >>top->bottom, >> >>
i.e. the other way round. (there is discussion of = >>that at >> >>
>HREF=3D"http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue= >>68">http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue68>A>.) >>

>> >>

(non-trivial) >> >>
3.3: i didn't really understand this section. = >>multi-homing >> >>
(or any multi-interface) issues have their impact in = >>D mode >> >>
only (in fact, query mode messages and NLI payloads), = >>which >> >>
are unchanged; the linkage to MAs is done by cookie = >>matching, >> >>
which is also unchanged. so I don't see why the fact = >>that the >> >>
MA can use a multi-homing transport protocol should = >>make any >> >>
difference. >>

>> >>

3.4.1: one of the fundamental goals of the API is = >>precisely >> >>
that it should *not* change to allow the use of SCTP. = >>(this >> >>
was extensively discussed at the 2004 interim and was = >>stated >> >>
as a goal in the spec.) so it's unclear what API = >>changes should >> >>
be needed. But in fact, I can't tell what changes = >>3.4.1 actually >> >>
proposes - it describes how to map SCTP features on = >>to the >> >>
API (which is reasonable), but the API itself seems = >>unchanged. >>

>> >>

cheers, >>

>> >>

robert h. >>

>> >>

> -----Original Message----- >> >>
> From: nsis-bounces@ietf.org [>HREF=3D"mailto:nsis-bounces@ietf.org">mailto:nsis-bounces@ietf.org] = >>On >> >>
> Behalf Of Xiaoming Fu >> >>
> Sent: 16 October 2005 17:51 >> >>
> To: nsis@ietf.org >> >>
> Cc: Jon Crowcroft >> >>
> Subject: [NSIS] new draft "GIST over = >>SCTP" and some comments to GIST >> >>
> >> >>
> >> >>
> Hi all, >> >>
> >> >>
> We have submitted a new Internet draft on = >>running GIST over >> >>
> SCTP, with >> >>
> the following abstract: >> >>
> >> >>
> Abstract: >> >>
>     The General Internet = >>Signaling Transport (GIST) protocol >> >>
> currently >> >>
> uses TCP or TLS over TCP for connection mode = >>operation.  This >> >>
> document >> >>
> describes the usage of GIST over the Stream = >>Control Transmission >> >>
> Protocol (SCTP). The use of SCTP can take the = >>advantage of features >> >>
> provided by SCTP, namely streaming-based = >>transport, support >> >>
> of multiple >> >>
> streams to avoid head of line blocking, and the = >>support of >> >>
> multi-homing >> >>
> to provide network level fault tolerance. = >>Additionally, the >> >>
> support for >> >>
> some extensions of SCTP is also discussed, = >>namely its Partial >> >>
> Reliability Extension and the usage of TLS over = >>SCTP. >> >>
> >> >>
> Before it appears in IETF I-D repository, you = >>can find it in the >> >>
> following URL: >> >>
> >HREF=3D"http://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sc">h= >>ttp://user.informatik.uni-goettingen.de/~fu/nsis/gist-over-sc >> >>
tp/draft-fu-nsis-ntlp-sctp-00.txt >>

>> >>

We would appreciate it if you would review and comment = >>on the draft. >>

>> >>

We have also performed a prototype implementation for = >>the basic SCTP >> >>
support in GIST which we plan to include in the next = >>release. In >> >>
addition, we would like to point to some = >>observations/questions about >> >>
GIST thru this work: >> >>
- Multi-homing: our analysis show that any = >>multi-homing scenario (e.g., >> >>
host multihoming or AS level multihoming) may involve = >>non-marginal >> >>
consideration in GIST level state management and = >>likely additional >> >>
objects or readapted Stack-Proposal/Stack-Config-Data = >>may be necessary. >> >>
See some preliminary discussions in Section = >>3.4. >> >>
- API: should Transfer Attribute be constrained to = >>only two values >> >>
(Reliability, Unreliability)? What if the NSLP = >>requires partial >> >>
reliability? See more discussions in Section 3.4.1 in = >>this I-D. >> >>
- In general, what if the two GIST peers do support a = >>same type of >> >>
transport mechanism, but not the same protocol = >>version (e.g., TLS1.0 >> >>
v.s. 1.1, TCP with Reno v.s. with NewReno, as well as = >>above-mentioned >> >>
standard SCTP v.s. PR-SCTP, and so on). >>

>> >>

Thanks, >> >>
Xiaoming >>

>> >>

_______________________________________________ >> >>
nsis mailing list >> >>
nsis@ietf.org >> >>
>HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.or= >>g/mailman/listinfo/nsis >>

>> >> >> >>------_=_NextPart_001_01C5D279.05328580-- cheers jon _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 09:31:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERV4u-0007e2-RU; Mon, 17 Oct 2005 09:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERV4r-0007ca-C2 for nsis@megatron.ietf.org; Mon, 17 Oct 2005 09:30:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12248 for ; Mon, 17 Oct 2005 09:30:50 -0400 (EDT) Received: from pfwhqs1.ncr.disa.mil ([209.22.99.17] helo=pfwhqs101.ncr.disa.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERVGB-00061P-Mw for nsis@ietf.org; Mon, 17 Oct 2005 09:42:40 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0E5207AE@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Roy, Radhika (AEAD)'" , "Nguyen, An" Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Mon, 17 Oct 2005 09:30:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org, "Tschofenig, Hannes" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2137822633==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2137822633== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D31E.F025B5D0" 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_01C5D31E.F025B5D0 Content-Type: text/plain; charset="iso-8859-1" Roy, Correct me if I am wrong!. I think you were talking abou this: http://www.tschofenig.priv.at/drafts/draft-alfano-aaa-qosprot-04.html An -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: Thursday, October 13, 2005 6:17 PM To: Nguyen, An; Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages Hi, An: OK, let us start working on this item - how NSIS signaling protocol, Diameter SIP application and Diameter QoS application work in an integrated way. By the way, do you have any clue about the Diameter QoS application as I indicate in my earlier email? Best regards, Radhika _____ From: Nguyen, An [mailto:an.p.nguyen@dhs.gov] Sent: Thu 10/13/2005 4:30 PM To: Roy, Radhika (AEAD); Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Nguyen, An Subject: RE: AW: [NSIS] Re: authorizing query messages Roy, No, I don't have any problems. By the way, I would like to see how SIP, NSIS signaling protocol , Diameter SIP application and Diameter QoS application whill be integrated to provide end-to-end QoS also. Regards, An -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: Thursday, October 13, 2005 3:37 PM To: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages An and Hannes: Kindly see my earlier email related to this. In addition, I like to add couple of points related to Hannes comments as follows: 1. It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those. 2. Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those. 3. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS. 4. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait. 5. By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.) The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above. If An has any problems, let me know. Best regards, Radhika _____ From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, let me tell you my view on this issue. carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. ciao hannes ------_=_NextPart_001_01C5D31E.F025B5D0 Content-Type: text/html; charset="iso-8859-1" AW: AW: [NSIS] Re: authorizing query messages
 
Correct me if I am wrong!. I think you were talking abou this:
 
 
An
-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]
Sent: Thursday, October 13, 2005 6:17 PM
To: Nguyen, An; Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: RE: AW: [NSIS] Re: authorizing query messages

Hi, An:
 
OK, let us start working on this item - how NSIS signaling protocol, Diameter SIP application and Diameter QoS application work in an integrated way.
 
By the way, do you have any clue about the Diameter QoS application as I indicate in my earlier email?
 
Best regards,
Radhika

From: Nguyen, An [mailto:an.p.nguyen@dhs.gov]
Sent: Thu 10/13/2005 4:30 PM
To: Roy, Radhika (AEAD); Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Nguyen, An
Subject: RE: AW: [NSIS] Re: authorizing query messages

Roy,
 
No, I don't have any problems. By the way, I would like to see how SIP, NSIS signaling protocol , Diameter SIP application and Diameter QoS application whill be integrated to provide end-to-end QoS also.
 
Regards,
 
An
 
 
 
-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]
Sent: Thursday, October 13, 2005 3:37 PM
To: Tschofenig, Hannes; Nguyen, An
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: RE: AW: [NSIS] Re: authorizing query messages

An and Hannes:
 
Kindly see my earlier email related to this.
 
In addition, I like to add couple of points related to Hannes comments as follows:
  1. It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those.
  2. Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those.
  3. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS.
  4. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait.
  5. By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.)
The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above.
If An has any problems, let me know.
 
Best regards,
Radhika
From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42 AM
To: Nguyen, An; David R Oran
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: AW: AW: [NSIS] Re: authorizing query messages

hi an,

let me tell you my view on this issue.

carrying only the qspec parameter is not sufficient for the
authorization decision. you need todo more as you see in the document
(and more stuff will certainly follow -- based on the reviewers feedback
we recently received). you might not want to dump almost all
diameter-qos parameters into the diameter-sip document. instead, it
might be better to see how they interwork just like the diameter-sip
application needs to interwork with other diameter applications as well.
this is a bit more complex compared to radius where you can just dump
the desired parameter into a message since the concept of an application
is not defined. for the diameter-qos application we investigated the
interworking with other applications, such as nasreq and credit control.
this might be another application to take a look at.

in the past we had a few discussions how to map the qos
specific parameters in the sdp to the qspec. within the sdp payloads
only bandwidth parameters are carried. the 3gpp additionally uses
further parameters in addition to the bandwidth parameters but they are
determined based on codec information and bearer information.
as such, it was difficult to show a good mapping by investigating only
the ietf work.

ciao
hannes

------_=_NextPart_001_01C5D31E.F025B5D0-- --===============2137822633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2137822633==-- From nsis-bounces@ietf.org Mon Oct 17 09:53:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVQv-0005B6-DU; Mon, 17 Oct 2005 09:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVQt-0005Ay-S1 for nsis@megatron.ietf.org; Mon, 17 Oct 2005 09:53:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13537 for ; Mon, 17 Oct 2005 09:53:36 -0400 (EDT) From: Gabor.Bajko@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERVcD-0006i4-TG for nsis@ietf.org; Mon, 17 Oct 2005 10:05:27 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9HDoJ8s003357 for ; Mon, 17 Oct 2005 16:50:25 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 16:53:21 +0300 Received: from sdebe101.NOE.Nokia.com ([172.19.222.105]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 08:53:19 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5.7233.31 Subject: RE: [NSIS] NATFW issue 29: Port Range Parameter Field Date: Mon, 17 Oct 2005 06:53:17 -0700 Message-ID: <84CA64E50179964E8EF67403019ABB940137D251@sdebe101.NOE.Nokia.com> Thread-Topic: [NSIS] NATFW issue 29: Port Range Parameter Field Thread-Index: AcXS+vH/NsHk0m2YQ72xsJN+AiPutgAJNmGQ To: X-OriginalArrivalTime: 17 Oct 2005 13:53:19.0323 (UTC) FILETIME=[216F7AB0:01C5D322] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Then how could a DR signal to the FW to open a range of ports for him? (using proxy-mode)=20 There is a req in the 3gpp2 requirements doc=20 "The end point MUST be able to create pinholes with wildcard for source address, port, protocol and spi values field." I thought it was agremmenet on this. How could wildcard be supported if port range is not supported? Gabor >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Martin Stiemerling >Sent: Monday, October 17, 2005 2:09 AM >To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] NATFW issue 29: Port Range Parameter Field > >Hi John and all, > >The issue has been closed. > > Martin > >--On Freitag, 14. Oktober 2005 10:04 Uhr +0300 john.loughney@nokia.com >wrote: > >|> This issue has been already discussed in July 2005. >|> >|> My suggestion is to close this issue. From the tracker: >|> >|> Dave Oran said in an email on 15 July 2005: >|> "The alternative is to not worry about this at all and assume=20 >|> everybody will have implemented RFC3605 by now." >|> >|> My recommendation: Do not include Port Range Parameter=20 >Field and use=20 >|> RFC 3605. >|> >|> Anybody objections to close issue 29? >| >| I agree with the recommendation. >| >| John > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 10:12:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVib-0000wj-EF; Mon, 17 Oct 2005 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERViY-0000wK-Sa for nsis@megatron.ietf.org; Mon, 17 Oct 2005 10:12:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14535 for ; Mon, 17 Oct 2005 10:11:51 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERVtt-0007GX-FG for nsis@ietf.org; Mon, 17 Oct 2005 10:23:42 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 17 Oct 2005 10:11:42 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005101710114200892 ; Mon, 17 Oct 2005 10:11:42 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP; Mon, 17 Oct 2005 10:11:42 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 10:15:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Mon, 17 Oct 2005 10:15:04 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8660898EB@bh-exchange02.saic-abingdon.com> Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXTH3dhc2XzLcZjTzuPrX9IHXqiIQAAgmAQ From: "Roy, Radhika \(AEAD\)" To: X-OriginalArrivalTime: 17 Oct 2005 14:15:31.0890 (UTC) FILETIME=[3BB51120:01C5D325] X-Spam-Score: 0.6 (/) X-Scan-Signature: 0422d07f8ece7c28c8be9cc3edc33d94 Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org, "Tschofenig, Hannes" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0451798961==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0451798961== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D325.2B9778C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D325.2B9778C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An: =20 I got it, and let us work on this document for authorization where QSPEC needs to be integrated per suggestions provided in other emails. In addition, SIP, Diameter QoS applications, and NSIS QoS signaling protocol need to be used on end-to-end basis. By the way, FW/NAT crossing will also to be included with NSIS works along with STUN. =20 I appreciated for your pointer to the AAA QoS draft. I also got the url of this draft in the IETF-Draft section: http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-04.txt =20 Let me provide another IETF draft on QoS model: http://user.informatik.uni-goettingen.de/~fu/nsis/cls_qosm/draft-kappler -nsis-qosmodel-controlledload-03.txt The beauty of this QoS model is that, unlike so-called ITU's Y.series QoS models, it uses IETF IntServ's QoS model that does not depend on any specific values of any performance parameters. That is, any values of any QoS parameters can be used with the NSIS QoS signaling protocol. =20 Now, you can see how the co-authors/co-editors of the QSPEC draft are technically inconsistent to include so called value-specific Y-series QoS models in the draft, but do not include the non-QoS-value-specific IETF's IntServ QoS models. =20 Then the question comes: Why does QSPEC draft not DELETE those so-called QoS-value-specific QoS models that are creating so much technical confusions? Why do they not create separate QoS model-specific drafts for Y.xxxx and others like that of the Kappler draft to remove all technical confusions of the QSPEC draft? =20 Best regards, Radhika =20 ________________________________ From: an.p.nguyen@dhs.gov [mailto:an.p.nguyen@dhs.gov]=20 Sent: Monday, October 17, 2005 9:30 AM To: Roy, Radhika (AEAD); Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Tschofenig, Hannes Subject: RE: AW: [NSIS] Re: authorizing query messages =20 Roy, =20 Correct me if I am wrong!. I think you were talking abou this: =20 http://www.tschofenig.priv.at/drafts/draft-alfano-aaa-qosprot-04.html =20 =20 An -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: Thursday, October 13, 2005 6:17 PM To: Nguyen, An; Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages Hi, An: =20 OK, let us start working on this item - how NSIS signaling protocol, Diameter SIP application and Diameter QoS application work in an integrated way. =20 By the way, do you have any clue about the Diameter QoS application as I indicate in my earlier email? =20 Best regards, Radhika =20 =09 ________________________________ From: Nguyen, An [mailto:an.p.nguyen@dhs.gov] Sent: Thu 10/13/2005 4:30 PM To: Roy, Radhika (AEAD); Tschofenig, Hannes Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Nguyen, An Subject: RE: AW: [NSIS] Re: authorizing query messages Roy, =20 No, I don't have any problems. By the way, I would like to see how SIP, NSIS signaling protocol , Diameter SIP application and Diameter QoS application whill be integrated to provide end-to-end QoS also. =20 Regards, =20 An =20 =20 =20 -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com] Sent: Thursday, October 13, 2005 3:37 PM To: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages An and Hannes: =20 Kindly see my earlier email related to this. =20 In addition, I like to add couple of points related to Hannes comments as follows: 1. It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those. 2. Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those. 3. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS. 4. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait. 5. By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.) The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above. If An has any problems, let me know. =20 Best regards, Radhika =09 ________________________________ From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, =09 let me tell you my view on this issue. =09 carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. =09 in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. =09 ciao hannes ------_=_NextPart_001_01C5D325.2B9778C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable AW: AW: [NSIS] Re: authorizing query messages

An:

 

I got it, and let us work on this = document for authorization where QSPEC needs to be integrated per suggestions = provided in other emails. In addition, SIP, Diameter QoS applications, and NSIS = QoS signaling protocol need to be used on end-to-end basis. By the way, = FW/NAT crossing will also to be included with NSIS works along with = STUN.

 

I appreciated for your pointer to = the AAA QoS draft. I also got the url of this draft in the IETF-Draft section: = http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-04.txt

 

Let me provide another IETF draft = on QoS model: http://user.informatik.uni-g= oettingen.de/~fu/nsis/cls_qosm/draft-kappler-nsis-qosmodel-controlledload= -03.txt

The beauty of this QoS model is = that, unlike so-called ITU’s Y.series QoS models, it uses IETF = IntServ’s QoS model that does not depend on any specific values of any performance parameters. That is, any values of any QoS parameters can be used with = the NSIS QoS signaling protocol.

 

Now, you can see how the co-authors/co-editors of the QSPEC draft are technically inconsistent to include so called value-specific Y-series QoS models in the draft, but = do not include the non-QoS-value-specific IETF’s IntServ QoS = models.

 

Then the question comes: Why does = QSPEC draft not DELETE those so-called QoS-value-specific QoS models that are creating so much technical confusions? Why do they not create separate = QoS model-specific drafts for Y.xxxx and others like that of the Kappler = draft to remove all technical confusions of the QSPEC = draft?

 

Best = regards,

Radhika

=

 

From: an.p.nguyen@dhs.gov [mailto:an.p.nguyen@dhs.gov]
Sent: Monday, October 17, = 2005 9:30 AM
To: Roy, Radhika (AEAD); = Nguyen, An
Cc: McDonald, Andrew; = Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Tschofenig, Hannes
Subject: RE: AW: [NSIS] = Re: authorizing query messages

 

Roy,<= /o:p>

 

Correct me if I am wrong!. I think = you were talking abou this:

 

 

An

-----Original = Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]
Sent: Thursday, October = 13, 2005 6:17 PM
To: Nguyen, An; = Tschofenig, Hannes
Cc: McDonald, Andrew; = Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: RE: AW: [NSIS] = Re: authorizing query messages

Hi, An:

 

OK, let us start working on this item - how NSIS = signaling protocol, Diameter SIP application and Diameter QoS application work in = an integrated way.

 

By the way, do you have any clue about the Diameter = QoS application as I indicate in my earlier = email?

 

Best regards,

Radhika

 

From: Nguyen, An [mailto:an.p.nguyen@dhs.gov]
Sent: Thu 10/13/2005 4:30 = PM
To: Roy, Radhika (AEAD); Tschofenig, Hannes
Cc: McDonald, Andrew; = Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org; Nguyen, An
Subject: RE: AW: [NSIS] = Re: authorizing query messages

Roy,

 

No, I don't have any problems. By = the way, I would like to see how SIP, NSIS signaling protocol , Diameter SIP application and Diameter QoS application whill be integrated to provide end-to-end QoS also.

 

Regards,

 

An

 

 

 

-----Original = Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]
Sent: Thursday, October = 13, 2005 3:37 PM
To: Tschofenig, Hannes; = Nguyen, An
Cc: McDonald, Andrew; = Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: RE: AW: [NSIS] = Re: authorizing query messages

An and = Hannes:

 

Kindly see my earlier email related to = this.

 

In addition, I like to add couple of points related = to Hannes comments as follows:

  1. It is desirable to have all the QoS = parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment = those.
  1. Diameter QoS application does not need to = use QSPEC per se. It needs to carry the abstract of QSPEC QoS = parameters within the Diameter QoS application protocol. If any QoS parameters = or exact semantics are missing in Dia QoS, Dia QoS needs to be = extended for only those.
  1. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic = Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] = will invoke QoS.
  1. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about = this. All we need to see whether all the QoS parameters expressed in SDP have = the place holder in Dia QoS (indirectly QSPEC QoS). At present, as = Hannes mentioned, only bandwidth is there. If it is so, we are on the safe = side because Dia QoS/QSPEC can support this. In the future, we hope that = SDP QoS parameters can be extended to delay, jitter, packet loss, etc. = based on the QoS needs of each codec type. Until that happens, let us = wait.
  1. By the way, I would like to later how = SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying = the modeling and simulations results [sorry - not to be publicly = released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I = am waiting how the standard works progress. Later on, we hope to = implement for the worldwide network that will include MANET as the access = network.)

The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward = as describe above.

If An has any problems, let me = know.

 

Best regards,

Radhika

From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42 = AM
To: Nguyen, An; David R = Oran
Cc: McDonald, Andrew; = Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org
Subject: AW: AW: [NSIS] = Re: authorizing query messages

hi an,

let me tell you my view on this issue.

carrying only the qspec parameter is not sufficient for the
authorization decision. you need todo more as you see in the = document
(and more stuff will certainly follow -- based on the reviewers = feedback
we recently received). you might not want to dump almost all
diameter-qos parameters into the diameter-sip document. instead, it
might be better to see how they interwork just like the diameter-sip
application needs to interwork with other diameter applications as = well.
this is a bit more complex compared to radius where you can just = dump
the desired parameter into a message since the concept of an = application
is not defined. for the diameter-qos application we investigated the
interworking with other applications, such as nasreq and credit = control.
this might be another application to take a look at.

in the past we had a few discussions how to map the qos
specific parameters in the sdp to the qspec. within the sdp payloads
only bandwidth parameters are carried. the 3gpp additionally uses
further parameters in addition to the bandwidth parameters but they = are
determined based on codec information and bearer information.
as such, it was difficult to show a good mapping by investigating = only
the ietf work.

ciao
hannes

------_=_NextPart_001_01C5D325.2B9778C8-- --===============0451798961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0451798961==-- From nsis-bounces@ietf.org Mon Oct 17 10:28:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVyX-0005Ml-FO; Mon, 17 Oct 2005 10:28:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVyT-0005ML-3w for nsis@megatron.ietf.org; Mon, 17 Oct 2005 10:28:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15391 for ; Mon, 17 Oct 2005 10:28:17 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERW9m-0007kw-Rn for nsis@ietf.org; Mon, 17 Oct 2005 10:40:08 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9HERfEH010327; Mon, 17 Oct 2005 16:27:41 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9HERfGZ015182; Mon, 17 Oct 2005 16:27:41 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 16:27:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: AW: [NSIS] Re: authorizing query messages Date: Mon, 17 Oct 2005 16:26:27 +0200 Message-ID: Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXPT7yj8ePZgGgMSp29zr/zQf1xngACxQHQADOp9sEAvs3jkA== From: "Tschofenig, Hannes" To: , "Nguyen, An" X-OriginalArrivalTime: 17 Oct 2005 14:27:41.0163 (UTC) FILETIME=[EE634BB0:01C5D326] X-Spam-Score: 0.6 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0479469474==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0479469474== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D326.EE167224" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D326.EE167224 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi roy,=20 =20 thanks for the feedback. please see my comments inline: =20 -----Urspr=FCngliche Nachricht----- Von: RoyR@saic-abingdon.com [mailto:RoyR@saic-abingdon.com]=20 Gesendet: Donnerstag, 13. Oktober 2005 21:37 An: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Betreff: RE: AW: [NSIS] Re: authorizing query messages An and Hannes: =20 Kindly see my earlier email related to this. =20 In addition, I like to add couple of points related to Hannes comments = as follows: 1.=09 It is desirable to have all the QoS parameters of QSPEC to be = authorized. If something is missing in Diameter QoS application or vice = versa, we need to augment those. 2.=09 Diameter QoS application does not need to use QSPEC per se. It needs to = carry the abstract of QSPEC QoS parameters within the Diameter QoS = application protocol. If any QoS parameters or exact semantics are = missing in Dia QoS, Dia QoS needs to be extended for only those=20 it is a matter of taste whether you create your own object or to reuse = the same object for carrying the qos specific parameters (if the = semantic is the same).=20 we have chosen one approach but someone else might use a different = approach. =20 3.=09 Once items 1 and 2 are taken care of, authorization/authentication = will be taken care of by basic Diameter protocol (depending on which = application [e.g., SIP, FTP, etc.] will invoke QoS.=20 we aim to make the aaa interaction independent of the qos signaling = protocol. whether this is possible in all cases is subject for future = work.=20 for the design of the diameter application one might reuse different = applications. you might want to review the current design.=20 =20 4.=09 With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, = we do not need to worry about this. All we need to see whether all the = QoS parameters expressed in SDP have the place holder in Dia QoS = (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth = is there. If it is so, we are on the safe side because Dia QoS/QSPEC can = support this. In the future, we hope that SDP QoS parameters can be = extended to delay, jitter, packet loss, etc. based on the QoS needs of = each codec type. Until that happens, let us wait.=20 currently it seems that the mapping is straight forward.=20 =20 5.=09 By the way, I would like to later how SIP, NSIS signaling protocol, and = Diameter SIP application and Diameter QoS application are integrated on = end-to-end basis. (Note: We have done our home work for probable = implementation after studying the modeling and simulations results = [sorry - not to be publicly released] and test-bed [NSIS protocol NOT = yet] in controlled environments, but I am waiting how the standard works = progress. Later on, we hope to implement for the worldwide network that = will include MANET as the access network.)=20 further work is required to document these issues. the only document i = am aware of is a document written by martin that described the = interworking between the natfw nslp and sip signaling but this was some = time back.=20 The point that I like to make is this: QSPEC = Authorization/Authentication is NOT a big deal. It is straight forward = as describe above. If An has any problems, let me know.=20 =20 i am not sure what you mean by "big deal". it is a lot of work to put = things together and to describe them in a consistent way. we tried todo = this with the diameter-qos application (and with all our other = documents). =20 ciao hannes =20 =20 Best regards, Radhika _____ =20 From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, let me tell you my view on this issue. carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. ciao hannes ------_=_NextPart_001_01C5D326.EE167224 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
hi=20 roy,
 
thanks=20 for the feedback. please see my comments inline:
 
-----Urspr=FCngliche Nachricht-----
Von: = RoyR@saic-abingdon.com=20 [mailto:RoyR@saic-abingdon.com]
Gesendet: Donnerstag, 13. = Oktober=20 2005 21:37
An: Tschofenig, Hannes; Nguyen, An
Cc:=20 McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner;=20 nsis@ietf.org
Betreff: RE: AW: [NSIS] Re: authorizing query=20 messages

An and = Hannes:
 
Kindly see my earlier email = related to=20 this.
 
In addition, I like to add = couple of=20 points related to Hannes comments as follows:
  1. It is desirable to have all the QoS = parameters=20 of QSPEC to be authorized. If something is missing in Diameter QoS=20 application or vice versa, we need to augment those.
  2. Diameter QoS application does = not need to=20 use QSPEC per se. It needs to carry the abstract of QSPEC QoS = parameters=20 within the Diameter QoS application protocol. If any QoS parameters = or exact=20 semantics are missing in Dia QoS, Dia QoS needs to be extended for = only=20 those 

    it is=20 a matter of taste whether you create your own object or to reuse the = same=20 object for carrying the qos specific parameters (if the = semantic=20 is the same).
    we have chosen one approach but someone else might = use a=20 different approach.      
  3.  Once items 1 and 2 are taken = care of,=20 authorization/authentication will be taken care of by basic Diameter = protocol (depending on which application [e.g., SIP, FTP, etc.] will = invoke=20 QoS. 

    we aim to make the aaa interaction independent = of=20 the qos signaling protocol. whether this is possible in all = cases is=20 subject for future work. 
    for the design of the diameter application one=20 might reuse different applications. you might want to = review the=20 current design.
     
  4. With respect to mapping of = SIP/SDP QoS=20 parameters mapping into Dia QoS, we do not need to worry about this. = All we=20 need to see whether all the QoS parameters expressed in SDP have the = place=20 holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes = mentioned,=20 only bandwidth is there. If it is so, we are on the safe side = because Dia=20 QoS/QSPEC can support this. In the future, we hope that SDP QoS = parameters=20 can be extended to delay, jitter, packet loss, etc. based on the QoS = needs=20 of each codec type. Until that happens, let us wait. 

    currently it=20 seems that the mapping is straight=20 forward. 
     
  5. By the way, I would like to = later how=20 SIP, NSIS signaling protocol, and Diameter SIP application and = Diameter QoS=20 application are integrated on end-to-end basis. (Note: We have = done our=20 home work for probable implementation after studying the modeling = and=20 simulations results [sorry - not to be publicly released] and = test-bed [NSIS=20 protocol NOT yet] in controlled environments, but I am waiting how = the=20 standard works progress. Later on, we hope to implement for the = worldwide=20 network that will include MANET as the access network.) 

    further work is=20 required to document these issues. the only document i am aware of = is a=20 document written by martin that described the = interworking=20 between the natfw nslp and sip signaling but this was some time = back.=20
The point that I like to = make is this:=20 QSPEC Authorization/Authentication is NOT a big deal. It is straight = forward=20 as describe above.
If An has any = problems, let me=20 know. 
 
i am not sure what = you mean by=20 "big deal". it is a lot of work to put things together and = to=20 describe them in a consistent way. we tried todo this with=20 the diameter-qos application (and with all our other=20 documents).
 
ciao
hannes
 
 
Best regards,
Radhika
From: = nsis-bounces@ietf.org on=20 behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42=20 AM
To: Nguyen, An; David R Oran
Cc: McDonald, = Andrew;=20 Georgios Karagiannis; Jukka MJ Manner; = nsis@ietf.org
Subject: AW:=20 AW: [NSIS] Re: authorizing query messages

hi an,

let me tell you my view on this=20 issue.

carrying only the qspec parameter is not sufficient for=20 the
authorization decision. you need todo more as you see in the=20 document
(and more stuff will certainly follow -- based on the = reviewers=20 feedback
we recently received). you might not want to dump almost=20 all
diameter-qos parameters into the diameter-sip document. = instead,=20 it
might be better to see how they interwork just like the=20 diameter-sip
application needs to interwork with other diameter=20 applications as well.
this is a bit more complex compared to radius = where=20 you can just dump
the desired parameter into a message since the = concept of=20 an application
is not defined. for the diameter-qos application we=20 investigated the
interworking with other applications, such as = nasreq and=20 credit control.
this might be another application to take a look=20 at.

in the past we had a few discussions how to map the = qos
specific=20 parameters in the sdp to the qspec. within the sdp payloads
only = bandwidth=20 parameters are carried. the 3gpp additionally uses
further = parameters in=20 addition to the bandwidth parameters but they are
determined based = on codec=20 information and bearer information.
as such, it was difficult to = show a=20 good mapping by investigating only
the ietf=20 = work.

ciao
hannes

<= /HTML> ------_=_NextPart_001_01C5D326.EE167224-- --===============0479469474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0479469474==-- From nsis-bounces@ietf.org Mon Oct 17 10:28:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVyf-0005NZ-0V; Mon, 17 Oct 2005 10:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVye-0005NP-5H for nsis@megatron.ietf.org; Mon, 17 Oct 2005 10:28:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15413 for ; Mon, 17 Oct 2005 10:28:28 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERW9z-0007l6-D3 for nsis@ietf.org; Mon, 17 Oct 2005 10:40:19 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9HERgoj010332; Mon, 17 Oct 2005 16:27:42 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j9HERgQo004867; Mon, 17 Oct 2005 16:27:42 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 16:27:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [NSIS] Re: authorizing query messages Date: Mon, 17 Oct 2005 16:27:40 +0200 Message-ID: Thread-Topic: AW: [NSIS] Re: authorizing query messages Thread-Index: AcXPT7yj8ePZgGgMSp29zr/zQf1xngACxQHQADOp9sEAAlFX1QC8ZZyA From: "Tschofenig, Hannes" To: "Roy, Radhika \(AEAD\)" , "Nguyen, An" X-OriginalArrivalTime: 17 Oct 2005 14:27:41.0491 (UTC) FILETIME=[EE955830:01C5D326] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org # hi roy,=20 Hi, An: I also see that there is no direct work on Diameter QoS application unless something new is started in this area. Or, am I missing something? # i am not quite sure what you mean.=20 # have you read the diameter-qos application? The other thing is that we can assume that QSPEC is authorized using AAA (e.g., Diameter) protocol. In this cae, the standards development for authorization of QSPEC using AAA protocl falls under the charter of AAA WG, not a part of NSIS. # that's subject for discussion between the chairs and the area directors.=20 # ciao # hannes Best regards, Radhika From: nsis-bounces@ietf.org on behalf of Roy, Radhika (AEAD) Sent: Thu 10/13/2005 3:37 PM To: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages An and Hannes: Kindly see my earlier email related to this. In addition, I like to add couple of points related to Hannes comments as follows: It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those. Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait. By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.) The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above. If An has any problems, let me know. Best regards, Radhika From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, let me tell you my view on this issue. carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 11:10:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWdB-0008I0-3H; Mon, 17 Oct 2005 11:10:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWd9-0008H6-PG for nsis@megatron.ietf.org; Mon, 17 Oct 2005 11:10:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18219 for ; Mon, 17 Oct 2005 11:10:20 -0400 (EDT) Received: from mtassp3.ncr.disa.mil ([164.117.82.26] helo=mtassp3.disanet.disa-u.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWoU-0000kR-Jq for nsis@ietf.org; Mon, 17 Oct 2005 11:22:11 -0400 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id <4XSQLDW6>; Mon, 17 Oct 2005 11:10:32 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0E5207B0@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Tschofenig, Hannes'" , "Roy, Radhika (AEAD)" , "Nguyen, An" Subject: RE: AW: [NSIS] Re: authorizing query messages Date: Mon, 17 Oct 2005 11:10:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: "McDonald, Andrew" , Georgios Karagiannis , Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hannes, Thanks for your clarification. See inlines. An > >-----Original Message----- >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >Sent: Monday, October 17, 2005 10:28 AM >To: Roy, Radhika (AEAD); Nguyen, An >Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; >nsis@ietf.org >Subject: AW: AW: [NSIS] Re: authorizing query messages > > ># hi roy, > >Hi, An: > >I also see that there is no direct work on Diameter QoS application >unless something new is started in this area. Or, am I missing >something? ># i am not quite sure what you mean. ># have you read the diameter-qos application? Understood. >The other thing is that we can assume that QSPEC is authorized using AAA >(e.g., Diameter) protocol. In this cae, the standards development for >authorization of QSPEC using AAA protocl falls under the charter of AAA >WG, not a part of NSIS. Agreed. I just want to see the QSPEC authorization/authentication work gets done somewhere. ># that's subject for discussion between the chairs and the area >directors. > # ciao # hannes Best regards, Radhika From: nsis-bounces@ietf.org on behalf of Roy, Radhika (AEAD) Sent: Thu 10/13/2005 3:37 PM To: Tschofenig, Hannes; Nguyen, An Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: RE: AW: [NSIS] Re: authorizing query messages An and Hannes: Kindly see my earlier email related to this. In addition, I like to add couple of points related to Hannes comments as follows: It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those. Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those. Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS. With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait. By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.) The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above. If An has any problems, let me know. Best regards, Radhika From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes Sent: Thu 10/13/2005 4:42 AM To: Nguyen, An; David R Oran Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; nsis@ietf.org Subject: AW: AW: [NSIS] Re: authorizing query messages hi an, let me tell you my view on this issue. carrying only the qspec parameter is not sufficient for the authorization decision. you need todo more as you see in the document (and more stuff will certainly follow -- based on the reviewers feedback we recently received). you might not want to dump almost all diameter-qos parameters into the diameter-sip document. instead, it might be better to see how they interwork just like the diameter-sip application needs to interwork with other diameter applications as well. this is a bit more complex compared to radius where you can just dump the desired parameter into a message since the concept of an application is not defined. for the diameter-qos application we investigated the interworking with other applications, such as nasreq and credit control. this might be another application to take a look at. in the past we had a few discussions how to map the qos specific parameters in the sdp to the qspec. within the sdp payloads only bandwidth parameters are carried. the 3gpp additionally uses further parameters in addition to the bandwidth parameters but they are determined based on codec information and bearer information. as such, it was difficult to show a good mapping by investigating only the ietf work. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 16:29:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbbu-0002Ur-QT; Mon, 17 Oct 2005 16:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbbt-0002U2-8g for nsis@megatron.ietf.org; Mon, 17 Oct 2005 16:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17569 for ; Mon, 17 Oct 2005 16:29:21 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERbnE-0005RB-JN for nsis@ietf.org; Mon, 17 Oct 2005 16:41:15 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9HKTDWB004879 for ; Mon, 17 Oct 2005 22:29:13 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9HKTDCP030705 for ; Mon, 17 Oct 2005 22:29:13 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 Oct 2005 22:29:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D359.6FD0DCA8" Date: Mon, 17 Oct 2005 22:26:34 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-lefaucheur-emergency-rsvp-00.txt Thread-Index: AcXTVhKAhqXD6FieQ3i6mbIj8+K6VQAAtsEQ From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 17 Oct 2005 20:29:13.0877 (UTC) FILETIME=[7040C450:01C5D359] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [NSIS] WG: I-D ACTION:draft-lefaucheur-emergency-rsvp-00.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D359.6FD0DCA8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all,=20 this might be something to consider in the design of emergency related = parameters for the qspec.=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von = Internet-Drafts@ietf.org Gesendet: Montag, 17. Oktober 2005 21:50 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-lefaucheur-emergency-rsvp-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : RSVP Admission Priority Policy Element for Emergency Services=20 Author(s) : F. Le Faucheur, J. Polk Filename : draft-lefaucheur-emergency-rsvp-00.txt Pages : 15 Date : 2005-10-17 =09 An Emergency Telecommunications Service (ETS) requires the ability to = provide an elevated probability of call completion to an authorized=20 user in times of crisis. When supported over the Internet Protocol=20 suite, this may be achieved through an admission control solution=20 which supports call preemption capabilities as well as admission=20 priority capabilities, whereby some resources (e.g. bandwidth) are=20 reserved for emergency services only.=20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-lefaucheur-emergency-rsvp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-lefaucheur-emergency-rsvp-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C5D359.6FD0DCA8 Content-Type: application/octet-stream; name="draft-lefaucheur-emergency-rsvp-00.URL" Content-Description: draft-lefaucheur-emergency-rsvp-00.URL Content-Disposition: attachment; filename="draft-lefaucheur-emergency-rsvp-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1sZWZhdWNoZXVyLWVtZXJnZW5jeS1yc3ZwLTAwLnR4dA0K ------_=_NextPart_001_01C5D359.6FD0DCA8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C5D359.6FD0DCA8-- From nsis-bounces@ietf.org Mon Oct 17 17:47:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcpj-0005do-FP; Mon, 17 Oct 2005 17:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcph-0005dg-Id for nsis@megatron.ietf.org; Mon, 17 Oct 2005 17:47:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08906 for ; Mon, 17 Oct 2005 17:47:41 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERd14-000578-9j for nsis@ietf.org; Mon, 17 Oct 2005 17:59:37 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9HLlGWC012796; Mon, 17 Oct 2005 22:47:17 +0100 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 49WV78Z3; Mon, 17 Oct 2005 22:51:38 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST Date: Mon, 17 Oct 2005 22:47:11 +0100 Message-ID: <000101c5d364$54fbddf0$0302a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXTZPNwNuwl/KXHSN28nYaGkmMCJA== From: "Hancock, Robert" To: "Xiaoming Fu" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0020981460==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0020981460== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D364.F32E1100" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D364.F32E1100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi xiaoming, some more discussion: > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Xiaoming Fu > Sent: 17 October 2005 09:40 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] new draft "GIST over SCTP" and some=20 > comments to GIST >=20 >=20 > Hancock, Robert wrote: > >=20 > > (non-trivial) > > 3.3: i didn't really understand this section. multi-homing > > (or any multi-interface) issues have their impact in D mode > > only (in fact, query mode messages and NLI payloads), which > > are unchanged; the linkage to MAs is done by cookie matching, > > which is also unchanged. so I don't see why the fact that the > > MA can use a multi-homing transport protocol should make any > > difference. >=20 > I think there might be two issues here: > - only two end hosts are multihoming. This can have impact on how the=20 > MRIs are maintained, using which IP info in MRM of query messages and=20 > how to update the MRIs when a primary IP is changed from one=20 > to another. these are all multihoming issues, but i don't see what they have to do with the use of SCTP as a transport. note that multihoming for user data is not really visible to GIST (GIST sees this as several independent flows; it is up to the signalling applications to realise they are related to a single session). so you if you have several MRIs they are handled independently, and each MRI is handled quite deterministically. > - two neighboring GIST peers are multihoming. This may be=20 > related to how=20 > to represent multiple IP address pairs in the MA entry (or just the=20 > "node identifier" of its peer), in connection with SCTP=20 > association/chunk relationship. true, but (if you want to) this is already the case even with TCP as a transport for the messaging associations. the way that routing state is bound to messaging associations causes a new association to be set up for each address pair (this is a consequence of the state matching rules), BUT if nodes can determine that they are peering over multiple associations they can use a single one and discard the rest.=20 it may be that more text could be written (probably implementation guidance) about how this can be done. but i would not tie together the facts that multiple address pairs for routing state are relevant=20 between multi-interface nodes and that SCTP can support multiple address pairs. indeed, even in the non-multi-homed case, the IP peer addresses used in the routing state do not need to be closely tied to the IP addresses used by the transport layer protocol for the messaging association (they are tied together by cookie=20 matching, not address matching). so i certainly would not try to bind the two together in the multi-homed case. cheers, r. > Xiaoming >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C5D364.F32E1100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] new draft "GIST over SCTP" and some comments = to GIST

hi xiaoming,

some more discussion:

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of Xiaoming Fu
> Sent: 17 October 2005 09:40
> To: Hancock, Robert; nsis@ietf.org
> Subject: Re: [NSIS] new draft "GIST over = SCTP" and some
> comments to GIST
>
>
> Hancock, Robert wrote:
> >
> > (non-trivial)
> > 3.3: i didn't really understand this = section. multi-homing
> > (or any multi-interface) issues have their = impact in D mode
> > only (in fact, query mode messages and NLI = payloads), which
> > are unchanged; the linkage to MAs is done = by cookie matching,
> > which is also unchanged. so I don't see why = the fact that the
> > MA can use a multi-homing transport = protocol should make any
> > difference.
>
> I think there might be two issues here:
> - only two end hosts are multihoming. This can = have impact on how the
> MRIs are maintained, using which IP info in MRM = of query messages and
> how to update the MRIs when a primary IP is = changed from one
> to another.

these are all multihoming issues, but i don't see what = they have
to do with the use of SCTP as a transport. note that = multihoming
for user data is not really visible to GIST (GIST = sees this as
several independent flows; it is up to the signalling = applications
to realise they are related to a single session). so = you if you
have several MRIs they are handled independently, and = each MRI
is handled quite deterministically.

> - two neighboring GIST peers are multihoming. = This may be
> related to how
> to represent multiple IP address pairs in the MA = entry (or just the
> "node identifier" of its peer), in = connection with SCTP
> association/chunk relationship.

true, but (if you want to) this is already the case = even with TCP
as a transport for the messaging associations. the = way that routing
state is bound to messaging associations causes a new = association
to be set up for each address pair (this is a = consequence of the
state matching rules), BUT if nodes can determine = that they are
peering over multiple associations they can use a = single one and
discard the rest.

it may be that more text could be written (probably = implementation
guidance) about how this can be done. but i would not = tie together
the facts that multiple address pairs for routing = state are relevant
between multi-interface nodes and that SCTP can = support multiple
address pairs. indeed, even in the non-multi-homed = case, the IP
peer addresses used in the routing state do not need = to be closely
tied to the IP addresses used by the transport layer = protocol for
the messaging association (they are tied together by = cookie
matching, not address matching). so i certainly would = not try to
bind the two together in the multi-homed case.

cheers,

r.

> Xiaoming
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C5D364.F32E1100-- --===============0020981460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0020981460==-- From nsis-bounces@ietf.org Mon Oct 17 17:58:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERczx-0001L0-7i; Mon, 17 Oct 2005 17:58:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERczt-0001Kt-Rk for nsis@megatron.ietf.org; Mon, 17 Oct 2005 17:58:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09446 for ; Mon, 17 Oct 2005 17:58:14 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERdBI-0005N1-Mg for nsis@ietf.org; Mon, 17 Oct 2005 18:10:09 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9HLw1WA015191; Mon, 17 Oct 2005 22:58:01 +0100 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 49WV78ZR; Mon, 17 Oct 2005 23:02:22 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Date: Mon, 17 Oct 2005 22:57:56 +0100 Message-ID: <000901c5d365$d4df0370$0302a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Thread-Index: AcXTZnNZfhpelrmpRiKZe3R8LvoeHA== From: "Hancock, Robert" To: , , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0260872165==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0260872165== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D366.7308AB00" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D366.7308AB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, IIRC there were two aspects of this topic discussed at the interim: a) the availability of the diagnosis/query features in the first place, and b) the use of them to build some procedures for recovery from certain error/restart scenarios I don't recall much discussion of (a). I recall significant objections to (b) (indeed, I think I made several of them) because they seemed rather complicated and fragile. But that doesn't mean that the facilities themselves are not useful for - well - diagnosis (for which it's hard to build reasonable scenarios other than "something went wrong and I'd like to work out what"). It is possible to go overboard on diagnostics but I don't think we're there yet. r. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of john.loughney@nokia.com > Sent: 14 October 2005 08:09 > To: stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP >=20 >=20 > Hi Martin, >=20 > >Draft -07 of the NATFW NSLP describes a query and diagnosis=20 > >capability in Section 3.3.6. These capabilities have been in=20 > >the draft for while but no real usage scenarios have been=20 > >described so far (see issue 30 in the tracker=20 > >). > > > >The general feeling of the WG about these query and diagnosis=20 > >capabilities were quite mixed (as expressed during the last=20 > >interim in Munich). Since then I have not received any further=20 > >comments about this issue. > > > >Personally, I do not see any good use cases for such a=20 > >capability in the NATFW NSLP and I'm in favour of removing it=20 > >completely. > > > >I'm soliciting the WG to give feedback on this issue, whether=20 > >it is considered a useful feature or not. If you consider it a=20 > >useful feature, you should give some use cases. >=20 > I am leaning towards dropping this feature. I think that this is > extra functionality without defined use - this will make the > implementatino & usage more difficult. >=20 > John >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C5D366.7308AB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Query & Diagnosis Capabilities in NATFW = NSLP

hi all,

IIRC there were two aspects of this topic discussed at = the
interim:

a) the availability of the diagnosis/query features in = the
first place, and

b) the use of them to build some procedures for = recovery from
certain error/restart scenarios

I don't recall much discussion of (a). I recall = significant
objections to (b) (indeed, I think I made several of = them)
because they seemed rather complicated and = fragile.
But that doesn't mean that the facilities themselves = are
not useful for - well - diagnosis (for which it's = hard to
build reasonable scenarios other than "something = went wrong
and I'd like to work out what").

It is possible to go overboard on diagnostics but I = don't
think we're there yet.

r.

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of john.loughney@nokia.com
> Sent: 14 October 2005 08:09
> To: stiemerling@netlab.nec.de; = nsis@ietf.org
> Subject: RE: [NSIS] Query & Diagnosis = Capabilities in NATFW NSLP
>
>
> Hi Martin,
>
> >Draft -07 of the NATFW NSLP describes a = query and diagnosis
> >capability in Section 3.3.6. These = capabilities have been in
> >the draft for while but no real usage = scenarios have been
> >described so far (see issue 30 in the = tracker
> ><https= ://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue30>).
> >
> >The general feeling of the WG about these = query and diagnosis
> >capabilities were quite mixed (as expressed = during the last
> >interim in Munich). Since then I have not = received any further
> >comments about this issue.
> >
> >Personally, I do not see any good use cases = for such a
> >capability in the NATFW NSLP and I'm in = favour of removing it
> >completely.
> >
> >I'm soliciting the WG to give feedback on = this issue, whether
> >it is considered a useful feature or not. If = you consider it a
> >useful feature, you should give some use = cases.
>
> I am leaning towards dropping this = feature.  I think that this is
> extra functionality without defined use - this = will make the
> implementatino & usage more = difficult.
>
> John
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C5D366.7308AB00-- --===============0260872165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0260872165==-- From nsis-bounces@ietf.org Mon Oct 17 18:22:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdMm-0001Ql-1A; Mon, 17 Oct 2005 18:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdMj-0001PS-R2 for nsis@megatron.ietf.org; Mon, 17 Oct 2005 18:21:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10625 for ; Mon, 17 Oct 2005 18:21:49 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERdY8-0005wO-5R for nsis@ietf.org; Mon, 17 Oct 2005 18:33:45 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9HMLkv0014403; Tue, 18 Oct 2005 00:21:47 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9HMLk5j028734; Tue, 18 Oct 2005 00:21:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Oct 2005 00:21:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Date: Tue, 18 Oct 2005 00:21:16 +0200 Message-ID: Thread-Topic: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Thread-Index: AcXTZnNZfhpelrmpRiKZe3R8LvoeHAAATbsw From: "Tschofenig, Hannes" To: "Hancock, Robert" , , , X-OriginalArrivalTime: 17 Oct 2005 22:21:46.0708 (UTC) FILETIME=[29410140:01C5D369] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi martin,=20 the discussions at the interim meeting indeed questioned the usefulness = of a scenario where the end host fetches state information from the = firewall after the end host crashed. my impression was also that this = scenario is not particularly good.=20 in gabor's draft (see -----Original Message-----=20 > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of john.loughney@nokia.com=20 > Sent: 14 October 2005 08:09=20 > To: stiemerling@netlab.nec.de; nsis@ietf.org=20 > Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP=20 >=20 >=20 > Hi Martin,=20 >=20 > >Draft -07 of the NATFW NSLP describes a query and diagnosis=20 > >capability in Section 3.3.6. These capabilities have been in=20 > >the draft for while but no real usage scenarios have been=20 > >described so far (see issue 30 in the tracker=20 > >).=20 > >=20 > >The general feeling of the WG about these query and diagnosis=20 > >capabilities were quite mixed (as expressed during the last=20 > >interim in Munich). Since then I have not received any further=20 > >comments about this issue.=20 > >=20 > >Personally, I do not see any good use cases for such a=20 > >capability in the NATFW NSLP and I'm in favour of removing it=20 > >completely.=20 > >=20 > >I'm soliciting the WG to give feedback on this issue, whether=20 > >it is considered a useful feature or not. If you consider it a=20 > >useful feature, you should give some use cases.=20 >=20 > I am leaning towards dropping this feature. I think that this is=20 > extra functionality without defined use - this will make the=20 > implementatino & usage more difficult.=20 >=20 > John=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 17 18:55:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdte-00046o-02; Mon, 17 Oct 2005 18:55:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdta-00043k-4D for nsis@megatron.ietf.org; Mon, 17 Oct 2005 18:55:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13061 for ; Mon, 17 Oct 2005 18:55:45 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERe4z-00077a-3z for nsis@ietf.org; Mon, 17 Oct 2005 19:07:42 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9HMt1WA026071; Mon, 17 Oct 2005 23:55:01 +0100 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 49WV78Z4; Mon, 17 Oct 2005 23:59:21 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] TLS in the GIST draft Date: Mon, 17 Oct 2005 23:54:50 +0100 Message-ID: <002401c5d36d$cb2b5d80$0302a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] TLS in the GIST draft Thread-Index: AcXTbmmrzpaKZGvORFOnk1y3buFk+A== From: "Hancock, Robert" To: , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0741569049==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0741569049== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D36E.68EAAA80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D36E.68EAAA80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi pasi, john, all, [warning: long, dense mail] i've had time to think about this a little. in terms of what one could specific about TLS, there seem to be 4 (related) issues, all of one it would be good to see some more discussion on. 1. TLS version. The draft currently says MUST 1.0, SHOULD 1.1. Given that GIST will be built from TLS libraries (rather than already deployed TLS code), maybe we could be more prescriptive about wanting 1.1; would that be a good or bad thing? 2. Cipher suites (raised earlier in this thread). AFAICT from reading them, the TLS documents specify a single (mandatory to implement) cipher suite, so TLS compliance is enough to=20 provide interoperability from that point of view. Is there a need to be more prescriptive here? (Why did Diameter do so?) 3. What authentication methods (certificates, EAP, SRP, etc.=20 etc.) should be implemented. (Sometimes the authentication method seems to be implied by offering a certain special ciphersuite, as in the PSK case in particular.) 4. How to decide which identity is to be asserted and authenticated (of querying and responding node). (3) and (4) are the hard ones. However, AFAICT they are really linked, in that if you can work out which identities you want to deal with, that implicitly tells you what authentication method needs to implemented to support it. So, for (3) I don't think extra protocol machinery is required (there may be a=20 case for different accompanying documentation, see the end). So, the question is whether more work needs to be done on GIST to at least leave open the possibility of doing something decent for identity negotiation as per (4). If containers are needed in the GIST handshake to do this I would like to get them=20 identified at this stage, unless it turns into a real nightmare. There are 3 places where identity information could be derived from the GIST handshake: a) in the NLI (possible in current spec) b) as option data in the SCD (need to add a format for=20 option data to the TLS higher layer information format) c) as option data in the stack-proposal object (need to change the object format, quite significantly). The main reason for putting something in (c) is to be able to validate that it has not been modified in the protocol exchange (done by repeating it in the Confirm). But any decent authentication protocol will provide that function internally. So, it seems we don't need to do (c). Either of (a) or (b) would be relatively trivial from a specification point of=20 view. What needs a bit more thought is how we expect authentication to be configured in operational practice (in non-certificated cases). Presumably, if a GIST node is going to authenticate a peer, this means it has to know the identity of peers it trusts enough to form MAs with, and know (or know how to=20 retrieve) their credential information. So a GIST node will have to have access to some identity database, of identities of peers it will trust; this can also be used to configure the node with which identity it uses for itself, and what=20 authentication method to use. The requirement on the GIST specification is then that it must exchange enough information to allow lookups in this database. I think either of (a) or (b) would be good enough for this purpose, provided the identities exchanged are 'administratively' unique. There are some advantages to using the NLI object for this purpose, since if this changes it guarantees that a new MA is set up, whereas if one relies on fields in the SCD, implementations have to do a bit of extra work to trap this case. Even if we do stick with the NLI, there may still be a need to write something about operational issues. That could be to encourage some uniformity in the selection of authentication techniques, and also (maybe) proposing a structure for the PI field in the NLI (if only to make it human-readable).=20 That might be for the GIST spec itself, or (more likely?)=20 for some separate BCP-like thing. cheers, robert h. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Pasi.Eronen@nokia.com > Sent: 14 October 2005 12:03 > To: nsis@ietf.org > Subject: RE: [NSIS] TLS in the GIST draft >=20 >=20 > John Loughney wrote: > > Pasi, > >=20 > > Do you think that the Diameter text would be useful for GIST, or > > do you have other suggestions on what is currently common practice=20 > > for TLS features? >=20 > This really depends on what is the goal of specifying the use of=20 > TLS in the GIST draft.. >=20 > Something like the Diameter text is fine if the main goal is to > provide one plausible way to secure the GIST messaging (and pass > the security area review :-) But between the lines you can > certainly read that "we wrote this just because we had to, not > because we think that this is the way NSIS+TLS will actually be > used in real deployments"... >=20 > But then again, writing correct text to cover all possible > real-world deployment scenarios is certainly quite impossible. > And for NSIS, probably we don't quite yet know how it will > be actually used and deployed.. >=20 > > For your second point, I agree with your analysis, but do you=20 > > have a suggestion on the best way to handle the TLS negotiation? >=20 > The current text seems to cover the "TLS authenticated with > certificates" case reasonably well, so one option would be just > to say so, and explicitly say that Kerberos etc. are beyond the=20 > scope of this document. (If nobody plans to use Kerberos and=20 > RFC2712 with NSIS, spending a lot of effort to figure out how=20 > exactly it would work is probably not that great idea.) >=20 > Best regards, > Pasi >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C5D36E.68EAAA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] TLS in the GIST draft

hi pasi, john, all,

[warning: long, dense mail]

i've had time to think about this a little. in terms = of what one
could specific about TLS, there seem to be 4 = (related) issues,
all of one it would be good to see some more = discussion on.

1. TLS version. The draft currently says MUST 1.0, = SHOULD 1.1.
Given that GIST will be built from TLS libraries = (rather than
already deployed TLS code), maybe we could be more = prescriptive
about wanting 1.1; would that be a good or bad = thing?

2. Cipher suites (raised earlier in this thread). = AFAICT from
reading them, the TLS documents specify a single = (mandatory
to implement) cipher suite, so TLS compliance is = enough to
provide interoperability from that point of view. Is = there a
need to be more prescriptive here? (Why did Diameter = do so?)

3. What authentication methods (certificates, EAP, = SRP, etc.
etc.) should be implemented. (Sometimes the = authentication method
seems to be implied by offering a certain special = ciphersuite,
as in the PSK case in particular.)

4. How to decide which identity is to be asserted = and
authenticated (of querying and responding = node).

(3) and (4) are the hard ones. However, AFAICT they = are really
linked, in that if you can work out which identities = you want
to deal with, that implicitly tells you what = authentication
method needs to implemented to support it. So, for = (3) I don't
think extra protocol machinery is required (there may = be a
case for different accompanying documentation, see = the end).

So, the question is whether more work needs to be done = on GIST
to at least leave open the possibility of doing = something decent
for identity negotiation as per (4). If containers = are needed
in the GIST handshake to do this I would like to get = them
identified at this stage, unless it turns into a real = nightmare.

There are 3 places where identity information could be = derived
from the GIST handshake:
a) in the NLI (possible in current spec)
b) as option data in the SCD (need to add a format = for
option data to the TLS higher layer information = format)
c) as option data in the stack-proposal object (need = to
change the object format, quite = significantly).

The main reason for putting something in (c) is to be = able
to validate that it has not been modified in the = protocol
exchange (done by repeating it in the Confirm). But = any decent
authentication protocol will provide that function = internally.
So, it seems we don't need to do (c). Either of (a) = or (b)
would be relatively trivial from a specification = point of
view.

What needs a bit more thought is how we expect = authentication
to be configured in operational practice (in = non-certificated
cases). Presumably, if a GIST node is going to = authenticate
a peer, this means it has to know the identity of = peers it
trusts enough to form MAs with, and know (or know how = to
retrieve) their credential information. So a GIST = node will
have to have access to some identity database, of = identities
of peers it will trust; this can also be used to = configure the
node with which identity it uses for itself, and what =
authentication method to use. The requirement on the = GIST
specification is then that it must exchange enough = information
to allow lookups in this database. I think either of = (a) or (b)
would be good enough for this purpose, provided the = identities
exchanged are 'administratively' unique. There are = some
advantages to using the NLI object for this purpose, = since if
this changes it guarantees that a new MA is set up, = whereas
if one relies on fields in the SCD, implementations = have to
do a bit of extra work to trap this case.

Even if we do stick with the NLI, there may still be a = need
to write something about operational issues. That = could be
to encourage some uniformity in the selection of = authentication
techniques, and also (maybe) proposing a structure = for the
PI field in the NLI (if only to make it = human-readable).
That might be for the GIST spec itself, or (more = likely?)
for some separate BCP-like thing.

cheers,

robert h.

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of Pasi.Eronen@nokia.com
> Sent: 14 October 2005 12:03
> To: nsis@ietf.org
> Subject: RE: [NSIS] TLS in the GIST draft
>
>
> John Loughney wrote:
> > Pasi,
> >
> > Do you think that the Diameter text would = be useful for GIST, or
> > do you have other suggestions on what is = currently common practice
> > for TLS features?
>
> This really depends on what is the goal of = specifying the use of
> TLS in the GIST draft..
>
> Something like the Diameter text is fine if the = main goal is to
> provide one plausible way to secure the GIST = messaging (and pass
> the security area review :-)  But between = the lines you can
> certainly read that "we wrote this just = because we had to, not
> because we think that this is the way NSIS+TLS = will actually be
> used in real deployments"...
>
> But then again, writing correct text to cover = all possible
> real-world deployment scenarios is certainly = quite impossible.
> And for NSIS, probably we don't quite yet know = how it will
> be actually used and deployed..
>
> > For your second point, I agree with your = analysis, but do you
> > have a suggestion on the best way to handle = the TLS negotiation?
>
> The current text seems to cover the "TLS = authenticated with
> certificates" case reasonably well, so one = option would be just
> to say so, and explicitly say that Kerberos etc. = are beyond the
> scope of this document. (If nobody plans to use = Kerberos and
> RFC2712 with NSIS, spending a lot of effort to = figure out how
> exactly it would work is probably not that great = idea.)
>
> Best regards,
> Pasi
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C5D36E.68EAAA80-- --===============0741569049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0741569049==-- From nsis-bounces@ietf.org Mon Oct 17 22:04:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERgq2-0006Pw-TP; Mon, 17 Oct 2005 22:04:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERgq1-0006Pr-La for nsis@megatron.ietf.org; Mon, 17 Oct 2005 22:04:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24431 for ; Mon, 17 Oct 2005 22:04:17 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERh1R-0004BZ-Lj for nsis@ietf.org; Mon, 17 Oct 2005 22:16:15 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IOJ00B3F9QZEY@mailout2.samsung.com> for nsis@ietf.org; Tue, 18 Oct 2005 11:04:11 +0900 (KST) Received: from LocalHost ([75.2.91.243]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IOJ00H6T9QZZJ@mmp1.samsung.com> for nsis@ietf.org; Tue, 18 Oct 2005 11:04:11 +0900 (KST) Date: Tue, 18 Oct 2005 11:04:10 +0900 From: Sung-Hyuck Lee To: nsis@ietf.org Message-id: <001e01c5d388$3b2b3eb0$f35b024b@LocalHost> Organization: SAIT MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal References: <001001c5cda2$e1326720$ef2b024b@LocalHost> X-Spam-Score: 0.8 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [NSIS] NSIS Mobility Issue #12: Terminology: Path Update X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0476207106==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0476207106== Content-type: multipart/alternative; boundary="Boundary_(ID_Q4BR/Z/aYLKbqXL7sU6j+g)" This is a multi-part message in MIME format. --Boundary_(ID_Q4BR/Z/aYLKbqXL7sU6j+g) Content-type: text/plain; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT Hi all, The authors of NSIS mobility draft would like to address the following terminology issue on the NSIS mobility issue tracker: http://www.tschofenig.priv.at:8080/nsismob/. - Issue #12: Terminology, "Path Update" The term, "Path Update" has been chosen with the initial mobility manyfolks-draft. However, some folks think that the term does not appropriately represent the meaning of NSIS state recovery. Currently, the candidates for substitution of the term are i) "State Recovery" ii) "State Update" It would be helpful for progress of NSIS mobility draft if you could give any suggestion and comment. Thanks & Regards, (Kam-Sa-Hap-Ni-da) NSIS-Mobility authors --Boundary_(ID_Q4BR/Z/aYLKbqXL7sU6j+g) Content-type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT
Hi all,
 
The authors of NSIS mobility draft would like to address the following
terminology issue on the NSIS mobility issue tracker: http://www.tschofenig.priv.at:8080/nsismob/.
 
- Issue #12: Terminology, "Path Update"

   The term, "Path Update" has been chosen with the initial mobility
   manyfolks-draft. However, some folks think that the term does not 
   appropriately represent the meaning of NSIS state recovery. 
   Currently, the candidates for substitution of the term are 

      i) "State Recovery"
      ii) "State Update"
 
It would be helpful for progress of NSIS mobility draft if you could give
any suggestion and comment.
 
 
Thanks & Regards,
(Kam-Sa-Hap-Ni-da)
 
NSIS-Mobility authors
 
 

--Boundary_(ID_Q4BR/Z/aYLKbqXL7sU6j+g)-- --===============0476207106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0476207106==-- From nsis-bounces@ietf.org Tue Oct 18 00:57:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERjXB-00031x-93; Tue, 18 Oct 2005 00:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERjX8-00030R-Sr for nsis@megatron.ietf.org; Tue, 18 Oct 2005 00:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02866 for ; Tue, 18 Oct 2005 00:56:58 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERjia-0008Sf-T5 for nsis@ietf.org; Tue, 18 Oct 2005 01:08:58 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j9I4uqMC022273; Tue, 18 Oct 2005 06:56:52 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j9I4uq5B004553; Tue, 18 Oct 2005 06:56:52 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j9I4uqO02552; Tue, 18 Oct 2005 06:56:52 +0200 (MEST) Date: Tue, 18 Oct 2005 06:56:52 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: gash@att.com, attila.bader@ericsson.com, cornelia.kappler@siemens.com, jmanner@cs.Helsinki.FI, andrew.mcdonald@roke.co.uk Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 18 Oct 2005 04:56:52 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA8F08@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.377 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 18 Oct 2005 06:56:53 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org Subject: [NSIS] PACKET_CLASSIFIER in QSPEC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all >From the discussion that we have had in the NSIS mailing list, one can deduce that the PACKET_CLASSIFIER object cannot be carried as a pure QOS-NSLP object. The reason is that this will not work when QSPEC stacking is used. There are two solutions that one can apply: * Local configuration by each node, where the filters will be pre-configured by each QoS model * signaling using QSPEC; PACKET CLASSIFIER will be a QSPEC parameter! >From what I have understood, most of the participants in the discussion would prefer the signaling using QSPEC solution! Is this acepted by the NSIS WG? Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 18 01:44:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkH8-0000Kx-EG; Tue, 18 Oct 2005 01:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkH6-0000Km-8o for nsis@megatron.ietf.org; Tue, 18 Oct 2005 01:44:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05197 for ; Tue, 18 Oct 2005 01:44:27 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERkSZ-0001CH-Ce for nsis@ietf.org; Tue, 18 Oct 2005 01:56:27 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j9I5iVuh023845; Tue, 18 Oct 2005 07:44:31 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j9I5iU5B008405; Tue, 18 Oct 2005 07:44:31 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j9I5iVG14555; Tue, 18 Oct 2005 07:44:31 +0200 (MEST) Date: Tue, 18 Oct 2005 07:44:31 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 18 Oct 2005 05:44:31 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <1huAq68w.1129614270.9958990.karagian@ewi.utwente.nl> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.515 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 18 Oct 2005 07:44:32 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: andrew.mcdonald@roke.co.uk, jmanner@cs.Helsinki.FI Subject: [NSIS] Qos-NSLP modifications related to bypassing intermediate nodes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all Regarding the GIST bypassing due to the existence of an aggregated region, in addition to the GIST draft and extensibility draft, we will also have to make some modifications in the QOS-NSLP draft. It has to be specified that a signaling application, which uses the same SESSION_ID, may use more than one NSLP-IDs. This situation occurs when an aggregation or a stateless region has to be bypassed by a QoS-NSLP message. We also have to specify that the boundary of aggregation or stateless domains SHOULD be able to change, for the same session, the NSLP-ID of a message that passes through the aggregation or stateless domain. In particular: Required change in Section 4.6: ----------------------------- Change from: "Markings are used so that intermediate routers do not need to inspect the individual flow reservations." INTO: "The messages used for the signaling of the individual reservation need to be marked such that the intermediate routers will not inspect them. The marking MUST be accomplished by the Aggregator by modifying the QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value. The De-aggregator MUST stop this marking process by reassigning the QoS-NSLP default NSLP-ID value to these signaling messages." ----------------------------------- Required chnages in Section 4.7 ----------------------- Change from: "At the ingress the original RESERVE message is forwarded but ignored by the stateless or reduced-state nodes." INTO: "At the ingress the original RESERVE message is forwarded but ignored by the stateless or reduced-state nodes. This is accomplished by marking this message, i.e., modifying the QoS-NSLP default NSLP-ID value to another NSLP-ID predefined value. The marking MUST be accomplished by the ingress by modifying the QoS_NSLP default NSLP-ID value to a NSLP-ID predefined value. The egress MUST stop this marking process by reassigning the QoS-NSLP default NSLP-ID value to the original RESERVE message. The exact operation of modifying the NSLP-ID is specified in [I-D.ietf-nsis-rmd]." ----------------------------------- Proposed new Section 7.3 --------------------------- "7.3. Support for bypassing intermediate nodes The QoS NSLP may want to restrict the handling of its messages to specific nodes. This functionality is needed to support layering (explained in Section 3.2.8), when only the edge QNEs of a domain process the message. This requires a mechanism at GIMPS level (which can be invoked by the QoS NSLP) to bypass intermediates nodes between the edges of the domain. The intermediate nodes are bypassed using multiple levels of the router alert option. In that case, internal routers are configured to handle only certain levels of router alerts. This is accomplished by marking the signaling messages, i.e., modifying the QoS-NSLP default NSLP-ID value to another NSLP-ID predefined value. The marking MUST be accomplished by the ingress edge by modifying the QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value. The egress MUST stop this marking process by reassigning the QoS-NSLP default NSLP-ID value to the original RESERVE message. The exact operation of modifying the NSLP-ID must be specified in the relevant QoS model specification." ------------------------------------------------- Do you have any objections on these proposals? Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 18 09:37:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrfC-00051f-Vj; Tue, 18 Oct 2005 09:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrfB-0004zQ-IP for nsis@megatron.ietf.org; Tue, 18 Oct 2005 09:37:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00078 for ; Tue, 18 Oct 2005 09:37:50 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERrqe-0005O6-5A for nsis@ietf.org; Tue, 18 Oct 2005 09:49:53 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C91DC4F0008; Tue, 18 Oct 2005 15:09:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 15:09:10 +0200 Content-class: urn:content-classes:message Date: Tue, 18 Oct 2005 15:09:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: PACKET_CLASSIFIER in QSPEC X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcXToGJTon92RGZOS1mLx3tbGpySOQAQwaBA From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Georgios Karagiannis" , , , , X-OriginalArrivalTime: 18 Oct 2005 13:09:10.0479 (UTC) FILETIME=[2103B5F0:01C5D3E5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi All, Since the PACKET_CLASSIFIER is different in different QoS domains it = seems resonable to include it in the QSpec Template as control info. I = prefer this solution to configuring it in each node by filters. Anyway we will keep it as an open QSpec template issue until consensus = is reached. Best regards, Attila > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Tuesday, October 18, 2005 6:57 AM > To: gash@att.com; Attila B=E1der (IJ/ETH); = cornelia.kappler@siemens.com; > jmanner@cs.Helsinki.FI; andrew.mcdonald@roke.co.uk > Cc: nsis@ietf.org > Subject: PACKET_CLASSIFIER in QSPEC >=20 >=20 >=20 > Dear all >=20 > From the discussion that we have had in the NSIS mailing list, one can > deduce that the PACKET_CLASSIFIER object cannot be carried as a pure > QOS-NSLP object. The reason is that this will not work when QSPEC > stacking is used. > There are two solutions that one can apply: > * Local configuration by each node, where the filters will be > pre-configured by each QoS model >=20 > * signaling using QSPEC; PACKET CLASSIFIER will be a QSPEC parameter! >=20 > From what I have understood, most of the participants in the=20 > discussion > would prefer the signaling using QSPEC solution! >=20 > Is this acepted by the NSIS WG? > Best Regards, > Georgios >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 18 17:26:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERyy7-0000w8-WA; Tue, 18 Oct 2005 17:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERyy6-0000ul-OA for nsis@megatron.ietf.org; Tue, 18 Oct 2005 17:25:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29521 for ; Tue, 18 Oct 2005 17:25:50 -0400 (EDT) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERz9i-00055l-E0 for nsis@ietf.org; Tue, 18 Oct 2005 17:37:58 -0400 Received: from [84.132.147.46] (p5484932E.dip0.t-ipconnect.de [::ffff:84.132.147.46]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 18 Oct 2005 23:25:50 +0200 id 0001013D.4355685E.000053E6 Message-ID: <4355685D.9070002@cs.uni-goettingen.de> Date: Tue, 18 Oct 2005 23:25:49 +0200 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] new draft "GIST over SCTP" and some comments to GIST References: <000101c5d364$54fbddf0$0302a8c0@comm.ad.roke.co.uk> In-Reply-To: <000101c5d364$54fbddf0$0302a8c0@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org robert, thanks for your further comments. my comments inline: Hancock, Robert wrote: > hi xiaoming, > > some more discussion: > > Hancock, Robert wrote: > > > > > > (non-trivial) > > > 3.3: i didn't really understand this section. multi-homing > > > (or any multi-interface) issues have their impact in D mode > > > only (in fact, query mode messages and NLI payloads), which > > > are unchanged; the linkage to MAs is done by cookie matching, > > > which is also unchanged. so I don't see why the fact that the > > > MA can use a multi-homing transport protocol should make any > > > difference. > > > > I think there might be two issues here: > > - only two end hosts are multihoming. This can have impact on how the > > MRIs are maintained, using which IP info in MRM of query messages and > > how to update the MRIs when a primary IP is changed from one > > to another. > > these are all multihoming issues, but i don't see what they have > to do with the use of SCTP as a transport. note that multihoming > for user data is not really visible to GIST (GIST sees this as > several independent flows; it is up to the signalling applications > to realise they are related to a single session). so you if you > have several MRIs they are handled independently, and each MRI > is handled quite deterministically. i think this is viable way. > > > - two neighboring GIST peers are multihoming. This may be > > related to how > > to represent multiple IP address pairs in the MA entry (or just the > > "node identifier" of its peer), in connection with SCTP > > association/chunk relationship. > > true, but (if you want to) this is already the case even with TCP > as a transport for the messaging associations. the way that routing > state is bound to messaging associations causes a new association > to be set up for each address pair (this is a consequence of the > state matching rules), BUT if nodes can determine that they are > peering over multiple associations they can use a single one and > discard the rest. in the case of sctp, it is clear a given gist pair can have up to one sctp association, per rfc2960. > > it may be that more text could be written (probably implementation > guidance) about how this can be done. but i would not tie together > the facts that multiple address pairs for routing state are relevant > between multi-interface nodes and that SCTP can support multiple > address pairs. indeed, even in the non-multi-homed case, the IP > peer addresses used in the routing state do not need to be closely > tied to the IP addresses used by the transport layer protocol for > the messaging association (they are tied together by cookie > matching, not address matching). so i certainly would not try to > bind the two together in the multi-homed case. maybe i am a bit puzzled here - yes a cookie requires to be repeated in the query-response, but the problem here is a mrs is required to identify the right identities of its upstream and downstream peer. which identify should be relied on? in the current world likely will still be ip address i guess. xiaoming > > cheers, > > r. > > > Xiaoming > > > > _______________________________________________ > > 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 nsis-bounces@ietf.org Wed Oct 19 04:40:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9UR-0004Yf-Dw; Wed, 19 Oct 2005 04:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9UP-0004Wp-PA for nsis@megatron.ietf.org; Wed, 19 Oct 2005 04:40:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00073 for ; Wed, 19 Oct 2005 04:39:53 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES9fv-0003kh-1U for nsis@ietf.org; Wed, 19 Oct 2005 04:52:07 -0400 Received: from [192.168.1.6] (unknown [212.126.217.90]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 984A31BAC4D; Wed, 19 Oct 2005 10:39:38 +0200 (CEST) Date: Wed, 19 Oct 2005 10:39:34 +0200 From: Martin Stiemerling To: "Hancock, Robert" , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Message-ID: X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, --On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert" wrote: | hi all, | | IIRC there were two aspects of this topic discussed at the | interim: | | a) the availability of the diagnosis/query features in the | first place, and | | b) the use of them to build some procedures for recovery from | certain error/restart scenarios | | I don't recall much discussion of (a). I recall significant | objections to (b) (indeed, I think I made several of them) Yes, you've made those objections :) I object to b) as well since recovery from error/restart is complicated and fragile. So I see b) as ruled out. For case a) I have solicited real use cases for several times - without any real response. However, what can a node learn by using a query capability, other he can learn by using the already defined mechanisms (error messages, NOTIFY messages? (this is not a question to you Robert but others :) | because they seemed rather complicated and fragile. | But that doesn't mean that the facilities themselves are | not useful for - well - diagnosis (for which it's hard to | build reasonable scenarios other than "something went wrong | and I'd like to work out what"). | | It is possible to go overboard on diagnostics but I don't | think we're there yet. I see it the same way. Probably, somebody will find an interesting use case in the future. If so, we can extend the NATFW NSLP later. Thanks, Martin | | r. | |> -----Original Message----- |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On |> Behalf Of john.loughney@nokia.com |> Sent: 14 October 2005 08:09 |> To: stiemerling@netlab.nec.de; nsis@ietf.org |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP |> |> |> Hi Martin, |> |> > Draft -07 of the NATFW NSLP describes a query and diagnosis |> > capability in Section 3.3.6. These capabilities have been in |> > the draft for while but no real usage scenarios have been |> > described so far (see issue 30 in the tracker |> > ). |> > |> > The general feeling of the WG about these query and diagnosis |> > capabilities were quite mixed (as expressed during the last |> > interim in Munich). Since then I have not received any further |> > comments about this issue. |> > |> > Personally, I do not see any good use cases for such a |> > capability in the NATFW NSLP and I'm in favour of removing it |> > completely. |> > |> > I'm soliciting the WG to give feedback on this issue, whether |> > it is considered a useful feature or not. If you consider it a |> > useful feature, you should give some use cases. |> |> I am leaning towards dropping this feature. I think that this is |> extra functionality without defined use - this will make the |> implementatino & usage more difficult. |> |> John |> |> _______________________________________________ |> nsis mailing list |> nsis@ietf.org |> https://www1.ietf.org/mailman/listinfo/nsis |> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 04:43:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9Y0-0005Dh-4a; Wed, 19 Oct 2005 04:43:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9Xx-0005Cb-Of for nsis@megatron.ietf.org; Wed, 19 Oct 2005 04:43:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00224 for ; Wed, 19 Oct 2005 04:43:33 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES9jf-0003ps-Ch for nsis@ietf.org; Wed, 19 Oct 2005 04:55:47 -0400 Received: from [192.168.1.6] (unknown [212.126.217.90]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8915D1BAC4D; Wed, 19 Oct 2005 10:43:31 +0200 (CEST) Date: Wed, 19 Oct 2005 10:43:26 +0200 From: Martin Stiemerling To: "Tschofenig, Hannes" , "Hancock, Robert" , john.loughney@nokia.com, nsis@ietf.org Subject: Re: AW: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --On Dienstag, 18. Oktober 2005 0:21 Uhr +0200 "Tschofenig, Hannes"=20 wrote: | hi martin, | | the discussions at the interim meeting indeed questioned the usefulness | of a scenario where the end host fetches state information from the | firewall after the end host crashed. my impression was also that this | scenario is not particularly good. I see it the same way. The end host crash scenario is most probably not applicable since the node would need to figure out its old used session IDs to fetch further information. | | in gabor's draft (see -----Original Message----- |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On |> Behalf Of john.loughney@nokia.com |> Sent: 14 October 2005 08:09 |> To: stiemerling@netlab.nec.de; nsis@ietf.org |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP |> |> |> Hi Martin, |> |> > Draft -07 of the NATFW NSLP describes a query and diagnosis |> > capability in Section 3.3.6. These capabilities have been in |> > the draft for while but no real usage scenarios have been |> > described so far (see issue 30 in the tracker |> > ). |> > |> > The general feeling of the WG about these query and diagnosis |> > capabilities were quite mixed (as expressed during the last |> > interim in Munich). Since then I have not received any further |> > comments about this issue. |> > |> > Personally, I do not see any good use cases for such a |> > capability in the NATFW NSLP and I'm in favour of removing it |> > completely. |> > |> > I'm soliciting the WG to give feedback on this issue, whether |> > it is considered a useful feature or not. If you consider it a |> > useful feature, you should give some use cases. |> |> I am leaning towards dropping this feature. I think that this is |> extra functionality without defined use - this will make the |> implementatino & usage more difficult. |> |> John |> |> _______________________________________________ |> nsis mailing list |> nsis@ietf.org |> https://www1.ietf.org/mailman/listinfo/nsis |> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 04:50:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9eh-0007q2-PE; Wed, 19 Oct 2005 04:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9ee-0007mi-Ky for nsis@megatron.ietf.org; Wed, 19 Oct 2005 04:50:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00451 for ; Wed, 19 Oct 2005 04:50:28 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES9qM-0003zY-8G for nsis@ietf.org; Wed, 19 Oct 2005 05:02:42 -0400 Received: from [192.168.1.6] (unknown [212.126.217.90]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A72E31BAC4D; Wed, 19 Oct 2005 10:50:26 +0200 (CEST) Date: Wed, 19 Oct 2005 10:50:21 +0200 From: Martin Stiemerling To: Gabor.Bajko@nokia.com, nsis@ietf.org Subject: RE: [NSIS] NATFW issue 29: Port Range Parameter Field Message-ID: <4BB3C78F7754F07E3B67EF67@[192.168.1.6]> In-Reply-To: <84CA64E50179964E8EF67403019ABB940137D251@sdebe101.NOE.Nokia.com> References: <84CA64E50179964E8EF67403019ABB940137D251@sdebe101.NOE.Nokia.com > X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Gabor, --On Montag, 17. Oktober 2005 6:53 Uhr -0700 Gabor.Bajko@nokia.com wrote: | Hi, | | Then how could a DR signal to the FW to open a range of ports for him? | (using proxy-mode) | There is a req in the 3gpp2 requirements doc | | "The end point MUST be able to create pinholes with wildcard for source | address, port, protocol and spi values field." | | I thought it was agremmenet on this. How could wildcard be supported if | port range is not supported? With the upcoming NSLP specification it is not possible anymore to request a port range (has not been so for the last revisions). This port range is not consider to be a good feature since RFC 3605 should be considered. Now the wildcarding feature. Wildcarding is supported by the NATFW NSLP and you may wildcard address, port, protocol, and SPI values. The wildcarding is mainly taking place in NTLP's MRI. This information of the MRI is used in the NSLP in building the policy rules. Martin | | Gabor | |> -----Original Message----- |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On |> Behalf Of ext Martin Stiemerling |> Sent: Monday, October 17, 2005 2:09 AM |> To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org |> Subject: RE: [NSIS] NATFW issue 29: Port Range Parameter Field |> |> Hi John and all, |> |> The issue has been closed. |> |> Martin |> |> --On Freitag, 14. Oktober 2005 10:04 Uhr +0300 john.loughney@nokia.com |> wrote: |> |>|> This issue has been already discussed in July 2005. |>|> |>|> My suggestion is to close this issue. From the tracker: |>|> |>|> Dave Oran said in an email on 15 July 2005: |>|> "The alternative is to not worry about this at all and assume |>|> everybody will have implemented RFC3605 by now." |>|> |>|> My recommendation: Do not include Port Range Parameter |> Field and use |>|> RFC 3605. |>|> |>|> Anybody objections to close issue 29? |>| |>| I agree with the recommendation. |>| |>| John |> |> |> |> _______________________________________________ |> nsis mailing list |> nsis@ietf.org |> https://www1.ietf.org/mailman/listinfo/nsis |> | | _______________________________________________ | nsis mailing list | nsis@ietf.org | https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 06:45:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESBRl-00075c-B0; Wed, 19 Oct 2005 06:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESBRj-00075P-Cx for nsis@megatron.ietf.org; Wed, 19 Oct 2005 06:45:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06380 for ; Wed, 19 Oct 2005 06:45:14 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESBdP-00079V-4g for nsis@ietf.org; Wed, 19 Oct 2005 06:57:30 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-131.messagelabs.com!1129718519!12425444!19 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 5829 invoked from network); 19 Oct 2005 10:45:07 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-2.tower-131.messagelabs.com with SMTP; 19 Oct 2005 10:45:07 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4351BDFD001DDBE0; Wed, 19 Oct 2005 06:45:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 05:45:06 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA94C0@KCCLUST06EVS1.ugd.att.com> Thread-Topic: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXToGB/zFtsfpkXRwmN6j/qS6OxfQA9UIcg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, All, > From the discussion that we have had in the NSIS mailing list, one can > deduce that the PACKET_CLASSIFIER object cannot be carried as a pure > QOS-NSLP object. The reason is that this will not work when QSPEC > stacking is used. > There are two solutions that one can apply: > * Local configuration by each node, where the filters will be > pre-configured by each QoS model >=20 > * signaling using QSPEC; PACKET CLASSIFIER will be a QSPEC parameter! There is another solution. If separate packet_classifier's are needed for each of 2 QSPECs, then the packet-classifiers can be stacked in QoS-NSLP just as we agreed that separate QSPECs (and their lengths) can be stacked in QoS-NSLP. (BTW, it doesn't appear that there is consensus that separate classifiers would be needed for 2 QSPECs, however.) =20 > From what I have understood, most of the participants in the=20 > discussion would prefer the signaling using QSPEC solution! > > Is this accepted by the NSIS WG? I re-read the thread and it appears that Robert, John, Cornelia, and others support keeping the packet_classifier in QoS-NSLP. Cheng Hong also favored to put the packet_classifier in QoS-NSLP http://www1.ietf.org/mail-archive/web/nsis/current/msg05481.html. He raised a good point about a QNE not supporting a particular QOSM, if so, it may not be able to interpret the packet_classifier. The proposal to move the packet_classifier to the QSPEC also seems to contradict the guidance from the interim meeting. IMO I don't see why packet_classifier can't be kept in QoS-NSLP as others have also suggested. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 08:57:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDVx-0005Q2-AH; Wed, 19 Oct 2005 08:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDVu-0005Pf-Tr for nsis@megatron.ietf.org; Wed, 19 Oct 2005 08:57:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14512 for ; Wed, 19 Oct 2005 08:57:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESDhe-0002ZV-Ng for nsis@ietf.org; Wed, 19 Oct 2005 09:09:59 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Oct 2005 05:57:42 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9JCvc94024666; Wed, 19 Oct 2005 05:57:39 -0700 (PDT) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9JD81ZX015481; Wed, 19 Oct 2005 06:08:02 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Date: Wed, 19 Oct 2005 08:57:33 -0400 To: Martin Stiemerling X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=3523; t=1129727284; x=1130159484; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20[NSIS]=20Query=20&=20Diagnosis=20Capabilities=20in=20NATFW=20NSL P| From:David=20R=20Oran=20| Date:Wed,=2019=20Oct=202005=2008=3A57=3A33=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Gl1YGz8wg4pl+P1SRnxJTpuqOa2u6N7/eZyyX87GLoWsnaZKV7YSN2yFF8z5Nh1vRZ+/qyMf gzxOPyKoLFtoK1gtu0Ur0qP/NRbwoM/KmYfNAjy5Svxc9JXBUBq7BfYnu55aG/RISReWp9F2Rbl 1wdvK7BTEuMsti9eZo4kPuZk= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org I've stopped following the protocol details, so excuse me if these are stupid questions. 1. Is there a way (through QUERY or some other machinery) for an NSIS client to say "if I were to ask for a QoS reservation with the following attributes (including QSPEC) to the following destination, would it succeed, and if not, would the failure by due to a) insufficient resources b) policy violation c) something mal-formed 2. Does QUERY follow the same NSIS path as what it is querying about? If so, does the response tell me the path? If not, can I find out what path an NSIS session takes (either current or prospective) so I have the equivalent funcitonality for NSIS routing that I do with traceroute? I've often wished I had such diagnostic capabilities in RSVP. Dave. P.S. I happen to agree on point (b) that building separate state recovery / restart machinery is a bad idea - the protocol should simply work and have clear failure semantics when self-repair fails. On Oct 19, 2005, at 4:39 AM, Martin Stiemerling wrote: > Hi all, > > --On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert" > wrote: > > | hi all, > | > | IIRC there were two aspects of this topic discussed at the > | interim: > | > | a) the availability of the diagnosis/query features in the > | first place, and > | > | b) the use of them to build some procedures for recovery from > | certain error/restart scenarios > | > | I don't recall much discussion of (a). I recall significant > | objections to (b) (indeed, I think I made several of them) > > Yes, you've made those objections :) > > I object to b) as well since recovery from error/restart is > complicated and > fragile. So I see b) as ruled out. > > For case a) I have solicited real use cases for several times - > without any > real response. However, what can a node learn by using a query > capability, > other he can learn by using the already defined mechanisms (error > messages, > NOTIFY messages? (this is not a question to you Robert but others :) > > | because they seemed rather complicated and fragile. > | But that doesn't mean that the facilities themselves are > | not useful for - well - diagnosis (for which it's hard to > | build reasonable scenarios other than "something went wrong > | and I'd like to work out what"). > | > | It is possible to go overboard on diagnostics but I don't > | think we're there yet. > > I see it the same way. Probably, somebody will find an interesting > use case in the future. If so, we can extend the NATFW NSLP later. > > Thanks, > > Martin > > | > | r. > | > |> -----Original Message----- > |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > |> Behalf Of john.loughney@nokia.com > |> Sent: 14 October 2005 08:09 > |> To: stiemerling@netlab.nec.de; nsis@ietf.org > |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP > |> > |> > |> Hi Martin, > |> > |> > Draft -07 of the NATFW NSLP describes a query and diagnosis > |> > capability in Section 3.3.6. These capabilities have been in > |> > the draft for while but no real usage scenarios have been > |> > described so far (see issue 30 in the tracker > |> > ). > |> > > |> > The general feeling of the WG about these query and diagnosis > |> > capabilities were quite mixed (as expressed during the last > |> > interim in Munich). Since then I have not received any further > |> > comments about this issue. > |> > > |> > Personally, I do not see any good use cases for such a > |> > capability in the NATFW NSLP and I'm in favour of removing it > |> > completely. > |> > > |> > I'm soliciting the WG to give feedback on this issue, whether > |> > it is considered a useful feature or not. If you consider it a > |> > useful feature, you should give some use cases. > |> > |> I am leaning towards dropping this feature. I think that this is > |> extra functionality without defined use - this will make the > |> implementatino & usage more difficult. > |> > |> John > |> > |> _______________________________________________ > |> nsis mailing list > |> nsis@ietf.org > |> https://www1.ietf.org/mailman/listinfo/nsis > |> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 09:21:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDt8-0000tt-Dd; Wed, 19 Oct 2005 09:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDt6-0000th-6L for nsis@megatron.ietf.org; Wed, 19 Oct 2005 09:21:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16019 for ; Wed, 19 Oct 2005 09:21:38 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESE4p-0003HV-T8 for nsis@ietf.org; Wed, 19 Oct 2005 09:33:56 -0400 Received: from wrl-40.cs.helsinki.fi (wrl-40.cs.helsinki.fi [128.214.166.160]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 19 Oct 2005 16:21:42 +0300 id 000700CE.43564866.00002C00 Date: Wed, 19 Oct 2005 16:21:41 +0300 (EEST) From: Jukka MJ Manner To: David R Oran Subject: QoS Queries (Was: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP) In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, This is a thread about the NATFW, and you are talking about QoS, but I'm still answering. ;) You can ask that for resources on the exact data path you intend to send your data. The answer you get depends on your QUERY message, but in practise you should get this information in return, yes. Still you raised an interesting point, as I've thought that any authorization is done to see whether you are allowed in general to query for resources. Yet, you might also ask, whether you are allowed to reserve resources in the end. This needs some clarification in our work, Hannes? Currently, you can't trace the route, at least not that I know of. Cheers, Jukka On Wed, 19 Oct 2005, David R Oran wrote: > I've stopped following the protocol details, so excuse me if these are stupid > questions. > > 1. Is there a way (through QUERY or some other machinery) for an NSIS client > to say "if I were to ask for a QoS reservation with the following attributes > (including QSPEC) to the following destination, would it succeed, and if not, > would the failure by due to > a) insufficient resources > b) policy violation > c) something mal-formed > > 2. Does QUERY follow the same NSIS path as what it is querying about? If so, > does the response tell me the path? If not, can I find out what path an NSIS > session takes (either current or prospective) so I have the equivalent > funcitonality for NSIS routing that I do with traceroute? > > I've often wished I had such diagnostic capabilities in RSVP. > > Dave. > > P.S. I happen to agree on point (b) that building separate state recovery / > restart machinery is a bad idea - the protocol should simply work and have > clear failure semantics when self-repair fails. > > > On Oct 19, 2005, at 4:39 AM, Martin Stiemerling wrote: > > > Hi all, > > > > --On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert" > > wrote: > > > > | hi all, > > | > > | IIRC there were two aspects of this topic discussed at the > > | interim: > > | > > | a) the availability of the diagnosis/query features in the > > | first place, and > > | > > | b) the use of them to build some procedures for recovery from > > | certain error/restart scenarios > > | > > | I don't recall much discussion of (a). I recall significant > > | objections to (b) (indeed, I think I made several of them) > > > > Yes, you've made those objections :) > > > > I object to b) as well since recovery from error/restart is complicated and > > fragile. So I see b) as ruled out. > > > > For case a) I have solicited real use cases for several times - without any > > real response. However, what can a node learn by using a query capability, > > other he can learn by using the already defined mechanisms (error messages, > > NOTIFY messages? (this is not a question to you Robert but others :) > > > > | because they seemed rather complicated and fragile. > > | But that doesn't mean that the facilities themselves are > > | not useful for - well - diagnosis (for which it's hard to > > | build reasonable scenarios other than "something went wrong > > | and I'd like to work out what"). > > | > > | It is possible to go overboard on diagnostics but I don't > > | think we're there yet. > > > > I see it the same way. Probably, somebody will find an interesting > > use case in the future. If so, we can extend the NATFW NSLP later. > > > > Thanks, > > > > Martin > > > > | > > | r. > > | > > |> -----Original Message----- > > |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > |> Behalf Of john.loughney@nokia.com > > |> Sent: 14 October 2005 08:09 > > |> To: stiemerling@netlab.nec.de; nsis@ietf.org > > |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP > > |> > > |> > > |> Hi Martin, > > |> > > |> > Draft -07 of the NATFW NSLP describes a query and diagnosis > > |> > capability in Section 3.3.6. These capabilities have been in > > |> > the draft for while but no real usage scenarios have been > > |> > described so far (see issue 30 in the tracker > > |> > ). > > |> > > > |> > The general feeling of the WG about these query and diagnosis > > |> > capabilities were quite mixed (as expressed during the last > > |> > interim in Munich). Since then I have not received any further > > |> > comments about this issue. > > |> > > > |> > Personally, I do not see any good use cases for such a > > |> > capability in the NATFW NSLP and I'm in favour of removing it > > |> > completely. > > |> > > > |> > I'm soliciting the WG to give feedback on this issue, whether > > |> > it is considered a useful feature or not. If you consider it a > > |> > useful feature, you should give some use cases. > > |> > > |> I am leaning towards dropping this feature. I think that this is > > |> extra functionality without defined use - this will make the > > |> implementatino & usage more difficult. > > |> > > |> John > > |> > > |> _______________________________________________ > > |> nsis mailing list > > |> nsis@ietf.org > > |> https://www1.ietf.org/mailman/listinfo/nsis > > |> > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 09:30:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESE1P-0005Wn-8J; Wed, 19 Oct 2005 09:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESE1N-0005VM-Jz for nsis@megatron.ietf.org; Wed, 19 Oct 2005 09:30:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16528 for ; Wed, 19 Oct 2005 09:30:11 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESED7-0003Xr-Jz for nsis@ietf.org; Wed, 19 Oct 2005 09:42:30 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Oct 2005 06:30:12 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9JDU994012014; Wed, 19 Oct 2005 06:30:10 -0700 (PDT) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9JDeUge015770; Wed, 19 Oct 2005 06:40:33 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <932D2DE5-B132-47F6-B372-7C7387F75516@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: QoS Queries (Was: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP) Date: Wed, 19 Oct 2005 09:30:02 -0400 To: Jukka MJ Manner X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=4894; t=1129729235; x=1130161435; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20QoS=20Queries=20(Was=3A=20Re=3A=20[NSIS]=20Query=20&=20Diagnosis =20Capabilities=20in=20NATFW=20NSLP)| From:David=20R=20Oran=20| Date:Wed,=2019=20Oct=202005=2009=3A30=3A02=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=IPvMT0K3F8v5lKiKhf6a9Yrj41j6zNudxEEQdWuVw85AB8gq+cLNPYr8YKSkj1CrETlPshvB XUD+IlkyJgBgFQa6CaS5YG70cBEIiu4SBTCym9priXPEzE/YCSB1eJCyQL5pt+Am+owJ4o06LsC 4Sr/Y5vlzQuHYsAFpUa32aAc= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org On Oct 19, 2005, at 9:21 AM, Jukka MJ Manner wrote: > > Hi, > > This is a thread about the NATFW, and you are talking about QoS, > but I'm > still answering. ;) > S Sorry - I keep pretending that general-purpose functions are actually in a general-purpose part of the NSIS protocol suite :-) > You can ask that for resources on the exact data path you intend to > send > your data. The answer you get depends on your QUERY message, but in > practise you should get this information in return, yes. Still you > raised > an interesting point, as I've thought that any authorization is > done to > see whether you are allowed in general to query for resources. Yet, > you > might also ask, whether you are allowed to reserve resources in the > end. Yes, ditto for NAT/FW mappings, so you did a good job of correctly realizing my question, though framed in terms of QoS, could just as easily been framed in terms of NAT/FW. > This needs some clarification in our work, Hannes? > > Currently, you can't trace the route, at least not that I know of. > I'm interested in whether other folks think this is important, as I do. Thanks, Dave. > Cheers, > Jukka > > On Wed, 19 Oct 2005, David R Oran wrote: > > >> I've stopped following the protocol details, so excuse me if >> these are stupid >> questions. >> >> 1. Is there a way (through QUERY or some other machinery) for an >> NSIS client >> to say "if I were to ask for a QoS reservation with the following >> attributes >> (including QSPEC) to the following destination, would it succeed, >> and if not, >> would the failure by due to >> a) insufficient resources >> b) policy violation >> c) something mal-formed >> >> 2. Does QUERY follow the same NSIS path as what it is querying >> about? If so, >> does the response tell me the path? If not, can I find out what >> path an NSIS >> session takes (either current or prospective) so I have the >> equivalent >> funcitonality for NSIS routing that I do with traceroute? >> >> I've often wished I had such diagnostic capabilities in RSVP. >> >> Dave. >> >> P.S. I happen to agree on point (b) that building separate state >> recovery / >> restart machinery is a bad idea - the protocol should simply work >> and have >> clear failure semantics when self-repair fails. >> >> >> On Oct 19, 2005, at 4:39 AM, Martin Stiemerling wrote: >> >> >>> Hi all, >>> >>> --On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert" >>> wrote: >>> >>> | hi all, >>> | >>> | IIRC there were two aspects of this topic discussed at the >>> | interim: >>> | >>> | a) the availability of the diagnosis/query features in the >>> | first place, and >>> | >>> | b) the use of them to build some procedures for recovery from >>> | certain error/restart scenarios >>> | >>> | I don't recall much discussion of (a). I recall significant >>> | objections to (b) (indeed, I think I made several of them) >>> >>> Yes, you've made those objections :) >>> >>> I object to b) as well since recovery from error/restart is >>> complicated and >>> fragile. So I see b) as ruled out. >>> >>> For case a) I have solicited real use cases for several times - >>> without any >>> real response. However, what can a node learn by using a query >>> capability, >>> other he can learn by using the already defined mechanisms (error >>> messages, >>> NOTIFY messages? (this is not a question to you Robert but others :) >>> >>> | because they seemed rather complicated and fragile. >>> | But that doesn't mean that the facilities themselves are >>> | not useful for - well - diagnosis (for which it's hard to >>> | build reasonable scenarios other than "something went wrong >>> | and I'd like to work out what"). >>> | >>> | It is possible to go overboard on diagnostics but I don't >>> | think we're there yet. >>> >>> I see it the same way. Probably, somebody will find an interesting >>> use case in the future. If so, we can extend the NATFW NSLP later. >>> >>> Thanks, >>> >>> Martin >>> >>> | >>> | r. >>> | >>> |> -----Original Message----- >>> |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>> |> Behalf Of john.loughney@nokia.com >>> |> Sent: 14 October 2005 08:09 >>> |> To: stiemerling@netlab.nec.de; nsis@ietf.org >>> |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP >>> |> >>> |> >>> |> Hi Martin, >>> |> >>> |> > Draft -07 of the NATFW NSLP describes a query and diagnosis >>> |> > capability in Section 3.3.6. These capabilities have been in >>> |> > the draft for while but no real usage scenarios have been >>> |> > described so far (see issue 30 in the tracker >>> |> > ). >>> |> > >>> |> > The general feeling of the WG about these query and diagnosis >>> |> > capabilities were quite mixed (as expressed during the last >>> |> > interim in Munich). Since then I have not received any further >>> |> > comments about this issue. >>> |> > >>> |> > Personally, I do not see any good use cases for such a >>> |> > capability in the NATFW NSLP and I'm in favour of removing it >>> |> > completely. >>> |> > >>> |> > I'm soliciting the WG to give feedback on this issue, whether >>> |> > it is considered a useful feature or not. If you consider it a >>> |> > useful feature, you should give some use cases. >>> |> >>> |> I am leaning towards dropping this feature. I think that this is >>> |> extra functionality without defined use - this will make the >>> |> implementatino & usage more difficult. >>> |> >>> |> John >>> |> >>> |> _______________________________________________ >>> |> nsis mailing list >>> |> nsis@ietf.org >>> |> https://www1.ietf.org/mailman/listinfo/nsis >>> |> >>> >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 11:28:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESFrg-0002cc-8K; Wed, 19 Oct 2005 11:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESFre-0002aV-Lg for nsis@megatron.ietf.org; Wed, 19 Oct 2005 11:28:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23019 for ; Wed, 19 Oct 2005 11:28:18 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESG3P-0006kh-2d for nsis@ietf.org; Wed, 19 Oct 2005 11:40:36 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9JFS1WA013199; Wed, 19 Oct 2005 16:28:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VGTHX0C1; Wed, 19 Oct 2005 16:32:27 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST Date: Wed, 19 Oct 2005 16:27:59 +0100 Message-ID: <003001c5d4c1$b04f97b0$0302a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXUwk+1DnePmJddRpuQRBM/q4R5ow== From: "Hancock, Robert" To: "Xiaoming Fu" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0906540336==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0906540336== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D4C2.4F5A7780" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D4C2.4F5A7780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, another level of '>' ;-) [snip] > i think this is viable way. > >=20 > > > - two neighboring GIST peers are multihoming. This may be > > > related to how > > > to represent multiple IP address pairs in the MA entry=20 > (or just the > > > "node identifier" of its peer), in connection with SCTP > > > association/chunk relationship. > >=20 > > true, but (if you want to) this is already the case even with TCP > > as a transport for the messaging associations. the way that routing > > state is bound to messaging associations causes a new association > > to be set up for each address pair (this is a consequence of the > > state matching rules), BUT if nodes can determine that they are > > peering over multiple associations they can use a single one and > > discard the rest. >=20 > in the case of sctp, it is clear a given gist pair can have up to one=20 > sctp association, per rfc2960. why? 2960 says you can only have one sctp association between a pair of transport endpoints. but a GIST node can have lots of transport endpoints (for example, a different sctp port gives you a different transport endpoint, and i assume that outbound connections come from different source ports. maybe i'm muddled here...) > >=20 > > it may be that more text could be written (probably implementation > > guidance) about how this can be done. but i would not tie together > > the facts that multiple address pairs for routing state are relevant > > between multi-interface nodes and that SCTP can support multiple > > address pairs. indeed, even in the non-multi-homed case, the IP > > peer addresses used in the routing state do not need to be closely > > tied to the IP addresses used by the transport layer protocol for > > the messaging association (they are tied together by cookie > > matching, not address matching). so i certainly would not try to > > bind the two together in the multi-homed case. > maybe i am a bit puzzled here - yes a cookie requires to be=20 > repeated in=20 > the query-response, but the problem here is a mrs is required to=20 > identify the right identities of its upstream and downstream=20 > peer. which=20 > identify should be relied on? in the current world likely=20 > will still be=20 > ip address i guess. i guess which identity is used in an implementation depends on=20 whether the implementor reads the spec or not. the spec says do=20 matching on the cookie (at least, it's supposed to). are you saying that the spec should be changed to do matching on the ip address instead? cheers, robert h. ------_=_NextPart_001_01C5D4C2.4F5A7780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] new draft "GIST over SCTP" and some comments = to GIST

hi,

another level of '>' ;-)

[snip]
> i think this is viable way.
> >
> >  > - two neighboring GIST peers are = multihoming. This may be
> >  > related to how
> >  > to represent multiple IP address = pairs in the MA entry
> (or just the
> >  > "node identifier" of = its peer), in connection with SCTP
> >  > association/chunk = relationship.
> >
> > true, but (if you want to) this is already = the case even with TCP
> > as a transport for the messaging = associations. the way that routing
> > state is bound to messaging associations = causes a new association
> > to be set up for each address pair (this is = a consequence of the
> > state matching rules), BUT if nodes can = determine that they are
> > peering over multiple associations they can = use a single one and
> > discard the rest.
>
> in the case of sctp, it is clear a given gist = pair can have up to one
> sctp association, per rfc2960.

why? 2960 says you can only have one sctp association = between a pair
of transport endpoints. but a GIST node can have lots = of transport
endpoints (for example, a different sctp port gives = you a different
transport endpoint, and i assume that outbound = connections come from
different source ports. maybe i'm muddled = here...)

> >
> > it may be that more text could be written = (probably implementation
> > guidance) about how this can be done. but i = would not tie together
> > the facts that multiple address pairs for = routing state are relevant
> > between multi-interface nodes and that SCTP = can support multiple
> > address pairs. indeed, even in the = non-multi-homed case, the IP
> > peer addresses used in the routing state do = not need to be closely
> > tied to the IP addresses used by the = transport layer protocol for
> > the messaging association (they are tied = together by cookie
> > matching, not address matching). so i = certainly would not try to
> > bind the two together in the multi-homed = case.
> maybe i am a bit puzzled here - yes a cookie = requires to be
> repeated in
> the query-response, but the problem here is a = mrs is required to
> identify the right identities of its upstream = and downstream
> peer. which
> identify should be relied on? in the current = world likely
> will still be
> ip address i guess.

i guess which identity is used in an implementation = depends on
whether the implementor reads the spec or not. the = spec says do
matching on the cookie (at least, it's supposed to). = are you saying
that the spec should be changed to do matching on the = ip address
instead?

cheers,

robert h.

------_=_NextPart_001_01C5D4C2.4F5A7780-- --===============0906540336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0906540336==-- From nsis-bounces@ietf.org Wed Oct 19 16:48:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKrm-000472-SG; Wed, 19 Oct 2005 16:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKrl-00044r-7G for nsis@megatron.ietf.org; Wed, 19 Oct 2005 16:48:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02521 for ; Wed, 19 Oct 2005 16:48:44 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESL3Y-00072P-3Q for nsis@ietf.org; Wed, 19 Oct 2005 17:01:05 -0400 Received: from win2003.dickmann2003.home (p548A51CC.dip.t-dialin.net [84.138.81.204]) by www.difra-computer.de (Postfix) with ESMTP id 833073E402B for ; Wed, 19 Oct 2005 22:55:07 +0200 (CEST) Received: from dickmann.homeunix.org ([192.168.0.5]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Oct 2005 22:40:09 +0200 MIME-Version: 1.0 Date: Wed, 19 Oct 2005 22:44:41 +0200 From: Christian Dickmann To: nsis@ietf.org Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST In-Reply-To: 003001c5d4c1$b04f97b0$0302a8c0@comm.ad.roke.co.uk Message-ID: X-Sender: mail@christian-dickmann.de User-Agent: RoundCube Webmail/0.1a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2005 20:40:09.0775 (UTC) FILETIME=[4C065BF0:01C5D4ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, > i guess which identity is used in an implementation depends on > whether the implementor reads the spec or not. the spec says do > matching on the cookie (at least, it's supposed to). are you saying > that the spec should be changed to do matching on the ip address > instead? I think I do not understand your discussion. So what I am saying in this mail might be out of context, but this is at least a question to me: In a multi-homing scenario, which means, that one GIST node has multiple addresses, the node has to choose which IP address should be used in the NLI. Chapter 4.4.2 of GIST draft 08 states: "Association re-use is controlled by the Network-Layer-Information (NLI) object ... The NLI object includes: Peer-Identity: ... Interface-Address: ... " This section talks about when MAs can be re-used and it says that a match of Peer-Identity is not enough. "These should be rare events, so the expense of a new association setup is acceptable." So in a multihoming scenario there might be one association for every link of the multihomed node. Maybe you explain this scenario when you say: "If the authenticated peer identities match after association setup, the two Interface-Addresses MAY be bound to the association." But I do not get what you mean. Of course, this is not a SCTP related issue, but in the case of TCP it might be a bad thing to re-use the connection, as the choice of the NLI address might be intentional to do load-sharing at the multihomed node and this load-sharing would not be possible in TCP. Instead in a real multihoming supporting transport protocol re-use might be a good thing here. I hope I am not too confused right now. Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 19 18:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMGi-0007LV-4Z; Wed, 19 Oct 2005 18:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMGf-0007KS-Iv for nsis@megatron.ietf.org; Wed, 19 Oct 2005 18:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08342 for ; Wed, 19 Oct 2005 18:18:32 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESMST-0001WH-Cj for nsis@ietf.org; Wed, 19 Oct 2005 18:30:54 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9JMI8WA011309; Wed, 19 Oct 2005 23:18:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VGTHX0D5; Wed, 19 Oct 2005 23:22:26 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST Date: Wed, 19 Oct 2005 23:17:57 +0100 Message-ID: <004b01c5d4fa$f58ce010$0302a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXU+5Y+kO8tJ0dgRnCXhit6lLwEKA== From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0785426489==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0785426489== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D4FB.957FFD00" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D4FB.957FFD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi christian, my basic point was that if people implement GIST by doing identity matching of MAs to flow states by IP address comparison, rather than by cookie comparison, they are not following what the spec says (even if IP address comparison is a common=20 technique today). But your follow up questions are (as I might expect) very reasonable. More inline: > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Christian Dickmann > Sent: 19 October 2005 21:45 > To: nsis@ietf.org > Subject: RE: [NSIS] new draft "GIST over SCTP" and some=20 > comments to GIST >=20 >=20 > Hi Robert, >=20 > > i guess which identity is used in an implementation depends on=20 > > whether the implementor reads the spec or not. the spec says do=20 > > matching on the cookie (at least, it's supposed to). are you saying=20 > > that the spec should be changed to do matching on the ip address=20 > > instead?=20 >=20 > I think I do not understand your discussion. So what I am saying in=20 > this mail might be out of context, but this is at least a question=20 > to me: >=20 > In a multi-homing scenario, which means, that one GIST node has=20 > multiple addresses, the node has to choose which IP address should be > used in the NLI.=20 > Chapter 4.4.2 of GIST draft 08 states:=20 > "Association re-use is controlled by the Network-Layer-Information > (NLI) object ... > The NLI object includes: > Peer-Identity: ... > Interface-Address: ... " >=20 > This section talks about when MAs can be re-used and it says that=20 > a match of Peer-Identity is not enough.=20 > "These should be rare events, so the expense of a new association=20 > setup is acceptable." >=20 > So in a multihoming scenario there might be one association for every > link of the multihomed node. Right. Indeed, if you have a node with N interfaces peering with a=20 node with M interfaces, and there are flows traversing every possible=20 interface pair (which is an extremely pathological case, but anyway...) there could be be N*M MAs between them.=20 However, the more expected case (I think) would be that even a=20 multihomed node would have a relatively small number of peers out of any single interface, especially if those peers are 'nearby'. >=20 > Maybe you explain this scenario when you say: > "If the authenticated peer identities match after association setup,=20 > the two Interface-Addresses MAY be bound to the association." > But I do not get what you mean.=20 The intention of saying this is: the usual rule is that messages for an MRI can only be sent over an MA which was set up using a Q/R/C=20 handshake for that same MRI. However, if you know two MAs originate from the same peer (because of MA authentication), then you can use them interchangeably. (This may be a case of premature optimisation. I'd be interested to hear views on that. It might also be reasonable to be more restrictive, and say that you have to retain all the MAs, even though you know some of them are redundant.) >=20 > Of course, this is not a SCTP related issue, but in the case=20 > of TCP it=20 > might be a bad thing to re-use the connection, as the choice=20 > of the NLI=20 > address might be intentional to do load-sharing at the=20 > multihomed node=20 > and this load-sharing would not be possible in TCP. That is also a possible view. Note that it doesn't apply to the NLI selection by the Querying node (this is found directly and deterministically from the flow routing), but a Responding node could do some sort of load sharing by NLI selection. But OTOH, you could also make a case for saying that it is good for the NLI selection by the responding node to be tied to the flow=20 routing, from a fate sharing argument. I think this sort of=20 discussion could be good material for an implementors guide; I'm not sure how much it has to be pinned down in the GIST spec itself. =20 > Instead in a real=20 > multihoming supporting transport protocol re-use might be a good thing > here. >=20 > I hope I am not too confused right now. I don't think you are :-) [or at least, it's not your fault.] robert h. >=20 > Christian Dickmann >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C5D4FB.957FFD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] new draft "GIST over SCTP" and some comments = to GIST

hi christian,

my basic point was that if people implement GIST by = doing
identity matching of MAs to flow states by IP address = comparison,
rather than by cookie comparison, they are not = following what
the spec says (even if IP address comparison is a = common
technique today). But your follow up questions are = (as
I might expect) very reasonable. More inline:

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of Christian Dickmann
> Sent: 19 October 2005 21:45
> To: nsis@ietf.org
> Subject: RE: [NSIS] new draft "GIST over = SCTP" and some
> comments to GIST
>
>
> Hi Robert,
>
> > i guess which identity is used in an = implementation depends on
> > whether the implementor reads the spec or = not. the spec says do
> > matching on the cookie (at least, it's = supposed to). are you saying
> > that the spec should be changed to do = matching on the ip address
> > instead?
>
> I think I do not understand your discussion. So = what I am saying in
> this mail might be out of context, but this is = at least a question
> to me:
>
> In a multi-homing scenario, which means, that = one GIST node has
> multiple addresses, the node has to choose which = IP address should be
> used in the NLI.
> Chapter 4.4.2 of GIST draft 08 states:
> "Association re-use is controlled by the = Network-Layer-Information
>    (NLI) object ...
> The NLI object includes:
> Peer-Identity: ...
> Interface-Address: ... "
>
> This section talks about when MAs can be re-used = and it says that
> a match of Peer-Identity is not enough.
> "These should be rare events, so the = expense of a new association
> setup is acceptable."
>
> So in a multihoming scenario there might be one = association for every
> link of the multihomed node.

Right. Indeed, if you have a node with N interfaces = peering with a
node with M interfaces, and there are flows = traversing every possible
interface pair (which is an extremely pathological = case, but anyway...)
there could be be N*M MAs between them.

However, the more expected case (I think) would be = that even a
multihomed node would have a relatively small number = of peers out of
any single interface, especially if those peers are = 'nearby'.

>
> Maybe you explain this scenario when you = say:
> "If the authenticated peer identities match = after association setup,
> the two Interface-Addresses MAY be bound to the = association."
> But I do not get what you mean.

The intention of saying this is: the usual rule is = that messages for
an MRI can only be sent over an MA which was set up = using a Q/R/C
handshake for that same MRI. However, if you know two = MAs originate
from the same peer (because of MA authentication), = then you can use
them interchangeably. (This may be a case of = premature optimisation.
I'd be interested to hear views on that. It might = also be reasonable
to be more restrictive, and say that you have to = retain all the MAs,
even though you know some of them are = redundant.)

>
> Of course, this is not a SCTP related issue, but = in the case
> of TCP it
> might be a bad thing to re-use the connection, = as the choice
> of the NLI
> address might be intentional to do load-sharing = at the
> multihomed node
> and this load-sharing would not be possible in = TCP.

That is also a possible view. Note that it doesn't = apply to the
NLI selection by the Querying node (this is found = directly and
deterministically from the flow routing), but a = Responding node
could do some sort of load sharing by NLI selection. = But OTOH,
you could also make a case for saying that it is good = for the
NLI selection by the responding node to be tied to = the flow
routing, from a fate sharing argument. I think this = sort of
discussion could be good material for an implementors = guide;
I'm not sure how much it has to be pinned down in the = GIST
spec itself.
 
> Instead in a real
> multihoming supporting transport protocol re-use = might be a good thing
> here.
>
> I hope I am not too confused right now.

I don't think you are :-)
[or at least, it's not your fault.]

robert h.

>
> Christian Dickmann
>
>
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C5D4FB.957FFD00-- --===============0785426489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0785426489==-- From nsis-bounces@ietf.org Thu Oct 20 01:10:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESSgj-0001tB-Vp; Thu, 20 Oct 2005 01:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESSgi-0001qW-3C for nsis@megatron.ietf.org; Thu, 20 Oct 2005 01:10:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11110 for ; Thu, 20 Oct 2005 01:09:50 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESSsa-0000Au-8H for nsis@ietf.org; Thu, 20 Oct 2005 01:22:16 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j9K59pgi024689; Thu, 20 Oct 2005 07:09:51 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j9K59p5B004928; Thu, 20 Oct 2005 07:09:51 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j9K59or27326; Thu, 20 Oct 2005 07:09:50 +0200 (MEST) Date: Thu, 20 Oct 2005 07:09:50 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: gash@att.com, nsis@ietf.org Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 20 Oct 2005 05:09:50 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA94C0@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.383 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 20 Oct 2005 07:09:53 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry Please see in line! On 10/19/2005, "Ash, Gerald R (Jerry), ALABS" wrote: >Hi Georgios, All, > >> From the discussion that we have had in the NSIS mailing list, one can >> deduce that the PACKET_CLASSIFIER object cannot be carried as a pure >> QOS-NSLP object. The reason is that this will not work when QSPEC >> stacking is used. >> There are two solutions that one can apply: >> * Local configuration by each node, where the filters will be >> pre-configured by each QoS model >> >> * signaling using QSPEC; PACKET CLASSIFIER will be a QSPEC parameter! > >There is another solution. If separate packet_classifier's are needed >for each of 2 QSPECs, then the packet-classifiers can be stacked in >QoS-NSLP just as we agreed that separate QSPECs (and their lengths) can >be stacked in QoS-NSLP. Georgios: Yes, I agree that this solution can also be used. But if we will use this solution then all the QoS-NSLP stacking functionality used for QSPEC processing will also have to be used for Packet classifier processing! This is not efficient, increases the proibability of errors and the complexity of the QoS-NSLP protocol If the packet classifier will be included in the QSPEC then neither the complexity of the QOS-NSLP protocol nor the complexity of the QSPEC functionality is increased. When we will use one packet classifier parameter per QSPEC, then this parameter is just another QSPEC parameter. >(BTW, it doesn't appear that there is consensus that separate >classifiers would be needed for 2 QSPECs, however.) Georgios: Well, I thought that there is a consensus that there is a problem when one session will have to provide signaling to at least two QoS models in an end to end path, where one of these QoS models goes end to end and the other is applied locally. We cannot deny the problem, because otherwise, the NSIS solution of stacking two QSPECS will be useless! >> From what I have understood, most of the participants in the >> discussion would prefer the signaling using QSPEC solution! >> >> Is this accepted by the NSIS WG? > >I re-read the thread and it appears that Robert, John, Cornelia, and >others support keeping the packet_classifier in QoS-NSLP. =20 Georgios: Well, somehow they probably do not want to continue the discussion! We cannot deny the problem now and realize after one year that indeed we had to solve the problem one year earlier! Please note that Jukka is very much in favour of moving the packet classifier parameter into QSPEC! > Cheng Hong >also favored to put the packet_classifier in QoS-NSLP >http://www1.ietf.org/mail-archive/web/nsis/current/msg05481.html. =20 > He >raised a good point about a QNE not supporting a particular QOSM, if so, >it may not be able to interpret the packet_classifier. =20 Georgios: But this is an error situation that must not occur! This is because each Qos model MUST be able to use a different filter/packet classifier than some other QoS model, in an end to end path. Please understand that filtering and packet classification is a QOS model dependend functionality. Some other arguments against the proposal of including the packet classifier parameter into the QSPEC, where related to firewall traversal issues! If we include the packet classifier parameter into the QSPEC then this problem will not occur, since the packet classifier parameter will just be another parameter of the QSPEC object! Thus based on this, the packet classifier should be included in the QSPEC. > The proposal to >move the packet_classifier to the QSPEC also seems to contradict the >guidance from the interim meeting. Georgios: During the NSIS interim meeting no one brought this problem on the table! We cannot deny the problem now and realize after one year that indeed we had to solve the problem one year earlier! >IMO I don't see why packet_classifier can't be kept in QoS-NSLP as >others have also suggested. Georgios: please see above! >Thanks, >Regards, >Jerry > >_______________________________________________ >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 nsis-bounces@ietf.org Thu Oct 20 03:30:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUsN-0005Rg-2q; Thu, 20 Oct 2005 03:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUsL-0005Lx-EU for nsis@megatron.ietf.org; Thu, 20 Oct 2005 03:30:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21371 for ; Thu, 20 Oct 2005 03:29:59 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+gF4In3vKHB9GKWbRGiElYgxlNFvb/hAc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESV4D-0005RN-2Z for nsis@ietf.org; Thu, 20 Oct 2005 03:42:27 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ESUsB-0004du-LO; Thu, 20 Oct 2005 09:30:04 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3685DB27C; Thu, 20 Oct 2005 09:29:59 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ESUsA-0000NL-Vg; Thu, 20 Oct 2005 09:29:59 +0200 Message-ID: <43574776.8000108@tm.uka.de> Date: Thu, 20 Oct 2005 09:29:58 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: QoS Queries (Was: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP) References: <932D2DE5-B132-47F6-B372-7C7387F75516@cisco.com> In-Reply-To: <932D2DE5-B132-47F6-B372-7C7387F75516@cisco.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Jukka MJ Manner , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Dave, > Sorry - I keep pretending that general-purpose functions are actually > in a general-purpose part of the NSIS protocol suite :-) Unfortunately, no. That would be a candidate for common NSLP functionality, but we don't have a separate layer for that. >> Currently, you can't trace the route, at least not that I know of. >> > I'm interested in whether other folks think this is important, as I do. >From my experience it would be important at least for error diagnosis purposes. IIRC we discussed this a little at the interim meeting in Munich in the context of the GIST ping-tool, that is more like a traceroute NSLP. A problem using a separate NSLP instance for traceroute functionality is that the actual NSLP node set on the path may be slightly different for the ping/traceroute and the actually used QoS or NAT/FW NSLP. Nevertheless, I think it's helpful to know something about the (nodes on the) path at least in case of errors. That's why I requested some time ago to add something like an Error Source Identifier in NSLPs so that you may at least know where the failure occured. Having this, maybe we could easily mimic a tracroute functionality: GIST has a GHC (GIST Hop Count). If it is decremented to zero GIST will report an error to the sender. I'm not sure about the currently defined interaction of GIST with NSLP in this case, but I think it would be useful to let GIST report that error also to the NSLP via a MessageStatus API call (Robert?). That in turn could generate an NSLP error message that is propagated back towards the originator of the QUERY/RESERVE etc. Opinions? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 20 04:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVpS-0007Zm-K7; Thu, 20 Oct 2005 04:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVpQ-0007ZH-8u for nsis@megatron.ietf.org; Thu, 20 Oct 2005 04:31:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24417 for ; Thu, 20 Oct 2005 04:31:01 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESW1F-0007cn-3m for nsis@ietf.org; Thu, 20 Oct 2005 04:43:30 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1ESVoq-0000aJ-JQ; Thu, 20 Oct 2005 09:30:36 +0100 Message-ID: <43575607.5090808@dial.pipex.com> Date: Thu, 20 Oct 2005 09:32:07 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, all. Martin Stiemerling wrote: > Hi all, > > --On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert" > wrote: > > | hi all, > | > | IIRC there were two aspects of this topic discussed at the > | interim: > | > | a) the availability of the diagnosis/query features in the > | first place, and > | > | b) the use of them to build some procedures for recovery from > | certain error/restart scenarios > | > | I don't recall much discussion of (a). I recall significant > | objections to (b) (indeed, I think I made several of them) > > Yes, you've made those objections :) > > I object to b) as well since recovery from error/restart is > complicated and > fragile. So I see b) as ruled out. I agree that the recovery from error/restart is unlikely to be really useful. The chances of the node retaining enough information across a problem event for this mechanism to be useful is just too low. > > For case a) I have solicited real use cases for several times - > without any > real response. However, what can a node learn by using a query > capability, > other he can learn by using the already defined mechanisms (error > messages, > NOTIFY messages? (this is not a question to you Robert but others :) HOWEVER, I do see a case for a very limited query mechanism which would be able to report just the identities of NSLP nodes active on a session path. With this information, a management system (for example) would be able to make more specific queries about the session. Without it, the management system has no idea (or at least a very complex problem) of how to obtain and correlate information relating to a session - I believe this issue was discussed some time ago but in a more general context. It is a common problem for all path directed mecahnisms. A query message for NATFW NSLP specifically would be able to return the sequnce of device types (NAT or FW or combined) plus addressing information for the node (in the case of a NAT public and private sides). This is a strictly limited set of information which does not need to worry about how rules are formulated. It is simple to specify and gives the substrate on which more complex queries could be built using other (targeted) protocols. I suspect a similar query mechanism for QoS NSLP would also be useful. There would be some possible security issues. Would a remote node wish to give away its address, or even its existence? Nodes should (I guess) be able to 'pass' on the message - forward it without filling in information - and scope mechanisms might apply so that the message is turned round at the edge of a domain. I think it has to be at the NSLP level because of the specificity of sessions. > > | because they seemed rather complicated and fragile. > | But that doesn't mean that the facilities themselves are > | not useful for - well - diagnosis (for which it's hard to > | build reasonable scenarios other than "something went wrong > | and I'd like to work out what"). > | > | It is possible to go overboard on diagnostics but I don't > | think we're there yet. > > I see it the same way. Probably, somebody will find an interesting > use case in the future. If so, we can extend the NATFW NSLP later. > > Thanks, > > Martin > > | > | r. > | > |> -----Original Message----- > |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > |> Behalf Of john.loughney@nokia.com > |> Sent: 14 October 2005 08:09 > |> To: stiemerling@netlab.nec.de; nsis@ietf.org > |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP > |> > |> > |> Hi Martin, > |> > |> > Draft -07 of the NATFW NSLP describes a query and diagnosis > |> > capability in Section 3.3.6. These capabilities have been in > |> > the draft for while but no real usage scenarios have been > |> > described so far (see issue 30 in the tracker > |> > ). > |> > > |> > The general feeling of the WG about these query and diagnosis > |> > capabilities were quite mixed (as expressed during the last > |> > interim in Munich). Since then I have not received any further > |> > comments about this issue. > |> > > |> > Personally, I do not see any good use cases for such a > |> > capability in the NATFW NSLP and I'm in favour of removing it > |> > completely. > |> > > |> > I'm soliciting the WG to give feedback on this issue, whether > |> > it is considered a useful feature or not. If you consider it a > |> > useful feature, you should give some use cases. > |> > |> I am leaning towards dropping this feature. I think that this is > |> extra functionality without defined use - this will make the > |> implementatino & usage more difficult. > |> > |> John > |> > |> _______________________________________________ > |> nsis mailing list > |> nsis@ietf.org > |> https://www1.ietf.org/mailman/listinfo/nsis > |> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 20 12:57:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdjq-0006Ff-2r; Thu, 20 Oct 2005 12:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdjm-0006Fa-DV for nsis@megatron.ietf.org; Thu, 20 Oct 2005 12:57:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29781 for ; Thu, 20 Oct 2005 12:57:44 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESdvi-0000hB-3C for nsis@ietf.org; Thu, 20 Oct 2005 13:10:17 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1129826501!8863550!51 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 18218 invoked from network); 20 Oct 2005 16:57:38 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-2.tower-120.messagelabs.com with SMTP; 20 Oct 2005 16:57:38 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4351BDFD0035D1EF; Thu, 20 Oct 2005 12:57:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2005 11:57:37 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA94DE@KCCLUST06EVS1.ugd.att.com> Thread-Topic: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXUnrliFwFOeQbqSP+9ZDKXsp1cRgADJzYgADpfaMA= From: "Ash, Gerald R \(Jerry\), ALABS" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi All, =20 RE Robert's and John's postings on this thread: http://www1.ietf.org/mail-archive/web/nsis/current/msg05479.html http://www1.ietf.org/mail-archive/web/nsis/current/msg05486.html "whether this data should be in the qos-nslp or qspec is less clear to me. The concept in my head has always been that the qos-nslp carried everything about *what* resource reservation action you wanted to carry out, and the qspec was about how much "stuff" you actually wanted to reserve. the packet classifier needs to be given in every message about a transaction, whereas the "how much" information only in some; and the classifier can probably be universal, whereas the qspec need not be. I don't=20 see why having it in the qos-nslp is hard." I think this is the right way to think about where to put the packet_classifier. I agree with John and Robert that the packet_classifier fits more into qos-nslp and "what" resource reservation action is signaled rather than "how much stuff" is signaled using QSPEC. In particular, according to the NSIS framework http://ietf.org/rfc/rfc4080.txt: "A flow is defined by a packet classifier (in the simplest cases, just the destination address and topological origin are needed). In general we assume that when discussing only the data flow path, we only need to consider 'simple' fixed classifiers (e.g., IPv4 5-tuple or equivalent)." It seems to me that since packet_classifier identifies the flow, that information relates to the "what" you are signaling (i.e., identifying the flow) and not to the "how much stuff" (bandwidth, etc.) associated with the flow. How does an RMF identify a flow to populate the packet_classifier? Also, there are complexities in changing packet_classifiers for a flow identified in the NSIS framework. Again quoting from the NSIS framework: "However, for some more complex scenarios (especially mobility and multihoming related ones; see [1] and the mobility discussion of [5]), it is desirable to update the flow:session mapping during the session lifetime. For example, a new flow can be added, and the old one deleted (and maybe in that order, for a 'make-before-break' handover), effectively transferring the network control state between data flows to keep it associated with the same session. Such updates are best managed by the end systems (generally, systems that understand the flow:session mapping and are aware of the packet classifier change). To enable this, it must be possible to relate signaling messages to sessions as well as to data flows. A session identifier (Section 4.6.2) is one component of the solution. ... Note that the crossover router discovery may involve end-to-end signaling exchanges (especially for flows towards the mobile or multihomed node), which raises a latency concern. On the other hand, end-to-end signaling will have been necessary in any case, at the application level not only to communicate changed addresses, but also to update packet classifiers along the path. It is a matter for further analysis to decide how these exchanges could be combined or carried out in parallel. On the shared part of the path, signaling is needed at least to update the packet classifiers to include the new flow, although if correlation with the existing flow is possible it should be possible to bypass any policy or admission control processing. State installation on the new path (and possibly release on the old one are also required. Which entity (one of the end hosts or the crossover router) controls all these procedures depends on which entities are authorized to carry out network state manipulations, so this is therefore a matter of signaling application and NSLP design. The approach may depend on the sender/receiver orientation of the original signaling (see Section 3.3.1). In addition, in the mobility case, the old path may no longer be directly accessible to the mobile node; inter-access-router communication may be required to release state in these circumstances." IMO it isn't possible for the RMF to do these functions/manipulations with the packet_classifier. If it is possible, please clarify how. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 02:59:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESqsI-0006BP-0X; Fri, 21 Oct 2005 02:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESqsF-000614-QH for nsis@megatron.ietf.org; Fri, 21 Oct 2005 02:59:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01643 for ; Fri, 21 Oct 2005 02:59:21 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESr4K-0004Bj-N0 for nsis@ietf.org; Fri, 21 Oct 2005 03:12:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9L6vD5x005509; Fri, 21 Oct 2005 09:57:19 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 09:59:26 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 09:59:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST Date: Fri, 21 Oct 2005 09:59:25 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289BE1@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXU+5Y+kO8tJ0dgRnCXhit6lLwEKABEOS/Q To: , , X-OriginalArrivalTime: 21 Oct 2005 06:59:26.0622 (UTC) FILETIME=[F9A503E0:01C5D60C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, =20 Just adding some comments - hopefully not mudding the waters: =20 > This section talks about when MAs can be re-used and it says that=20 > a match of Peer-Identity is not enough.=20 > "These should be rare events, so the expense of a new association=20 > setup is acceptable."=20 >=20 > So in a multihoming scenario there might be one association for every=20 > link of the multihomed node.=20 Right. Indeed, if you have a node with N interfaces peering with a=20 node with M interfaces, and there are flows traversing every possible=20 interface pair (which is an extremely pathological case, but anyway...)=20 there could be be N*M MAs between them.=20 However, the more expected case (I think) would be that even a=20 multihomed node would have a relatively small number of peers out of=20 any single interface, especially if those peers are 'nearby'. =20 I agree. I think that there some attention will need to be paid how this is configured or setup. Just plugging things in and not paying attention to how things are setup or configured will cause problems with UDP & TCP. I guess some additional considerations will need to be paid when running SCTP with respect how you interconnect multiple (multihomed) nodes together. John=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 03:09:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESr1x-0004s3-Eq; Fri, 21 Oct 2005 03:09:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESr1v-0004rh-Bq for nsis@megatron.ietf.org; Fri, 21 Oct 2005 03:09:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02254 for ; Fri, 21 Oct 2005 03:09:20 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESrE0-0004XR-VL for nsis@ietf.org; Fri, 21 Oct 2005 03:22:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9L75lab000481; Fri, 21 Oct 2005 10:05:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 10:09:18 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 10:09:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] RE: PACKET_CLASSIFIER in QSPEC Date: Fri, 21 Oct 2005 10:09:16 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289BF6@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXToGJTon92RGZOS1mLx3tbGpySOQAQwaBAAIqjxmA= To: , , , , , X-OriginalArrivalTime: 21 Oct 2005 07:09:17.0846 (UTC) FILETIME=[5A0AA360:01C5D60E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, >Since the PACKET_CLASSIFIER is different in different QoS=20 >domains it seems resonable to include it in the QSpec Template=20 >as control info. I prefer this solution to configuring it in=20 >each node by filters. Well, I'd think that if we left it as local configuration, we wouldn't be doing our job. We are working on QoS signaling, and my assumption is that PACKET_CLASSIFIER is part of that. I'm not suggesting that we would not allow local configuration, but to insist on it would not be sensible, IMO. I think we should resolve the issue where the PACKET_CLASSIFIER belongs, so I'll see if I can see if we are heading to consensis on this or not. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 05:04:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESsoy-00075w-GO; Fri, 21 Oct 2005 05:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESsou-0006xV-CI for nsis@megatron.ietf.org; Fri, 21 Oct 2005 05:04:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07664 for ; Fri, 21 Oct 2005 05:04:01 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESt11-00006G-8q for nsis@ietf.org; Fri, 21 Oct 2005 05:16:43 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9L941ig019119; Fri, 21 Oct 2005 11:04:02 +0200 (MEST) Message-ID: <003001c5d61e$620d9f30$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Ash, Gerald R \(Jerry\), ALABS" , , , References: <9473683187ADC049A855ED2DA739ABCA09FA94DE@KCCLUST06EVS1.ugd.att.com> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Fri, 21 Oct 2005 11:03:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.113 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, J_CHICKENPOX_47 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 21 Oct 2005 11:04:05 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry I see that this discussion does not lead anywhere! Maybe is a good idea to have a lot of discussions in Vancouver related to this issue! Regarding the packet classifier used in the Qo-NSLP, the packet classifier should know what kind of filtering should use on the user data packets. This is because the created QoS-NSLP (RMF) reservation states (not the Qo-NSLP operational states) have to be associated with the user data packets passing through the node. Otherwise no QoS support can be provided. For example: * in a Intserv based model, the flow ID will be used to filter the user data packest and associate them with the Intserv based RMF reservation state * in another QoS model, the combination of IP source address and DSCP might be be used to filter the user data packets and associate them with the RMF reservation state The packet classifier can get this knowledge by: * local policy, configuring the node to associate the RMF reservation state with all user data packets that are filtered based on a predefined and configured rule * using signaling: For this case consider the following: two QoS models, say QoS model A (that goes end-to-end) and QoS model B (that goes locally: edge-to-edge) are used for the same session on an end to end path. The QNE that activates the signaling related to QoS model A generates a RESERVE and is including the QSPEC (A) and it is also including the type of the packet classifier used (packet classifier (A), say flow ID. All the intermediate nodes that use QoS model (A) will have to use QSPEC (A) and the packet classifier (A). On the end-to-end path the same session (and RESERVE message) passes through a local QoS model, say QoS model B. In this case the QNE at the edge of the domain that supports the QoS model B, will have to stack its QSPEC (B) on top of QSPEC (A). At the same time this QNE will have to include the packet classifier (B), information related to QoS model B, say combination of IP source address and DSCP, in the RESERVE message, in such a way that packet classifier (A) is not destroyed. All the intermediate nodes that use QoS model B will have to use QSPEC (B) and packet classifier (B). The QNE located at the other edge of the domain that supports the QoS model B, will have to remove QSEPC (B) and the packet classifier (B) from the RESERVE message. As you can see the packet classifier information and the QSPEC are very much dependent to each other. Thus there is a one to one matching between the packet classifier and the QSPEC. This means that the NSIS protocol suite needs to support the following functionalities: * packet classifier (B) information should not destroy the packet classifier (A) information * The packet classifier, say packet classifier (A), associated with a QSPEC, say QSPEC (A), must only be used in the domains that are using QSPEC (A). * If a QoS model does not recognise a QSPEC, say QSPEC (A) then it should not do anything with its associated packet classifier, say packet classifier (A). If the packet classifier information will be included in the QSPEC, then all the above functionalities are already provided! Best Regards, Georgios ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" To: ; ; Cc: "Ash, Gerald R (Jerry), ALABS" Sent: Thursday, October 20, 2005 6:57 PM Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi All, > > RE Robert's and John's postings on this thread: > http://www1.ietf.org/mail-archive/web/nsis/current/msg05479.html > http://www1.ietf.org/mail-archive/web/nsis/current/msg05486.html > > "whether this data should be in the qos-nslp or qspec is less clear to > me. The concept in my head has always been that the qos-nslp carried > everything about *what* resource reservation action you wanted to carry > out, and the qspec was about how much "stuff" you actually wanted to > reserve. the packet classifier needs to be given in every message about > a transaction, whereas the "how much" information only in some; and the > classifier can probably be universal, whereas the qspec need not be. I > don't > see why having it in the qos-nslp is hard." > > I think this is the right way to think about where to put the > packet_classifier. I agree with John and Robert that the > packet_classifier fits more into qos-nslp and "what" resource > reservation action is signaled rather than "how much stuff" is signaled > using QSPEC. > > In particular, according to the NSIS framework > http://ietf.org/rfc/rfc4080.txt: > > "A flow is defined by a packet classifier (in the simplest cases, just > the destination address and topological origin are needed). In general > we assume that when discussing only the data flow path, we only need to > consider 'simple' fixed classifiers (e.g., IPv4 5-tuple or equivalent)." > > It seems to me that since packet_classifier identifies the flow, that > information relates to the "what" you are signaling (i.e., identifying > the flow) and not to the "how much stuff" (bandwidth, etc.) associated > with the flow. How does an RMF identify a flow to populate the > packet_classifier? > > Also, there are complexities in changing packet_classifiers for a flow > identified in the NSIS framework. Again quoting from the NSIS > framework: > > "However, for some more complex scenarios (especially mobility and > multihoming related ones; see [1] and the mobility discussion of [5]), > it is desirable to update the flow:session mapping during the session > lifetime. For example, a new flow can be added, and the old one deleted > (and maybe in that order, for a 'make-before-break' handover), > effectively transferring the network control state between data flows to > keep it associated with the same session. Such updates are best managed > by the end systems (generally, systems that understand the flow:session > mapping and are aware of the packet classifier change). To enable this, > it must be possible to relate signaling messages to sessions as well as > to data flows. A session identifier (Section 4.6.2) is one component of > the solution. > ... > Note that the crossover router discovery may involve end-to-end > signaling exchanges (especially for flows towards the mobile or > multihomed node), which raises a latency concern. On the other hand, > end-to-end signaling will have been necessary in any case, at the > application level not only to communicate changed addresses, but also to > update packet classifiers along the path. It is a matter for further > analysis to decide how these exchanges could be combined or carried out > in parallel. > > On the shared part of the path, signaling is needed at least to update > the packet classifiers to include the new flow, although if correlation > with the existing flow is possible it should be possible to bypass any > policy or admission control processing. State installation on the new > path (and possibly release on the old one are also required. Which > entity (one of the end hosts or the crossover router) controls all these > procedures depends on which entities are authorized to carry out network > state manipulations, so this is therefore a matter of signaling > application and NSLP design. The approach may depend on the > sender/receiver orientation of the original signaling (see Section > 3.3.1). In addition, in the mobility case, the old path may no longer > be directly accessible to the mobile node; inter-access-router > communication may be required to release state in these circumstances." > > IMO it isn't possible for the RMF to do these functions/manipulations > with the packet_classifier. If it is possible, please clarify how. > > Thanks, > Regards, > Jerry > > _______________________________________________ > 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 nsis-bounces@ietf.org Fri Oct 21 07:03:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESugQ-0002LD-7t; Fri, 21 Oct 2005 07:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESugN-0002L2-NY for nsis@megatron.ietf.org; Fri, 21 Oct 2005 07:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13830 for ; Fri, 21 Oct 2005 07:03:21 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESusV-0004DA-Iu for nsis@ietf.org; Fri, 21 Oct 2005 07:16:04 -0400 Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B0855D9F2; Fri, 21 Oct 2005 13:03:11 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 13:03:11 +0200 Date: Fri, 21 Oct 2005 13:03:11 +0200 From: Martin Stiemerling To: David R Oran , Jukka MJ Manner Subject: Re: QoS Queries (Was: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP) Message-ID: In-Reply-To: <932D2DE5-B132-47F6-B372-7C7387F75516@cisco.com> References: <932D2DE5-B132-47F6-B372-7C7387F75516@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 21 Oct 2005 11:03:11.0620 (UTC) FILETIME=[06D29C40:01C5D62F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Dave and all, --On Mittwoch, 19. Oktober 2005 9:30 Uhr -0400 David R Oran wrote: | | On Oct 19, 2005, at 9:21 AM, Jukka MJ Manner wrote: | |> |> Hi, |> |> This is a thread about the NATFW, and you are talking about QoS, |> but I'm |> still answering. ;) |> S | Sorry - I keep pretending that general-purpose functions are actually in | a general-purpose part of the NSIS protocol suite :-) | |> You can ask that for resources on the exact data path you intend to |> send |> your data. The answer you get depends on your QUERY message, but in |> practise you should get this information in return, yes. Still you |> raised |> an interesting point, as I've thought that any authorization is |> done to |> see whether you are allowed in general to query for resources. Yet, |> you |> might also ask, whether you are allowed to reserve resources in the |> end. | Yes, ditto for NAT/FW mappings, so you did a good job of correctly | realizing my question, though framed in terms of QoS, could just as | easily been framed in terms of NAT/FW. The NATFW NSLPs does not give such a QUERY where you can ask if you theoretically can obtain these resources. The way to do this in the NATFW NSLP is to send a request message (CREATE, REA, UCREATE, or their proxy variants) and to see the reply. The reply will tell, if the request has been fulfilled successfully or if there has been an error (for instance, firewall/NAT does not like your requested policy rule, no resources left, not allowed to get this policy rule, etc). | |> This needs some clarification in our work, Hannes? |> |> Currently, you can't trace the route, at least not that I know of. |> | I'm interested in whether other folks think this is important, as I do. Until I have been against a traceroute functionality in the NATFW NSLP, but some recent discussions have changed that. My response to Elwyn's email contains my thoughts. Best regards, Martin | | Thanks, Dave. | |> Cheers, |> Jukka |> |> On Wed, 19 Oct 2005, David R Oran wrote: |> |> |>> I've stopped following the protocol details, so excuse me if |>> these are stupid |>> questions. |>> |>> 1. Is there a way (through QUERY or some other machinery) for an |>> NSIS client |>> to say "if I were to ask for a QoS reservation with the following |>> attributes |>> (including QSPEC) to the following destination, would it succeed, |>> and if not, |>> would the failure by due to |>> a) insufficient resources |>> b) policy violation |>> c) something mal-formed |>> |>> 2. Does QUERY follow the same NSIS path as what it is querying |>> about? If so, |>> does the response tell me the path? If not, can I find out what |>> path an NSIS |>> session takes (either current or prospective) so I have the |>> equivalent |>> funcitonality for NSIS routing that I do with traceroute? |>> |>> I've often wished I had such diagnostic capabilities in RSVP. |>> |>> Dave. |>> |>> P.S. I happen to agree on point (b) that building separate state |>> recovery / |>> restart machinery is a bad idea - the protocol should simply work |>> and have |>> clear failure semantics when self-repair fails. |>> |>> |>> On Oct 19, 2005, at 4:39 AM, Martin Stiemerling wrote: |>> |>> |>>> Hi all, |>>> |>>> --On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert" |>>> wrote: |>>> |>>> | hi all, |>>> | |>>> | IIRC there were two aspects of this topic discussed at the |>>> | interim: |>>> | |>>> | a) the availability of the diagnosis/query features in the |>>> | first place, and |>>> | |>>> | b) the use of them to build some procedures for recovery from |>>> | certain error/restart scenarios |>>> | |>>> | I don't recall much discussion of (a). I recall significant |>>> | objections to (b) (indeed, I think I made several of them) |>>> |>>> Yes, you've made those objections :) |>>> |>>> I object to b) as well since recovery from error/restart is |>>> complicated and |>>> fragile. So I see b) as ruled out. |>>> |>>> For case a) I have solicited real use cases for several times - |>>> without any |>>> real response. However, what can a node learn by using a query |>>> capability, |>>> other he can learn by using the already defined mechanisms (error |>>> messages, |>>> NOTIFY messages? (this is not a question to you Robert but others :) |>>> |>>> | because they seemed rather complicated and fragile. |>>> | But that doesn't mean that the facilities themselves are |>>> | not useful for - well - diagnosis (for which it's hard to |>>> | build reasonable scenarios other than "something went wrong |>>> | and I'd like to work out what"). |>>> | |>>> | It is possible to go overboard on diagnostics but I don't |>>> | think we're there yet. |>>> |>>> I see it the same way. Probably, somebody will find an interesting |>>> use case in the future. If so, we can extend the NATFW NSLP later. |>>> |>>> Thanks, |>>> |>>> Martin |>>> |>>> | |>>> | r. |>>> | |>>> |> -----Original Message----- |>>> |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On |>>> |> Behalf Of john.loughney@nokia.com |>>> |> Sent: 14 October 2005 08:09 |>>> |> To: stiemerling@netlab.nec.de; nsis@ietf.org |>>> |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP |>>> |> |>>> |> |>>> |> Hi Martin, |>>> |> |>>> |> > Draft -07 of the NATFW NSLP describes a query and diagnosis |>>> |> > capability in Section 3.3.6. These capabilities have been in |>>> |> > the draft for while but no real usage scenarios have been |>>> |> > described so far (see issue 30 in the tracker |>>> |> > ). |>>> |> > |>>> |> > The general feeling of the WG about these query and diagnosis |>>> |> > capabilities were quite mixed (as expressed during the last |>>> |> > interim in Munich). Since then I have not received any further |>>> |> > comments about this issue. |>>> |> > |>>> |> > Personally, I do not see any good use cases for such a |>>> |> > capability in the NATFW NSLP and I'm in favour of removing it |>>> |> > completely. |>>> |> > |>>> |> > I'm soliciting the WG to give feedback on this issue, whether |>>> |> > it is considered a useful feature or not. If you consider it a |>>> |> > useful feature, you should give some use cases. |>>> |> |>>> |> I am leaning towards dropping this feature. I think that this is |>>> |> extra functionality without defined use - this will make the |>>> |> implementatino & usage more difficult. |>>> |> |>>> |> John |>>> |> |>>> |> _______________________________________________ |>>> |> nsis mailing list |>>> |> nsis@ietf.org |>>> |> https://www1.ietf.org/mailman/listinfo/nsis |>>> |> |>>> |>>> |>>> |>>> _______________________________________________ |>>> nsis mailing list |>>> nsis@ietf.org |>>> https://www1.ietf.org/mailman/listinfo/nsis |>>> |>>> |>> |>> _______________________________________________ |>> nsis mailing list |>> nsis@ietf.org |>> https://www1.ietf.org/mailman/listinfo/nsis |>> |> | | _______________________________________________ | nsis mailing list | nsis@ietf.org | https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 07:06:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuja-00030z-CP; Fri, 21 Oct 2005 07:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESujY-00030p-FM for nsis@megatron.ietf.org; Fri, 21 Oct 2005 07:06:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13958 for ; Fri, 21 Oct 2005 07:06:38 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESuvg-0004Jx-F8 for nsis@ietf.org; Fri, 21 Oct 2005 07:19:20 -0400 Received: from venus.office (venus.office [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4C0A2DC51; Fri, 21 Oct 2005 13:06:36 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 13:06:36 +0200 Date: Fri, 21 Oct 2005 13:06:34 +0200 From: Martin Stiemerling To: Roland Bless , David R Oran Subject: Re: QoS Queries (Was: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP) Message-ID: In-Reply-To: <43574776.8000108@tm.uka.de> References: <932D2DE5-B132-47F6-B372-7C7387F75516@cisco.com> <43574776.8000108@tm.uka.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 21 Oct 2005 11:06:36.0227 (UTC) FILETIME=[80C72930:01C5D62F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Jukka MJ Manner , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --On Donnerstag, 20. Oktober 2005 9:29 Uhr +0200 Roland Bless wrote: | Hi Dave, | |> Sorry - I keep pretending that general-purpose functions are actually |> in a general-purpose part of the NSIS protocol suite :-) | | Unfortunately, no. That would be a candidate for common NSLP | functionality, but we don't have a separate layer for that. I even doubt that it could be done in a separate layer, since the parameters to query are quite different per NSLP. | |>> Currently, you can't trace the route, at least not that I know of. |>> |> I'm interested in whether other folks think this is important, as I do. | |> From my experience it would be important at least for error | diagnosis purposes. IIRC we discussed this a little at the interim | meeting in Munich in the context of the GIST ping-tool, that is | more like a traceroute NSLP. A problem using a separate NSLP instance | for traceroute functionality is that the actual NSLP node set on the | path may be slightly different for the ping/traceroute and the | actually used QoS or NAT/FW NSLP. | | Nevertheless, I think it's helpful to know something about | the (nodes on the) path at least in case of errors. NATFW NSLP people are currently discussing about this feature. So stay tuned :-) Regards, Martin | That's why I requested some time ago to add something like | an Error Source Identifier in NSLPs so that you may at least | know where the failure occured. Having this, maybe we could easily | mimic a tracroute functionality: | GIST has a GHC (GIST Hop Count). If it is decremented to zero GIST | will report an error to the sender. I'm not sure about the currently | defined interaction of GIST with NSLP in this case, but I think | it would be useful to let GIST report that error also to the NSLP | via a MessageStatus API call (Robert?). That in turn could generate an | NSLP error message that is propagated back towards the originator of | the QUERY/RESERVE etc. Opinions? | | Regards, | Roland | | _______________________________________________ | 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 nsis-bounces@ietf.org Fri Oct 21 07:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESutD-0000q9-Dg; Fri, 21 Oct 2005 07:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESutB-0000q0-A5 for nsis@megatron.ietf.org; Fri, 21 Oct 2005 07:16:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14488 for ; Fri, 21 Oct 2005 07:16:35 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESv5J-0004gC-Et for nsis@ietf.org; Fri, 21 Oct 2005 07:29:17 -0400 Received: from venus.office (chiba.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B596814FEB; Fri, 21 Oct 2005 13:16:33 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 13:16:33 +0200 Date: Fri, 21 Oct 2005 13:16:33 +0200 From: Martin Stiemerling To: Elwyn Davies Subject: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP Message-ID: <753AD8E473371FEFB0F10109@[10.1.1.109]> In-Reply-To: <43575607.5090808@dial.pipex.com> References: <43575607.5090808@dial.pipex.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 21 Oct 2005 11:16:33.0657 (UTC) FILETIME=[E4DFBE90:01C5D630] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Elwyn, --On Donnerstag, 20. Oktober 2005 9:32 Uhr +0100 Elwyn Davies wrote: [...] | |> |> For case a) I have solicited real use cases for several times - |> without any |> real response. However, what can a node learn by using a query |> capability, |> other he can learn by using the already defined mechanisms (error |> messages, |> NOTIFY messages? (this is not a question to you Robert but others :) | | HOWEVER, I do see a case for a very limited query mechanism which would | be able to report just | the identities of NSLP nodes active on a session path. With this | information, a management system | (for example) would be able to make more specific queries about the | session. Without it, the | management system has no idea (or at least a very complex problem) of how | to obtain and correlate information | relating to a session - I believe this issue was discussed some time ago | but in a more general context. It is | a common problem for all path directed mecahnisms. | | A query message for NATFW NSLP specifically would be able to return the | sequnce of device types (NAT or FW or combined) | plus addressing information for the node (in the case of a NAT public and | private sides). This is a strictly limited set | of information which does not need to worry about how rules are | formulated. It is simple to specify and gives the | substrate on which more complex queries could be built using other | (targeted) protocols. This proposal sounds realistic, since the response is limited to a very specific information. Past proposals included reporting of policy rules installed at the involved firewalls/NATs. In my opinion, reporting of the policy rules is challenging in many ways: - Administrators do not like others to see the real policy rules will all parameters, - Returning policy rules per hop may result in quite large messages - Representation of any thinkable policy rule in a generic and interoperable seem quite difficult. (Consider all the possible parameters of firewall/NAT implementations and the number of vendors + software version) | | I suspect a similar query mechanism for QoS NSLP would also be useful. | | There would be some possible security issues. Would a remote node wish | to give away its address, or even its existence? I guess that many operators do not like others to see details about their infrastructure. Especially, when nodes from outside the network can learn about the infrastructure. As you have said below, a scoping mechanism is required. Furthermore, I would suggest to declare the NATFW Query mechanism optional, i.e., nodes may enter the IP address but they must not. | Nodes should (I guess) be able to 'pass' on the message - forward it | without filling in information - and scope mechanisms might apply | so that the message is turned round at the edge of a domain. | | I think it has to be at the NSLP level because of the specificity of | sessions. Right. Best regards, Martin | |> |> | because they seemed rather complicated and fragile. |> | But that doesn't mean that the facilities themselves are |> | not useful for - well - diagnosis (for which it's hard to |> | build reasonable scenarios other than "something went wrong |> | and I'd like to work out what"). |> | |> | It is possible to go overboard on diagnostics but I don't |> | think we're there yet. |> |> I see it the same way. Probably, somebody will find an interesting |> use case in the future. If so, we can extend the NATFW NSLP later. |> |> Thanks, |> |> Martin |> |> | |> | r. |> | |> |> -----Original Message----- |> |> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On |> |> Behalf Of john.loughney@nokia.com |> |> Sent: 14 October 2005 08:09 |> |> To: stiemerling@netlab.nec.de; nsis@ietf.org |> |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP |> |> |> |> |> |> Hi Martin, |> |> |> |> > Draft -07 of the NATFW NSLP describes a query and diagnosis |> |> > capability in Section 3.3.6. These capabilities have been in |> |> > the draft for while but no real usage scenarios have been |> |> > described so far (see issue 30 in the tracker |> |> > ). |> |> > |> |> > The general feeling of the WG about these query and diagnosis |> |> > capabilities were quite mixed (as expressed during the last |> |> > interim in Munich). Since then I have not received any further |> |> > comments about this issue. |> |> > |> |> > Personally, I do not see any good use cases for such a |> |> > capability in the NATFW NSLP and I'm in favour of removing it |> |> > completely. |> |> > |> |> > I'm soliciting the WG to give feedback on this issue, whether |> |> > it is considered a useful feature or not. If you consider it a |> |> > useful feature, you should give some use cases. |> |> |> |> I am leaning towards dropping this feature. I think that this is |> |> extra functionality without defined use - this will make the |> |> implementatino & usage more difficult. |> |> |> |> John |> |> |> |> _______________________________________________ |> |> nsis mailing list |> |> nsis@ietf.org |> |> https://www1.ietf.org/mailman/listinfo/nsis |> |> |> |> |> |> _______________________________________________ |> nsis mailing list |> nsis@ietf.org |> https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 07:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESv5N-0000Oy-9A; Fri, 21 Oct 2005 07:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESv5L-0000Oj-FF for nsis@megatron.ietf.org; Fri, 21 Oct 2005 07:29:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15013 for ; Fri, 21 Oct 2005 07:29:09 -0400 (EDT) Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESvHS-00056I-N5 for nsis@ietf.org; Fri, 21 Oct 2005 07:41:52 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9076F117; Fri, 21 Oct 2005 13:29:01 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31300-04; Fri, 21 Oct 2005 13:28:59 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0938310E; Fri, 21 Oct 2005 13:28:59 +0200 (MST) Message-ID: <4358D0FA.7090509@uni-tuebingen.de> Date: Fri, 21 Oct 2005 13:28:58 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , Falko Dressler , Tschofenig Hannes , 'Juergen Quittek' , Changpeng Fan , Kappler Cornelia Subject: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, while updating the M-NSLP drafts, we had a discussion about how flexible should the flow specification be for the flows to be measured. The current text in http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-02.txt says: -------------- Section: 4.2.6.1 The Object restricts the set of considered flows for the metering. The MSPEC MUST support a value for that is different from the flow information kept at GIST. In particular, could be for example, a 5-tuple where one or more fields are wild-carded. For example, it MUST be possible to count all TCP SYN packets or all ICMP packets going to a given destination IP address. -------------- However, we are currently questionning this statement. The reason is whether it makes sense to use NSIS for the configuration of Metering Entities on the path from A to B to measure characteristics of other flows than the ones going from A to B. I would like to ask you for your opinion on this topic: - do you think that the specification of the flows to be measured should be restricted to the MRI from GIST. -Or do you think it should be as flexible as possible? Best regards, Ali. -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 08:38:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwA8-0000ry-7J; Fri, 21 Oct 2005 08:38:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwA6-0000qt-Bt for nsis@megatron.ietf.org; Fri, 21 Oct 2005 08:38:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18904 for ; Fri, 21 Oct 2005 08:38:08 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwME-0007fE-8M for nsis@ietf.org; Fri, 21 Oct 2005 08:50:51 -0400 Received: from [222.68.242.242] (unknown [222.68.242.242]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 64F491BAC4D; Fri, 21 Oct 2005 14:38:03 +0200 (CEST) Date: Fri, 21 Oct 2005 14:37:58 +0200 From: Juergen Quittek To: Ali Fessi , nsis Message-ID: <3CA1A6582E5C79EEFFEEA1E6@[222.68.242.242]> In-Reply-To: <4358D0FA.7090509@uni-tuebingen.de> References: <4358D0FA.7090509@uni-tuebingen.de> X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , Tschofenig Hannes , Changpeng Fan , Falko Dressler , Kappler Cornelia Subject: [NSIS] Re: Filters for the flow specification for the measurement in the Metering NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Ali, This is an interesting question: Shall NSIS signaling be used to signal something that is not directly related to the traffic flow specified by the MRI? We would signal along a certain path (given by the MRI) but affect something different, for example "Please measure along the path specified by the MRI all traffic that is directed to the IP address of my neighbor's PC" This enters a new area of path-coupled signaling that was not covered by NSIS so far. A non-critical case would be just further restricting the MRI. In the case of using NSIS to configure traffic measurement this would mean measuring just a specified subset of the packets identified by the MRI. This should be no problem. Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 21.10.2005 13:28 Uhr +0200 Ali Fessi wrote: > Dear all, > > while updating the M-NSLP drafts, we had a discussion about how flexible should the flow specification be for the flows to be measured. > > The current text in > > http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-02.txt > > says: > > -------------- > > Section: 4.2.6.1 The Object > > restricts the set of considered flows for the metering. > The MSPEC MUST support a value for that is different from > the flow information kept at GIST. In particular, could be for example, a 5-tuple where one or more fields are wild-carded. > > For example, it MUST be possible to count all TCP SYN packets or all > ICMP packets going to a given destination IP address. > > -------------- > > However, we are currently questionning this statement. > > The reason is whether it makes sense to use NSIS for the configuration of Metering Entities on the path from A to B to measure characteristics of other flows than the ones going from A to B. > > I would like to ask you for your opinion on this topic: > > - do you think that the specification of the flows to be measured should be restricted to the MRI from GIST. > > -Or do you think it should be as flexible as possible? > > Best regards, > Ali. > > -- > Ali Fessi > University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 10:34:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxyJ-0002Q1-1F; Fri, 21 Oct 2005 10:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxyH-0002Pt-FM for nsis@megatron.ietf.org; Fri, 21 Oct 2005 10:34:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24911 for ; Fri, 21 Oct 2005 10:34:02 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18Vq/esEQ9grDPvul54CNh+pzd7YyZoTws=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyAO-0003Eg-HR for nsis@ietf.org; Fri, 21 Oct 2005 10:46:47 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ESxxp-0005VE-Q9; Fri, 21 Oct 2005 16:33:52 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 50E9FB3B2; Fri, 21 Oct 2005 16:33:45 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ESxxo-0003p1-SB; Fri, 21 Oct 2005 16:33:44 +0200 Message-ID: <4358FC48.8030904@tm.uka.de> Date: Fri, 21 Oct 2005 16:33:44 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: QoS Queries (Was: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP) References: <932D2DE5-B132-47F6-B372-7C7387F75516@cisco.com> <43574776.8000108@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: David R Oran , Jukka MJ Manner , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Martin, > |> Sorry - I keep pretending that general-purpose functions are actually > |> in a general-purpose part of the NSIS protocol suite :-) > | > | Unfortunately, no. That would be a candidate for common NSLP > | functionality, but we don't have a separate layer for that. > > I even doubt that it could be done in a separate layer, since the > parameters to query are quite different per NSLP. I think Dave meant something like a record route or traceroute. That would be IMHO a very basic and simple functionality for all NSLPs. But you're right if you're interested in more specific information about a particular NSLP. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 11:13:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESya4-0002gb-9g; Fri, 21 Oct 2005 11:13:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESya2-0002g8-EJ for nsis@megatron.ietf.org; Fri, 21 Oct 2005 11:13:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01658 for ; Fri, 21 Oct 2005 11:13:02 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESym3-0006FL-N5 for nsis@ietf.org; Fri, 21 Oct 2005 11:25:43 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-126.messagelabs.com!1129907469!8021466!10 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 21244 invoked from network); 21 Oct 2005 15:12:51 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-3.tower-126.messagelabs.com with SMTP; 21 Oct 2005 15:12:51 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4351BDFD0046A518; Fri, 21 Oct 2005 11:12:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Fri, 21 Oct 2005 10:12:49 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA94FB@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXWHmeCOn5NUU7HTSy6ThDCRXx49wAI6NZw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, Thanks for your detailed example, I think this is a good way to resolve the issue. > I see that this discussion does not lead anywhere! > Maybe is a good idea to have a lot of discussions in > Vancouver related to this issue! OK, but let's continue on the list, and see if we can make progress. =20 > Regarding the packet classifier used in the QoS-NSLP, the=20 > packet classifier should know what kind of filtering should > use on the user data packets. This is because the created > QoS-NSLP (RMF) reservation states (not the QoS-NSLP > operational states) have to be associated with the user data > packets passing through the node. Otherwise no QoS support > can be provided. >=20 > For example: > * in a Intserv based model, the flow ID will be used to=20 > filter the user data packets and associate them with the > Intserv based RMF reservation state > * in another QoS model, the combination of IP source address=20 > and DSCP might be used to filter the user data packets > and associate them with the RMF reservation state >=20 > The packet classifier can get this knowledge by: > * local policy, configuring the node to associate the RMF=20 > reservation state with all user data packets that are > filtered based on a predefined and configured rule > * using signaling: > For this case consider the following: > two QoS models, say QoS model A (that goes end-to-end) and=20 > QoS model B (that goes locally: edge-to-edge) are used for > the same session on an end to end path. > The QNE that activates the signaling related to QoS model=20 > A generates a RESERVE and is including the QSPEC (A) and > it is also including the type of the packet classifier > used (packet classifier (A), say flow ID. So the QNE gets the packet_classifier information from where? It seems it still has to be configured according to the QoS model A that the QNE is using, right? > All the intermediate nodes that use QoS model (A) will=20 > have to use QSPEC (A) and the packet classifier (A). > On the end-to-end path the same session (and RESERVE=20 > message) passes through a local QoS model, say QoS model B. > In this case the QNE at the edge of the domain that > supports the QoS model B, will have to stack its QSPEC (B) > on top of QSPEC (A). At the same time this QNE will have to=20 > include the packet classifier (B), information related to > QoS model B, say combination of IP source address and DSCP, > in the RESERVE message, in such a way that packet classifier > (A) is not destroyed. Same question the QNE gets the packet_classifier information from where? It seems it still has to be configured according to the QoS model B that the QNE is using, right? > All the intermediate nodes that use QoS model B will have=20 > to use QSPEC (B) and packet classifier (B). The QNE located > at the other edge of the domain that supports the QoS model > B, will have to remove QSPEC (B) and the packet classifier > (B) from the RESERVE message. >=20 > As you can see the packet classifier information and the=20 > QSPEC are very much dependent to each other. Thus there is > a one to one matching between the packet classifier and the=20 > QSPEC. So each QOSM I-D needs to specify what packet_classifier it will use? > This means that the NSIS protocol suite needs to support=20 > the following functionalities: > * packet classifier (B) information should not destroy the packet=20 > classifier (A) information > * The packet classifier, say packet classifier (A), associated > with a QSPEC, say QSPEC (A), must only be used in the domains that > are using QSPEC (A). > * If a QoS model does not recognize a QSPEC, say QSPEC (A)=20 > then it should not do anything with its associated packet classifier, > say packet classifier (A). >=20 > If the packet classifier information will be included in the QSPEC, > then all the above functionalities are already provided! Let's see if others agree with this? Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 15:42:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2ms-0008W4-MZ; Fri, 21 Oct 2005 15:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2mn-0008Vb-OP for nsis@megatron.ietf.org; Fri, 21 Oct 2005 15:42:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29020 for ; Fri, 21 Oct 2005 15:42:30 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18GD66+vsAfOBqQoW4FS9ud2ED/rFLsJeY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET2yy-0003wG-Cp for nsis@ietf.org; Fri, 21 Oct 2005 15:55:18 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ET2ma-0004hN-IX; Fri, 21 Oct 2005 21:42:37 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id F107EB378; Fri, 21 Oct 2005 21:42:25 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ET2mX-00044m-Jq; Fri, 21 Oct 2005 21:42:25 +0200 Message-ID: <435944AF.7070604@tm.uka.de> Date: Fri, 21 Oct 2005 21:42:39 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP References: <4358D0FA.7090509@uni-tuebingen.de> In-Reply-To: <4358D0FA.7090509@uni-tuebingen.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , Falko Dressler , nsis , Tschofenig Hannes , Changpeng Fan , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Ali, (comments inline) Ali Fessi wrote: > Section: 4.2.6.1 The Object > > restricts the set of considered flows for the metering. > The MSPEC MUST support a value for that is different from > the flow information kept at GIST. In particular, could be > for example, a 5-tuple where one or more fields are wild-carded. > > For example, it MUST be possible to count all TCP SYN packets or all > ICMP packets going to a given destination IP address. > > -------------- The MF classifier definition from RFC 2475 is quite generic and could possibly be referenced here. > The reason is whether it makes sense to use NSIS for the configuration > of Metering Entities on the path from A to B to measure characteristics > of other flows than the ones going from A to B. That's an interesting question. On one hand this may be error prone, but see examples below. > I would like to ask you for your opinion on this topic: > > - do you think that the specification of the flows to be measured should > be restricted to the MRI from GIST. > -Or do you think it should be as flexible as possible? IMHO it would be good to be at least more flexible in the sense that you're interested in a subset of the aggregate that is defined by the MRI between A and B. For example, I think it is perfectly legitimate to measure or sample only certain TCP packets (as in your example above) or certain ICMP messages or even particular HTTP messages. So the MRI would match an aggregate flowing from A to B, and you're interested in a particular sub aggregate within. So the logic within the NSLP could check the semantics, i.e. whether the filter is actually picking a subset of the MRI. OTOH I can imagine a scenario where you are configuring filter for packets that are normally and currently *not* flowing on the path from A to B. So the filter would be used to detect/measure some failure conditions or anomalies. In this case it would be even useful to configure filters along A->B so that they match flows that are currently not routed along that path. Best regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 21 15:52:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2w6-0004rT-Sz; Fri, 21 Oct 2005 15:52:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2u3-0003sR-7d; Fri, 21 Oct 2005 15:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00038; Fri, 21 Oct 2005 15:49:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET367-0004YE-UL; Fri, 21 Oct 2005 16:02:44 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tu-0001F7-CZ; Fri, 21 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-08.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSLP for Quality-of-Service signalling Author(s) : S. Van den Bosch, et al. Filename : draft-ietf-nsis-qos-nslp-08.txt Pages : 73 Date : 2005-10-21 This draft describes an NSIS Signalling Layer Protocol (NSLP) for signalling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This draft explains the overall protocol approach, design decisions made and provides examples. It specifies object and message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-08.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-qos-nslp-08.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-qos-nslp-08.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: <2005-10-21141643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21141643.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Oct 21 15:54:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2yF-0006C5-0G; Fri, 21 Oct 2005 15:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2uK-00041A-FP; Fri, 21 Oct 2005 15:50:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00217; Fri, 21 Oct 2005 15:50:17 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET368-0004YS-6p; Fri, 21 Oct 2005 16:02:44 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tu-0001Fj-KT; Fri, 21 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-04.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-04.txt Pages : 56 Date : 2005-10-21 This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-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-rmd-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-rmd-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: <2005-10-21143728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21143728.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Oct 21 16:24:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3Rg-00038f-Lx; Fri, 21 Oct 2005 16:24:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3Re-000389-Mc for nsis@megatron.ietf.org; Fri, 21 Oct 2005 16:24:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16994 for ; Fri, 21 Oct 2005 16:24:43 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET3dp-0002kN-Gm for nsis@ietf.org; Fri, 21 Oct 2005 16:37:31 -0400 Received: from [222.68.242.242] (unknown [222.68.242.242]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 78C6B1BAC4D; Fri, 21 Oct 2005 22:24:33 +0200 (CEST) Date: Fri, 21 Oct 2005 22:24:27 +0200 From: Juergen Quittek To: Roland Bless , Ali Fessi Subject: Re: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP Message-ID: In-Reply-To: <435944AF.7070604@tm.uka.de> References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> X-Mailer: Mulberry/3.1.6 (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-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , Falko Dressler , nsis , Tschofenig Hannes , Changpeng Fan , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland, --On 21.10.2005 21:42 Uhr +0200 Roland Bless wrote: > Hi Ali, > > (comments inline) > > Ali Fessi wrote: > >> Section: 4.2.6.1 The Object >> >> restricts the set of considered flows for the metering. >> The MSPEC MUST support a value for that is different from >> the flow information kept at GIST. In particular, could be >> for example, a 5-tuple where one or more fields are wild-carded. >> >> For example, it MUST be possible to count all TCP SYN packets or all >> ICMP packets going to a given destination IP address. >> >> -------------- > > The MF classifier definition from RFC 2475 is quite generic > and could possibly be referenced here. > >> The reason is whether it makes sense to use NSIS for the configuration >> of Metering Entities on the path from A to B to measure characteristics >> of other flows than the ones going from A to B. > > That's an interesting question. On one hand this may be error prone, > but see examples below. > >> I would like to ask you for your opinion on this topic: >> >> - do you think that the specification of the flows to be measured should >> be restricted to the MRI from GIST. > >> -Or do you think it should be as flexible as possible? > > IMHO it would be good to be at least more flexible in the sense that > you're interested in a subset of the aggregate that is defined > by the MRI between A and B. For example, I think it is perfectly > legitimate to measure or sample only certain TCP packets (as in your > example above) or certain ICMP messages or even particular HTTP > messages. > So the MRI would match an aggregate flowing from A to B, and you're > interested in a particular sub aggregate within. So the logic within > the NSLP could check the semantics, i.e. whether the filter is > actually picking a subset of the MRI. In this case we can save implementing a lot of logic by specifying that the filter of the NSLP is applied in addition to the filter defined by the MRI. Then you would only need to specify port=80 or TCP_SYN_FLAG=1, respectively. This would also be less error prone. Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 22 02:58:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETDKZ-0000M4-OG; Sat, 22 Oct 2005 02:58:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETDKX-0000HL-4h for nsis@megatron.ietf.org; Sat, 22 Oct 2005 02:58:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22775 for ; Sat, 22 Oct 2005 02:58:02 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETDWo-0002oA-K2 for nsis@ietf.org; Sat, 22 Oct 2005 03:10:56 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j9M6w6Bi019550; Sat, 22 Oct 2005 08:58:06 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j9M6w55B010753; Sat, 22 Oct 2005 08:58:06 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j9M6w6Z12333; Sat, 22 Oct 2005 08:58:06 +0200 (MEST) Date: Sat, 22 Oct 2005 08:58:06 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: gash@att.com, nsis@ietf.org Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 22 Oct 2005 06:58:05 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA94FB@KCCLUST06EVS1.ugd.att.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.378 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 22 Oct 2005 08:58:08 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry Please see in line! On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" wrote: >Hi Georgios, > >Thanks for your detailed example, I think this is a good way to resolve >the issue. > >> I see that this discussion does not lead anywhere! >> Maybe is a good idea to have a lot of discussions in >> Vancouver related to this issue! > >OK, but let's continue on the list, and see if we can make progress. > >> Regarding the packet classifier used in the QoS-NSLP, the >> packet classifier should know what kind of filtering should >> use on the user data packets. This is because the created >> QoS-NSLP (RMF) reservation states (not the QoS-NSLP >> operational states) have to be associated with the user data >> packets passing through the node. Otherwise no QoS support >> can be provided. >> >> For example: >> * in a Intserv based model, the flow ID will be used to >> filter the user data packets and associate them with the >> Intserv based RMF reservation state >> * in another QoS model, the combination of IP source address >> and DSCP might be used to filter the user data packets >> and associate them with the RMF reservation state >> >> The packet classifier can get this knowledge by: >> * local policy, configuring the node to associate the RMF >> reservation state with all user data packets that are >> filtered based on a predefined and configured rule >> * using signaling: >> For this case consider the following: >> two QoS models, say QoS model A (that goes end-to-end) and >> QoS model B (that goes locally: edge-to-edge) are used for >> the same session on an end to end path. >> The QNE that activates the signaling related to QoS model >> A generates a RESERVE and is including the QSPEC (A) and >> it is also including the type of the packet classifier >> used (packet classifier (A), say flow ID. > >So the QNE gets the packet_classifier information from where? It seems >it still has to be configured according to the QoS model A that the QNE >is using, right? Georgios: Yes, you are right, it has to be configured according to the QoS model A, that QNE is using >> All the intermediate nodes that use QoS model (A) will >> have to use QSPEC (A) and the packet classifier (A). >> On the end-to-end path the same session (and RESERVE >> message) passes through a local QoS model, say QoS model B. >> In this case the QNE at the edge of the domain that >> supports the QoS model B, will have to stack its QSPEC (B) >> on top of QSPEC (A). At the same time this QNE will have to >> include the packet classifier (B), information related to >> QoS model B, say combination of IP source address and DSCP, >> in the RESERVE message, in such a way that packet classifier >> (A) is not destroyed. > >Same question the QNE gets the packet_classifier information from where? >It seems it still has to be configured according to the QoS model B that >the QNE is using, right? Georgios: Yes, you are right, it has to be configured according to the QoS model B, that QNE is using >> All the intermediate nodes that use QoS model B will have >> to use QSPEC (B) and packet classifier (B). The QNE located >> at the other edge of the domain that supports the QoS model >> B, will have to remove QSPEC (B) and the packet classifier >> (B) from the RESERVE message. >> >> As you can see the packet classifier information and the >> QSPEC are very much dependent to each other. Thus there is >> a one to one matching between the packet classifier and the >> QSPEC. > >So each QOSM I-D needs to specify what packet_classifier it will use? Georgios: Yes, you are right, each QoSM I-D nees to specify what packet classifier it will use! >> This means that the NSIS protocol suite needs to support >> the following functionalities: >> * packet classifier (B) information should not destroy the packet >> classifier (A) information >> * The packet classifier, say packet classifier (A), associated >> with a QSPEC, say QSPEC (A), must only be used in the domains that >> are using QSPEC (A). >> * If a QoS model does not recognize a QSPEC, say QSPEC (A) >> then it should not do anything with its associated packet classifier, >> say packet classifier (A). >> >> If the packet classifier information will be included in the QSPEC, >> then all the above functionalities are already provided! > >Let's see if others agree with this? > >Thanks, >Regards, >Jerry Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 22 16:23:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETPts-0004TT-4N; Sat, 22 Oct 2005 16:23:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETPtq-0004TL-A1 for nsis@megatron.ietf.org; Sat, 22 Oct 2005 16:23:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27724 for ; Sat, 22 Oct 2005 16:23:18 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19zuR4bQmd02l8Kx0NH6hPRrSkBDIABROY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETQ6E-0003dW-VV for nsis@ietf.org; Sat, 22 Oct 2005 16:36:20 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ETPtU-0003qg-RR; Sat, 22 Oct 2005 22:23:13 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 678C38A19; Sat, 22 Oct 2005 22:23:08 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ETPtU-0005cC-0p; Sat, 22 Oct 2005 22:23:08 +0200 Message-ID: <435A9FBA.7020603@tm.uka.de> Date: Sat, 22 Oct 2005 22:23:22 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: [NSIS] GIST Responder Cookie Generation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, we asked ourselfs some practical questions when implementing the responder cookie mechanism. While the GIST draft provides already a very good basis for an implementation, I think it would be helpful to give a little more advice and security background for implementers (not in the sense of a too strict specification) in order to avoid weak implementations. I see two attacks against the cookie mechanism: 1) A blind attacker sends GIST-Confirm messages with random and invalid cookies. The responder must check if the cookie is correct. Extremly high message rates may exhaust CPU resources. However, the responder will only check the cookie in case the liveness data is correct (i.e. it lies within the validity period). 2) An on-path attacker records the GIST-Response message and performs a brute force offline attack on the secret. Once he knows the secret, the attacker can launch a DoS attack within the remaining validity period of the secret by resource exhaustion due to rapid state creation. Consequently, I see two requirements following from these two attacks: 1) Liveness data should not be guessable by a blind attacker. 2) The secret must be long enough so that a brute force attack will not be feasible in the lifetime of the secret. Thus a second requirement is that a new secret is generated frequently enough so that an attacker has not enough time to perform an offline attack on the secret. Following the IKEv2 approach we decided to use a generation number of the secret as liveness data instead of a timestamp (that could be guessed more easily). But how large should this generation number be? We think that it must be at least 32-bit wide (randomly chosen at the beginning), because the probability for a blind attacker is then small enough to hit a valid secret generation number by chance. The secret must be large enough, too, presumably 64-bit at least. Furthermore, the next secret must be generated soon enough so that an attacker has not enough time to perform a brute force attack to find out the secret. Usually you want to store at least one old secret, so the validity time of a secret is twice as long as the period for secret generation in this case. My request is therefore to provide a little more background so that an implementer can make reasonable choices. Even if my above statements are incorrect it may be a sign that some details are still not clear enough and some security area guys can try to clarify. Best regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 22 16:48:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETQID-00016y-6d; Sat, 22 Oct 2005 16:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETQI8-00016t-QB for nsis@megatron.ietf.org; Sat, 22 Oct 2005 16:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28659 for ; Sat, 22 Oct 2005 16:48:24 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/Y/iiZvIR837O4u1keNzYo1H+g7BMhETg=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETQUY-0004PG-Dq for nsis@ietf.org; Sat, 22 Oct 2005 17:01:26 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ETQI3-0004kH-T0; Sat, 22 Oct 2005 22:48:34 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 296348A2B; Sat, 22 Oct 2005 22:48:27 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ETQHy-0005d7-QU; Sat, 22 Oct 2005 22:48:26 +0200 Message-ID: <435AA5A8.8080106@tm.uka.de> Date: Sat, 22 Oct 2005 22:48:40 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Falko Dressler , nsis , Tschofenig Hannes , Changpeng Fan , Martin Stiemerling , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Juergen, > In this case we can save implementing a lot of logic by > specifying that the filter of the NSLP is applied in addition > to the filter defined by the MRI. Then you would only need > to specify port=80 or TCP_SYN_FLAG=1, respectively. > This would also be less error prone. Yes, that's basically the idea. The MRI contains a port number already, but no TCP flags, IGMP types and so on. A separate full filter spec could, however, be useful for the last scenario that I described (e.g. to detect anomalies). Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 05:23:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyYA-00020i-Da; Mon, 24 Oct 2005 05:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyY8-0001yj-9v for nsis@megatron.ietf.org; Mon, 24 Oct 2005 05:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26679 for ; Mon, 24 Oct 2005 05:23:11 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETyko-0003Zp-P9 for nsis@ietf.org; Mon, 24 Oct 2005 05:36:33 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9O9N0VC012665; Mon, 24 Oct 2005 12:23:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 12:23:02 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 12:23:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Mon, 24 Oct 2005 12:23:00 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D01289E30@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXW1nHlfCd1Q8H4Sz2JUzTiEBZzGgBpgaSw To: , , X-OriginalArrivalTime: 24 Oct 2005 09:23:01.0593 (UTC) FILETIME=[87CE8490:01C5D87C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: gash@att.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios, Do you feel that this is now resolved? It looks like you and Jerry have come to an agreement. John=20 >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Georgios Karagiannis >Sent: 22 October, 2005 09:58 >To: gash@att.com; nsis@ietf.org >Cc: Ash, Gerald R (Jerry), ALABS >Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > > >Hi Jerry > >Please see in line! > >On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" wrote: > >>Hi Georgios, >> >>Thanks for your detailed example, I think this is a good way=20 >to resolve=20 >>the issue. >> >>> I see that this discussion does not lead anywhere! >>> Maybe is a good idea to have a lot of discussions in Vancouver=20 >>> related to this issue! >> >>OK, but let's continue on the list, and see if we can make progress. >> >>> Regarding the packet classifier used in the QoS-NSLP, the packet=20 >>> classifier should know what kind of filtering should use on=20 >the user=20 >>> data packets. This is because the created QoS-NSLP (RMF)=20 >reservation=20 >>> states (not the QoS-NSLP operational states) have to be associated=20 >>> with the user data packets passing through the node.=20 >Otherwise no QoS=20 >>> support can be provided. >>> >>> For example: >>> * in a Intserv based model, the flow ID will be used to filter the=20 >>> user data packets and associate them with the Intserv based RMF=20 >>> reservation state >>> * in another QoS model, the combination of IP source=20 >address and DSCP=20 >>> might be used to filter the user data packets and associate=20 >them with=20 >>> the RMF reservation state >>> >>> The packet classifier can get this knowledge by: >>> * local policy, configuring the node to associate the RMF=20 >reservation=20 >>> state with all user data packets that are filtered based on a=20 >>> predefined and configured rule >>> * using signaling: >>> For this case consider the following: >>> two QoS models, say QoS model A (that goes end-to-end) and=20 >QoS model=20 >>> B (that goes locally: edge-to-edge) are used for the same=20 >session on=20 >>> an end to end path. >>> The QNE that activates the signaling related to QoS model A=20 >generates=20 >>> a RESERVE and is including the QSPEC (A) and it is also=20 >including the=20 >>> type of the packet classifier used (packet classifier (A), say flow=20 >>> ID. >> >>So the QNE gets the packet_classifier information from where?=20 > It seems=20 >>it still has to be configured according to the QoS model A=20 >that the QNE=20 >>is using, right? > >Georgios: Yes, you are right, it has to be configured=20 >according to the QoS model A, that QNE is using > > >>> All the intermediate nodes that use QoS model (A) will have to use=20 >>> QSPEC (A) and the packet classifier (A). >>> On the end-to-end path the same session (and RESERVE >>> message) passes through a local QoS model, say QoS model B. >>> In this case the QNE at the edge of the domain that=20 >supports the QoS=20 >>> model B, will have to stack its QSPEC (B) on top of QSPEC=20 >(A). At the=20 >>> same time this QNE will have to include the packet classifier (B),=20 >>> information related to QoS model B, say combination of IP source=20 >>> address and DSCP, in the RESERVE message, in such a way that packet=20 >>> classifier >>> (A) is not destroyed. >> >>Same question the QNE gets the packet_classifier information=20 >from where? >>It seems it still has to be configured according to the QoS model B=20 >>that the QNE is using, right? > >Georgios: Yes, you are right, it has to be configured=20 >according to the QoS model B, that QNE is using > >>> All the intermediate nodes that use QoS model B will have to use=20 >>> QSPEC (B) and packet classifier (B). The QNE located at the other=20 >>> edge of the domain that supports the QoS model B, will have to=20 >>> remove QSPEC (B) and the packet classifier >>> (B) from the RESERVE message. >>> >>> As you can see the packet classifier information and the QSPEC are=20 >>> very much dependent to each other. Thus there is a one to one=20 >>> matching between the packet classifier and the QSPEC. >> >>So each QOSM I-D needs to specify what packet_classifier it will use? > > >Georgios: Yes, you are right, each QoSM I-D nees to specify=20 >what packet classifier it will use! > > >>> This means that the NSIS protocol suite needs to support the=20 >>> following functionalities: >>> * packet classifier (B) information should not destroy the packet=20 >>> classifier (A) information >>> * The packet classifier, say packet classifier (A),=20 >associated with=20 >>> a QSPEC, say QSPEC (A), must only be used in the domains that are=20 >>> using QSPEC (A). >>> * If a QoS model does not recognize a QSPEC, say QSPEC=20 >(A) then it=20 >>> should not do anything with its associated packet classifier, say=20 >>> packet classifier (A). >>> >>> If the packet classifier information will be included in the QSPEC,=20 >>> then all the above functionalities are already provided! >> >>Let's see if others agree with this? >> >>Thanks, >>Regards, >>Jerry > >Best Regards, >Georgios > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 05:43:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyrm-0007FW-CP; Mon, 24 Oct 2005 05:43:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyrj-0007E9-L1 for nsis@megatron.ietf.org; Mon, 24 Oct 2005 05:43:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27656 for ; Mon, 24 Oct 2005 05:43:27 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETz4R-0004Fi-M8 for nsis@ietf.org; Mon, 24 Oct 2005 05:56:49 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9O9hTT1007617; Mon, 24 Oct 2005 11:43:29 +0200 (MEST) Message-ID: <00b301c5d87f$648bfff0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: , , References: <1AA39B75171A7144A73216AED1D7478D01289E30@esebe100.NOE.Nokia.com> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Mon, 24 Oct 2005 11:43:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.412 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 24 Oct 2005 11:43:31 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Cc: gash@att.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John I am not sure what was the conclusion? Jerry do you agree to include the Packet classifier in the QSPEC? Best Regards, Georgios ----- Original Message ----- From: To: ; ; Cc: Sent: Monday, October 24, 2005 11:23 AM Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Georgios, > > Do you feel that this is now resolved? It looks like you and Jerry > have come to an agreement. > > John > >>-----Original Message----- >>From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>Behalf Of ext Georgios Karagiannis >>Sent: 22 October, 2005 09:58 >>To: gash@att.com; nsis@ietf.org >>Cc: Ash, Gerald R (Jerry), ALABS >>Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >> >> >>Hi Jerry >> >>Please see in line! >> >>On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" wrote: >> >>>Hi Georgios, >>> >>>Thanks for your detailed example, I think this is a good way >>to resolve >>>the issue. >>> >>>> I see that this discussion does not lead anywhere! >>>> Maybe is a good idea to have a lot of discussions in Vancouver >>>> related to this issue! >>> >>>OK, but let's continue on the list, and see if we can make progress. >>> >>>> Regarding the packet classifier used in the QoS-NSLP, the packet >>>> classifier should know what kind of filtering should use on >>the user >>>> data packets. This is because the created QoS-NSLP (RMF) >>reservation >>>> states (not the QoS-NSLP operational states) have to be associated >>>> with the user data packets passing through the node. >>Otherwise no QoS >>>> support can be provided. >>>> >>>> For example: >>>> * in a Intserv based model, the flow ID will be used to filter the >>>> user data packets and associate them with the Intserv based RMF >>>> reservation state >>>> * in another QoS model, the combination of IP source >>address and DSCP >>>> might be used to filter the user data packets and associate >>them with >>>> the RMF reservation state >>>> >>>> The packet classifier can get this knowledge by: >>>> * local policy, configuring the node to associate the RMF >>reservation >>>> state with all user data packets that are filtered based on a >>>> predefined and configured rule >>>> * using signaling: >>>> For this case consider the following: >>>> two QoS models, say QoS model A (that goes end-to-end) and >>QoS model >>>> B (that goes locally: edge-to-edge) are used for the same >>session on >>>> an end to end path. >>>> The QNE that activates the signaling related to QoS model A >>generates >>>> a RESERVE and is including the QSPEC (A) and it is also >>including the >>>> type of the packet classifier used (packet classifier (A), say flow >>>> ID. >>> >>>So the QNE gets the packet_classifier information from where? >> It seems >>>it still has to be configured according to the QoS model A >>that the QNE >>>is using, right? >> >>Georgios: Yes, you are right, it has to be configured >>according to the QoS model A, that QNE is using >> >> >>>> All the intermediate nodes that use QoS model (A) will have to use >>>> QSPEC (A) and the packet classifier (A). >>>> On the end-to-end path the same session (and RESERVE >>>> message) passes through a local QoS model, say QoS model B. >>>> In this case the QNE at the edge of the domain that >>supports the QoS >>>> model B, will have to stack its QSPEC (B) on top of QSPEC >>(A). At the >>>> same time this QNE will have to include the packet classifier (B), >>>> information related to QoS model B, say combination of IP source >>>> address and DSCP, in the RESERVE message, in such a way that packet >>>> classifier >>>> (A) is not destroyed. >>> >>>Same question the QNE gets the packet_classifier information >>from where? >>>It seems it still has to be configured according to the QoS model B >>>that the QNE is using, right? >> >>Georgios: Yes, you are right, it has to be configured >>according to the QoS model B, that QNE is using >> >>>> All the intermediate nodes that use QoS model B will have to use >>>> QSPEC (B) and packet classifier (B). The QNE located at the other >>>> edge of the domain that supports the QoS model B, will have to >>>> remove QSPEC (B) and the packet classifier >>>> (B) from the RESERVE message. >>>> >>>> As you can see the packet classifier information and the QSPEC are >>>> very much dependent to each other. Thus there is a one to one >>>> matching between the packet classifier and the QSPEC. >>> >>>So each QOSM I-D needs to specify what packet_classifier it will use? >> >> >>Georgios: Yes, you are right, each QoSM I-D nees to specify >>what packet classifier it will use! >> >> >>>> This means that the NSIS protocol suite needs to support the >>>> following functionalities: >>>> * packet classifier (B) information should not destroy the packet >>>> classifier (A) information >>>> * The packet classifier, say packet classifier (A), >>associated with >>>> a QSPEC, say QSPEC (A), must only be used in the domains that are >>>> using QSPEC (A). >>>> * If a QoS model does not recognize a QSPEC, say QSPEC >>(A) then it >>>> should not do anything with its associated packet classifier, say >>>> packet classifier (A). >>>> >>>> If the packet classifier information will be included in the QSPEC, >>>> then all the above functionalities are already provided! >>> >>>Let's see if others agree with this? >>> >>>Thanks, >>>Regards, >>>Jerry >> >>Best Regards, >>Georgios >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 06:14:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzLd-0006uS-DN; Mon, 24 Oct 2005 06:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzLb-0006uK-JV for nsis@megatron.ietf.org; Mon, 24 Oct 2005 06:14:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29228 for ; Mon, 24 Oct 2005 06:14:18 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETzYJ-0005Mi-Gr for nsis@ietf.org; Mon, 24 Oct 2005 06:27:41 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9OADwWA012897; Mon, 24 Oct 2005 11:13:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] new draft "GIST over SCTP" and some comments to GIST Date: Mon, 24 Oct 2005 11:13:58 +0100 Message-ID: Thread-Topic: [NSIS] new draft "GIST over SCTP" and some comments to GIST Thread-Index: AcXU+5Y+kO8tJ0dgRnCXhit6lLwEKABEOS/QAJ1AOCA= From: "Hancock, Robert" To: , , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi john, could you be a bit more explicit about what sort of problems you think could occur? my view is that unless an implementor works hard to break things, 'plug & hope' should lead to a success in *any* scenario. (here, 'works hard' means something like binding to specific ports in the Querying node and setting those ports up to be re-used, neither of which one sees in=20 normal socket code. it would also lead just to a set of runtime errors rather than an incorrect GIST configuration.) i would expect the same reasoning to apply to any transport protocol. there is however an issue if nodes attempt to economise on the number of messaging associations by retaining a single one where several have been set up with the same authenticated identity. at the moment the spec says you MAY do this but doesn't indicate how each end agrees this should be done (if one end doesn't agree, some validation checks will fail and messages will be rejected.) I lean towards a MUST or MUST NOT here, with updates to the=20 text on validation in the former case. robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: 21 October 2005 07:59 > To: Hancock, Robert; mail@christian-dickmann.de; nsis@ietf.org > Subject: RE: [NSIS] new draft "GIST over SCTP" and some=20 > comments to GIST >=20 >=20 > Hi all, > =20 > Just adding some comments - hopefully not mudding the waters: > =20 > > This section talks about when MAs can be re-used and it says that=20 > > a match of Peer-Identity is not enough.=20 > > "These should be rare events, so the expense of a new association=20 > > setup is acceptable."=20 > >=20 > > So in a multihoming scenario there might be one association=20 > for every=20 > > link of the multihomed node.=20 >=20 > Right. Indeed, if you have a node with N interfaces=20 > peering with a=20 > node with M interfaces, and there are flows traversing=20 > every possible=20 > interface pair (which is an extremely pathological=20 > case, but anyway...)=20 > there could be be N*M MAs between them.=20 >=20 > However, the more expected case (I think) would be that even a=20 > multihomed node would have a relatively small number of=20 > peers out of=20 > any single interface, especially if those peers are 'nearby'. =20 >=20 > I agree. I think that there some attention will need=20 > to be paid how > this is configured or setup. Just plugging things in=20 > and not paying > attention to how things are setup or configured will=20 > cause problems > with UDP & TCP. I guess some additional considerations=20 > will need > to be paid when running SCTP with respect how you interconnect > multiple (multihomed) nodes together. >=20 > John=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 06:51:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzuy-0007l5-0m; Mon, 24 Oct 2005 06:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzuw-0007l0-Ea for nsis@megatron.ietf.org; Mon, 24 Oct 2005 06:51:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01263 for ; Mon, 24 Oct 2005 06:50:49 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EU07c-0006Zu-8D for nsis@ietf.org; Mon, 24 Oct 2005 07:04:12 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-126.messagelabs.com!1130151041!0!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 1549 invoked from network); 24 Oct 2005 10:50:41 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-15.tower-126.messagelabs.com with SMTP; 24 Oct 2005 10:50:41 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA00009AC5; Mon, 24 Oct 2005 06:50:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Mon, 24 Oct 2005 05:50:38 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9521@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXYf2exVRpvIkhgSDqViGY+sfBH6QABxYkw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John, Georgios, All, It appears that the packet_classifier could be done either in QoS-NSLP or QSPEC. However, Cornelia had concerns about putting it in QSPEC so I think we should hear from her again on this (I believe she is away at the moment). Robert also expressed some concerns I believe. It still seems to me that the packet_classifier identifies 'what' reservation is being made, and does not identify 'how much stuff' is reserved. By that distinction, it belongs in QoS-NSLP (this is John's and Robert's logic also). I also don't understand why putting the packet_classifier in QoS-NSLP is any more complex or prone to errors than putting it in QSPEC. We listed it as an open issue in the latest QSPEC-07 update (to be announced). Hopefully we can resolve the issue prior to IETF-64. Thanks, Regards, Jerry=20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: Monday, October 24, 2005 5:43 AM To: john.loughney@nokia.com; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Hi John I am not sure what was the conclusion? Jerry do you agree to include the Packet classifier in the QSPEC? Best Regards, Georgios ----- Original Message -----=20 From: To: ; ; Cc: Sent: Monday, October 24, 2005 11:23 AM Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Georgios, >=20 > Do you feel that this is now resolved? It looks like you and Jerry > have come to an agreement. >=20 > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 08:07:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU16r-000415-L8; Mon, 24 Oct 2005 08:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU16q-00040y-8J for nsis@megatron.ietf.org; Mon, 24 Oct 2005 08:07:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05530 for ; Mon, 24 Oct 2005 08:07:10 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU1Ja-0000uH-17 for nsis@ietf.org; Mon, 24 Oct 2005 08:20:35 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9OC6wWA008603; Mon, 24 Oct 2005 13:06:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2005 13:06:49 +0100 Message-ID: Thread-Topic: GIST Responder Cookie Generation Thread-Index: AcXXRnRJ3FYnXwIYTHe+AXZ+oRML4ABRFF5A From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org Subject: [NSIS] RE: GIST Responder Cookie Generation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland, I think this is a very useful piece of analysis. Certainly there is a case for adding the issues about blind attacks and strength of the secret (if secret-based liveness data is used) to the discussion of the cookie requirements. I've created=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue97 to capture it. What i'm not certain about is where to document the more detailed ideas about how to defend against the problems, e.g. rollover rate, key length and so on. ideally they'd be written down somewhere. but it seems to me that the gist spec itself is not the best place for them: specifically, it would be good to allow them to evolve and be added to=20 rather freely, because they don't affect interoperability, whereas the spec is supposed to be (or become) stable. i'd like to see an implementors guide, but i'm not sure what=20 other people think about that. cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 22 October 2005 21:23 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: GIST Responder Cookie Generation >=20 >=20 > Hi Robert, >=20 > we asked ourselfs some practical questions when implementing > the responder cookie mechanism. While the GIST draft provides > already a very good basis for an implementation, I think it > would be helpful to give a little more advice and security > background for implementers (not in the sense of a too strict > specification) in order to avoid weak implementations. >=20 > I see two attacks against the cookie mechanism: > 1) A blind attacker sends GIST-Confirm messages with random and > invalid cookies. The responder must check if the cookie is > correct. Extremly high message rates may exhaust CPU > resources. However, the responder will only check the > cookie in case the liveness data is correct (i.e. > it lies within the validity period). > 2) An on-path attacker records the GIST-Response message > and performs a brute force offline attack on the secret. > Once he knows the secret, the attacker can launch > a DoS attack within the remaining validity period of > the secret by resource exhaustion due to rapid state > creation. >=20 > Consequently, I see two requirements following from these > two attacks: > 1) Liveness data should not be guessable by a blind > attacker. > 2) The secret must be long enough so that a brute force > attack will not be feasible in the lifetime of the > secret. Thus a second requirement is that a new secret > is generated frequently enough so that an attacker has > not enough time to perform an offline attack on the > secret. >=20 > Following the IKEv2 approach we decided to use a generation > number of the secret as liveness data instead of a > timestamp (that could be guessed more easily). But how > large should this generation number be? > We think that it must be at least 32-bit wide (randomly > chosen at the beginning), because the probability > for a blind attacker is then small enough to hit a valid > secret generation number by chance. > The secret must be large enough, too, presumably 64-bit > at least. Furthermore, the next secret must be generated > soon enough so that an attacker has not enough time to > perform a brute force attack to find out the secret. > Usually you want to store at least one old secret, so > the validity time of a secret is twice as long as the > period for secret generation in this case. >=20 > My request is therefore to provide a little more > background so that an implementer can make reasonable > choices. Even if my above statements are incorrect > it may be a sign that some details are still not > clear enough and some security area guys can try to > clarify. >=20 > Best regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 08:45:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1hn-0006mA-KA; Mon, 24 Oct 2005 08:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1hm-0006m0-6B for nsis@megatron.ietf.org; Mon, 24 Oct 2005 08:45:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07453 for ; Mon, 24 Oct 2005 08:45:20 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+c7LXplIEIkGw7nzqnZGgTOxrdZcTk0AA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU1uW-0002Av-5z for nsis@ietf.org; Mon, 24 Oct 2005 08:58:45 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EU1hg-0003qq-C0; Mon, 24 Oct 2005 14:45:30 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C5E22B274; Mon, 24 Oct 2005 14:45:27 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EU1hf-0008QG-CW; Mon, 24 Oct 2005 14:45:27 +0200 Message-ID: <435CD766.5050107@tm.uka.de> Date: Mon, 24 Oct 2005 14:45:26 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: [NSIS] Re: GIST Responder Cookie Generation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > Certainly there is a case for adding the issues about > blind attacks and strength of the secret (if secret-based > liveness data is used) to the discussion of the cookie > requirements. I've created > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue97 > to capture it. Ok, thanks. > What i'm not certain about is where to document the more > detailed ideas about how to defend against the problems, > e.g. rollover rate, key length and so on. ideally they'd > be written down somewhere. but it seems to me that the Yep. > gist spec itself is not the best place for them: specifically, > it would be good to allow them to evolve and be added to > rather freely, because they don't affect interoperability, 100% agreed. That's what I meant by "(not in the sense of a too strict specification)". Therefore I requested only to provide additional background on the threats rather than giving exact numbers for rollover rate or key length. These will evolve over time and 64-bit may seem sufficient *today* for one parameter but this setting should be adapted over time as threats and CPUs evolve... > whereas the spec is supposed to be (or become) stable. i'd > like to see an implementors guide, but i'm not sure what > other people think about that. That would be a nice thing to have, but I'm not sure what else would go in there at the moment. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 09:01:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1wx-0002Hj-Kv; Mon, 24 Oct 2005 09:01:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1ww-0002HN-0E for nsis@megatron.ietf.org; Mon, 24 Oct 2005 09:01:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08077 for ; Mon, 24 Oct 2005 09:01:00 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/eWGnufVO188D4PXNT5e+AoAXi5EGPYNE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU29f-0002fY-SU for nsis@ietf.org; Mon, 24 Oct 2005 09:14:25 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EU1wo-0004cz-MN; Mon, 24 Oct 2005 15:01:08 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 1A371B274; Mon, 24 Oct 2005 15:01:05 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EU1wm-0008Qq-Ps; Mon, 24 Oct 2005 15:01:04 +0200 Message-ID: <435CDB10.9030703@tm.uka.de> Date: Mon, 24 Oct 2005 15:01:04 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <9473683187ADC049A855ED2DA739ABCA09FA9521@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9521@KCCLUST06EVS1.ugd.att.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, Georgios Karagiannis , nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry, Ash, Gerald R (Jerry), ALABS write: > It appears that the packet_classifier could be done either in QoS-NSLP > or QSPEC. However, Cornelia had concerns about putting it in QSPEC so I > think we should hear from her again on this (I believe she is away at > the moment). Robert also expressed some concerns I believe. > > It still seems to me that the packet_classifier identifies 'what' > reservation is being made, and does not identify 'how much stuff' is > reserved. By that distinction, it belongs in QoS-NSLP (this is John's > and Robert's logic also). I also don't understand why putting the > packet_classifier in QoS-NSLP is any more complex or prone to errors > than putting it in QSPEC. And Georgious point was that the packet classifier depends probably on the QoS model or is at least somehow related to it. So if put into QoS NSLP you possibly end up with a stack of packet classifiers in addition to the QSPEC stack. Integrating packet classifiers into QSPECs would remove the need to support also a separate stack of packet classifiers. If thinking about it from a DiffServ perspective I would support the view that a packet classifier is probably QoS model dependent. However, in DiffServ you also need additional elements like markers or droppers for a useful traffic conditioning mechanism. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 10:59:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3nU-00048M-53; Mon, 24 Oct 2005 10:59:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3nR-00047n-P1 for nsis@megatron.ietf.org; Mon, 24 Oct 2005 10:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14103 for ; Mon, 24 Oct 2005 10:59:19 -0400 (EDT) Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU40A-0006Z9-8Y for nsis@ietf.org; Mon, 24 Oct 2005 11:12:46 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 99E5411B; Mon, 24 Oct 2005 16:59:10 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 27184-03; Mon, 24 Oct 2005 16:59:08 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0E2AE139; Mon, 24 Oct 2005 16:59:06 +0200 (DFT) Message-ID: <435CF6BA.4060203@uni-tuebingen.de> Date: Mon, 24 Oct 2005 16:59:06 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> In-Reply-To: <435944AF.7070604@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Falko Dressler , nsis , Tschofenig Hannes , Changpeng Fan , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland, hi Juergen and all, Roland Bless wrote: > IMHO it would be good to be at least more flexible in the sense that > you're interested in a subset of the aggregate that is defined > by the MRI between A and B. For example, I think it is perfectly > legitimate to measure or sample only certain TCP packets (as in your > example above) or certain ICMP messages or even particular HTTP > messages. > So the MRI would match an aggregate flowing from A to B, and you're > interested in a particular sub aggregate within. So the logic within > the NSLP could check the semantics, i.e. whether the filter is > actually picking a subset of the MRI. > > OTOH I can imagine a scenario where you are configuring > filter for packets that are normally and currently *not* > flowing on the path from A to B. So the filter would be > used to detect/measure some failure conditions or anomalies. In this > case it would be even useful to configure filters along > A->B so that they match flows that are currently not routed > along that path. > > Best regards, > Roland > both scenarios sound meaningful to me. I'm also in favor a flexible flow specification in the MSPEC and think it would give the Metering NSLP a broader applicability. But I currently see the following challenges: - verifying the semantic of the flow specification in the MSPEC and its relationship to the MRI will be scenario dependant which will make it more complex and error prone - Authorizing Metering NSLP configuration messages with a flexible flow spec will be also more complex, since the whole MSPEC needs to be verified against a set of security policies which will be also dependant on the application scenario and can not be generalized. - NAT traversal: when crossing a NAT, the flow specification in the MSPEC will need to be updated. This means that the M-NSLP will need to look for the fields in the flow spec that need to be modified and modify them correctly according to the NAT binding. This might be not easy, if e.g. some port ranges and IP address netmasks, etc. Looking at these issues, it seems to be a hard job to solve them and I'm currently not sure what is the best solution?! Any comments are welcome! Best regards, Ali. -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 11:41:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Rt-0007jb-Mg; Mon, 24 Oct 2005 11:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Rr-0007gV-FF for nsis@megatron.ietf.org; Mon, 24 Oct 2005 11:41:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16029 for ; Mon, 24 Oct 2005 11:41:06 -0400 (EDT) Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EU4ec-0007rg-Da for nsis@ietf.org; Mon, 24 Oct 2005 11:54:32 -0400 Received: (qmail invoked by alias); 24 Oct 2005 15:41:05 -0000 Received: from p54A3420F.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.66.15] by mail.gmx.net (mp013) with SMTP; 24 Oct 2005 17:41:05 +0200 X-Authenticated: #4469397 From: Thomas Herzog To: nsis@ietf.org Subject: [NSIS] GIST section 4.3.2, adjacency-check Date: Mon, 24 Oct 2005 17:36:17 +0200 User-Agent: KMail/1.8 References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> <435CF6BA.4060203@uni-tuebingen.de> In-Reply-To: <435CF6BA.4060203@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510241736.17919.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, all, I am currently implementing GIST Message Association setup and stumbled a little over section 4.3.2, concerning the adjacency-check which should be done in GIST responder node: > Even when a message relates to a local signaling application, an > adjacency MAY be required based on signaling application policy, and > the application of this policy MAY depend on the NSLP payload. > Therefore, when this decision has to be made, the NSLP payload is > delivered and the signaling application has two options: > > o to proceed setting up the adjacency. The application MAY provide > an NSLP payload (which will be used in any GIST-Response). > > o to bypass the message and drop out of the signaling path. The > application MAY provide an updated NSLP payload (which will be > used in the message which is then forwarded by GIST). As the GIST API defines a "adjacency check" flag in RecvMessage, I suppose, GIST must indicate the request of a Messaging Association ("adjacency"?!?!) to the NSLP and the NSLP will then answer using a SendMessage with Transfer atributes accordingly set? This raises some problems in my eyes: - When late state setup is used, GIST does not save any state where it later could check if a Message Association is rightly established (it will be established on receipt of a GIST Confirm). Only possibility would be to send no Stack Proposal in the Response. However, some local state must be established on Query receipt for asynchronously asking the NSLP via the API?!?! - When a message association is to be set up, the GIST Querier does generally not include NSLP payload in the Query at all, because it gets queued until the Association is set up (NSLP could have required 'reliable' or 'secure' for the data). So GIST has no data to deliver to the NSLP when it asks if the association should be set up. It would in general only deliver "shall I associate", the MRI, the Session ID and the NSLPID... Or is this section to be understood in a more general way? Is this "adjacency" simply about setting up routing state in general? Even in this case, GIST would have no data payload if a Messaging Asociation is to be set up to deliver to the NSLP which then again has no information to decide about....however section 4.3.2 implies that NSLP payload could be essential for this decision. Also, this procedure should be included in the state machine definitions, I think? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 13:37:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6GI-0005iX-4t; Mon, 24 Oct 2005 13:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6GF-0005eB-0A for nsis@megatron.ietf.org; Mon, 24 Oct 2005 13:37:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22451 for ; Mon, 24 Oct 2005 13:37:13 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU6Sy-0003Oo-2j for nsis@ietf.org; Mon, 24 Oct 2005 13:50:40 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2005 10:37:13 -0700 X-IronPort-AV: i="3.97,245,1125903600"; d="scan'208"; a="356003140:sNHT30024944" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9OHbB94021980 for ; Mon, 24 Oct 2005 10:37:11 -0700 (PDT) Received: from [10.42.3.188] (sjc-vpn1-383.cisco.com [10.21.97.127]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9OHl0RL026878 for ; Mon, 24 Oct 2005 10:47:17 -0700 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8185CE00-EB4B-4532-9308-E526CFC5262A@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Mon, 24 Oct 2005 08:57:14 -0400 To: nsis Group X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=5360; t=1130176037; x=1130608237; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20[NSIS]=20RE=3A=20PACKET_CLASSIFIER=20in=20QSPEC| From:David=20R=20Oran=20| Date:Mon,=2024=20Oct=202005=2008=3A57=3A14=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=iolktKgxjGR1HJoXDmuhjhPUbrMrxPl1REfwnPolYCVxHKPygrZCWJU//4nbdMoz6X4K59OW JtjzRMSkKk0NVzCezFzppVsdEbkKXj+SqX8fQ0LRnCMxIoB/4UMllAdEXCjDg6tkp0B6U7mQHe1 sw0EF0fvyaMfwyC9M27Lefr4= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.7 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org On Oct 22, 2005, at 2:58 AM, Georgios Karagiannis wrote: > > Hi Jerry > > Please see in line! > > On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" wrote: > > >> Hi Georgios, >> >> Thanks for your detailed example, I think this is a good way to >> resolve >> the issue. >> Well, I'm still shaking my head over this entire thread. I simply can't imagine how it would be useful for a single NSIS session, with or without multiple stacked QSPECs or other amazing complexity, to have that session apply to different packets at different points along the path. How the heck would I debug this? Let's see. Not only can I have multiple flows mapped to a single NSIS session (for resource sharing), but I can't even tell whether a given packet will be afforded particular treatment unless I can peer inside local state at every hop on the NSIS path. I could certainly see why a node might decide to install a data plane packet classifier which covers a larger equivalence class of packets than the control plane packet classifier provided through NSIS. It might need to do this to avoid state explosion, or want to live dangerously by playing some statistical/queueing-theory games, or because it knows certain degrees of freedom will never occur in practice. What I can't for the life of me follow is the benefit of allowing any arbitrary packet classifier to be associated with a segment of the end to end (or edge to edge path) simply by stacking QSPECS. The only application which even remotely touches on such complexity would be session tunneling, as is done with RSVP aggregation. But in that case the packet classifier used inside the tunnel is associated with a completely independent RSVP session is isn't some kind of simple stacking of QSPECS in a single reservation/session. I'm so completely blown away by the gratuitous complexity this allows that I'm not sure I can engage in a rational engineering tradeoff discussion. Of course, I'm one who argued against stacked QSPECs in the first place... Dave. >> >>> I see that this discussion does not lead anywhere! >>> Maybe is a good idea to have a lot of discussions in >>> Vancouver related to this issue! >>> >> >> OK, but let's continue on the list, and see if we can make progress. >> >> >>> Regarding the packet classifier used in the QoS-NSLP, the >>> packet classifier should know what kind of filtering should >>> use on the user data packets. This is because the created >>> QoS-NSLP (RMF) reservation states (not the QoS-NSLP >>> operational states) have to be associated with the user data >>> packets passing through the node. Otherwise no QoS support >>> can be provided. >>> >>> For example: >>> * in a Intserv based model, the flow ID will be used to >>> filter the user data packets and associate them with the >>> Intserv based RMF reservation state >>> * in another QoS model, the combination of IP source address >>> and DSCP might be used to filter the user data packets >>> and associate them with the RMF reservation state >>> >>> The packet classifier can get this knowledge by: >>> * local policy, configuring the node to associate the RMF >>> reservation state with all user data packets that are >>> filtered based on a predefined and configured rule >>> * using signaling: >>> For this case consider the following: >>> two QoS models, say QoS model A (that goes end-to-end) and >>> QoS model B (that goes locally: edge-to-edge) are used for >>> the same session on an end to end path. >>> The QNE that activates the signaling related to QoS model >>> A generates a RESERVE and is including the QSPEC (A) and >>> it is also including the type of the packet classifier >>> used (packet classifier (A), say flow ID. >>> >> >> So the QNE gets the packet_classifier information from where? It >> seems >> it still has to be configured according to the QoS model A that >> the QNE >> is using, right? >> > > Georgios: Yes, you are right, it has to be configured according to the > QoS model A, that QNE is using > > > >>> All the intermediate nodes that use QoS model (A) will >>> have to use QSPEC (A) and the packet classifier (A). >>> On the end-to-end path the same session (and RESERVE >>> message) passes through a local QoS model, say QoS model B. >>> In this case the QNE at the edge of the domain that >>> supports the QoS model B, will have to stack its QSPEC (B) >>> on top of QSPEC (A). At the same time this QNE will have to >>> include the packet classifier (B), information related to >>> QoS model B, say combination of IP source address and DSCP, >>> in the RESERVE message, in such a way that packet classifier >>> (A) is not destroyed. >>> >> >> Same question the QNE gets the packet_classifier information from >> where? >> It seems it still has to be configured according to the QoS model >> B that >> the QNE is using, right? >> > > Georgios: Yes, you are right, it has to be configured according to the > QoS model B, that QNE is using > > >>> All the intermediate nodes that use QoS model B will have >>> to use QSPEC (B) and packet classifier (B). The QNE located >>> at the other edge of the domain that supports the QoS model >>> B, will have to remove QSPEC (B) and the packet classifier >>> (B) from the RESERVE message. >>> >>> As you can see the packet classifier information and the >>> QSPEC are very much dependent to each other. Thus there is >>> a one to one matching between the packet classifier and the >>> QSPEC. >>> >> >> So each QOSM I-D needs to specify what packet_classifier it will use? >> > > > Georgios: Yes, you are right, each QoSM I-D nees to specify what > packet > classifier it will use! > > > >>> This means that the NSIS protocol suite needs to support >>> the following functionalities: >>> * packet classifier (B) information should not destroy the packet >>> classifier (A) information >>> * The packet classifier, say packet classifier (A), associated >>> with a QSPEC, say QSPEC (A), must only be used in the domains that >>> are using QSPEC (A). >>> * If a QoS model does not recognize a QSPEC, say QSPEC (A) >>> then it should not do anything with its associated packet >>> classifier, >>> say packet classifier (A). >>> >>> If the packet classifier information will be included in the QSPEC, >>> then all the above functionalities are already provided! >>> >> >> Let's see if others agree with this? >> >> Thanks, >> Regards, >> Jerry >> > > Best Regards, > Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 15:46:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8HF-0001uo-Nn; Mon, 24 Oct 2005 15:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8HD-0001ua-Ss for nsis@megatron.ietf.org; Mon, 24 Oct 2005 15:46:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28412 for ; Mon, 24 Oct 2005 15:46:21 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8U2-0007N7-6g for nsis@ietf.org; Mon, 24 Oct 2005 15:59:50 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 24 Oct 2005 15:46:15 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005102415461528489 ; Mon, 24 Oct 2005 15:46:15 -0400 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Mon, 24 Oct 2005 15:46:15 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:49:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Mon, 24 Oct 2005 15:49:44 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA8660898F5@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXYwrYPdBFiUdeHR8KMO4XLlBZ3SwADKZeg From: "Roy, Radhika \(AEAD\)" To: "David R Oran" , "nsis Group" X-OriginalArrivalTime: 24 Oct 2005 19:49:56.0102 (UTC) FILETIME=[1BCD1A60:01C5D8D4] X-Spam-Score: 0.2 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0615783538==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0615783538== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D8D4.14C2BC20" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D8D4.14C2BC20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The way I see the problems are as follows: 1. The scope of NSIS spec is so generic that can (will be able to) accommodate all QoS models either end-to-end and/or a combination of edge-to-middle/middle-to-edge/edge-to-edge over all transport layers (Datagram mode, Connection mode). 2. There is not a generalized QoS model that can be used, and NSIS can take care of that model. 3. To accommodate multiple QoS models in a single session will always invite complexity whether packet filter classifications and others that are needed for the implementation-specific QoS models are done in QSPEC or otherwise. 4. To invite comparison NSIS with RSVP is a good one as a starting point, however, items 1-3 show that we have to explore much more complex situations what have never been envisioned in RSVP. The best way to assure that NSIS signaling (QoS, Others) applications will work is to do some analysis with use cases as follows: a. Use a single QoS model on end-to-end (e.g., IntServ). b. Use multiple QoS models on end-to-end (e.g., IntServ at edges, DiffServ in Backbone). c. Use Y.xxxx model in combinations with items a and/or b (Note: Y-model can be used in addition to IntServ and/or DiffServ restricting only the values of QoS parameters). Will it be too complex to get the right answer to remove Dave's concerns? Best regards, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of David R Oran Sent: Monday, October 24, 2005 8:57 AM To: nsis Group Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC On Oct 22, 2005, at 2:58 AM, Georgios Karagiannis wrote: > > Hi Jerry > > Please see in line! > > On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" wrote: > > >> Hi Georgios, >> >> Thanks for your detailed example, I think this is a good way to =20 >> resolve >> the issue. >> Well, I'm still shaking my head over this entire thread. I simply =20 can't imagine how it would be useful for a single NSIS session, with =20 or without multiple stacked QSPECs or other amazing complexity, to =20 have that session apply to different packets at different points =20 along the path. How the heck would I debug this? Let's see. Not only =20 can I have multiple flows mapped to a single NSIS session (for =20 resource sharing), but I can't even tell whether a given packet will =20 be afforded particular treatment unless I can peer inside local state =20 at every hop on the NSIS path. I could certainly see why a node might decide to install a data plane =20 packet classifier which covers a larger equivalence class of packets =20 than the control plane packet classifier provided through NSIS. It =20 might need to do this to avoid state explosion, or want to live =20 dangerously by playing some statistical/queueing-theory games, or =20 because it knows certain degrees of freedom will never occur in =20 practice. What I can't for the life of me follow is the benefit of allowing any =20 arbitrary packet classifier to be associated with a segment of the =20 end to end (or edge to edge path) simply by stacking QSPECS. The only application which even remotely touches on such complexity =20 would be session tunneling, as is done with RSVP aggregation. But in =20 that case the packet classifier used inside the tunnel is associated =20 with a completely independent RSVP session is isn't some kind of =20 simple stacking of QSPECS in a single reservation/session. I'm so completely blown away by the gratuitous complexity this allows =20 that I'm not sure I can engage in a rational engineering tradeoff =20 discussion. Of course, I'm one who argued against stacked QSPECs in the first =20 place... Dave. ------_=_NextPart_001_01C5D8D4.14C2BC20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

The way I see the problems are as follows:

1.      = The scope of = NSIS spec is so generic that can = (will be able to) accommodate all QoS models either end-to-end and/or a combination = of = edge-to-middle/middle-to-edge/edge-to-edge over all transport layers (Datagram = mode, = Connection mode).

2.      There is not a generalized QoS model that can be used, and NSIS can take care of that = model.
3.      To accommodate multiple QoS models in a single session will = always invite complexity whether packet filter classifications and = others = that are needed for = the implementation-specific QoS models are done in QSPEC or otherwise.

4.      To invite = comparison NSIS with RSVP is a good one as a starting point, however, items 1-3 show that we = have to explore much more complex situations what have never been envisioned = in RSVP.

The best way to assure = that NSIS signaling (QoS, Others) = applications will work is to do some analysis with = use cases as follows:

a.      Use a single QoS model on end-to-end (e.g., IntServ).
b.      = Use multiple QoS models on = end-to-end (e.g., IntServ at edges, DiffServ in = Backbone).
c.      Use = Y.xxxx model in combinations with items a and/or = b (Note: Y-model can be used in addition to IntServ and/or = DiffServ restricting only the values of QoS = parameters).

Will it be too complex to get the right answer to remove Dave's = concerns?

Best regards,

Radhika

-----Original Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of David R Oran
Sent: Monday, October 24, 2005 8:57 AM
To: nsis Group
Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC


On Oct 22, 2005, at 2:58 AM, Georgios Karagiannis = wrote:

>

> Hi Jerry

>

> Please see in line!

>

> On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" = <gash@att.com> wrote:

>

>

>> Hi Georgios,

>>

>> Thanks for your detailed example, I think this is a good = way to 

>> resolve

>> the issue.

>>

Well, I'm still shaking my head over this entire thread. I = simply 

can't imagine how it would be useful for a single NSIS session, = with 

or without multiple stacked QSPECs or other amazing complexity, = to 

have that session apply to different packets at different = points 

along the path. How the heck would I debug this? Let's see. Not = only 

can I have multiple flows mapped to a single NSIS session = (for 

resource sharing), but I can't even tell whether a given packet = will 

be afforded particular treatment unless I can peer inside local = state 

at every hop on the NSIS path.

I could certainly see why a node might decide to install a data = plane 

packet classifier which covers a larger equivalence class of = packets 

than the control plane packet classifier provided through NSIS. = It 

might need to do this to avoid state explosion, or want to = live 

dangerously by playing some statistical/queueing-theory games, = or 

because it knows certain degrees of freedom will never occur = in 

practice.

What I can't for the life of me follow is the benefit of allowing = any 

arbitrary packet classifier to be associated with a segment of = the 

end to end (or edge to edge path) simply by stacking = QSPECS.

The only application which even remotely touches on such = complexity 

would be session tunneling, as is done with RSVP aggregation. But = in 

that case the packet classifier used inside the tunnel is = associated 

with a completely independent RSVP session is isn't some kind = of 

simple stacking of QSPECS in a single = reservation/session.

I'm so completely blown away by the gratuitous complexity this = allows 

that I'm not sure I can engage in a rational engineering = tradeoff 

discussion.

Of course, I'm one who argued against stacked QSPECs in the = first 

place...

Dave.

------_=_NextPart_001_01C5D8D4.14C2BC20-- --===============0615783538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0615783538==-- From nsis-bounces@ietf.org Mon Oct 24 16:20:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8ip-0007IM-LH; Mon, 24 Oct 2005 16:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8in-0007HX-8A for nsis@megatron.ietf.org; Mon, 24 Oct 2005 16:15:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06966 for ; Mon, 24 Oct 2005 16:14:50 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8vZ-0002U4-Iv for nsis@ietf.org; Mon, 24 Oct 2005 16:28:20 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j9OKEtjw012122; Mon, 24 Oct 2005 22:14:55 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j9OKEt5B014531; Mon, 24 Oct 2005 22:14:55 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j9OKEte27477; Mon, 24 Oct 2005 22:14:55 +0200 (MEST) Date: Mon, 24 Oct 2005 22:14:55 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: oran@cisco.com, nsis@ietf.org Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 24 Oct 2005 20:14:55 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <8185CE00-EB4B-4532-9308-E526CFC5262A@cisco.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.393 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 24 Oct 2005 22:14:57 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Dave Please see in line! On 10/24/2005, "David R Oran" wrote: > >On Oct 22, 2005, at 2:58 AM, Georgios Karagiannis wrote: > >> >> Hi Jerry >> >> Please see in line! >> >> On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" wrote: >> >> >>> Hi Georgios, >>> >>> Thanks for your detailed example, I think this is a good way to >>> resolve >>> the issue. >>> >Well, I'm still shaking my head over this entire thread. I simply >can't imagine how it would be useful for a single NSIS session, with >or without multiple stacked QSPECs or other amazing complexity, to >have that session apply to different packets at different points >along the path. How the heck would I debug this? Let's see. Not only >can I have multiple flows mapped to a single NSIS session (for >resource sharing), but I can't even tell whether a given packet will >be afforded particular treatment unless I can peer inside local state >at every hop on the NSIS path. > >I could certainly see why a node might decide to install a data plane >packet classifier which covers a larger equivalence class of packets >than the control plane packet classifier provided through NSIS. It >might need to do this to avoid state explosion, or want to live >dangerously by playing some statistical/queueing-theory games, or >because it knows certain degrees of freedom will never occur in >practice. > >What I can't for the life of me follow is the benefit of allowing any >arbitrary packet classifier to be associated with a segment of the >end to end (or edge to edge path) simply by stacking QSPECS. > >The only application which even remotely touches on such complexity >would be session tunneling, as is done with RSVP aggregation. But in >that case the packet classifier used inside the tunnel is associated >with a completely independent RSVP session is isn't some kind of >simple stacking of QSPECS in a single reservation/session. Georgios: agree, but in the case of RSVP aggregation the used user plane is the same as the user plane used by the end to end session, but this user plane uses different packet classifiers in the different end to end path locations! The described case in the thread allows a higher degree of modularity (i.e., since this is one of the main goals of NSIS). >I'm so completely blown away by the gratuitous complexity this allows >that I'm not sure I can engage in a rational engineering tradeoff >discussion. Georgios: I do not see any additional complexity in the NSIS protocol suite if the packet classifier will just become an additional QSPEC parameter. Best Regards, Georgios >Of course, I'm one who argued against stacked QSPECs in the first >place... > >Dave. > >>> >>>> I see that this discussion does not lead anywhere! >>>> Maybe is a good idea to have a lot of discussions in >>>> Vancouver related to this issue! >>>> >>> >>> OK, but let's continue on the list, and see if we can make progress. >>> >>> >>>> Regarding the packet classifier used in the QoS-NSLP, the >>>> packet classifier should know what kind of filtering should >>>> use on the user data packets. This is because the created >>>> QoS-NSLP (RMF) reservation states (not the QoS-NSLP >>>> operational states) have to be associated with the user data >>>> packets passing through the node. Otherwise no QoS support >>>> can be provided. >>>> >>>> For example: >>>> * in a Intserv based model, the flow ID will be used to >>>> filter the user data packets and associate them with the >>>> Intserv based RMF reservation state >>>> * in another QoS model, the combination of IP source address >>>> and DSCP might be used to filter the user data packets >>>> and associate them with the RMF reservation state >>>> >>>> The packet classifier can get this knowledge by: >>>> * local policy, configuring the node to associate the RMF >>>> reservation state with all user data packets that are >>>> filtered based on a predefined and configured rule >>>> * using signaling: >>>> For this case consider the following: >>>> two QoS models, say QoS model A (that goes end-to-end) and >>>> QoS model B (that goes locally: edge-to-edge) are used for >>>> the same session on an end to end path. >>>> The QNE that activates the signaling related to QoS model >>>> A generates a RESERVE and is including the QSPEC (A) and >>>> it is also including the type of the packet classifier >>>> used (packet classifier (A), say flow ID. >>>> >>> >>> So the QNE gets the packet_classifier information from where? It >>> seems >>> it still has to be configured according to the QoS model A that >>> the QNE >>> is using, right? >>> >> >> Georgios: Yes, you are right, it has to be configured according to the >> QoS model A, that QNE is using >> >> >> >>>> All the intermediate nodes that use QoS model (A) will >>>> have to use QSPEC (A) and the packet classifier (A). >>>> On the end-to-end path the same session (and RESERVE >>>> message) passes through a local QoS model, say QoS model B. >>>> In this case the QNE at the edge of the domain that >>>> supports the QoS model B, will have to stack its QSPEC (B) >>>> on top of QSPEC (A). At the same time this QNE will have to >>>> include the packet classifier (B), information related to >>>> QoS model B, say combination of IP source address and DSCP, >>>> in the RESERVE message, in such a way that packet classifier >>>> (A) is not destroyed. >>>> >>> >>> Same question the QNE gets the packet_classifier information from >>> where? >>> It seems it still has to be configured according to the QoS model >>> B that >>> the QNE is using, right? >>> >> >> Georgios: Yes, you are right, it has to be configured according to the >> QoS model B, that QNE is using >> >> >>>> All the intermediate nodes that use QoS model B will have >>>> to use QSPEC (B) and packet classifier (B). The QNE located >>>> at the other edge of the domain that supports the QoS model >>>> B, will have to remove QSPEC (B) and the packet classifier >>>> (B) from the RESERVE message. >>>> >>>> As you can see the packet classifier information and the >>>> QSPEC are very much dependent to each other. Thus there is >>>> a one to one matching between the packet classifier and the >>>> QSPEC. >>>> >>> >>> So each QOSM I-D needs to specify what packet_classifier it will use? >>> >> >> >> Georgios: Yes, you are right, each QoSM I-D nees to specify what >> packet >> classifier it will use! >> >> >> >>>> This means that the NSIS protocol suite needs to support >>>> the following functionalities: >>>> * packet classifier (B) information should not destroy the packet >>>> classifier (A) information >>>> * The packet classifier, say packet classifier (A), associated >>>> with a QSPEC, say QSPEC (A), must only be used in the domains that >>>> are using QSPEC (A). >>>> * If a QoS model does not recognize a QSPEC, say QSPEC (A) >>>> then it should not do anything with its associated packet >>>> classifier, >>>> say packet classifier (A). >>>> >>>> If the packet classifier information will be included in the QSPEC, >>>> then all the above functionalities are already provided! >>>> >>> >>> Let's see if others agree with this? >>> >>> Thanks, >>> Regards, >>> Jerry >>> >> >> Best Regards, >> Georgios >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 18:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB9F-0004ke-Bi; Mon, 24 Oct 2005 18:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB8m-0004cr-MF; Mon, 24 Oct 2005 18:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26555; Mon, 24 Oct 2005 18:49:51 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBLa-0002qV-K6; Mon, 24 Oct 2005 19:03:19 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUB8j-0007BW-LT; Mon, 24 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-07.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : QoS-NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-07.txt Pages : 45 Date : 2005-10-24 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.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-qspec-07.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-qspec-07.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: <2005-10-24161108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-24161108.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Oct 24 21:55:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUE27-0003Z0-Js; Mon, 24 Oct 2005 21:55:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUE26-0003Yp-Aw for nsis@megatron.ietf.org; Mon, 24 Oct 2005 21:55:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10722 for ; Mon, 24 Oct 2005 21:55:07 -0400 (EDT) Message-Id: <200510250155.VAA10722@ietf.org> Received: from relaygw1.kornet.net ([61.74.75.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUEEx-0000pb-2e for nsis@ietf.org; Mon, 24 Oct 2005 22:08:40 -0400 Received: from [211.48.62.136] ([211.48.62.136]) by relaygw1.kornet.net ([61.74.75.196]) with ESMTP id 2005102510:55:08:539992.32585.107989936 for ; Tue, 25 Oct 2005 10:55:08 +0900 (KST) Received: from [203.253.70.47] ([203.253.70.47]) by relay8.kornet.net ([211.48.62.136]) with ESMTP id 2005102510:55:08:648294.5738.43707312 for ; Tue, 25 Oct 2005 10:55:08 +0900 (KST) From: "Seong-Ho Jeong" To: Date: Tue, 25 Oct 2005 10:55:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWWsZE0SZMMmPPEQSanZrqfJmzrwAAxrHRgACVievAQPHYk0A== In-Reply-To: <200508031303.JAA13148@ietf.org> X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [NSIS] Updated draft (3GPP QoS Model) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, We have submitted an updated version of the draft "3GPP QoS Model for Networks Using 3GPP QoS Classes". It can be found at http://cclab.hufs.ac.kr/drafts/draft-jeong-nsis-3gpp-qosm-02.txt. This draft describes an NSIS QoS Model (QOSM) based on 3GPP QoS classes and bearer service attributes. Specifically, this draft describes additional optional parameters for QSPEC which carries 3GPP QOSM specific information, how the QSPEC information should be processed in QNEs, which and how other NSIS QoS models, e.g., RMD- QOSM and Y.1541-QOSM, can be applied and interoperate with the 3GPP PDP context signaling. The major changes since -01 version include: - Updated abstract, introduction, additional optional QSPEC parameters, and interoperation with 3GPP UMTS. - Created a new section entitled "NSIS Signaling within the IP-based Transport Part of UMTS/GPRS". Any comments or suggestions are very much appreciated. Thanks and regards, Seong-Ho _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 24 22:45:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUEos-0003ml-Pz; Mon, 24 Oct 2005 22:45:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUEoq-0003jL-Ee for nsis@megatron.ietf.org; Mon, 24 Oct 2005 22:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12548 for ; Mon, 24 Oct 2005 22:45:29 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUF1i-0001pJ-9U for nsis@ietf.org; Mon, 24 Oct 2005 22:59:03 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9P2jVWe013143 for ; Tue, 25 Oct 2005 11:45:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j9P2jYT15723 for ; Tue, 25 Oct 2005 11:45:34 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id j9P2jXA05818 for ; Tue, 25 Oct 2005 11:45:33 +0900 (JST) Received: from Palpatine ([10.81.113.73]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 10:42:49 +0800 From: "Cheng Hong" To: "nsis" Subject: RE: [NSIS] Filters for the flow specification for the measurementin the Metering NSLP Date: Tue, 25 Oct 2005 10:42:46 +0800 Organization: Panasonic Singapore Labs Message-ID: <000101c5d90d$c8286560$4971510a@psl.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcXYq6w3tM2hIsJSRcWm7MaZda6hbwAYFfVAAABsyDA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 25 Oct 2005 02:42:49.0679 (UTC) FILETIME=[CA00F5F0:01C5D90D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hong.cheng@sg.panasonic.com List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Ali, and all, I would like to support having a certain level of flexibility. We have seen some similar requirements from the other NSLP applications, i.e. the QoS NSLP. There are cases that the MRI is not sufficient for the flow specification, and additional information is necessary. PACKET_CLASSIFIER in QoS NSLP is probably trying to provide such flexibility, but it still relies too much on the MRI. Sometimes it is good to allow a flow specification that is not presented in the MRI. We have submitted a Internet Draft on the packet classification issues (temporary available at: http://www.psl.com.sg/internet-drafts/draft-cheng-nsis-flowid-issues-02.txt) . It discussed some of the relevant issues you mentioned below (although more in the QoS NSLP context). cheers Cheng Hong > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf > Of Ali Fessi > Sent: Monday, October 24, 2005 10:59 PM > To: Roland Bless > Cc: Falko Dressler; nsis; Tschofenig Hannes; Changpeng Fan; Kappler > Cornelia > Subject: Re: [NSIS] Filters for the flow specification for the > measurementin the Metering NSLP > > Hi Roland, hi Juergen and all, > > Roland Bless wrote: > > > IMHO it would be good to be at least more flexible in the > sense that > > you're interested in a subset of the aggregate that is > defined by the > > MRI between A and B. For example, I think it is perfectly > legitimate > > to measure or sample only certain TCP packets (as in your example > > above) or certain ICMP messages or even particular HTTP messages. > > So the MRI would match an aggregate flowing from A to B, and you're > > interested in a particular sub aggregate within. So the > logic within > > the NSLP could check the semantics, i.e. whether the filter is > > actually picking a subset of the MRI. > > > > OTOH I can imagine a scenario where you are configuring filter for > > packets that are normally and currently *not* flowing on > the path from > > A to B. So the filter would be used to detect/measure some failure > > conditions or anomalies. In this case it would be even useful to > > configure filters along > > A->B so that they match flows that are currently not routed > > along that path. > > > > Best regards, > > Roland > > > > both scenarios sound meaningful to me. I'm also in favor a flexible > flow specification in the MSPEC and think it would give the Metering > NSLP a broader applicability. But I currently see the following > challenges: > > - verifying the semantic of the flow specification in the MSPEC and > its relationship to the MRI will be scenario dependant which will make > it more complex and error prone > > - Authorizing Metering NSLP configuration messages with a flexible > flow spec will be also more complex, since the whole MSPEC needs to be > verified against a set of security policies which will be also > dependant on the application scenario and can not be generalized. > > - NAT traversal: when crossing a NAT, the flow specification in the > MSPEC will need to be updated. This means that the M-NSLP will need to > look for the fields in the flow spec that need to be modified and > modify them correctly according to the NAT binding. This might be not > easy, if e.g. some port ranges and IP address netmasks, etc. > > Looking at these issues, it seems to be a hard job to solve them and > I'm currently not sure what is the best solution?! > > Any comments are welcome! > > Best regards, > Ali. > -- > Ali Fessi > University of Tuebingen, Germany > > _______________________________________________ > 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 nsis-bounces@ietf.org Mon Oct 24 23:34:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUFZi-0003yT-Kz; Mon, 24 Oct 2005 23:34:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUFZK-0003yC-90 for nsis@megatron.ietf.org; Mon, 24 Oct 2005 23:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15876 for ; Mon, 24 Oct 2005 23:33:31 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUFmB-0003GJ-Iv for nsis@ietf.org; Mon, 24 Oct 2005 23:47:05 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9P3XJJh016600; Tue, 25 Oct 2005 12:33:19 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9P3XIA02598; Tue, 25 Oct 2005 12:33:19 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with SMTP id j9P3XK924476; Tue, 25 Oct 2005 12:33:20 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 25 Oct 2005 11:30:31 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD75A838@pslexc01.psl.local> Thread-topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXYmw1PY0yjY0P+QP+iro8prVpEDAActO4g From: "Cheng Hong" To: "Roland Bless" , "Ash, Gerald R \(Jerry\), ALABS" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: john.loughney@nokia.com, Georgios Karagiannis , Takako Sanda , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland and Georgios, and all, The packet_classifier is indeed pretty much depending on the QoS Model in use. As point out by Georgios, the QoS Model may dictate what is the proper information to use for the packet_classifier.=20 Regarding the packet_classifier, I have two question/issue to clarify. Firstly, I am wondering, since the packet_classifier is QoS Model dependent, does the packet_classifier still need to be general (format) or it can be QoS Model specific?=20 Secondly, regarding placing the packet_classifier in QSPEC, it may place certain requirement on the NAT traversal. For example, a QoS NSLP message is send from QNE-A to QNE-B passing throgh a NAPT, the packet_classifier needs to change. Before the NAPT, the port address is not used for the packet classification, and therefore is no set. After the NAPT, the port number is definitly required for the packet classification, and should be set. In this case, if the packet classifier is in the QSPEC, the NAPT needs to be able to process the message so that it can parse the QSPEC, and update it. Is this an acceptable requirement on the NAT traversal? Regarding stacking the packet_classifier, I am not sure what is the problem in the implementation. It seems that the operation only needs to be synchronized with that applied on the QSPEC. (Sorry for my ignorance about the implemenation issues) It doesn't seems like a major problem to me.=20 cheers Cheng Hong > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Roland Bless > Sent: Monday, October 24, 2005 9:01 PM > To: Ash, Gerald R (Jerry), ALABS > Cc: john.loughney@nokia.com; Georgios Karagiannis;=20 > nsis@ietf.org; cornelia.kappler@siemens.com > Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >=20 > Hi Jerry, >=20 > Ash, Gerald R (Jerry), ALABS write: > > It appears that the packet_classifier could be done either=20 > in QoS-NSLP=20 > > or QSPEC. However, Cornelia had concerns about putting it=20 > in QSPEC so=20 > > I think we should hear from her again on this (I believe=20 > she is away=20 > > at the moment). Robert also expressed some concerns I believe. > >=20 > > It still seems to me that the packet_classifier identifies 'what' > > reservation is being made, and does not identify 'how much=20 > stuff' is=20 > > reserved. By that distinction, it belongs in QoS-NSLP=20 > (this is John's=20 > > and Robert's logic also). I also don't understand why putting the=20 > > packet_classifier in QoS-NSLP is any more complex or prone=20 > to errors=20 > > than putting it in QSPEC. >=20 > And Georgious point was that the packet classifier depends=20 > probably on the QoS model or is at least somehow related to=20 > it. So if put into QoS NSLP you possibly end up with a stack=20 > of packet classifiers in addition to the QSPEC stack. > Integrating packet classifiers into QSPECs would remove the=20 > need to support also a separate stack of packet classifiers. > If thinking about it from a DiffServ perspective I would=20 > support the view that a packet classifier is probably QoS=20 > model dependent. > However, in DiffServ you also need additional elements like=20 > markers or droppers for a useful traffic conditioning mechanism. >=20 > Regards, > Roland >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 00:55:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUGqU-0007bE-8i; Tue, 25 Oct 2005 00:55:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUGqR-0007Xw-Vl for nsis@megatron.ietf.org; Tue, 25 Oct 2005 00:55:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19528 for ; Tue, 25 Oct 2005 00:55:18 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUH3L-0005WT-1A for nsis@ietf.org; Tue, 25 Oct 2005 01:08:51 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9P4tKJh005720 for ; Tue, 25 Oct 2005 13:55:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9P4tMd15245 for ; Tue, 25 Oct 2005 13:55:22 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id j9P4tM408637 for ; Tue, 25 Oct 2005 13:55:22 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 25 Oct 2005 12:52:31 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD75A85F@pslexc01.psl.local> Thread-topic: Issue list for MRI, packet_classifier, flow specficiation, etc.. Thread-Index: AcXZH+h1PD4gWSfjTMSO+L02eHEXMg== From: "Cheng Hong" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: Toyoki Ue , Qijie Huang , Takako Sanda Subject: [NSIS] Issue list for MRI, packet_classifier, flow specficiation, etc.. X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, We have presented a internet draft regarding the Flow ID issues in last IETF meeting, and was given a action point to provide an issue list on that topic for further discussion. Due to all sorts of reasons, it has been delayed. It seems that the group is now talking about the relevant issues in several different threads. So, in a related note, below is the relevant issues we have identified (it is also covered in the updated draft http://www.psl.com.sg/internet-drafts/draft-cheng-nsis-flowid-issues-02. txt). cheers Cheng Hong =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D - synchronization issue of the MRI and flow specification The MRI, as its name suggests, it is mainly designed for the message routing. However, in the current NSIS framework, it is also used for deriving the packet classification (flow specification) information. In certain cases, it is desired to have a more flexible relationship between the two.=20 These cases includes: =3D Multiple addresses flow specification support. The MRI is not able = to properly signal multiple address combination for the packet classification, even with the assistance of the wildcarding and PACKET_CLASSIFIER.=20 =3D Predictive signaling support. In this case, the specific flow specification (packet classification) information may not be able when the signaling is needed. Due to the dependency on the MRI, to change/update the packet classification info will result in a different MRI/Flow ID, which is not desirable since it means re-establishment of the signaling state. =3D Address manipulation support without change the signaling state. = This is required in some scenario, e.g. some application progressively adds in flows, and the tunneling support. Current packet classifier definition requires change of the MRI/Flow ID when the (packet classification) address information changes. (More details are available in http://www.psl.com.sg/internet-drafts/draft-cheng-nsis-flowid-issues-02. txt) =3D Some NSLP application requirements. Certain NSLP application = desires to have a flexibility to signaling some flow specification that is not covered in MRI. (e.g. as per discussion of the metering QoS NSLP in metering NSLP relevant issues discussed in http://www.ietf.org/mail-archive/web/nsis/current/msg05591.html)=20 In conclusion, we see some requirement for a greater flexibility for signaling the flow specification than the current practice (using MRI only). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D However, to introduce that flexibility, we also see some problem/issues. - NAT traversal. Current MRI based flow specification signaling only requires update of the MRI when goes through the NAT. However, if other objects are introduced, the NAT will need to update both objects, and need to guarantee that the same rules are applied on them. =09 - Place to carry the packet classifier. This has been discussed extensively in the tread http://www1.ietf.org/mail-archive/web/nsis/current/msg05583.html There are different options: place in QoS-NSLP, or in QSPEC. For placing it in QoS-NSLP, a stackable packet_classifier is needed to support stackable QSPEC. But, to place it in QSPEC, some NAT traversal problem is envisaged. - There are also some issues that has been mentioned in Ali's post regarding the flexibility=20 http://www.ietf.org/mail-archive/web/nsis/current/msg05605.html - Implementation(debugging) considerations Some concerns has been raised about the difficulties in the implementation and debugging once more flexibility is introduced. This has to be a tradeoff between the function needs (or signaling efficiency) and the implementation complexity.=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 05:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUKiL-0005Jr-Tk; Tue, 25 Oct 2005 05:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUKiK-0005Ji-4u for nsis@megatron.ietf.org; Tue, 25 Oct 2005 05:03:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01213 for ; Tue, 25 Oct 2005 05:03:09 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUKvE-0003Mt-Ep for nsis@ietf.org; Tue, 25 Oct 2005 05:16:45 -0400 Received: (qmail invoked by alias); 25 Oct 2005 09:03:11 -0000 Received: from p54A30959.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.9.89] by mail.gmx.net (mp014) with SMTP; 25 Oct 2005 11:03:11 +0200 X-Authenticated: #4469397 From: Thomas Herzog To: nsis@ietf.org Subject: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Date: Tue, 25 Oct 2005 10:58:36 +0200 User-Agent: KMail/1.8 References: <5F09D220B62F79418461A978CA0921BD75A85F@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD75A85F@pslexc01.psl.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251058.36573.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, all, I am currently implementing a GIST instance, which can be configured to use Late State installation as described in Section 4.4.1. Section 4.4.1 states, "the GIST-confirm must contain sufficient information to allow it to be processed identically to the original Query". However, a GIST-Confirm does NOT contain a stack configuration data object (it is furthermore said, that even the stack proposal object it carries is a mirror of the one it received in the confirm). When the Querier Node wants to set up a C-Mode Message Association, it will send the Confirm via the newly created C-Mode connection. The Responder now must install the MA_HOLD_TIME of the Querier, so its MA State Machine can set the SendHello timer accordingly (GIST Hellos are sent from either direction to hold the MA open). Unfortunately, in the late state installation case, it has no access to the Querier's MA_HOLD_TIME, as this would be carried in the stack configuration object, which is not included. (and even if it would be included, it should be the mirrored one from the Response, fitting to the stack proposal object...) So in my eyes, with the current draft, there is no possibility to set up a Message Association in Late State Installation case! Can someone elaborate on this and tell me if I am totally mistaken? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 08:19:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUNjp-0003WE-Gv; Tue, 25 Oct 2005 08:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUNjo-0003Vw-1R for nsis@megatron.ietf.org; Tue, 25 Oct 2005 08:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12446 for ; Tue, 25 Oct 2005 08:16:53 -0400 (EDT) Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUNwi-0000Xh-K8 for nsis@ietf.org; Tue, 25 Oct 2005 08:30:31 -0400 Received: (qmail invoked by alias); 25 Oct 2005 12:16:47 -0000 Received: from p54A30959.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.9.89] by mail.gmx.net (mp015) with SMTP; 25 Oct 2005 14:16:47 +0200 X-Authenticated: #4469397 From: Thomas Herzog To: "Hancock, Robert" Subject: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Date: Tue, 25 Oct 2005 14:12:12 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251412.12845.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org [sorry, I sent the last message as a reply, so some may have missed that this is a new issue if they use a threaded view in their mailer] Hi all, I am currently implementing a GIST instance, which can be configured to use Late State installation as described in Section 4.4.1. Section 4.4.1 states, "the GIST-confirm must contain sufficient information to allow it to be processed identically to the original Query". However, a GIST-Confirm does NOT contain a stack configuration data object (it is furthermore said, that even the stack proposal object it carries is a mirror of the one it received in the response). When the Querier Node wants to set up a C-Mode Message Association, it will send the Confirm via the newly created C-Mode connection. The Responder now must install the MA_HOLD_TIME of the Querier, so its MA State Machine can set the SendHello timer accordingly (GIST Hellos are sent from either direction to hold the MA open). Unfortunately, in the late state installation case, it has no access to the Querier's MA_HOLD_TIME, as this would be carried in the stack configuration object, which is not included. (and even if it would be included, it should be the mirrored one from the Response, fitting to the stack proposal object...) So in my eyes, with the current draft, there is no possibility to set up a Message Association in Late State Installation case! Can someone elaborate on this and tell me if I am totally mistaken? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 08:28:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUNv7-0008B2-5K; Tue, 25 Oct 2005 08:28:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUNv5-0008Ar-Sa for nsis@megatron.ietf.org; Tue, 25 Oct 2005 08:28:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13447 for ; Tue, 25 Oct 2005 08:28:33 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUO80-0000yG-S8 for nsis@ietf.org; Tue, 25 Oct 2005 08:42:11 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-126.messagelabs.com!1130243264!8969684!21 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 27117 invoked from network); 25 Oct 2005 12:28:32 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.167.132) by server-5.tower-126.messagelabs.com with SMTP; 25 Oct 2005 12:28:32 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA000387F7 for nsis@ietf.org; Tue, 25 Oct 2005 08:28:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 25 Oct 2005 07:28:33 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA953E@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ietf-nsis-qspec-07.txt Thread-Index: AcXY75i8urKWr0dGQyWWJJWJ0TWQbgAbNm5Q From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-07.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi All, Please review and comment on the updated 'QoS-NSLP QSPEC Template' I-D at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt. The updates include the following (including -06 updates): 1. defined "error flag" for error handling, Section 4.5.1 2. defined "not-supported flag" and "tunneled parameter flag", Section 4.5.2 3. updated bit error rate (BER) parameter to packet loss ratio (PLR) parameter, Section 5.2.2 & 7.2.10 4. added packet error ratio (PER) parameter, Section 5.2.2 & 7.2.11 5. added text (from David Black) on DiffServ QSPEC example, Section 6.2 6. coding checked by independent expert and updated to include RE flags in QSPEC objects and MENT flags in QSPEC parameters, Section 7 7. expanded IANA Considerations, Section 9 Remaining open issues include: 1. placement of packet_classifier in QSPEC or QoS-NSLP? Please review and comment. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 24, 2005 6:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: I-D ACTION:draft-ietf-nsis-qspec-07.txt=20 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 : QoS-NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-07.txt Pages : 45 Date : 2005-10-24 =09 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This draft defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 08:48:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUOEC-0001xz-8E; Tue, 25 Oct 2005 08:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUOEB-0001xu-FS for nsis@megatron.ietf.org; Tue, 25 Oct 2005 08:48:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14438 for ; Tue, 25 Oct 2005 08:48:16 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUOR8-0001Tk-K7 for nsis@ietf.org; Tue, 25 Oct 2005 09:01:54 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-131.messagelabs.com!1130244470!12710506!7 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 10090 invoked from network); 25 Oct 2005 12:48:21 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.167.132) by server-12.tower-131.messagelabs.com with SMTP; 25 Oct 2005 12:48:21 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA00039730 for nsis@ietf.org; Tue, 25 Oct 2005 08:48:21 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 25 Oct 2005 07:48:21 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA953F@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-nsis-vertical-interface-01.txt Thread-Index: AcXY2ZTUFjo5fcWyQHCHZN191cUzjQAhumiw From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: I-D ACTION:draft-ash-nsis-vertical-interface-01.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi All, Please review and comment on the updated 'User Application-to-User Plane Vertical Interface' I-D at http://www.ietf.org/internet-drafts/draft-ash-nsis-vertical-interface-01 .txt. The updates include the following: 1. incorporates John Loughney's comments to remove technology specifics such as DSTE, ETS, etc., and to emphasize when vertical interface protocol (VIP) and NSIS signaling takes place in relation to application layer signaling 2. updated Section 3 with a call flow example Open issues include: 1. the I-D proposes that NSIS QoS-NSLP would be an appropriate basis for the VIP. Future updates will specific any needed NSIS extensions to support VIP. Please review and comment. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 24, 2005 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-nsis-vertical-interface-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : User Application-to-User Plane Vertical Interface Author(s) : J. Ash, et al. Filename : draft-ash-nsis-vertical-interface-01.txt Pages : 9 Date : 2005-10-24 =09 This draft describes a mechanism to map QoS requirements from the User application layer down to the user plane to create an NSIS session. This 'vertical signaling interface' between the user application layer and user plane is needed to communicate these QoS requirements, such as bandwidth, flow priority values, etc. to user plane network elements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-nsis-vertical-interface-01 .txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 09:30:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUOsP-0007o3-U7; Tue, 25 Oct 2005 09:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUOsN-0007ng-P8 for nsis@megatron.ietf.org; Tue, 25 Oct 2005 09:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16772 for ; Tue, 25 Oct 2005 09:29:49 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19ETHTPFDUjrDFjdPZcp1KOsDTUNoxy33U=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUP5L-0002az-Fs for nsis@ietf.org; Tue, 25 Oct 2005 09:43:27 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EUOrX-0002wc-MX; Tue, 25 Oct 2005 15:30:00 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id E5D828699; Tue, 25 Oct 2005 15:29:10 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EUOrW-0001wf-GU; Tue, 25 Oct 2005 15:29:10 +0200 Message-ID: <435E3325.7070507@tm.uka.de> Date: Tue, 25 Oct 2005 15:29:09 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Thomas Herzog Subject: Re: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME References: <200510251412.12845.thomas.herzog@gmx.li> In-Reply-To: <200510251412.12845.thomas.herzog@gmx.li> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Report: Spam detection software, running on the system "iramx1.ira.uni-karlsruhe.de", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see mail@atis.uka.de for details. Content preview: Hi Thomas, > Section 4.4.1 states, "the GIST-confirm must contain sufficient information to > allow it to be processed identically to the original Query". following from the problem below, the GIST-Confirm must contain at least the MA-Hold-Time of the Q-Node. Sending the selected Q-Node Stack Proposal in the GIST-Confirm may be one viable option though this is not really required since the MA was setup by the Q-Node already. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Thomas, > Section 4.4.1 states, "the GIST-confirm must contain sufficient information to > allow it to be processed identically to the original Query". following from the problem below, the GIST-Confirm must contain at least the MA-Hold-Time of the Q-Node. Sending the selected Q-Node Stack Proposal in the GIST-Confirm may be one viable option though this is not really required since the MA was setup by the Q-Node already. A further clarification may be required for the case when a Q-Node sets up an MA that differs from the R-Node Stack Proposal, e.g. the latter was TLS/TCP and TLS/SCTP :-), but the Q-Node setup a normal TCP connection w/o TLS (to which the R-Node listens, too, for connections of other peers). In this case the R-Node should check that the Q-Node used an MA that is not allowed by the R-Node Stack Proposal. > However, a GIST-Confirm does NOT contain a stack configuration data object (it > is furthermore said, that even the stack proposal object it carries is a > mirror of the one it received in the response). > > When the Querier Node wants to set up a C-Mode Message Association, it will > send the Confirm via the newly created C-Mode connection. > > The Responder now must install the MA_HOLD_TIME of the Querier, so its MA > State Machine can set the SendHello timer accordingly (GIST Hellos are sent > from either direction to hold the MA open). There should be another clarification in the draft. When should a node send these GIST-MA-Hellos exactly? It is only specified that a node MUST not tear down state for the period of MA-Hold-Time if no GIST message was seen over the MA. But I guess that setting the timer near MA-Hold-Time may be to fragile and a static setting may possibly cause undesired synchronization effects? Should the Hello send in the interval somewhere between 0.7 and 0.95 * MA-Hold-Time to avoid a tear down? Or should one set the NoActivity to MA-Hold-Time * 1.5? While it is ok to leave some implementation freedom I guess that sending a GIST-MA-Hello exactly every MA-Hold-Time msec will not work for all implementations and scenarios. > Unfortunately, in the late state installation case, it has no access to the > Querier's MA_HOLD_TIME, as this would be carried in the stack configuration > object, which is not included. (and even if it would be included, it should > be the mirrored one from the Response, fitting to the stack proposal > object...) > So in my eyes, with the current draft, there is no possibility to set up a > Message Association in Late State Installation case! I assume you're correct here. Other experiences? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 10:25:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPkI-0004QA-MH; Tue, 25 Oct 2005 10:25:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPkG-0004Pg-UI for nsis@megatron.ietf.org; Tue, 25 Oct 2005 10:25:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20301 for ; Tue, 25 Oct 2005 10:25:30 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPxE-0004JN-E2 for nsis@ietf.org; Tue, 25 Oct 2005 10:39:09 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9PEOxWA001980; Tue, 25 Oct 2005 15:24:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Date: Tue, 25 Oct 2005 15:24:59 +0100 Message-ID: Thread-Topic: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Thread-Index: AcXZaEYJBNb9Y4zZSmCZy3ujMdh4fwABjzYQ From: "Hancock, Robert" To: "Roland Bless" , "Thomas Herzog" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all, the missing MA_HOLD_TIME is definitely a bug.=20 i think the neatest solution here is to move the MA_HOLD_TIME to the NLI as an optional field there. the Q-node NLI is repeated in the confirm. i'd rather not repeat the whole stack-config-data, and the stack-proposal is for the 'wrong' node anyway. this is not quite as logically pure as the current structure, but is probably the right compromise between purity and sophistication. (the NLI is repeated in the confirm for precisely the reason that the R-node will have forgotten the original, so there is a match of purpose here). i will add a new issue for this. for roland's other points: - i think the case of using a 'wrong' MA configuration is=20 something that should be checked as part of validating the R-cookie in the response. there should be enough information=20 there for the R-node to work out what stack-proposal it would have made (since this is supposed to be a matter of static policy, and not dependent on the Query); if the confirm is not valid, it can be rejected. (there is an 'invalid cookie' error.) - the point on timer setting is valid; certainly you should not wait to the last millisecond before the Hello is sent. we had a similar discussion on the routing state timer (also signalled in the NLI, btw...) and the refresh operation. should this=20 discussion be in the spec or in a (hypothetical) implementors' guide, however?=20 r. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 25 October 2005 14:29 > To: Thomas Herzog > Cc: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] GIST Confirm contains no stack=20 > configuration data, which holds MA_HOLD_TIME >=20 >=20 > Hi Thomas, >=20 > > Section 4.4.1 states, "the GIST-confirm must contain=20 > sufficient information to=20 > > allow it to be processed identically to the original Query". >=20 > following from the problem below, the GIST-Confirm must=20 > contain at least > the MA-Hold-Time of the Q-Node. Sending the selected Q-Node Stack > Proposal in the GIST-Confirm may be one viable option though this is > not really required since the MA was setup by the Q-Node already. >=20 > A further clarification may be required for the case when a Q-Node > sets up an MA that differs from the R-Node Stack Proposal, e.g. > the latter was TLS/TCP and TLS/SCTP :-), but the Q-Node setup a > normal TCP connection w/o TLS (to which the R-Node listens, too, for > connections of other peers). In this case the R-Node should check > that the Q-Node used an MA that is not allowed by the R-Node Stack > Proposal. >=20 > > However, a GIST-Confirm does NOT contain a stack=20 > configuration data object (it=20 > > is furthermore said, that even the stack proposal object it=20 > carries is a=20 > > mirror of the one it received in the response). > >=20 > > When the Querier Node wants to set up a C-Mode Message=20 > Association, it will=20 > > send the Confirm via the newly created C-Mode connection. > >=20 > > The Responder now must install the MA_HOLD_TIME of the=20 > Querier, so its MA=20 > > State Machine can set the SendHello timer accordingly (GIST=20 > Hellos are sent=20 > > from either direction to hold the MA open). >=20 > There should be another clarification in the draft. > When should a node send these GIST-MA-Hellos exactly? It is only > specified that > a node MUST not tear down state for the period of MA-Hold-Time if no > GIST message was seen over the MA. But I guess that setting the timer > near MA-Hold-Time may be to fragile and a static setting may possibly > cause undesired synchronization effects? Should the Hello send in the > interval somewhere between 0.7 and 0.95 * MA-Hold-Time to avoid > a tear down? Or should one set the NoActivity to MA-Hold-Time * 1.5? > While it is ok to leave some implementation freedom I guess=20 > that sending > a GIST-MA-Hello exactly every MA-Hold-Time msec will not work for all > implementations and scenarios. >=20 > > Unfortunately, in the late state installation case, it has=20 > no access to the=20 > > Querier's MA_HOLD_TIME, as this would be carried in the=20 > stack configuration=20 > > object, which is not included. (and even if it would be=20 > included, it should=20 > > be the mirrored one from the Response, fitting to the stack=20 > proposal=20 > > object...) >=20 > > So in my eyes, with the current draft, there is no=20 > possibility to set up a=20 > > Message Association in Late State Installation case! >=20 > I assume you're correct here. Other experiences? >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 10:34:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPsZ-0007l6-Ex; Tue, 25 Oct 2005 10:34:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPsX-0007l1-Be for nsis@megatron.ietf.org; Tue, 25 Oct 2005 10:34:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20714 for ; Tue, 25 Oct 2005 10:34:02 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+12XzIPJqDPWZT2MSAY695PWgZU7vzLnE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQ5T-0004Xa-Jm for nsis@ietf.org; Tue, 25 Oct 2005 10:47:42 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EUPsI-0006c4-NB; Tue, 25 Oct 2005 16:34:08 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 79BBBB3A9; Tue, 25 Oct 2005 16:34:01 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EUPsH-00021E-37; Tue, 25 Oct 2005 16:34:01 +0200 Message-ID: <435E4258.9070409@tm.uka.de> Date: Tue, 25 Oct 2005 16:34:00 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Thomas Herzog Subject: Re: [NSIS] GIST section 4.3.2, adjacency-check References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> <435CF6BA.4060203@uni-tuebingen.de> <200510241736.17919.thomas.herzog@gmx.li> In-Reply-To: <200510241736.17919.thomas.herzog@gmx.li> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Thomas, I think section 4.3.2 needs definitely some clarifications. >> Even when a message relates to a local signaling application, an >> adjacency MAY be required based on signaling application policy, and >> the application of this policy MAY depend on the NSLP payload. >> Therefore, when this decision has to be made, the NSLP payload is >> delivered and the signaling application has two options: >> >> o to proceed setting up the adjacency. The application MAY provide >> an NSLP payload (which will be used in any GIST-Response). >> >> o to bypass the message and drop out of the signaling path. The >> application MAY provide an updated NSLP payload (which will be >> used in the message which is then forwarded by GIST). > > > As the GIST API defines a "adjacency check" flag in RecvMessage, I suppose, > GIST must indicate the request of a Messaging Association ("adjacency"?!?!) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ At least the terminology section doesn't state that Adjacency means or is identical to an MA between two peers. IMHO it only defines that two GIST nodes are directly adjacent with respect to GIST and NSLP. If I understood the Adjacency Check mechanism correctly it allows an NSLP to act as a bypass if it is not interested in the exchange. A little bit confusing is the fact that section 4.3.2 doesn't specify exactly the message which may request the setup of an adjacency. Is there a difference if it is a GIST-Query, GIST-Confirm, GIST-Response or GIST-Data (maybe even received via an existing MA). Again in more detail: >> Even when a message relates to a local signaling application, an >> adjacency MAY be required based on signaling application policy, "an adjacency": is it an adjacency with the Querying upstream node? Could it be a different adjacency with another third node? >> o to proceed setting up the adjacency. The application MAY provide >> an NSLP payload (which will be used in any GIST-Response). So an adjacency can only be setup by a GIST-Query? What is the reaction of the local node? Does it send a GIST-Response back in this case or why says the above sentence "_any_ GIST-Response"? >> o to bypass the message and drop out of the signaling path. The >> application MAY provide an updated NSLP payload (which will be >> used in the message which is then forwarded by GIST). I assume that it should mean: the original message type with the updated NSLP payload is forwarded further down the path, i.e. in this case no GIST-Response is generated. > This raises some problems in my eyes: > > - When late state setup is used, GIST does not save any state where it later > could check if a Message Association is rightly established (it will be > established on receipt of a GIST Confirm). Only possibility would be to send > no Stack Proposal in the Response. However, some local state must be > established on Query receipt for asynchronously asking the NSLP via the > API?!?! So you mean some temporary local state until the NSLP has given an answer and a corresponding GIST-Response is created and sent back? This may be negligible because you would need some resources for processing a Query anyway. It is however important that no state is kept after the Response is sent. > - When a message association is to be set up, the GIST Querier does generally > not include NSLP payload in the Query at all, because it gets queued until > the Association is set up (NSLP could have required 'reliable' or 'secure' > for the data). So GIST has no data to deliver to the NSLP when it asks if the > association should be set up. It would in general only deliver "shall I > associate", the MRI, the Session ID and the NSLPID... This is related somewhat to the problem mentioned in the thread "NSLP-Data in intial GIST-Query" and http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74 > Or is this section to be understood in a more general way? Is this "adjacency" > simply about setting up routing state in general? I think it is not clearly defined in the draft what "setting up an adjacency" really means... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 10:52:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQA7-0004GQ-Uu; Tue, 25 Oct 2005 10:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQA6-0004G9-On for nsis@megatron.ietf.org; Tue, 25 Oct 2005 10:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21718 for ; Tue, 25 Oct 2005 10:52:11 -0400 (EDT) Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUQN5-00052L-9Y for nsis@ietf.org; Tue, 25 Oct 2005 11:05:51 -0400 Received: (qmail invoked by alias); 25 Oct 2005 14:52:16 -0000 Received: from p54A30959.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.9.89] by mail.gmx.net (mp031) with SMTP; 25 Oct 2005 16:52:16 +0200 X-Authenticated: #4469397 Resent-From: Thomas Herzog Resent-To: nsis@ietf.org Resent-Date: Tue, 25 Oct 2005 16:47:37 +0200 Resent-Message-ID: <200510251647.37033.thomas.herzog@gmx.li> From: Thomas Herzog To: "Hancock, Robert" Subject: Re: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Date: Tue, 25 Oct 2005 16:46:40 +0200 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251646.41003.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Am Dienstag, 25. Oktober 2005 16:24 schrieben Sie: > hi all, > > the missing MA_HOLD_TIME is definitely a bug. > > i think the neatest solution here is to move the MA_HOLD_TIME to > the NLI as an optional field there. the Q-node NLI is repeated in > the confirm. i'd rather not repeat the whole stack-config-data, > and the stack-proposal is for the 'wrong' node anyway. this is > not quite as logically pure as the current structure, but is > probably the right compromise between purity and sophistication. > (the NLI is repeated in the confirm for precisely the reason that > the R-node will have forgotten the original, so there is a match > of purpose here). i will add a new issue for this. Hm, but we should be aware that the NLI still has no "optional" fields at all, including an optional field would introduce also a flag to signal this. This solution seems however really cute, as the NLI is supposed to be used as key identifying a MA, so it would also imply that every MA has its MA_HOLD_TIME in its NLI available, so also no additional data data structure is needed for saving it. > for roland's other points: > > - i think the case of using a 'wrong' MA configuration is > something that should be checked as part of validating the > R-cookie in the response. there should be enough information > there for the R-node to work out what stack-proposal it would > have made (since this is supposed to be a matter of static > policy, and not dependent on the Query); if the confirm is > not valid, it can be rejected. (there is an 'invalid cookie' > error.) Yes, sounds good, a Responder Node would simply pull its ability data and check if the given R-Node stack proposal object in the confirm fits. This would also allow to specify specific nodes (maybe on IP ranges) to which only secure connections may be made. So the Responder would check all this on Confirm reception. But as I have read, it is also stated, that the contents of a Response shall not be dependent on the Query, but this would outrule the possibility of granting special connection possibilities to specific nodes? A R-Node thus can only give its complete set of possible connections to a node, maybe this is not as flexible as one may want (the above possibility would be outruled)? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 11:25:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQgY-0000Us-5u; Tue, 25 Oct 2005 11:25:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQgX-0000Un-HQ for nsis@megatron.ietf.org; Tue, 25 Oct 2005 11:25:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29381 for ; Tue, 25 Oct 2005 11:25:42 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18hR4bJiw+fKy5y85v5Wp01GmekXF4y4MM=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQtW-00081f-2n for nsis@ietf.org; Tue, 25 Oct 2005 11:39:22 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EUQgS-0000rW-Qi; Tue, 25 Oct 2005 17:25:55 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id D00A8B3BD; Tue, 25 Oct 2005 17:25:51 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EUQgR-00024t-Ag; Tue, 25 Oct 2005 17:25:51 +0200 Message-ID: <435E4E7E.5090107@tm.uka.de> Date: Tue, 25 Oct 2005 17:25:50 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, thanks for the fast response. My comments inline. > the missing MA_HOLD_TIME is definitely a bug. > > i think the neatest solution here is to move the MA_HOLD_TIME to > the NLI as an optional field there. the Q-node NLI is repeated in > the confirm. i'd rather not repeat the whole stack-config-data, > and the stack-proposal is for the 'wrong' node anyway. this is Agreed. > not quite as logically pure as the current structure, but is > probably the right compromise between purity and sophistication. > (the NLI is repeated in the confirm for precisely the reason that > the R-node will have forgotten the original, so there is a match > of purpose here). i will add a new issue for this. Good. > for roland's other points: > > - i think the case of using a 'wrong' MA configuration is > something that should be checked as part of validating the > R-cookie in the response. there should be enough information > there for the R-node to work out what stack-proposal it would > have made (since this is supposed to be a matter of static > policy, and not dependent on the Query); if the confirm is > not valid, it can be rejected. (there is an 'invalid cookie' > error.) Hmm, then I don't see any reason why the R-Node Stack Proposal should be repeated by the Q-Node anyway. A man in the middle attacker may remove some protocols in the R-Node's stack proposal within the GIST-Response, but he may also re-insert the original stack proposal in the GIST-Confirm. IMHO the R-Node must check anyway whether the established MA fits to its own Stack proposal but if this is done according to the own static list anyway, then the repetition of the R-Node's Stack Proposal in the GIST-Confirm is superfluous anyway. I think it is more interesting to be able to detect the selection of a weak protocol. For instance, if both nodes offer TLS/TCP and TCP but only TCP is selected that should make the R-Node suspicious. However, according to the policy TCP is acceptable anyway. So I don't see a reason to repeat the R-Node's Stack Proposal. Maybe someone else could elaborate what "certain bidding down attacks" means. Currently I don't see any real value in it. > - the point on timer setting is valid; certainly you should not > wait to the last millisecond before the Hello is sent. we had a > similar discussion on the routing state timer (also signalled > in the NLI, btw...) and the refresh operation. should this > discussion be in the spec or in a (hypothetical) implementors' > guide, however? Hmm, I think that in this case the interoperability is affected. So IMHO it should go into the spec itself. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 11:34:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQp6-0004hR-Jf; Tue, 25 Oct 2005 11:34:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQp5-0004hH-KO for nsis@megatron.ietf.org; Tue, 25 Oct 2005 11:34:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29931 for ; Tue, 25 Oct 2005 11:34:32 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUR23-0008H1-A1 for nsis@ietf.org; Tue, 25 Oct 2005 11:48:13 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9PFY5WA018793; Tue, 25 Oct 2005 16:34:05 +0100 Received: from [193.118.197.247] ([193.118.197.247]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 16:34:05 +0100 Message-ID: <435E506D.5010909@roke.co.uk> Date: Tue, 25 Oct 2005 16:34:05 +0100 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2005 15:34:05.0489 (UTC) FILETIME=[88893210:01C5D979] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios Karagiannis wrote: >>The only application which even remotely touches on such complexity >>would be session tunneling, as is done with RSVP aggregation. But in >>that case the packet classifier used inside the tunnel is associated >>with a completely independent RSVP session is isn't some kind of >>simple stacking of QSPECS in a single reservation/session. > > Georgios: agree, but in the case of RSVP aggregation the used user plane > is the same as the user plane used by the end to end session, but this > user plane uses different packet classifiers in the different end to end > path locations! > The described case in the thread allows a higher degree of modularity > (i.e., since this is one of the main goals of NSIS). The different packet classifiers may be a sign that we should be using a different signalling session. If we take RMD as an example, the per domain (i.e. end-to-end) reservation and the per hop (i.e. aggregate-related) reservation are based on different subsets of information in the MRI, and so require different PACKET_CLASSIFIERs. The end-to-end signalling performs per-microflow reservations based on something like the 5-tuple. The aggregate uses a packet classifier which is just the DSCP. However, RMD (looking at, for example, figure 3 in the RMD draft) uses separate signalling sessions for its 'per domain' and 'per hop' reservations, so only a single PACKET_CLASSIFIER is needed for each session. Allowing multiple classifiers seems possible, but does look like unnecessary complexity. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 11:42:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQwm-0006UO-Gg; Tue, 25 Oct 2005 11:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQwk-0006T9-Bu for nsis@megatron.ietf.org; Tue, 25 Oct 2005 11:42:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00536 for ; Tue, 25 Oct 2005 11:42:26 -0400 (EDT) Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUR9f-00005l-Rn for nsis@ietf.org; Tue, 25 Oct 2005 11:56:07 -0400 Received: (qmail invoked by alias); 25 Oct 2005 15:42:27 -0000 Received: from p54A30959.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.9.89] by mail.gmx.net (mp014) with SMTP; 25 Oct 2005 17:42:27 +0200 X-Authenticated: #4469397 From: Thomas Herzog To: Roland Bless Subject: Re: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Date: Tue, 25 Oct 2005 17:37:47 +0200 User-Agent: KMail/1.8 References: <435E4E7E.5090107@tm.uka.de> In-Reply-To: <435E4E7E.5090107@tm.uka.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251737.47718.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Roland, exactly, what I meant, too. Am Dienstag, 25. Oktober 2005 17:25 schrieb Roland Bless: > I think it is more interesting to be able to detect the > selection of a weak protocol. For instance, if both nodes offer > TLS/TCP and TCP but only TCP is selected that should make > the R-Node suspicious. However, according to the policy TCP > is acceptable anyway. So I don't see a reason to repeat > the R-Node's Stack Proposal. Maybe someone else could elaborate > what "certain bidding down attacks" means. Currently I don't > see any real value in it. To my understanding, even this case (selection of a weak protocol) is not really useful. As the Message Transfer security is set by the NSLP which called SendMessage with "transfer-attributes=secure/reliable", it is also possible that the NSLP would NOT have required security (e.g. set only "reliable"). In this case, both nodes still send their full set of proposals, but the Q-Node is then free to use a "weak" connection. (The Q-Node would include it's full ability set, because it could be that the R-Node local policy would require secure connections) So selecting a "weak" Profile in case both nodes can support more secure ones can't be an error according to the spec. Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 12:25:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURcO-0006cC-Jr; Tue, 25 Oct 2005 12:25:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURcM-0006aT-SQ for nsis@megatron.ietf.org; Tue, 25 Oct 2005 12:25:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02994 for ; Tue, 25 Oct 2005 12:25:27 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURpL-0001MC-7A for nsis@ietf.org; Tue, 25 Oct 2005 12:39:08 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9PGPVZ6013265; Tue, 25 Oct 2005 18:25:31 +0200 (MEST) Message-ID: <050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Andrew McDonald" References: <435E506D.5010909@roke.co.uk> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Tue, 25 Oct 2005 18:25:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.417 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 25 Oct 2005 18:25:36 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew Please see in line! >> Georgios: agree, but in the case of RSVP aggregation the used user plane >> is the same as the user plane used by the end to end session, but this >> user plane uses different packet classifiers in the different end to end >> path locations! >> The described case in the thread allows a higher degree of modularity >> (i.e., since this is one of the main goals of NSIS). > > The different packet classifiers may be a sign that we should be using a > different signalling session. > > If we take RMD as an example, the per domain (i.e. end-to-end) reservation > and the per hop (i.e. aggregate-related) reservation are based on > different subsets of information in the MRI, and so require different > PACKET_CLASSIFIERs. The end-to-end signalling performs per-microflow > reservations based on something like the 5-tuple. The aggregate uses a > packet classifier which is just the DSCP. > > However, RMD (looking at, for example, figure 3 in the RMD draft) uses > separate signalling sessions for its 'per domain' and 'per hop' > reservations, so only a single PACKET_CLASSIFIER is needed for each > session. > > Allowing multiple classifiers seems possible, but does look like > unnecessary complexity. Georgios: Exactly this discussion is not related to the RMD concept! I think that the easier solution will just be to have a sentence in the QOS-NSLP draft which says: "The QOS-NSLP nodes SHOULD use one or more parameters included in the MRI for packet classification." In this way we will also allow nodes to use other types of parameters for packet classification, by e.g., using local node configuration. Please note that in this way the packet classification will work fine, it will be simple and it will solve the NAT translation problems mentioned by Cheng! Please note that something similar is proposed in the NAT./Firewall NSLP draft! Hannes also proposed the above the above solution in one of first e-mails relatted to this thread! Best regards, Georgios _______ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 25 23:43:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcCC-0002Sn-0E; Tue, 25 Oct 2005 23:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUcCA-0002Se-25 for nsis@megatron.ietf.org; Tue, 25 Oct 2005 23:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18834 for ; Tue, 25 Oct 2005 23:43:06 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUcPE-0000a0-Ud for nsis@ietf.org; Tue, 25 Oct 2005 23:56:53 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9Q3giWe014021; Wed, 26 Oct 2005 12:42:44 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9Q3gjf27571; Wed, 26 Oct 2005 12:42:45 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id j9Q3gix14875; Wed, 26 Oct 2005 12:42:44 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 26 Oct 2005 11:39:49 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD75AA08@pslexc01.psl.local> Thread-topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXZgIK9ErAhw8KjQT6CS3ID6QU6kAAUykwg From: "Cheng Hong" To: "Georgios Karagiannis" , "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: Takako Sanda , nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, and Andrew, and all, > I think that the easier solution will just be to have a=20 > sentence in the QOS-NSLP draft which says: >=20 > "The QOS-NSLP nodes SHOULD use one or more parameters=20 > included in the MRI for packet classification." >=20 This would be an easy way to address the NAT issue. We may also need to identify how to indicate that "one or more parameters" to be used for the packet classification. Maybe that is what the PACKET_CLASSIFIER is meant for.=20 However, this may result in an increment in the signaling session/messages when the MRI cannot provide enough information for the packet classification. Therefore, it would be a tradeoff between the signaling efficiency and complexity.=20 My feeling is that we at least need to allow some extra information to be included in the QoS-NSLP to complement the MRI for the packet classification. So, how about changing the sentence to: > "The QOS-NSLP nodes SHOULD use one or more parameters=20 > of the MRI, as indicated by PACKET_CLASSIFIER, for packet classification.=20 > When PACKET_CLASSIFIER indicates an additional packet classification object included > in QoS-NSLP, the additional object should be used for packet classification." As for the NAT traversal problem, I think it would not be an issue if we can make the indicator for this additional object and the object itself common for all the NSLPs (as a common function of all the NSLP). In this case, the NAT doesn't need to be specific NSLP aware to do the update of the object (same as treating the MRI). So far, I think this additional packet classification information is useful for QoS-NSLP, NAT/FW-NSLP, and also the recently discussed metering-NSLP.=20 For the stackable QSPEC issue raised by Georgios earlier in this thread, I am not sure how it could be solved by limiting the packet classification information to the MRI. If the intension is to preserve the packet classification information for a stacked QSPEC (which is different from the current MRI), the MRI itself also needs to be stackable (if it is the sole source of packet classification information).=20 cheers Cheng Hong =20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Georgios Karagiannis > Sent: Wednesday, October 26, 2005 12:25 AM > To: Andrew McDonald > Cc: nsis@ietf.org; Hannes.Tschofenig@siemens.com > Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >=20 > Hi Andrew >=20 > Please see in line! >=20 > >> Georgios: agree, but in the case of RSVP aggregation the used user=20 > >> plane is the same as the user plane used by the end to end=20 > session,=20 > >> but this user plane uses different packet classifiers in the=20 > >> different end to end path locations! > >> The described case in the thread allows a higher degree of=20 > >> modularity (i.e., since this is one of the main goals of NSIS). > > > > The different packet classifiers may be a sign that we=20 > should be using=20 > > a different signalling session. > > > > If we take RMD as an example, the per domain (i.e. end-to-end)=20 > > reservation and the per hop (i.e. aggregate-related)=20 > reservation are=20 > > based on different subsets of information in the MRI, and=20 > so require=20 > > different PACKET_CLASSIFIERs. The end-to-end signalling performs=20 > > per-microflow reservations based on something like the 5-tuple. The=20 > > aggregate uses a packet classifier which is just the DSCP. > > > > However, RMD (looking at, for example, figure 3 in the RMD=20 > draft) uses=20 > > separate signalling sessions for its 'per domain' and 'per hop' > > reservations, so only a single PACKET_CLASSIFIER is needed for each=20 > > session. > > > > Allowing multiple classifiers seems possible, but does look like=20 > > unnecessary complexity. >=20 > Georgios: Exactly this discussion is not related to the RMD concept! >=20 >=20 > I think that the easier solution will just be to have a=20 > sentence in the QOS-NSLP draft which says: >=20 > "The QOS-NSLP nodes SHOULD use one or more parameters=20 > included in the MRI for packet classification." >=20 > In this way we will also allow nodes to use other types of=20 > parameters for packet classification, by e.g., using local=20 > node configuration. >=20 > Please note that in this way the packet classification will=20 > work fine, it will be simple and it will solve the NAT=20 > translation problems mentioned by Cheng! >=20 > Please note that something similar is proposed in the=20 > NAT./Firewall NSLP draft! > Hannes also proposed the above the above solution in one of=20 > first e-mails relatted to this thread! >=20 > Best regards, > Georgios >=20 >=20 >=20 >=20 >=20 > _______ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 04:18:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgRd-00081o-It; Wed, 26 Oct 2005 04:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgRa-00080l-Uq for nsis@megatron.ietf.org; Wed, 26 Oct 2005 04:15:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02815 for ; Wed, 26 Oct 2005 04:15:19 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUged-0000UR-TG for nsis@ietf.org; Wed, 26 Oct 2005 04:29:05 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9Q8FKQV024155; Wed, 26 Oct 2005 10:15:21 +0200 (MEST) Message-ID: <001101c5da05$6a300230$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Cheng Hong" , "Andrew McDonald" References: <5F09D220B62F79418461A978CA0921BD75AA08@pslexc01.psl.local> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 10:15:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.413 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 10:15:27 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, Takako Sanda , Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cheng Please see in line. ----- Original Message ----- From: "Cheng Hong" To: "Georgios Karagiannis" ; "Andrew McDonald" Cc: "Takako Sanda" ; ; Sent: Wednesday, October 26, 2005 5:39 AM Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi Georgios, and Andrew, and all, > >> I think that the easier solution will just be to have a >> sentence in the QOS-NSLP draft which says: >> >> "The QOS-NSLP nodes SHOULD use one or more parameters >> included in the MRI for packet classification." >> > > This would be an easy way to address the NAT issue. We may also need to > identify how to indicate that "one or more parameters" to be used for > the packet classification. Maybe that is what the PACKET_CLASSIFIER is > meant for. Georgios: This will have to be defined by the used QoS model, and should not be signaled. If a QoS model needs to use other parameters then it will be able to configure them! This is up to the QoS model. > However, this may result in an increment in the signaling > session/messages when the MRI cannot provide enough information for the > packet classification. Therefore, it would be a tradeoff between the > signaling efficiency and complexity. > > My feeling is that we at least need to allow some extra information to > be included in the QoS-NSLP to complement the MRI for the packet > classification. So, how about changing the sentence to: > >> "The QOS-NSLP nodes SHOULD use one or more parameters >> of the MRI, as indicated by PACKET_CLASSIFIER, for packet > classification. >> When PACKET_CLASSIFIER indicates an additional packet classification > object included >> in QoS-NSLP, the additional object should be used for packet > classification." Georgios: The stacking problems will not allow to just use a PACKET CLASSIFIER QoS-NSLP object. You have either to generate a stacked PACKET_CLASSIFIER QOS-NSLP object or you have to included in the QSPEC. But as I mentioned above, this information does not have to be signaled. > As for the NAT traversal problem, I think it would not be an issue if we > can make the indicator for this additional object and the object itself > common for all the NSLPs (as a common function of all the NSLP). In this > case, the NAT doesn't need to be specific NSLP aware to do the update of > the object (same as treating the MRI). So far, I think this additional > packet classification information is useful for QoS-NSLP, NAT/FW-NSLP, > and also the recently discussed metering-NSLP. Georgios: But this solution will only work if we mandate that the NATP is NAT-NSLP aware, QoS-NSLP-aware, ...-NSLP aware, etc.. I think we do not want to impose such requirements! > For the stackable QSPEC issue raised by Georgios earlier in this thread, > I am not sure how it could be solved by limiting the packet > classification information to the MRI. Georgios: It can be solved since the GIST should update the MRI, if the GIST session traverses a NATP that modifies the source/destination port and addresses, then GIST should modify ther MRI. All the NSLPs are using the MRI that is provided by GIST. In this case the described problem by you will be solved. > the packet classification information for a stacked QSPEC (which is > different from the current MRI), the MRI itself also needs to be > stackable (if it is the sole source of packet classification > information). Georgios: No, please see my comment above! Best Regards, Georgios > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of Georgios Karagiannis >> Sent: Wednesday, October 26, 2005 12:25 AM >> To: Andrew McDonald >> Cc: nsis@ietf.org; Hannes.Tschofenig@siemens.com >> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >> >> Hi Andrew >> >> Please see in line! >> >> >> Georgios: agree, but in the case of RSVP aggregation the used user >> >> plane is the same as the user plane used by the end to end >> session, >> >> but this user plane uses different packet classifiers in the >> >> different end to end path locations! >> >> The described case in the thread allows a higher degree of >> >> modularity (i.e., since this is one of the main goals of NSIS). >> > >> > The different packet classifiers may be a sign that we >> should be using >> > a different signalling session. >> > >> > If we take RMD as an example, the per domain (i.e. end-to-end) >> > reservation and the per hop (i.e. aggregate-related) >> reservation are >> > based on different subsets of information in the MRI, and >> so require >> > different PACKET_CLASSIFIERs. The end-to-end signalling performs >> > per-microflow reservations based on something like the 5-tuple. The >> > aggregate uses a packet classifier which is just the DSCP. >> > >> > However, RMD (looking at, for example, figure 3 in the RMD >> draft) uses >> > separate signalling sessions for its 'per domain' and 'per hop' >> > reservations, so only a single PACKET_CLASSIFIER is needed for each >> > session. >> > >> > Allowing multiple classifiers seems possible, but does look like >> > unnecessary complexity. >> >> Georgios: Exactly this discussion is not related to the RMD concept! >> >> >> I think that the easier solution will just be to have a >> sentence in the QOS-NSLP draft which says: >> >> "The QOS-NSLP nodes SHOULD use one or more parameters >> included in the MRI for packet classification." >> >> In this way we will also allow nodes to use other types of >> parameters for packet classification, by e.g., using local >> node configuration. >> >> Please note that in this way the packet classification will >> work fine, it will be simple and it will solve the NAT >> translation problems mentioned by Cheng! >> >> Please note that something similar is proposed in the >> NAT./Firewall NSLP draft! >> Hannes also proposed the above the above solution in one of >> first e-mails relatted to this thread! >> >> Best regards, >> Georgios >> >> >> >> >> >> _______ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> > >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 04:41:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgqy-00085o-3q; Wed, 26 Oct 2005 04:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgqv-00083F-N7 for nsis@megatron.ietf.org; Wed, 26 Oct 2005 04:41:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04104 for ; Wed, 26 Oct 2005 04:41:30 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUh43-0001Hv-1z for nsis@ietf.org; Wed, 26 Oct 2005 04:55:20 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9Q8fMWe003249; Wed, 26 Oct 2005 17:41:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9Q8fO019624; Wed, 26 Oct 2005 17:41:24 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with SMTP id j9Q8fOG28562; Wed, 26 Oct 2005 17:41:24 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 26 Oct 2005 16:38:30 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD75AAED@pslexc01.psl.local> Thread-topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXaBRmwNd4GfzSMROWvrAwamSvCGQAAHgBw From: "Cheng Hong" To: "Georgios Karagiannis" , "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org, Takako Sanda , Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, Please see some comments below: > > > > This would be an easy way to address the NAT issue. We may=20 > also need=20 > > to identify how to indicate that "one or more parameters"=20 > to be used=20 > > for the packet classification. Maybe that is what the=20 > > PACKET_CLASSIFIER is meant for. >=20 > Georgios: This will have to be defined by the used QoS model,=20 > and should not be signaled. > If a QoS model needs to use other parameters then it will be=20 > able to configure them! > This is up to the QoS model. You are right that the QoS Model needs to define what should to be signaled. The concern is that what the QoS Model defined may not be able to be signaled by using the MRI only. The QoS Model can define a format, no the contents, because the actual packet classificaiton information (defined within a QoS Model) could be affected by the operation. As what we discussed earlier, for example, a QoS Model could define that a MF classifier is needed, however, it cannot predict that whether the port number should be wildcarded or a specific port should be used. Whether to use the port number (or multiple port number) still needs to be signaled over between QNEs (by using something else than MRI). =20 > > My feeling is that we at least need to allow some extra=20 > information to=20 > > be included in the QoS-NSLP to complement the MRI for the packet=20 > > classification. So, how about changing the sentence to: > > > >> "The QOS-NSLP nodes SHOULD use one or more parameters of=20 > the MRI, as=20 > >> indicated by PACKET_CLASSIFIER, for packet > > classification. > >> When PACKET_CLASSIFIER indicates an additional packet=20 > classification > > object included > >> in QoS-NSLP, the additional object should be used for packet > > classification." >=20 > Georgios: The stacking problems will not allow to just use a=20 > PACKET CLASSIFIER QoS-NSLP object. You have either to=20 > generate a stacked PACKET_CLASSIFIER QOS-NSLP object or you=20 > have to included in the QSPEC. > But as I mentioned above, this information does not have to=20 > be signaled. Yes. If the QSPEC stacking is to be supported, the object has to be stackable also, as we discussed before. Maybe a simple way out of this is to limit the stackable option of the QSPEC (disallow that), if we want to avoid the problem. Even if we limit the information to the MRI, we still may face the problem for the stackable issue on MRI. (please see comments below regarding the stackable MRI issue) =20 > > As for the NAT traversal problem, I think it would not be=20 > an issue if=20 > > we can make the indicator for this additional object and the object=20 > > itself common for all the NSLPs (as a common function of all the=20 > > NSLP). In this case, the NAT doesn't need to be specific=20 > NSLP aware to=20 > > do the update of the object (same as treating the MRI). So far, I=20 > > think this additional packet classification information is=20 > useful for=20 > > QoS-NSLP, NAT/FW-NSLP, and also the recently discussed=20 > metering-NSLP. >=20 > Georgios: But this solution will only work if we mandate that=20 > the NATP is NAT-NSLP aware, QoS-NSLP-aware, ...-NSLP aware, etc.. > I think we do not want to impose such requirements! If every NSLP has the same format, the NAT doesn't need to understand/know which NSLP is that. It only process the common formated information element for the packet_classifier if it is present. (well, that may require an indicator for its presence be placed in the common header, not tied to message type) > > For the stackable QSPEC issue raised by Georgios earlier in this=20 > > thread, I am not sure how it could be solved by limiting the packet=20 > > classification information to the MRI. >=20 > Georgios: It can be solved since the GIST should update the=20 > MRI, if the GIST session traverses a NATP that modifies the=20 > source/destination port and addresses, then GIST should=20 > modify ther MRI. > All the NSLPs are using the MRI that is provided by GIST. In=20 > this case the described problem by you will be solved. Please note that this is not about the NAT issue. It is on the stacking support of the QSPEC you mentioned earlier: "> As you can see the packet classifier information and the=20 > QSPEC are very much dependent to each other. > Thus there is a one to one matching between the packet=20 > classifier and the QSPEC. > This means that the NSIS protocol suite needs to support=20 > the following > functionalities: > * packet classifier (B) information should not destroy the=20 > packet classifier (A) information > * The packet classifier, say packet classifier (A), =20 > associated with a QSPEC, say QSPEC (A), > must only be used in the domains that are using QSPEC (A). > * If a QoS model does not recognise a QSPEC, say QSPEC (A)=20 > then it should not do > anything with its associated packet classifier, say=20 > packet classifier (A). " So in this case, if the MRI is the sole source of information for the packet_classifier, does it also needs to be stackable? cheers Cheng Hong > > the packet classification information for a stacked QSPEC (which is=20 > > different from the current MRI), the MRI itself also needs to be=20 > > stackable (if it is the sole source of packet classification=20 > > information). >=20 > Georgios: No, please see my comment above! >=20 > Best Regards, > Georgios >=20 > > > >> -----Original Message----- > >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > On Behalf=20 > >> Of Georgios Karagiannis > >> Sent: Wednesday, October 26, 2005 12:25 AM > >> To: Andrew McDonald > >> Cc: nsis@ietf.org; Hannes.Tschofenig@siemens.com > >> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > >> > >> Hi Andrew > >> > >> Please see in line! > >> > >> >> Georgios: agree, but in the case of RSVP aggregation=20 > the used user=20 > >> >> plane is the same as the user plane used by the end to end > >> session, > >> >> but this user plane uses different packet classifiers in the=20 > >> >> different end to end path locations! > >> >> The described case in the thread allows a higher degree of=20 > >> >> modularity (i.e., since this is one of the main goals of NSIS). > >> > > >> > The different packet classifiers may be a sign that we > >> should be using > >> > a different signalling session. > >> > > >> > If we take RMD as an example, the per domain (i.e. end-to-end)=20 > >> > reservation and the per hop (i.e. aggregate-related) > >> reservation are > >> > based on different subsets of information in the MRI, and > >> so require > >> > different PACKET_CLASSIFIERs. The end-to-end signalling performs=20 > >> > per-microflow reservations based on something like the=20 > 5-tuple. The=20 > >> > aggregate uses a packet classifier which is just the DSCP. > >> > > >> > However, RMD (looking at, for example, figure 3 in the RMD > >> draft) uses > >> > separate signalling sessions for its 'per domain' and 'per hop' > >> > reservations, so only a single PACKET_CLASSIFIER is=20 > needed for each=20 > >> > session. > >> > > >> > Allowing multiple classifiers seems possible, but does look like=20 > >> > unnecessary complexity. > >> > >> Georgios: Exactly this discussion is not related to the=20 > RMD concept! > >> > >> > >> I think that the easier solution will just be to have a=20 > sentence in=20 > >> the QOS-NSLP draft which says: > >> > >> "The QOS-NSLP nodes SHOULD use one or more parameters=20 > included in the=20 > >> MRI for packet classification." > >> > >> In this way we will also allow nodes to use other types of=20 > parameters=20 > >> for packet classification, by e.g., using local node configuration. > >> > >> Please note that in this way the packet classification will work=20 > >> fine, it will be simple and it will solve the NAT translation=20 > >> problems mentioned by Cheng! > >> > >> Please note that something similar is proposed in the=20 > NAT./Firewall=20 > >> NSLP draft! > >> Hannes also proposed the above the above solution in one of first=20 > >> e-mails relatted to this thread! > >> > >> Best regards, > >> Georgios > >> > >> > >> > >> > >> > >> _______ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > > >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 04:51:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUh04-0003NG-3z; Wed, 26 Oct 2005 04:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUh01-0003NB-Oj for nsis@megatron.ietf.org; Wed, 26 Oct 2005 04:51:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04816 for ; Wed, 26 Oct 2005 04:50:54 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUhD8-0001Zk-Dr for nsis@ietf.org; Wed, 26 Oct 2005 05:04:44 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9Q8oHWA000376; Wed, 26 Oct 2005 09:50:17 +0100 Received: from [193.118.197.247] ([193.118.197.247]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 09:50:17 +0100 Message-ID: <435F4348.5070703@roke.co.uk> Date: Wed, 26 Oct 2005 09:50:16 +0100 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <435E506D.5010909@roke.co.uk> <050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2005 08:50:17.0764 (UTC) FILETIME=[4A197E40:01C5DA0A] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios Karagiannis wrote: >> The different packet classifiers may be a sign that we should be using >> a different signalling session. >> >> If we take RMD as an example, the per domain (i.e. end-to-end) >> reservation and the per hop (i.e. aggregate-related) reservation are >> based on different subsets of information in the MRI, and so require >> different PACKET_CLASSIFIERs. The end-to-end signalling performs >> per-microflow reservations based on something like the 5-tuple. The >> aggregate uses a packet classifier which is just the DSCP. >> >> However, RMD (looking at, for example, figure 3 in the RMD draft) uses >> separate signalling sessions for its 'per domain' and 'per hop' >> reservations, so only a single PACKET_CLASSIFIER is needed for each >> session. >> >> Allowing multiple classifiers seems possible, but does look like >> unnecessary complexity. > > > Georgios: Exactly this discussion is not related to the RMD concept! OK. Examples based on using "flow ID" in one classifier, and "DSCP" in another had obviously misled me. I've may have got lost in the ebbs and flows of this thread. However, that doesn't change my concluding thought - in fact it probably reinforces it, since I haven't seen any compelling examples of why multiple packet classifiers are required. > I think that the easier solution will just be to have a sentence in the > QOS-NSLP draft > which says: > > "The QOS-NSLP nodes SHOULD use one or more parameters included in the > MRI for packet classification." > > In this way we will also allow nodes to use other types of parameters > for packet classification, > by e.g., using local node configuration. There is a fairly significant difference between signalling this information and leaving it up to individual nodes. Particular issues that come to mind: - if you don't signal it then the QNI doesn't know what traffic will be treated as part of the reservation it is requesting - it makes the definition of whether two signalling messages are about the same flow a local configuration (or QoS model dependent) issue - there may be authorisation issues, in terms of what traffic/reservation is actually being requested and authorised by the authorisation information provided in the signalling Consequently, I'm uncomfortable with leaving this totally up to local configuration. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 05:09:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhHk-0004lT-IT; Wed, 26 Oct 2005 05:09:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhHi-0004kD-LA for nsis@megatron.ietf.org; Wed, 26 Oct 2005 05:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05636 for ; Wed, 26 Oct 2005 05:09:11 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUhUq-00023P-O9 for nsis@ietf.org; Wed, 26 Oct 2005 05:23:01 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9Q99LuI027428; Wed, 26 Oct 2005 11:09:21 +0200 (MEST) Message-ID: <005c01c5da0c$f4b1e890$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Cheng Hong" , "Andrew McDonald" References: <5F09D220B62F79418461A978CA0921BD75AAED@pslexc01.psl.local> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 11:09:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.413 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 11:09:23 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: Takako Sanda , nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cheng Please see in line! ----- Original Message ----- From: "Cheng Hong" To: "Georgios Karagiannis" ; "Andrew McDonald" Cc: ; "Takako Sanda" ; Sent: Wednesday, October 26, 2005 10:38 AM Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi Georgios, > > Please see some comments below: > > >> > >> > This would be an easy way to address the NAT issue. We may >> also need >> > to identify how to indicate that "one or more parameters" >> to be used >> > for the packet classification. Maybe that is what the >> > PACKET_CLASSIFIER is meant for. >> >> Georgios: This will have to be defined by the used QoS model, >> and should not be signaled. >> If a QoS model needs to use other parameters then it will be >> able to configure them! >> This is up to the QoS model. > > You are right that the QoS Model needs to define what should to be > signaled. The concern is that what the QoS Model defined may not be able > to be signaled by using the MRI only. The QoS Model can define a format, > no the contents, because the actual packet classificaiton information > (defined within a QoS Model) could be affected by the operation. As what > we discussed earlier, for example, a QoS Model could define that a MF > classifier is needed, however, it cannot predict that whether the port > number should be wildcarded or a specific port should be used. Whether > to use the port number (or multiple port number) still needs to be > signaled over between QNEs (by using something else than MRI). Georgios: Why? A QoS model can configure locally a node to use the MF classifier for packet classification. Another case will be that the QOS model will configure the edge of the QoS model to use the MF classifier and that then this edge will signal this information to all intermediary nodes (that are using the same QoS model) to use this information for packet classification. In both approaches the QoS model has to configure that! > > >> > My feeling is that we at least need to allow some extra >> information to >> > be included in the QoS-NSLP to complement the MRI for the packet >> > classification. So, how about changing the sentence to: >> > >> >> "The QOS-NSLP nodes SHOULD use one or more parameters of >> the MRI, as >> >> indicated by PACKET_CLASSIFIER, for packet >> > classification. >> >> When PACKET_CLASSIFIER indicates an additional packet >> classification >> > object included >> >> in QoS-NSLP, the additional object should be used for packet >> > classification." >> >> Georgios: The stacking problems will not allow to just use a >> PACKET CLASSIFIER QoS-NSLP object. You have either to >> generate a stacked PACKET_CLASSIFIER QOS-NSLP object or you >> have to included in the QSPEC. >> But as I mentioned above, this information does not have to >> be signaled. > > Yes. If the QSPEC stacking is to be supported, the object has to be > stackable also, as we discussed before. Maybe a simple way out of this > is to limit the stackable option of the QSPEC (disallow that), if we > want to avoid the problem. Even if we limit the information to the MRI, > we still may face the problem for the stackable issue on MRI. (please > see comments below regarding the stackable MRI issue) Georgios: Well I do not thing that this is the right solution. I do not understand why you think that stacking is needed. We do not need to stack the MRI. Each QoS model will choose the parameters from ther MRI! > >> > As for the NAT traversal problem, I think it would not be >> an issue if >> > we can make the indicator for this additional object and the object >> > itself common for all the NSLPs (as a common function of all the >> > NSLP). In this case, the NAT doesn't need to be specific >> NSLP aware to >> > do the update of the object (same as treating the MRI). So far, I >> > think this additional packet classification information is >> useful for >> > QoS-NSLP, NAT/FW-NSLP, and also the recently discussed >> metering-NSLP. >> >> Georgios: But this solution will only work if we mandate that >> the NATP is NAT-NSLP aware, QoS-NSLP-aware, ...-NSLP aware, etc.. >> I think we do not want to impose such requirements! > > If every NSLP has the same format, the NAT doesn't need to > understand/know which NSLP is that. It only process the common formated > information element for the packet_classifier if it is present. (well, > that may require an indicator for its presence be placed in the common > header, not tied to message type) Georgios: Not sure if this can be applied. The NATP has to recognise all types of NSLSP messages in order to do that. Thus it should be all-NSLP aware. > >> > For the stackable QSPEC issue raised by Georgios earlier in this >> > thread, I am not sure how it could be solved by limiting the packet >> > classification information to the MRI. >> >> Georgios: It can be solved since the GIST should update the >> MRI, if the GIST session traverses a NATP that modifies the >> source/destination port and addresses, then GIST should >> modify ther MRI. >> All the NSLPs are using the MRI that is provided by GIST. In >> this case the described problem by you will be solved. > > Please note that this is not about the NAT issue. It is on the stacking > support of the QSPEC you mentioned earlier: Georgios: Well each QoS model will choose the required parameters from the MRI. Thus QoS model A will choose some parameters from MRI and QoS model B will choose other parameters from the same MRI. Thus MRI does not need to be stackable! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 05:21:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhTi-00038N-N5; Wed, 26 Oct 2005 05:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhTf-00038I-W2 for nsis@megatron.ietf.org; Wed, 26 Oct 2005 05:21:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06260 for ; Wed, 26 Oct 2005 05:21:32 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUhgn-0002QS-8j for nsis@ietf.org; Wed, 26 Oct 2005 05:35:22 -0400 Received: from venus.office (ftp.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C2FDEDA0F; Wed, 26 Oct 2005 11:21:27 +0200 (CEST) Received: from [10.1.1.109] ([10.1.1.109]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 11:21:27 +0200 Date: Wed, 26 Oct 2005 11:21:27 +0200 From: Martin Stiemerling To: Roland Bless , Ali Fessi Subject: Re: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP Message-ID: In-Reply-To: <435944AF.7070604@tm.uka.de> References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 26 Oct 2005 09:21:27.0708 (UTC) FILETIME=[A4AC4DC0:01C5DA0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: Falko Dressler , nsis , Tschofenig Hannes , Changpeng Fan , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, comments are inline. --On Freitag, 21. Oktober 2005 21:42 Uhr +0200 Roland Bless wrote: | Hi Ali, | | (comments inline) | | Ali Fessi wrote: | |> Section: 4.2.6.1 The Object |> |> restricts the set of considered flows for the metering. |> The MSPEC MUST support a value for that is different from |> the flow information kept at GIST. In particular, could be |> for example, a 5-tuple where one or more fields are wild-carded. |> |> For example, it MUST be possible to count all TCP SYN packets or all |> ICMP packets going to a given destination IP address. |> |> -------------- | | The MF classifier definition from RFC 2475 is quite generic | and could possibly be referenced here. | |> The reason is whether it makes sense to use NSIS for the configuration |> of Metering Entities on the path from A to B to measure characteristics |> of other flows than the ones going from A to B. | | That's an interesting question. On one hand this may be error prone, | but see examples below. | |> I would like to ask you for your opinion on this topic: |> |> - do you think that the specification of the flows to be measured should |> be restricted to the MRI from GIST. | |> -Or do you think it should be as flexible as possible? | | IMHO it would be good to be at least more flexible in the sense that | you're interested in a subset of the aggregate that is defined | by the MRI between A and B. For example, I think it is perfectly | legitimate to measure or sample only certain TCP packets (as in your | example above) or certain ICMP messages or even particular HTTP | messages. | So the MRI would match an aggregate flowing from A to B, and you're | interested in a particular sub aggregate within. So the logic within | the NSLP could check the semantics, i.e. whether the filter is | actually picking a subset of the MRI. I can second this. It is quite useful to extend the information by the MRI on the NSLP level. The NATFW NSLP is doing something similar with the extended flow information object and the data terminal object. Both extend the MRI by limiting the flow spec. | | OTOH I can imagine a scenario where you are configuring | filter for packets that are normally and currently *not* | flowing on the path from A to B. So the filter would be | used to detect/measure some failure conditions or anomalies. In this | case it would be even useful to configure filters along | A->B so that they match flows that are currently not routed | along that path. This would not be purely "path-coupled" anymore, since your are signaling for flows apart your path. Is see the only envisioned use case for this filter spec in Section 4.3 "Monitoring for Network Security" of the M-NSLP framework draft. However, I do not see the value of this use case and therefore objecting the proposed semantics. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 05:24:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhVo-0003l9-E2; Wed, 26 Oct 2005 05:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhVm-0003l4-Pa for nsis@megatron.ietf.org; Wed, 26 Oct 2005 05:23:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06351 for ; Wed, 26 Oct 2005 05:23:43 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUhit-0002TU-VC for nsis@ietf.org; Wed, 26 Oct 2005 05:37:33 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9Q9NrPW028281; Wed, 26 Oct 2005 11:23:53 +0200 (MEST) Message-ID: <006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Andrew McDonald" References: <435E506D.5010909@roke.co.uk><050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl> <435F4348.5070703@roke.co.uk> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 11:23:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.412 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 11:23:54 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org -//- snip > >> I think that the easier solution will just be to have a sentence in the >> QOS-NSLP draft >> which says: >> >> "The QOS-NSLP nodes SHOULD use one or more parameters included in the MRI >> for packet classification." >> >> In this way we will also allow nodes to use other types of parameters for >> packet classification, >> by e.g., using local node configuration. > > There is a fairly significant difference between signalling this > information and leaving it up to individual nodes. Particular issues that > come to mind: > - if you don't signal it then the QNI doesn't know what traffic will be > treated as part of the reservation it is requesting Georgios: why not? > - it makes the definition of whether two signalling messages are about the > same flow a local configuration (or QoS model dependent) issue Georgios: Please see some previous e-mails in this thread. It is a QoS model issue. > - there may be authorisation issues, in terms of what traffic/reservation > is actually being requested and authorised by the authorisation > information provided in the signalling Georgios: but if the node accepts the QSPEC then there is no problem! A node can process a QSPEC only if it is able to recognise it. This means that the packet classifier is also configured. Best Regards, Georgios > Consequently, I'm uncomfortable with leaving this totally up to local > configuration. > > > Andrew > > _______________________________________________ > 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 nsis-bounces@ietf.org Wed Oct 26 05:40:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhm0-00049Z-Se; Wed, 26 Oct 2005 05:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhlz-00049T-T6 for nsis@megatron.ietf.org; Wed, 26 Oct 2005 05:40:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07221 for ; Wed, 26 Oct 2005 05:40:27 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUhz6-0002xf-L7 for nsis@ietf.org; Wed, 26 Oct 2005 05:54:18 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9Q9dwWA013279; Wed, 26 Oct 2005 10:39:58 +0100 Received: from [193.118.197.247] ([193.118.197.247]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 10:39:58 +0100 Message-ID: <435F4EED.6080401@roke.co.uk> Date: Wed, 26 Oct 2005 10:39:57 +0100 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cheng Hong Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <5F09D220B62F79418461A978CA0921BD75AA08@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD75AA08@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2005 09:39:58.0308 (UTC) FILETIME=[3AA46A40:01C5DA11] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: Georgios Karagiannis , Takako Sanda , nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cheng Hong, some comments below Cheng Hong wrote: >>I think that the easier solution will just be to have a >>sentence in the QOS-NSLP draft which says: >> >>"The QOS-NSLP nodes SHOULD use one or more parameters >>included in the MRI for packet classification." > > This would be an easy way to address the NAT issue. We may also need to > identify how to indicate that "one or more parameters" to be used for > the packet classification. Maybe that is what the PACKET_CLASSIFIER is > meant for. > > However, this may result in an increment in the signaling > session/messages when the MRI cannot provide enough information for the > packet classification. Therefore, it would be a tradeoff between the > signaling efficiency and complexity. > > My feeling is that we at least need to allow some extra information to > be included in the QoS-NSLP to complement the MRI for the packet > classification. So, how about changing the sentence to: > >>"The QOS-NSLP nodes SHOULD use one or more parameters >>of the MRI, as indicated by PACKET_CLASSIFIER, for packet >> classification. > >>When PACKET_CLASSIFIER indicates an additional packet classification >> object included >>in QoS-NSLP, the additional object should be used for packet >> classification." > > As for the NAT traversal problem, I think it would not be an issue if we > can make the indicator for this additional object and the object itself > common for all the NSLPs (as a common function of all the NSLP). In this > case, the NAT doesn't need to be specific NSLP aware to do the update of > the object (same as treating the MRI). So far, I think this additional > packet classification information is useful for QoS-NSLP, NAT/FW-NSLP, > and also the recently discussed metering-NSLP. There are a couple of cases to consider when thinking about how the packet classifier may deviate from the MRI. In the first case you want more information for the packet classifier than is carried by the MRI. One issue with this is that of message routing - would the extra fields cause a divergence from the MRI-based path, e.g. if you provide a 'port range' then would some load balancer route the traffic all the same way? Also, adverse NAT-effects may be caused e.g. if you identify ports above the GIST layer, then an 'NSIS-aware NAT' has to look at more than just GIST. The nature of on-path signalling makes this one difficult for the obvious things you might want to do. There may be some cases where it will work where the additional information is from higher layers which you are certain do not affect the routing and NATs do not touch. In the second case you want less information than is carried within the MRI, though actually this still requires some additional information: i.e. which bits of the MRI should be used. As you say, this is what the current 'packet classifier flags' are doing. You don't have any NAT issues at the NSLP, since the NAT-relevant information is all carried in the GIST layer. > For the stackable QSPEC issue raised by Georgios earlier in this thread, > I am not sure how it could be solved by limiting the packet > classification information to the MRI. If the intension is to preserve > the packet classification information for a stacked QSPEC (which is > different from the current MRI), the MRI itself also needs to be > stackable (if it is the sole source of packet classification > information). I have no idea what a "stackable MRI" means in the context of GIST. MRI = message routing information. If you have one message with two MRIs, which way do you route it? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 05:43:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhoD-0004Qa-Hs; Wed, 26 Oct 2005 05:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhoA-0004Pi-J9 for nsis@megatron.ietf.org; Wed, 26 Oct 2005 05:43:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07373 for ; Wed, 26 Oct 2005 05:42:42 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUi1I-00032d-Hz for nsis@ietf.org; Wed, 26 Oct 2005 05:56:33 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9Q9gaJh007221; Wed, 26 Oct 2005 18:42:36 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9Q9gb015780; Wed, 26 Oct 2005 18:42:37 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id j9Q9gbA18260; Wed, 26 Oct 2005 18:42:37 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 26 Oct 2005 17:39:41 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD75AB1C@pslexc01.psl.local> Thread-topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXaDJwSNgXK4k2QR9KTop2O9l0gzwAAvdcQ From: "Cheng Hong" To: "Georgios Karagiannis" , "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable Cc: Takako Sanda , nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, Please see some comments below: > Georgios: Why? > A QoS model can configure locally a node to use the MF=20 > classifier for packet classification. Yes. That is to be defined by the QoS Model.=20 > Another case will be that the QOS model will configure the=20 > edge of the QoS model to use the MF classifier and that then=20 > this edge will signal this information to all intermediary=20 > nodes (that are using the same QoS model) to use this=20 > information for packet classification. You mean there would be a separate (local) signaling session between QNEs of same QoS Model to dynamically setup which field of the MF classifier should be used for packet classification?=20 > > If every NSLP has the same format, the NAT doesn't need to=20 > > understand/know which NSLP is that. It only process the common=20 > > formated information element for the packet_classifier if it is=20 > > present. (well, that may require an indicator for its presence be=20 > > placed in the common header, not tied to message type) >=20 > Georgios: Not sure if this can be applied. > The NATP has to recognise all types of NSLSP messages in=20 > order to do that. > Thus it should be all-NSLP aware. If there is an indicator in the header to specify if there is an packet calssification object contained in the message (of a fix position), the NAT doesn't have to the x-NSLP aware. That is what I meant with the words in the bracket. It may not be that good, but it is a possible solution. > Georgios: Well each QoS model will choose the required=20 > parameters from the MRI. > Thus QoS model A will choose some parameters from MRI and QoS=20 > model B will choose other parameters from the same MRI. Thus=20 > MRI does not need to be stackable! This is only when the QoS Model A and QoS Model B uses the same information for the packet classification (from different parts of the MRI). However, if they use different info, that may not work. That is when the MRI needs to be stackable (when classifier A and classifier B cannot be represented by the same MRI). cheers Cheng Hong =20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Wednesday, October 26, 2005 5:09 PM > To: Cheng Hong; Andrew McDonald > Cc: nsis@ietf.org; Takako Sanda; Hannes.Tschofenig@siemens.com > Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >=20 > Hi Cheng >=20 > Please see in line! >=20 > ----- Original Message ----- > From: "Cheng Hong" > To: "Georgios Karagiannis" ; "Andrew=20 > McDonald"=20 > > Cc: ; "Takako Sanda"=20 > ; > Sent: Wednesday, October 26, 2005 10:38 AM > Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >=20 >=20 > > Hi Georgios, > > > > Please see some comments below: > > > > > >> > > >> > This would be an easy way to address the NAT issue. We may > >> also need > >> > to identify how to indicate that "one or more parameters" > >> to be used > >> > for the packet classification. Maybe that is what the=20 > >> > PACKET_CLASSIFIER is meant for. > >> > >> Georgios: This will have to be defined by the used QoS model, and=20 > >> should not be signaled. > >> If a QoS model needs to use other parameters then it will=20 > be able to=20 > >> configure them! > >> This is up to the QoS model. > > > > You are right that the QoS Model needs to define what should to be=20 > > signaled. The concern is that what the QoS Model defined may not be=20 > > able to be signaled by using the MRI only. The QoS Model=20 > can define a=20 > > format, no the contents, because the actual packet classificaiton=20 > > information (defined within a QoS Model) could be affected by the=20 > > operation. As what we discussed earlier, for example, a QoS Model=20 > > could define that a MF classifier is needed, however, it cannot=20 > > predict that whether the port number should be wildcarded or a=20 > > specific port should be used. Whether to use the port number (or=20 > > multiple port number) still needs to be signaled over=20 > between QNEs (by using something else than MRI). >=20 > Georgios: Why? > A QoS model can configure locally a node to use the MF=20 > classifier for packet classification. > Another case will be that the QOS model will configure the=20 > edge of the QoS model to use the MF classifier and that then=20 > this edge will signal this information to all intermediary=20 > nodes (that are using the same QoS model) to use this=20 > information for packet classification. > In both approaches the QoS model has to configure that! >=20 >=20 > > > > > >> > My feeling is that we at least need to allow some extra > >> information to > >> > be included in the QoS-NSLP to complement the MRI for the packet=20 > >> > classification. So, how about changing the sentence to: > >> > > >> >> "The QOS-NSLP nodes SHOULD use one or more parameters of > >> the MRI, as > >> >> indicated by PACKET_CLASSIFIER, for packet > >> > classification. > >> >> When PACKET_CLASSIFIER indicates an additional packet > >> classification > >> > object included > >> >> in QoS-NSLP, the additional object should be used for packet > >> > classification." > >> > >> Georgios: The stacking problems will not allow to just use=20 > a PACKET=20 > >> CLASSIFIER QoS-NSLP object. You have either to generate a stacked=20 > >> PACKET_CLASSIFIER QOS-NSLP object or you have to included in the=20 > >> QSPEC. > >> But as I mentioned above, this information does not have to be=20 > >> signaled. > > > > Yes. If the QSPEC stacking is to be supported, the object has to be=20 > > stackable also, as we discussed before. Maybe a simple way=20 > out of this=20 > > is to limit the stackable option of the QSPEC (disallow=20 > that), if we=20 > > want to avoid the problem. Even if we limit the information to the=20 > > MRI, we still may face the problem for the stackable issue on MRI.=20 > > (please see comments below regarding the stackable MRI issue) >=20 > Georgios: Well I do not thing that this is the right solution. > I do not understand why you think that stacking is needed. >=20 > We do not need to stack the MRI. Each QoS model will choose=20 > the parameters from ther MRI! >=20 > > > >> > As for the NAT traversal problem, I think it would not be > >> an issue if > >> > we can make the indicator for this additional object and=20 > the object=20 > >> > itself common for all the NSLPs (as a common function of all the=20 > >> > NSLP). In this case, the NAT doesn't need to be specific > >> NSLP aware to > >> > do the update of the object (same as treating the MRI).=20 > So far, I=20 > >> > think this additional packet classification information is > >> useful for > >> > QoS-NSLP, NAT/FW-NSLP, and also the recently discussed > >> metering-NSLP. > >> > >> Georgios: But this solution will only work if we mandate that the=20 > >> NATP is NAT-NSLP aware, QoS-NSLP-aware, ...-NSLP aware, etc.. > >> I think we do not want to impose such requirements! > > > > If every NSLP has the same format, the NAT doesn't need to=20 > > understand/know which NSLP is that. It only process the common=20 > > formated information element for the packet_classifier if it is=20 > > present. (well, that may require an indicator for its presence be=20 > > placed in the common header, not tied to message type) >=20 > Georgios: Not sure if this can be applied. > The NATP has to recognise all types of NSLSP messages in=20 > order to do that. > Thus it should be all-NSLP aware. >=20 > > > >> > For the stackable QSPEC issue raised by Georgios earlier in this=20 > >> > thread, I am not sure how it could be solved by limiting=20 > the packet=20 > >> > classification information to the MRI. > >> > >> Georgios: It can be solved since the GIST should update=20 > the MRI, if=20 > >> the GIST session traverses a NATP that modifies the=20 > >> source/destination port and addresses, then GIST should=20 > modify ther=20 > >> MRI. > >> All the NSLPs are using the MRI that is provided by GIST. In this=20 > >> case the described problem by you will be solved. > > > > Please note that this is not about the NAT issue. It is on the=20 > > stacking support of the QSPEC you mentioned earlier: >=20 >=20 > Georgios: Well each QoS model will choose the required=20 > parameters from the MRI. > Thus QoS model A will choose some parameters from MRI and QoS=20 > model B will choose other parameters from the same MRI. Thus=20 > MRI does not need to be stackable! >=20 > Best regards, > Georgios >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 05:52:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhxm-0002id-0X; Wed, 26 Oct 2005 05:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhxj-0002hW-TH for nsis@megatron.ietf.org; Wed, 26 Oct 2005 05:52:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08038 for ; Wed, 26 Oct 2005 05:52:36 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiAq-0003R4-4d for nsis@ietf.org; Wed, 26 Oct 2005 06:06:26 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9Q9qVJh015993; Wed, 26 Oct 2005 18:52:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9Q9qVf01547; Wed, 26 Oct 2005 18:52:31 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id j9Q9qWU00028; Wed, 26 Oct 2005 18:52:32 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 26 Oct 2005 17:49:38 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD75AB21@pslexc01.psl.local> Thread-topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXaEPbtsdvPwhhBRxq5Ddr4EXiJMgAAHoow From: "Cheng Hong" To: "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable Cc: Georgios Karagiannis , Takako Sanda , nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew, Thanks a lot for summarizing the issue. That is really helpful. Please see some comments inline: > There are a couple of cases to consider when thinking about=20 > how the packet classifier may deviate from the MRI. >=20 > In the first case you want more information for the packet=20 > classifier than is carried by the MRI. One issue with this is=20 > that of message routing - would the extra fields cause a=20 > divergence from the MRI-based path, e.g. if you provide a=20 > 'port range' then would some load balancer route the traffic=20 > all the same way? Also, adverse NAT-effects may be caused=20 > e.g. if you identify ports above the GIST layer, then an=20 > 'NSIS-aware NAT' has to look at more than just GIST. >=20 > The nature of on-path signalling makes this one difficult for=20 > the obvious things you might want to do. There may be some=20 > cases where it will work where the additional information is=20 > from higher layers which you are certain do not affect the=20 > routing and NATs do not touch. You are right. The major issue regarding this case is the NAT traversal. So far, we havn't seen a very good solution for that (some possibility are mentioned in other emails of this thread).=20 However, there are some instances that may benefit from including more information than that is carried in the MRI (as also discussed in the other thread). I think this is the major issue the group need to sort out. > In the second case you want less information than is carried=20 > within the MRI, though actually this still requires some=20 > additional information:=20 > i.e. which bits of the MRI should be used. As you say, this=20 > is what the current 'packet classifier flags' are doing. You=20 > don't have any NAT issues at the NSLP, since the NAT-relevant=20 > information is all carried in the GIST layer. Agree.=20 > I have no idea what a "stackable MRI" means in the context of=20 > GIST. MRI =3D message routing information. If you have one=20 > message with two MRIs, which way do you route it? Similar to the QSPEC stacking: the top MRI will be used for routing.=20 Well, I am not really proposing this (it would be a nightmare for implementation). Just would like to point out that if the QSPEC stacking is to be support, as pointed out by Georgios, using only MRI for the packet classification may also face the same issue (stacking of MRI since it equals to the packet_classifier in that case) cheers Cheng Hong =20 =20 > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Wednesday, October 26, 2005 5:40 PM > To: Cheng Hong > Cc: Georgios Karagiannis; nsis@ietf.org;=20 > Hannes.Tschofenig@siemens.com; Takako Sanda > Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >=20 > Hi Cheng Hong, >=20 > some comments below >=20 > Cheng Hong wrote: > >>I think that the easier solution will just be to have a sentence in=20 > >>the QOS-NSLP draft which says: > >> > >>"The QOS-NSLP nodes SHOULD use one or more parameters=20 > included in the=20 > >>MRI for packet classification." > >=20 > > This would be an easy way to address the NAT issue. We may=20 > also need=20 > > to identify how to indicate that "one or more parameters"=20 > to be used=20 > > for the packet classification. Maybe that is what the=20 > > PACKET_CLASSIFIER is meant for. > >=20 > > However, this may result in an increment in the signaling=20 > > session/messages when the MRI cannot provide enough information for=20 > > the packet classification. Therefore, it would be a=20 > tradeoff between=20 > > the signaling efficiency and complexity. > >=20 > > My feeling is that we at least need to allow some extra=20 > information to=20 > > be included in the QoS-NSLP to complement the MRI for the packet=20 > > classification. So, how about changing the sentence to: > >=20 > >>"The QOS-NSLP nodes SHOULD use one or more parameters of=20 > the MRI, as=20 > >>indicated by PACKET_CLASSIFIER, for packet classification. > >=20 > >>When PACKET_CLASSIFIER indicates an additional packet=20 > classification =20 > >>object included in QoS-NSLP, the additional object should=20 > be used for=20 > >>packet classification." > > > > As for the NAT traversal problem, I think it would not be=20 > an issue if=20 > > we can make the indicator for this additional object and the object=20 > > itself common for all the NSLPs (as a common function of all the=20 > > NSLP). In this case, the NAT doesn't need to be specific=20 > NSLP aware to=20 > > do the update of the object (same as treating the MRI). So far, I=20 > > think this additional packet classification information is=20 > useful for=20 > > QoS-NSLP, NAT/FW-NSLP, and also the recently discussed=20 > metering-NSLP. >=20 > There are a couple of cases to consider when thinking about=20 > how the packet classifier may deviate from the MRI. >=20 > In the first case you want more information for the packet=20 > classifier than is carried by the MRI. One issue with this is=20 > that of message routing - would the extra fields cause a=20 > divergence from the MRI-based path, e.g. if you provide a=20 > 'port range' then would some load balancer route the traffic=20 > all the same way? Also, adverse NAT-effects may be caused=20 > e.g. if you identify ports above the GIST layer, then an=20 > 'NSIS-aware NAT' has to look at more than just GIST. >=20 > The nature of on-path signalling makes this one difficult for=20 > the obvious things you might want to do. There may be some=20 > cases where it will work where the additional information is=20 > from higher layers which you are certain do not affect the=20 > routing and NATs do not touch. >=20 > In the second case you want less information than is carried=20 > within the MRI, though actually this still requires some=20 > additional information:=20 > i.e. which bits of the MRI should be used. As you say, this=20 > is what the current 'packet classifier flags' are doing. You=20 > don't have any NAT issues at the NSLP, since the NAT-relevant=20 > information is all carried in the GIST layer. >=20 > > For the stackable QSPEC issue raised by Georgios earlier in this=20 > > thread, I am not sure how it could be solved by limiting the packet=20 > > classification information to the MRI. If the intension is=20 > to preserve=20 > > the packet classification information for a stacked QSPEC (which is=20 > > different from the current MRI), the MRI itself also needs to be=20 > > stackable (if it is the sole source of packet classification=20 > > information). >=20 > I have no idea what a "stackable MRI" means in the context of=20 > GIST. MRI =3D message routing information. If you have one=20 > message with two MRIs, which way do you route it? >=20 > regards, > Andrew >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 05:56:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUi1M-0003zu-8p; Wed, 26 Oct 2005 05:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUi1K-0003yD-EQ for nsis@megatron.ietf.org; Wed, 26 Oct 2005 05:56:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08182 for ; Wed, 26 Oct 2005 05:56:18 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiER-0003WV-Oi for nsis@ietf.org; Wed, 26 Oct 2005 06:10:09 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9Q9uQu9000476; Wed, 26 Oct 2005 11:56:26 +0200 (MEST) Message-ID: <007a01c5da13$887aa520$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Cheng Hong" , "Andrew McDonald" References: <5F09D220B62F79418461A978CA0921BD75AB1C@pslexc01.psl.local> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 11:56:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.41 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 11:56:30 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, Takako Sanda , Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cheng I do not understand what you mean bty stacked MRI? I think that we do not need such a fature! >> Georgios: Well each QoS model will choose the required >> parameters from the MRI. >> Thus QoS model A will choose some parameters from MRI and QoS >> model B will choose other parameters from the same MRI. Thus >> MRI does not need to be stackable! > > This is only when the QoS Model A and QoS Model B uses the same > information for the packet classification (from different parts of the > MRI). However, if they use different info, that may not work. That is > when the MRI needs to be stackable (when classifier A and classifier B > cannot be represented by the same MRI). Georgios: No, each QoS model can select to use other MRI parameters. Best Regards, Georgios ----- Original Message ----- From: "Cheng Hong" To: "Georgios Karagiannis" ; "Andrew McDonald" Cc: "Takako Sanda" ; ; Sent: Wednesday, October 26, 2005 11:39 AM Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi Georgios, > > Please see some comments below: > >> Georgios: Why? >> A QoS model can configure locally a node to use the MF >> classifier for packet classification. > > Yes. That is to be defined by the QoS Model. > >> Another case will be that the QOS model will configure the >> edge of the QoS model to use the MF classifier and that then >> this edge will signal this information to all intermediary >> nodes (that are using the same QoS model) to use this >> information for packet classification. > > You mean there would be a separate (local) signaling session between > QNEs of same QoS Model to dynamically setup which field of the MF > classifier should be used for packet classification? > >> > If every NSLP has the same format, the NAT doesn't need to >> > understand/know which NSLP is that. It only process the common >> > formated information element for the packet_classifier if it is >> > present. (well, that may require an indicator for its presence be >> > placed in the common header, not tied to message type) >> >> Georgios: Not sure if this can be applied. >> The NATP has to recognise all types of NSLSP messages in >> order to do that. >> Thus it should be all-NSLP aware. > > If there is an indicator in the header to specify if there is an packet > calssification object contained in the message (of a fix position), the > NAT doesn't have to the x-NSLP aware. That is what I meant with the > words in the bracket. It may not be that good, but it is a possible > solution. > >> Georgios: Well each QoS model will choose the required >> parameters from the MRI. >> Thus QoS model A will choose some parameters from MRI and QoS >> model B will choose other parameters from the same MRI. Thus >> MRI does not need to be stackable! > > This is only when the QoS Model A and QoS Model B uses the same > information for the packet classification (from different parts of the > MRI). However, if they use different info, that may not work. That is > when the MRI needs to be stackable (when classifier A and classifier B > cannot be represented by the same MRI). > > cheers > > Cheng Hong > > > > > > > > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Wednesday, October 26, 2005 5:09 PM >> To: Cheng Hong; Andrew McDonald >> Cc: nsis@ietf.org; Takako Sanda; Hannes.Tschofenig@siemens.com >> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >> >> Hi Cheng >> >> Please see in line! >> >> ----- Original Message ----- >> From: "Cheng Hong" >> To: "Georgios Karagiannis" ; "Andrew >> McDonald" >> >> Cc: ; "Takako Sanda" >> ; >> Sent: Wednesday, October 26, 2005 10:38 AM >> Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >> >> >> > Hi Georgios, >> > >> > Please see some comments below: >> > >> > >> >> > >> >> > This would be an easy way to address the NAT issue. We may >> >> also need >> >> > to identify how to indicate that "one or more parameters" >> >> to be used >> >> > for the packet classification. Maybe that is what the >> >> > PACKET_CLASSIFIER is meant for. >> >> >> >> Georgios: This will have to be defined by the used QoS model, and >> >> should not be signaled. >> >> If a QoS model needs to use other parameters then it will >> be able to >> >> configure them! >> >> This is up to the QoS model. >> > >> > You are right that the QoS Model needs to define what should to be >> > signaled. The concern is that what the QoS Model defined may not be >> > able to be signaled by using the MRI only. The QoS Model >> can define a >> > format, no the contents, because the actual packet classificaiton >> > information (defined within a QoS Model) could be affected by the >> > operation. As what we discussed earlier, for example, a QoS Model >> > could define that a MF classifier is needed, however, it cannot >> > predict that whether the port number should be wildcarded or a >> > specific port should be used. Whether to use the port number (or >> > multiple port number) still needs to be signaled over >> between QNEs (by using something else than MRI). >> >> Georgios: Why? >> A QoS model can configure locally a node to use the MF >> classifier for packet classification. >> Another case will be that the QOS model will configure the >> edge of the QoS model to use the MF classifier and that then >> this edge will signal this information to all intermediary >> nodes (that are using the same QoS model) to use this >> information for packet classification. >> In both approaches the QoS model has to configure that! >> >> >> > >> > >> >> > My feeling is that we at least need to allow some extra >> >> information to >> >> > be included in the QoS-NSLP to complement the MRI for the packet >> >> > classification. So, how about changing the sentence to: >> >> > >> >> >> "The QOS-NSLP nodes SHOULD use one or more parameters of >> >> the MRI, as >> >> >> indicated by PACKET_CLASSIFIER, for packet >> >> > classification. >> >> >> When PACKET_CLASSIFIER indicates an additional packet >> >> classification >> >> > object included >> >> >> in QoS-NSLP, the additional object should be used for packet >> >> > classification." >> >> >> >> Georgios: The stacking problems will not allow to just use >> a PACKET >> >> CLASSIFIER QoS-NSLP object. You have either to generate a stacked >> >> PACKET_CLASSIFIER QOS-NSLP object or you have to included in the >> >> QSPEC. >> >> But as I mentioned above, this information does not have to be >> >> signaled. >> > >> > Yes. If the QSPEC stacking is to be supported, the object has to be >> > stackable also, as we discussed before. Maybe a simple way >> out of this >> > is to limit the stackable option of the QSPEC (disallow >> that), if we >> > want to avoid the problem. Even if we limit the information to the >> > MRI, we still may face the problem for the stackable issue on MRI. >> > (please see comments below regarding the stackable MRI issue) >> >> Georgios: Well I do not thing that this is the right solution. >> I do not understand why you think that stacking is needed. >> >> We do not need to stack the MRI. Each QoS model will choose >> the parameters from ther MRI! >> >> > >> >> > As for the NAT traversal problem, I think it would not be >> >> an issue if >> >> > we can make the indicator for this additional object and >> the object >> >> > itself common for all the NSLPs (as a common function of all the >> >> > NSLP). In this case, the NAT doesn't need to be specific >> >> NSLP aware to >> >> > do the update of the object (same as treating the MRI). >> So far, I >> >> > think this additional packet classification information is >> >> useful for >> >> > QoS-NSLP, NAT/FW-NSLP, and also the recently discussed >> >> metering-NSLP. >> >> >> >> Georgios: But this solution will only work if we mandate that the >> >> NATP is NAT-NSLP aware, QoS-NSLP-aware, ...-NSLP aware, etc.. >> >> I think we do not want to impose such requirements! >> > >> > If every NSLP has the same format, the NAT doesn't need to >> > understand/know which NSLP is that. It only process the common >> > formated information element for the packet_classifier if it is >> > present. (well, that may require an indicator for its presence be >> > placed in the common header, not tied to message type) >> >> Georgios: Not sure if this can be applied. >> The NATP has to recognise all types of NSLSP messages in >> order to do that. >> Thus it should be all-NSLP aware. >> >> > >> >> > For the stackable QSPEC issue raised by Georgios earlier in this >> >> > thread, I am not sure how it could be solved by limiting >> the packet >> >> > classification information to the MRI. >> >> >> >> Georgios: It can be solved since the GIST should update >> the MRI, if >> >> the GIST session traverses a NATP that modifies the >> >> source/destination port and addresses, then GIST should >> modify ther >> >> MRI. >> >> All the NSLPs are using the MRI that is provided by GIST. In this >> >> case the described problem by you will be solved. >> > >> > Please note that this is not about the NAT issue. It is on the >> > stacking support of the QSPEC you mentioned earlier: >> >> >> Georgios: Well each QoS model will choose the required >> parameters from the MRI. >> Thus QoS model A will choose some parameters from MRI and QoS >> model B will choose other parameters from the same MRI. Thus >> MRI does not need to be stackable! >> >> Best regards, >> Georgios >> >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 06:38:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUifp-0006yX-H3; Wed, 26 Oct 2005 06:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUifn-0006xd-HJ for nsis@megatron.ietf.org; Wed, 26 Oct 2005 06:38:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10518 for ; Wed, 26 Oct 2005 06:38:07 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUisv-0004oN-HE for nsis@ietf.org; Wed, 26 Oct 2005 06:51:58 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9QAZtwL002306; Wed, 26 Oct 2005 13:36:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 13:38:18 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 13:38:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 13:38:17 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D013D4756@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXaCtHdyXdgeyQKS7eTEyNty8XnoQADdYmQ To: , X-OriginalArrivalTime: 26 Oct 2005 10:38:17.0919 (UTC) FILETIME=[6092ACF0:01C5DA19] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, Just tipping one toe back into this thread: >However, that doesn't change my concluding thought - in fact=20 >it probably reinforces it, since I haven't seen any compelling=20 >examples of why multiple packet classifiers are required. I agree, I would like to see a more compelling reason for supporting=20 multiple packet classifiers. If you would model the end-to-end flow traversing multiple QoS domains, wouldn't you still need to have some notion of a classifier that would work along the entire path? I don't quite see what a different packet classifier somewhere in the=20 middle of the network would buy you. I guess if you are aggregating multiple flows in the network, where you would have multiple packet classifiers, you would need to use the 'looser' packet classifier, but I think that could be a local policy decision. Or am I misunderstanding things here? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 06:45:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUimw-0002Tw-JF; Wed, 26 Oct 2005 06:45:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUimu-0002Ol-C3 for nsis@megatron.ietf.org; Wed, 26 Oct 2005 06:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10918 for ; Wed, 26 Oct 2005 06:45:28 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUj03-00052h-1Z for nsis@ietf.org; Wed, 26 Oct 2005 06:59:19 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9QAjFWA029368; Wed, 26 Oct 2005 11:45:15 +0100 Received: from [193.118.197.247] ([193.118.197.247]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 11:45:21 +0100 Message-ID: <435F5E3B.1040204@roke.co.uk> Date: Wed, 26 Oct 2005 11:45:15 +0100 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <435E506D.5010909@roke.co.uk><050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl> <435F4348.5070703@roke.co.uk> <006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2005 10:45:21.0266 (UTC) FILETIME=[5CE84D20:01C5DA1A] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, some comments below Georgios Karagiannis wrote: > -//- snip >> >>> I think that the easier solution will just be to have a sentence in >>> the QOS-NSLP draft >>> which says: >>> >>> "The QOS-NSLP nodes SHOULD use one or more parameters included in the >>> MRI for packet classification." >>> >>> In this way we will also allow nodes to use other types of parameters >>> for packet classification, >>> by e.g., using local node configuration. >> >> >> There is a fairly significant difference between signalling this >> information and leaving it up to individual nodes. Particular issues >> that come to mind: >> - if you don't signal it then the QNI doesn't know what traffic will >> be treated as part of the reservation it is requesting > > Georgios: why not? > >> - it makes the definition of whether two signalling messages are about >> the same flow a local configuration (or QoS model dependent) issue > > Georgios: Please see some previous e-mails in this thread. It is a QoS > model > issue. > >> - there may be authorisation issues, in terms of what >> traffic/reservation is actually being requested and authorised by the >> authorisation information provided in the signalling > > Georgios: but if the node accepts the QSPEC then there is no problem! > A node can process a QSPEC only if it is able to recognise it. > This means that the packet classifier is also configured. I think understand what the difference is between the 'pure local configuration' and 'QoS model defined' non-signalled packet classifier possibilities are. As I understand it, your suggestion is that the "QoS model" field in the QSpec object implicitly identifies the packet filtering rules. Some issues that spring to mind: - what happens for a QoS Model that can use different packet classifiers? e.g. in the Intserv controlled load case you could make a reservation relating to a pair of IP addresses, or one relating to the full 5-tuple, or ... - allowing the local QoS Model to choose the packet classifier creates additional problem cases where the local view differs from the end-to-end view, e.g. you go into a domain where the QoS model uses the DSCP as part of the packet classifier, but the QNI hasn't included the DSCP in the MRI. You could possibly do some remarking, etc in this QoS model domain, but that would seem to be a situation where you should be using a separate signalling session. - what happens in the case of an unknown QoS Model? There is supposed to be a mandatory subset of the QSpec objects which allows things to proceed even if the QoS model is not understood. What do these nodes use for the packet classifier? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 07:52:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjps-00051H-To; Wed, 26 Oct 2005 07:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjpr-00050d-Ca for nsis@megatron.ietf.org; Wed, 26 Oct 2005 07:52:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13565 for ; Wed, 26 Oct 2005 07:52:36 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUk30-0006uF-I4 for nsis@ietf.org; Wed, 26 Oct 2005 08:06:27 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9QBqDWA013563; Wed, 26 Oct 2005 12:52:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Date: Wed, 26 Oct 2005 12:52:23 +0100 Message-ID: Thread-Topic: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Thread-Index: AcXZeskIl4LcopIdQYG+95Fhsi0bEgAo9dkg From: "Hancock, Robert" To: "Thomas Herzog" , "Roland Bless" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi roland, thomas, the question of bidding down attacks is a really tricky one to work through in detail. but the basic components of the reasoning are as follows: - if the response SCD is allowed to depend on the Query, then manipulation of the Query might cause a 'weak' proposal to be offered in the response. Saying that the response SCD MUST NOT depend on the Query is a 'play safe' approach - you could define less restrictive approaches, but actually the benefit of allowing more flexibility has not been clear. you *are* able to have different policies/offered SCDs for different NSLPs or interfaces (e.g. 'inside' vs. 'outside'), and this would seem to be sufficient (at least to me). - the Q-node must do a MA setup which respects the options given in the response SCD. so, interfering with the response-SCD could weaken the possible security properties of the MA. *if* all the following conditions apply: - a MITM can modify the response to weaken the set of offers - the Q node policy allows the use of the weaker protocol - the MITM is on the forward and reverse paths - the MITM can break the weaker protocol *in real time* *then there is nothing further that can be done against the attacker. so, the level of defence that is possible is a=20 combination of policy setting (at the Q-node) and verification=20 of the echoed R-SCD (at the R-node) - if the nodes have policies that minimally require selection of a MA which cannot be broken=20 in real time, then the rest of the protocol machinery will ensure that any attack is detected. is this discussion logically coherent? should it be in the spec? (currently there is a reference to the sip-sec-agree spec, which has a very similar analysis). robert h. > -----Original Message----- > From: Thomas Herzog [mailto:thomas.herzog@gmx.li]=20 > Sent: 25 October 2005 16:38 > To: Roland Bless > Cc: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] GIST Confirm contains no stack=20 > configuration data, which holds MA_HOLD_TIME >=20 >=20 > Hi, Roland, >=20 > exactly, what I meant, too. >=20 > Am Dienstag, 25. Oktober 2005 17:25 schrieb Roland Bless: >=20 > > I think it is more interesting to be able to detect the > > selection of a weak protocol. For instance, if both nodes offer > > TLS/TCP and TCP but only TCP is selected that should make > > the R-Node suspicious. However, according to the policy TCP > > is acceptable anyway. So I don't see a reason to repeat > > the R-Node's Stack Proposal. Maybe someone else could elaborate > > what "certain bidding down attacks" means. Currently I don't > > see any real value in it. >=20 > To my understanding, even this case (selection of a weak=20 > protocol) is not=20 > really useful. >=20 > As the Message Transfer security is set by the NSLP which=20 > called SendMessage=20 > with "transfer-attributes=3Dsecure/reliable", it is also=20 > possible that the NSLP=20 > would NOT have required security (e.g. set only "reliable"). >=20 > In this case, both nodes still send their full set of=20 > proposals, but the=20 > Q-Node is then free to use a "weak" connection. >=20 > (The Q-Node would include it's full ability set, because it=20 > could be that the=20 > R-Node local policy would require secure connections) >=20 > So selecting a "weak" Profile in case both nodes can support=20 > more secure ones=20 > can't be an error according to the spec. >=20 > Cheers, Thomas >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 08:46:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkfi-0003Ao-U8; Wed, 26 Oct 2005 08:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkfi-0003Aj-10 for nsis@megatron.ietf.org; Wed, 26 Oct 2005 08:46:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16980 for ; Wed, 26 Oct 2005 08:46:11 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUksr-0000Fs-0B for nsis@ietf.org; Wed, 26 Oct 2005 09:00:02 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9QCkKXh011223; Wed, 26 Oct 2005 14:46:20 +0200 (MEST) Message-ID: <009301c5da2b$4482d140$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Andrew McDonald" References: <435E506D.5010909@roke.co.uk><050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl><435F4348.5070703@roke.co.uk><006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> <435F5E3B.1040204@roke.co.uk> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 14:46:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.408 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 14:46:21 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew Please see in line! >> >> Georgios: but if the node accepts the QSPEC then there is no problem! >> A node can process a QSPEC only if it is able to recognise it. >> This means that the packet classifier is also configured. > > I think understand what the difference is between the 'pure local > configuration' and 'QoS model defined' non-signalled packet classifier > possibilities are. As I understand it, your suggestion is that the "QoS > model" field in the QSpec object implicitly identifies the packet > filtering rules. Georgios: No, my last proposal is that we do not need to signal the packet classifier information at all! > Some issues that spring to mind: > > - what happens for a QoS Model that can use different packet classifiers? > e.g. in the Intserv controlled load case you could make a reservation > relating to a pair of IP addresses, or one relating to the full 5-tuple, > or ... Georgios: Well, in the previous e-mail discussions I have tried to make this very clear, please check the previous e-mail of this tread! Furthermore, the rules of this packet classifier should be rules that are related to the information included in the header of the IP packets. Thus each QoS model can specify any additional filtering rule (note that typically it should use MRI parameters) it wants assuming that these rules are related to the fields of the IP header. Please note that the responsability of assigning packet classifier rules is the responsability of the QoS model. > allowing the local QoS Model to choose the packet classifier creates > additional problem cases where the local view differs from the end-to-end > view, e.g. you go into a domain where the QoS model uses the DSCP as part > of the packet classifier, but the QNI hasn't included the DSCP in the MRI. > You could possibly do some remarking, etc in this QoS model domain, but > that would seem to be a situation where you should be using a separate > signalling session. Georgios: I do not think that you will have any problems. Please see my previous e-mails on this tread! in the case of an unknown QoS Model? There is supposed to > be a mandatory subset of the QSpec objects which allows things to proceed > even if the QoS model is not understood. What do these nodes use for the > packet classifier? Georgios: This should be specified by the QoS model! Best Regards, Georgios > > > regards, > > Andrew > > _______________________________________________ > 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 nsis-bounces@ietf.org Wed Oct 26 08:51:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkk8-0003zf-Di; Wed, 26 Oct 2005 08:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkk6-0003za-Vi for nsis@megatron.ietf.org; Wed, 26 Oct 2005 08:50:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17174 for ; Wed, 26 Oct 2005 08:50:44 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkxG-0000NR-15 for nsis@ietf.org; Wed, 26 Oct 2005 09:04:35 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9QCooNg011525; Wed, 26 Oct 2005 14:50:50 +0200 (MEST) Message-ID: <009801c5da2b$e5995f90$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: , , References: <1AA39B75171A7144A73216AED1D7478D013D4756@esebe100.NOE.Nokia.com> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 14:50:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.406 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 14:50:54 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org, Hannes.Tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John My point, is similar to the point that Hannes did in one of the first e-mails of this tread is that we do not need to signal the packet classifier information. Typically each QoS model will have to use the information provided by GIST in the MRI to do that. Thus this is signaled by GIST and each QoS model is responsible of choosing the right MRI parameters for packet classification. If a QoS model needs to use another type of packet classification, then it shoul use local configuration for it, considering that the rules are related to parameters of the IP header. Best regards, georgios ----- Original Message ----- From: To: ; Cc: ; Sent: Wednesday, October 26, 2005 12:38 PM Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi all, > > Just tipping one toe back into this thread: > >>However, that doesn't change my concluding thought - in fact >>it probably reinforces it, since I haven't seen any compelling >>examples of why multiple packet classifiers are required. > > I agree, I would like to see a more compelling reason for supporting > multiple packet classifiers. If you would model the end-to-end flow > traversing multiple QoS domains, wouldn't you still need to have some > notion of a classifier that would work along the entire path? I don't > quite see what a different packet classifier somewhere in the > middle of the network would buy you. > > I guess if you are aggregating multiple flows in the network, where you > would have multiple packet classifiers, you would need to use the > 'looser' > packet classifier, but I think that could be a local policy decision. > > Or am I misunderstanding things here? > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 09:42:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlXs-0008HQ-RS; Wed, 26 Oct 2005 09:42:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlXr-0008GK-KW for nsis@megatron.ietf.org; Wed, 26 Oct 2005 09:42:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20143 for ; Wed, 26 Oct 2005 09:42:08 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUll1-0001zb-Mw for nsis@ietf.org; Wed, 26 Oct 2005 09:56:00 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9QDg3WA007867; Wed, 26 Oct 2005 14:42:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST section 4.3.2, adjacency-check Date: Wed, 26 Oct 2005 14:42:04 +0100 Message-ID: Thread-Topic: [NSIS] GIST section 4.3.2, adjacency-check Thread-Index: AcXZcTDntcFIqJGATBWhVvgJQ0CuWgAtpfqg From: "Hancock, Robert" To: "Roland Bless" , "Thomas Herzog" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi roland, thomas, i can provide some general and specific clarifications. 1) "adjacent" =3D "having explicit routing state towards"; the key point is about routing state, not messaging associations. signalling=20 applications care about being adjacent or not, but don't care about messaging associations. (MAs can only be set up between adjacent peers, but this is logically subordinate to the adjacency, which is the primary concept.) 2) routing state is managed entirely by GIST handshake operations. so, the key message is the Query - you have to accept Responses to your own Queries, and have to accept Responses to your own Confirms. So, the=20 choice is made during the processing of the initial Query. 3) the adjecency check that GIST makes with the NSLP is performed *within* the processing of the Query message, i.e. during the=20 processing GIST will at some point call RecvMessage and will expect a return value which tells it what to do. it then sends a Response for re-forwards the Query as appropriate. There is no separate SendMessage call from the NSLP to do this. some further detailed comments in line, r. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 25 October 2005 15:34 > To: Thomas Herzog > Cc: nsis@ietf.org; Hancock, Robert > Subject: Re: [NSIS] GIST section 4.3.2, adjacency-check >=20 >=20 > Hi Thomas, >=20 > I think section 4.3.2 needs definitely some clarifications. >=20 > >> Even when a message relates to a local signaling application, an > >> adjacency MAY be required based on signaling application=20 > policy, and > >> the application of this policy MAY depend on the NSLP payload. > >> Therefore, when this decision has to be made, the NSLP payload is > >> delivered and the signaling application has two options: > >> > >> o to proceed setting up the adjacency. The application=20 > MAY provide > >> an NSLP payload (which will be used in any GIST-Response). > >> > >> o to bypass the message and drop out of the signaling path. The > >> application MAY provide an updated NSLP payload (which will be > >> used in the message which is then forwarded by GIST). > >=20 > >=20 > > As the GIST API defines a "adjacency check" flag in=20 > RecvMessage, I suppose,=20 > > GIST must indicate the request of a Messaging Association=20 > ("adjacency"?!?!)=20 > =20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > At least the terminology section doesn't state that Adjacency means or > is identical to an MA between two peers. IMHO it only defines that two > GIST nodes are directly adjacent with respect to GIST and NSLP. > If I understood the Adjacency Check mechanism correctly it allows an > NSLP to act as a bypass if it is not interested in the exchange. yep. >=20 > A little bit confusing is the fact that section 4.3.2 doesn't > specify exactly the message which may request the setup of an=20 > adjacency. > Is there a difference if it is a GIST-Query, GIST-Confirm,=20 > GIST-Response > or GIST-Data (maybe even received via an existing MA). see above (i hope). >=20 > Again in more detail: > >> Even when a message relates to a local signaling application, an > >> adjacency MAY be required based on signaling application policy, >=20 > "an adjacency": is it an adjacency with the Querying upstream node? > Could it be a different adjacency with another third node? with the upstream node. >=20 > >> o to proceed setting up the adjacency. The application=20 > MAY provide > >> an NSLP payload (which will be used in any GIST-Response). >=20 > So an adjacency can only be setup by a GIST-Query? What is the > reaction of the local node? Does it send a GIST-Response back > in this case or why says the above sentence "_any_ GIST-Response"? the *any* refers to the fact that there may instead be a GIST-Error, or retransmitted Responses, etc. >=20 > >> o to bypass the message and drop out of the signaling path. The > >> application MAY provide an updated NSLP payload (which will be > >> used in the message which is then forwarded by GIST). >=20 > I assume that it should mean: the original message type with=20 > the updated > NSLP payload is forwarded further down the path, i.e. in this case no > GIST-Response is generated. yes - and the original message is a Query. >=20 > > This raises some problems in my eyes: > >=20 > > - When late state setup is used, GIST does not save any=20 > state where it later=20 > > could check if a Message Association is rightly established=20 > (it will be=20 > > established on receipt of a GIST Confirm). Only possibility=20 > would be to send=20 > > no Stack Proposal in the Response. However, some local=20 > state must be=20 > > established on Query receipt for asynchronously asking the=20 > NSLP via the=20 > > API?!?! >=20 > So you mean some temporary local state until the NSLP has > given an answer and a corresponding GIST-Response > is created and sent back? This may be negligible because > you would need some resources for processing a Query anyway. > It is however important that no state is kept after the > Response is sent. i hope this is explained by point (3) above. >=20 > > - When a message association is to be set up, the GIST=20 > Querier does generally=20 > > not include NSLP payload in the Query at all, because it=20 > gets queued until=20 > > the Association is set up (NSLP could have required=20 > 'reliable' or 'secure'=20 > > for the data). So GIST has no data to deliver to the NSLP=20 > when it asks if the=20 > > association should be set up. It would in general only=20 > deliver "shall I=20 > > associate", the MRI, the Session ID and the NSLPID... >=20 > This is related somewhat to the problem mentioned in the thread > "NSLP-Data in intial GIST-Query" and > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74 you can easily imagine some initial data which does some capability discovery at the NSLP level (which might not need to be sent=20 securely). in any case, this is a matter of NSLP design. >=20 > > Or is this section to be understood in a more general way?=20 > Is this "adjacency"=20 > > simply about setting up routing state in general? >=20 > I think it is not clearly defined in the draft what "setting up > an adjacency" really means... >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 11:31:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnFB-0006kV-0n; Wed, 26 Oct 2005 11:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnF9-0006kN-Kq for nsis@megatron.ietf.org; Wed, 26 Oct 2005 11:31:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01465 for ; Wed, 26 Oct 2005 11:30:56 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+ZDAeZOBtSb8OYL2SVOOfzvt0wtbBFEOE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnSK-0007DT-3P for nsis@ietf.org; Wed, 26 Oct 2005 11:44:49 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EUnEv-0007dc-80; Wed, 26 Oct 2005 17:31:02 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B306F7E2E; Wed, 26 Oct 2005 17:30:56 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EUnEu-0003wb-8j; Wed, 26 Oct 2005 17:30:56 +0200 Message-ID: <435FA12F.1060608@tm.uka.de> Date: Wed, 26 Oct 2005 17:30:55 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, > the question of bidding down attacks is a really tricky > one to work through in detail. but the basic components of > the reasoning are as follows: > > - if the response SCD is allowed to depend on the Query, then > manipulation of the Query might cause a 'weak' proposal to be > offered in the response. Saying that the response SCD MUST NOT > depend on the Query is a 'play safe' approach - you could define > less restrictive approaches, but actually the benefit of > allowing more flexibility has not been clear. you *are* able to > have different policies/offered SCDs for different NSLPs or > interfaces (e.g. 'inside' vs. 'outside'), and this would seem > to be sufficient (at least to me). Yep, agreed, and I guess this point was already clear. Though it may be good to include the explicit hint: "you *are* able to have different policies/offered SCDs for different NSLPs or interfaces (e.g. 'inside' vs. 'outside')" in the Spec. > - the Q-node must do a MA setup which respects the options given > in the response SCD. so, interfering with the response-SCD could > weaken the possible security properties of the MA. > *if* all the following conditions apply: > - a MITM can modify the response to weaken the set of offers > - the Q node policy allows the use of the weaker protocol > - the MITM is on the forward and reverse paths > - the MITM can break the weaker protocol *in real time* Correct analysis. > *then there is nothing further that can be done against the > attacker. so, the level of defence that is possible is a > combination of policy setting (at the Q-node) and verification > of the echoed R-SCD (at the R-node) - if the nodes have policies > that minimally require selection of a MA which cannot be broken > in real time, then the rest of the protocol machinery will ensure > that any attack is detected. So far agreed. The only criticism I had was that echoing the R-SCD is useless except for the situation where you have a MITM on the reverse path (i.e., from R-Node to Q-Node) and the MITM has no access to the forward path. So we should simply save the bandwidth and use it for sending back the MA-Hold-Time in an "empty" Stack Configuration Data. > is this discussion logically coherent? should it be in the spec? > (currently there is a reference to the sip-sec-agree spec, which > has a very similar analysis). Oops, sorry I must have missed that one. However, except for the on-reverse-path-attacker-only case, I don't see any value in "echoing" the R-SCD (it would have a real value in case it was integrity protected by the Q-Node) and would plead for simplification. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 12:00:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnhY-0007r3-Ja; Wed, 26 Oct 2005 12:00:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnhV-0007qt-SL for nsis@megatron.ietf.org; Wed, 26 Oct 2005 12:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03399 for ; Wed, 26 Oct 2005 12:00:14 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/0qkQmd67CYY1TDrNjHADOSJuY0jGa5gw=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnug-00089b-NW for nsis@ietf.org; Wed, 26 Oct 2005 12:14:08 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EUnhR-0000ic-Gn; Wed, 26 Oct 2005 18:00:27 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 36F348457; Wed, 26 Oct 2005 18:00:25 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EUnhQ-0003yE-Tf; Wed, 26 Oct 2005 18:00:25 +0200 Message-ID: <435FA818.7050806@tm.uka.de> Date: Wed, 26 Oct 2005 18:00:24 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME References: <435E4E7E.5090107@tm.uka.de> In-Reply-To: <435E4E7E.5090107@tm.uka.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, >>not quite as logically pure as the current structure, but is >>probably the right compromise between purity and sophistication. >>(the NLI is repeated in the confirm for precisely the reason that >>the R-node will have forgotten the original, so there is a match >>of purpose here). i will add a new issue for this. After some discussion with Thomas, we concluded that it would possibly be a cleaner approach to send a Q-Node Stack-Configuration Data in the GIST-confirm back, essentially only containing one MA-Hold-Time, i.e. HL-Count=0 since the MA was setup already anyway. Cheers, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 12:48:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoRg-0003qW-SG; Wed, 26 Oct 2005 12:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoRe-0003on-SI for nsis@megatron.ietf.org; Wed, 26 Oct 2005 12:48:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06678 for ; Wed, 26 Oct 2005 12:47:54 -0400 (EDT) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUoeq-0001OU-Ab for nsis@ietf.org; Wed, 26 Oct 2005 13:01:49 -0400 Received: (qmail invoked by alias); 26 Oct 2005 16:47:57 -0000 Received: from p54A333BE.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.51.190] by mail.gmx.net (mp025) with SMTP; 26 Oct 2005 18:47:57 +0200 X-Authenticated: #4469397 From: Thomas Herzog To: "Hancock, Robert" Subject: Re: [NSIS] GIST section 4.3.2, adjacency-check Date: Wed, 26 Oct 2005 18:43:24 +0200 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510261843.24954.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Robert, You input made it all clearer, but maybe the first paragraphs auf 4.3.2 need some alteration to make it clear that: "When the initial GIST-Query is received, GIST checks with the appropriate NSLP if routing state towards the Q-Node should be established. This is done by calling the RecvMessage primitive with Adjacency-Check flag set. GIST then interprets the Return value to carry out what the NSLP has decided. This can be: - ... - ..." The other irritations I had were caused by the fact that I did not recognize that the RecvMessage call is in fact a synchronous function call (with a return value). As we are implementing the API via Messages (over a UNIX domain socket), this implies some modifications to our implementation specific state machine. But besides implementation specific issues, there is still one little quirk in the draft: - GIST calls RecvMessage with the Adjacency-Flag set, the Return value is inspected so it will either send a response or relay the message. This is done synchronously via the API primitive. - The NSLP MAY provide altered data payload in both cases How is THAT to be done? Is the FIRST SendMessage from the NSLP carrying that data? Is it defined in NSLP drafts, that there MUST be a SendMessage after a RecvMessage with Adjacency-Check flag set? Furthermore, if GIST inspected the return code of the RecvMessage call, it would still have to wait for Data to include? How long would it wait? What if NSLP wants to include NO UPDATED data? Will it pass a SendMessage anyway, even with the old data? Or should there be MORE return values to RecvMessage? e.g. "relay"/"relay - data following"/"setup state"/"setup state - data following"? The return values are not defined further in the draft. This also seems to require a "temporary" state for the R-Node state machine: "awaiting replaced data" which will be destroyed if the action (send back response or relay query, go to awaiting-confirm or dead afterwards) has been performed. This requirement seems not to be implementation specific, SendMessage is an asynchronous primitive after all. Cheers, Thomas Am Mittwoch, 26. Oktober 2005 17:29 schrieben Sie: > hi, > > i've added this as > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue100 > > will either/both of you be in vancouver? it might be good to have > a review of the next version (which i will probably do during the > meeting ...) to find out whether particular parts are clearer. > > cheers, > > r. > > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > Behalf Of Hancock, Robert > > Sent: 26 October 2005 14:42 > > To: Roland Bless; Thomas Herzog > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] GIST section 4.3.2, adjacency-check > > > > > > hi roland, thomas, > > > > i can provide some general and specific clarifications. > > > > 1) "adjacent" = "having explicit routing state towards"; the key point > > is about routing state, not messaging associations. signalling > > applications care about being adjacent or not, but don't care about > > messaging associations. (MAs can only be set up between > > adjacent peers, > > but this is logically subordinate to the adjacency, which is > > the primary > > concept.) > > > > 2) routing state is managed entirely by GIST handshake operations. so, > > the key message is the Query - you have to accept Responses > > to your own > > Queries, and have to accept Responses to your own Confirms. So, the > > choice is made during the processing of the initial Query. > > > > 3) the adjecency check that GIST makes with the NSLP is performed > > *within* the processing of the Query message, i.e. during the > > processing GIST will at some point call RecvMessage and will expect > > a return value which tells it what to do. it then sends a Response > > for re-forwards the Query as appropriate. There is no separate > > SendMessage call from the NSLP to do this. > > > > some further detailed comments in line, > > > > r. > > > > > -----Original Message----- > > > From: Roland Bless [mailto:bless@tm.uka.de] > > > Sent: 25 October 2005 15:34 > > > To: Thomas Herzog > > > Cc: nsis@ietf.org; Hancock, Robert > > > Subject: Re: [NSIS] GIST section 4.3.2, adjacency-check > > > > > > > > > Hi Thomas, > > > > > > I think section 4.3.2 needs definitely some clarifications. > > > > > > >> Even when a message relates to a local signaling > > > > application, an > > > > > >> adjacency MAY be required based on signaling application > > > > > > policy, and > > > > > > >> the application of this policy MAY depend on the NSLP payload. > > > >> Therefore, when this decision has to be made, the NSLP > > > > payload is > > > > > >> delivered and the signaling application has two options: > > > >> > > > >> o to proceed setting up the adjacency. The application > > > > > > MAY provide > > > > > > >> an NSLP payload (which will be used in any GIST-Response). > > > >> > > > >> o to bypass the message and drop out of the signaling > > > > path. The > > > > > >> application MAY provide an updated NSLP payload > > > > (which will be > > > > > >> used in the message which is then forwarded by GIST). > > > > > > > > As the GIST API defines a "adjacency check" flag in > > > > > > RecvMessage, I suppose, > > > > > > > GIST must indicate the request of a Messaging Association > > > > > > ("adjacency"?!?!) > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > At least the terminology section doesn't state that > > > > Adjacency means or > > > > > is identical to an MA between two peers. IMHO it only > > > > defines that two > > > > > GIST nodes are directly adjacent with respect to GIST and NSLP. > > > If I understood the Adjacency Check mechanism correctly it > > > > allows an > > > > > NSLP to act as a bypass if it is not interested in the exchange. > > > > yep. > > > > > A little bit confusing is the fact that section 4.3.2 doesn't > > > specify exactly the message which may request the setup of an > > > adjacency. > > > Is there a difference if it is a GIST-Query, GIST-Confirm, > > > GIST-Response > > > or GIST-Data (maybe even received via an existing MA). > > > > see above (i hope). > > > > > Again in more detail: > > > >> Even when a message relates to a local signaling > > > > application, an > > > > > >> adjacency MAY be required based on signaling > > > > application policy, > > > > > "an adjacency": is it an adjacency with the Querying upstream node? > > > Could it be a different adjacency with another third node? > > > > with the upstream node. > > > > > >> o to proceed setting up the adjacency. The application > > > > > > MAY provide > > > > > > >> an NSLP payload (which will be used in any GIST-Response). > > > > > > So an adjacency can only be setup by a GIST-Query? What is the > > > reaction of the local node? Does it send a GIST-Response back > > > in this case or why says the above sentence "_any_ GIST-Response"? > > > > the *any* refers to the fact that there may instead be a GIST-Error, > > or retransmitted Responses, etc. > > > > > >> o to bypass the message and drop out of the signaling > > > > path. The > > > > > >> application MAY provide an updated NSLP payload > > > > (which will be > > > > > >> used in the message which is then forwarded by GIST). > > > > > > I assume that it should mean: the original message type with > > > the updated > > > NSLP payload is forwarded further down the path, i.e. in > > > > this case no > > > > > GIST-Response is generated. > > > > yes - and the original message is a Query. > > > > > > This raises some problems in my eyes: > > > > > > > > - When late state setup is used, GIST does not save any > > > > > > state where it later > > > > > > > could check if a Message Association is rightly established > > > > > > (it will be > > > > > > > established on receipt of a GIST Confirm). Only possibility > > > > > > would be to send > > > > > > > no Stack Proposal in the Response. However, some local > > > > > > state must be > > > > > > > established on Query receipt for asynchronously asking the > > > > > > NSLP via the > > > > > > > API?!?! > > > > > > So you mean some temporary local state until the NSLP has > > > given an answer and a corresponding GIST-Response > > > is created and sent back? This may be negligible because > > > you would need some resources for processing a Query anyway. > > > It is however important that no state is kept after the > > > Response is sent. > > > > i hope this is explained by point (3) above. > > > > > > - When a message association is to be set up, the GIST > > > > > > Querier does generally > > > > > > > not include NSLP payload in the Query at all, because it > > > > > > gets queued until > > > > > > > the Association is set up (NSLP could have required > > > > > > 'reliable' or 'secure' > > > > > > > for the data). So GIST has no data to deliver to the NSLP > > > > > > when it asks if the > > > > > > > association should be set up. It would in general only > > > > > > deliver "shall I > > > > > > > associate", the MRI, the Session ID and the NSLPID... > > > > > > This is related somewhat to the problem mentioned in the thread > > > "NSLP-Data in intial GIST-Query" and > > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74 > > > > you can easily imagine some initial data which does some capability > > discovery at the NSLP level (which might not need to be sent > > securely). in any case, this is a matter of NSLP design. > > > > > > Or is this section to be understood in a more general way? > > > > > > Is this "adjacency" > > > > > > > simply about setting up routing state in general? > > > > > > I think it is not clearly defined in the draft what "setting up > > > an adjacency" really means... > > > > > > Regards, > > > Roland > > > > _______________________________________________ > > 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 nsis-bounces@ietf.org Wed Oct 26 13:03:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUogE-0004tM-Bc; Wed, 26 Oct 2005 13:03:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUogC-0004qs-9x for nsis@megatron.ietf.org; Wed, 26 Oct 2005 13:03:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07555 for ; Wed, 26 Oct 2005 13:02:56 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUotL-0001sn-7p for nsis@ietf.org; Wed, 26 Oct 2005 13:16:51 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9QGtNWA023034; Wed, 26 Oct 2005 17:55:23 +0100 Received: from [193.118.197.247] ([193.118.197.247]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 17:55:23 +0100 Message-ID: <435FB4FB.4000208@roke.co.uk> Date: Wed, 26 Oct 2005 17:55:23 +0100 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <435E506D.5010909@roke.co.uk><050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl><435F4348.5070703@roke.co.uk><006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> <435F5E3B.1040204@roke.co.uk> <009301c5da2b$4482d140$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <009301c5da2b$4482d140$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2005 16:55:23.0475 (UTC) FILETIME=[0E748A30:01C5DA4E] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, Georgios Karagiannis wrote: >>> Georgios: but if the node accepts the QSPEC then there is no problem! >>> A node can process a QSPEC only if it is able to recognise it. >>> This means that the packet classifier is also configured. >> >> >> I think understand what the difference is between the 'pure local >> configuration' and 'QoS model defined' non-signalled packet classifier >> possibilities are. As I understand it, your suggestion is that the >> "QoS model" field in the QSpec object implicitly identifies the packet >> filtering rules. > > > Georgios: No, my last proposal is that we do not need to signal the > packet classifier information at all! In that case I don't understand what you are proposing at the moment. I may have missed (or misunderstood) something in one of your previous e-mails. Can you clarify what you mean when you say "It is a QoS model issue"? I can see two possibilities for this: a) The packet classifier is determined by the QoS model used by the QSpec in the message b) The packet classifier is determined by the node receiving a message based on the QoS model it supports I thought you meant (a). Do you mean (b)? Or is it something else? Andrew >> Some issues that spring to mind: >> >> - what happens for a QoS Model that can use different packet >> classifiers? e.g. in the Intserv controlled load case you could make a >> reservation relating to a pair of IP addresses, or one relating to the >> full 5-tuple, or ... > > > Georgios: Well, in the previous e-mail discussions I have tried to make > this very clear, please check the > previous e-mail of this tread! > Furthermore, the rules of this packet classifier should be rules that > are related to the > information included in the header of the IP packets. Thus each QoS > model can > specify any additional filtering rule (note that typically it should > use MRI parameters) > it wants assuming that these rules are related to the > fields of the IP header. > Please note that the responsability of assigning packet classifier rules > is the responsability of the QoS model. > > > >> allowing the local QoS Model to choose the packet classifier creates >> additional problem cases where the local view differs from the >> end-to-end view, e.g. you go into a domain where the QoS model uses >> the DSCP as part of the packet classifier, but the QNI hasn't included >> the DSCP in the MRI. You could possibly do some remarking, etc in this >> QoS model domain, but that would seem to be a situation where you >> should be using a separate signalling session. > > > Georgios: I do not think that you will have any problems. Please see my > previous e-mails on this tread! > > > in the case of an unknown QoS Model? There is supposed to > >> be a mandatory subset of the QSpec objects which allows things to >> proceed even if the QoS model is not understood. What do these nodes >> use for the packet classifier? > > > Georgios: This should be specified by the QoS model! > > Best Regards, > Georgios > >> >> >> regards, >> >> Andrew >> >> _______________________________________________ >> 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 nsis-bounces@ietf.org Wed Oct 26 13:13:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoqN-0007w7-8q; Wed, 26 Oct 2005 13:13:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoqK-0007u3-VK for nsis@megatron.ietf.org; Wed, 26 Oct 2005 13:13:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08207 for ; Wed, 26 Oct 2005 13:13:24 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUp3V-0002Cz-8f for nsis@ietf.org; Wed, 26 Oct 2005 13:27:19 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-126.messagelabs.com!1130346807!9034668!2 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 4177 invoked from network); 26 Oct 2005 17:13:28 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-5.tower-126.messagelabs.com with SMTP; 26 Oct 2005 17:13:28 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA00077A27; Wed, 26 Oct 2005 13:13:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 12:12:56 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9570@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXaCtHdyXdgeyQKS7eTEyNty8XnoQADdYmQAAxi+TA= From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John, All, > > However, that doesn't change my concluding thought - in fact=20 > > it probably reinforces it, since I haven't seen any compelling=20 > > examples of why multiple packet classifiers are required. > I agree, I would like to see a more compelling reason for supporting=20 > multiple packet classifiers. If you would model the end-to-end flow > traversing multiple QoS domains, wouldn't you still need to have some > notion of a classifier that would work along the entire path? I don't > quite see what a different packet classifier somewhere in the=20 > middle of the network would buy you. I also agree. It would be good to see a concrete example (vs. hypothetical example) of when separate packet_classifiers are needed. I'm not sure I follow the current drift of the discussion. Are we now saying that - we do *not* need to signal packet_classifier in the QSPEC - we do *not* need to signal multiple packet_classifier's in QoS-NSLP Hopefully the answers are both 'yes', but I'd appreciate someone to clarify. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 26 13:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUowe-0005p3-Pk; Wed, 26 Oct 2005 13:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUowc-0005m8-O6 for nsis@megatron.ietf.org; Wed, 26 Oct 2005 13:20:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08506 for ; Wed, 26 Oct 2005 13:19:54 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUp9p-0002Pl-2G for nsis@ietf.org; Wed, 26 Oct 2005 13:33:49 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9QHK0tw027470; Wed, 26 Oct 2005 19:20:00 +0200 (MEST) Message-ID: <010301c5da51$800d0430$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Andrew McDonald" References: <435E506D.5010909@roke.co.uk><050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl><435F4348.5070703@roke.co.uk><006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> <435F5E3B.1040204@roke.co.uk> <009301c5da2b$4482d140$4c0d5982@dynamic.ewi.utwente.nl> <435FB4FB.4000208@roke.co.uk> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 19:19:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.407 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 19:20:04 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew Please see in line! ----- Original Message ----- From: "Andrew McDonald" To: "Georgios Karagiannis" Cc: Sent: Wednesday, October 26, 2005 6:55 PM Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi Georgios, > > Georgios Karagiannis wrote: >>>> Georgios: but if the node accepts the QSPEC then there is no problem! >>>> A node can process a QSPEC only if it is able to recognise it. >>>> This means that the packet classifier is also configured. >>> >>> >>> I think understand what the difference is between the 'pure local >>> configuration' and 'QoS model defined' non-signalled packet classifier >>> possibilities are. As I understand it, your suggestion is that the "QoS >>> model" field in the QSpec object implicitly identifies the packet >>> filtering rules. >> >> >> Georgios: No, my last proposal is that we do not need to signal the >> packet classifier information at all! > > In that case I don't understand what you are proposing at the moment. I > may have missed (or misunderstood) something in one of your previous > e-mails. > > Can you clarify what you mean when you say "It is a QoS model issue"? I > can see two possibilities for this: > a) The packet classifier is determined by the QoS model used by the QSpec > in the message > b) The packet classifier is determined by the node receiving a message > based on the QoS model it supports > > I thought you meant (a). Do you mean (b)? Or is it something else? > Georgios: Well I have been supporting a), but Cheng (NATP translation problems) convinced me that we have to use the paramters of MRI as much as possible. In addition we can allow QoS models to use local configuration of the packet classifier rules. Best Regards, Georgios > Andrew > > >>> Some issues that spring to mind: >>> >>> - what happens for a QoS Model that can use different packet >>> classifiers? e.g. in the Intserv controlled load case you could make a >>> reservation relating to a pair of IP addresses, or one relating to the >>> full 5-tuple, or ... >> >> >> Georgios: Well, in the previous e-mail discussions I have tried to make >> this very clear, please check the >> previous e-mail of this tread! >> Furthermore, the rules of this packet classifier should be rules that are >> related to the >> information included in the header of the IP packets. Thus each QoS model >> can >> specify any additional filtering rule (note that typically it should use >> MRI parameters) >> it wants assuming that these rules are related to the >> fields of the IP header. >> Please note that the responsability of assigning packet classifier rules >> is the responsability of the QoS model. >> >> >> >>> allowing the local QoS Model to choose the packet classifier creates >>> additional problem cases where the local view differs from the >>> end-to-end view, e.g. you go into a domain where the QoS model uses the >>> DSCP as part of the packet classifier, but the QNI hasn't included the >>> DSCP in the MRI. You could possibly do some remarking, etc in this QoS >>> model domain, but that would seem to be a situation where you should be >>> using a separate signalling session. >> >> >> Georgios: I do not think that you will have any problems. Please see my >> previous e-mails on this tread! >> >> >> in the case of an unknown QoS Model? There is supposed to >> >>> be a mandatory subset of the QSpec objects which allows things to >>> proceed even if the QoS model is not understood. What do these nodes use >>> for the packet classifier? >> >> >> Georgios: This should be specified by the QoS model! >> >> Best Regards, >> Georgios >> >>> >>> >>> regards, >>> >>> Andrew >>> >>> _______________________________________________ >>> 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 nsis-bounces@ietf.org Wed Oct 26 13:24:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUp0u-00077B-B5; Wed, 26 Oct 2005 13:24:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUp0p-00075X-Ov for nsis@megatron.ietf.org; Wed, 26 Oct 2005 13:24:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08661 for ; Wed, 26 Oct 2005 13:24:15 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUpDz-0002Wd-9p for nsis@ietf.org; Wed, 26 Oct 2005 13:38:07 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9QHOMhq027650; Wed, 26 Oct 2005 19:24:22 +0200 (MEST) Message-ID: <010d01c5da52$1c47ad00$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Ash, Gerald R \(Jerry\), ALABS" , , References: <9473683187ADC049A855ED2DA739ABCA09FA9570@KCCLUST06EVS1.ugd.att.com> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 26 Oct 2005 19:24:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.206 () ALL_TRUSTED, AWL, BAYES_00, FVGT_m_MULTI_ODD, FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 26 Oct 2005 19:24:24 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry Please see in line! ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" To: ; Cc: "Ash, Gerald R (Jerry), ALABS" Sent: Wednesday, October 26, 2005 7:12 PM Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi John, All, > >> > However, that doesn't change my concluding thought - in fact >> > it probably reinforces it, since I haven't seen any compelling >> > examples of why multiple packet classifiers are required. > >> I agree, I would like to see a more compelling reason for supporting >> multiple packet classifiers. If you would model the end-to-end flow >> traversing multiple QoS domains, wouldn't you still need to have some >> notion of a classifier that would work along the entire path? I don't >> quite see what a different packet classifier somewhere in the >> middle of the network would buy you. > > I also agree. It would be good to see a concrete example (vs. > hypothetical example) of when separate packet_classifiers are needed. > > I'm not sure I follow the current drift of the discussion. Are we now > saying that > - we do *not* need to signal packet_classifier in the QSPEC > - we do *not* need to signal multiple packet_classifier's in QoS-NSLP > > Hopefully the answers are both 'yes', but I'd appreciate someone to > clarify. Georgios: From my point of view the answers is Yes for both! Georgios: Please note that I was supporting the option of including the packet classifier in the QQSPEC, but Cheng (due NATP translation problems) convinced me that we have to use the paramters of MRI as much as possible. In addition we can allow QoS models to use local configuration of the packet classifier rules. Best Regards, Georgios > > Thanks, > Jerry > > _______________________________________________ > 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 nsis-bounces@ietf.org Wed Oct 26 18:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu8C-0001LJ-Sv; Wed, 26 Oct 2005 18:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu61-0000XQ-5m; Wed, 26 Oct 2005 18:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02402; Wed, 26 Oct 2005 18:49:56 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUuJ7-0008Hp-E8; Wed, 26 Oct 2005 19:03:49 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5r-0005e4-6z; Wed, 26 Oct 2005 18:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 18:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-applicability-mobility-signaling-03.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Applicability Statement of NSIS Protocols in Mobile Environments Author(s) : S. Lee, et al. Filename : draft-ietf-nsis-applicability-mobility-signaling-03.txt Pages : 70 Date : 2005-10-26 The mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocols, and how the protocols operate in different scenarios, and together with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-03.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-applicability-mobility-signaling-03.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-applicability-mobility-signaling-03.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: <2005-10-26182957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-applicability-mobility-signaling-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26182957.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Thu Oct 27 04:36:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3Fd-0003O3-JT; Thu, 27 Oct 2005 04:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV3Fc-0003Mt-E7 for nsis@megatron.ietf.org; Thu, 27 Oct 2005 04:36:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15962 for ; Thu, 27 Oct 2005 04:36:28 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV3Sv-0002xd-EH for nsis@ietf.org; Thu, 27 Oct 2005 04:50:31 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j9R8aVp0000269 for ; Thu, 27 Oct 2005 17:36:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j9R8aWc11723 for ; Thu, 27 Oct 2005 17:36:32 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j9R8aVk19636 for ; Thu, 27 Oct 2005 17:36:31 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml26) id j9R8aVE26470 for nsis@ietf.org; Thu, 27 Oct 2005 17:36:31 +0900 (JST) Received: from [10.68.136.43] by soml26.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j9R8aJu25987; Thu, 27 Oct 2005 17:36:19 +0900 (JST) Date: Thu, 27 Oct 2005 17:36:20 +0900 From: Takako Sanda To: nsis@ietf.org Message-Id: <20051027173418.F100.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Toyoki Ue , Cheng Hong Subject: [NSIS] Requirements for handling multiple paths in NSIS signaling X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, We have updated a draft "Path type support for NSIS signaling". http://www.ietf.org/internet-drafts/draft-sanda-nsis-path-type-03.txt In this version, problems and requirements for handling the case one session has multiple paths, such as multihoming and Mobile IP RO, are cleared. We would like to discuss if the problems and requirements described in this draft would be useful for NSIS study, especially for mobility/multihoming support in NSIS. abstract: NSIS state management needs to track data path changes and update the states along the affected data paths. However, in certain scenarios, there are multiple concurrent paths involved in the communication. In this case, the normal NSIS scheme does not provide sufficient support for the state manipulation. Therefore, extra functionality for data path identification and distinction is necessary. In current Internet, with the increasing use of multi-homing devices and the employment of Mobile IP, the above issue is getting more prominent. This draft discusses in detail the problems and issues involved in the NSIS state management relevant to the data path differentiation. Specific scenarios for multi-homing and Mobile IP route optimization are studied. Potential solution and its impacts on current NSIS protocol design are discussed as well. BR, Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 27 06:48:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV5J5-0007JZ-4p; Thu, 27 Oct 2005 06:48:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV5J2-0007JL-Uw for nsis@megatron.ietf.org; Thu, 27 Oct 2005 06:48:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21164 for ; Thu, 27 Oct 2005 06:48:08 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV5WO-00066R-4t for nsis@ietf.org; Thu, 27 Oct 2005 07:02:12 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9RAliWA031399; Thu, 27 Oct 2005 11:47:44 +0100 Received: from [193.118.197.247] ([193.118.197.247]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 11:47:44 +0100 Message-ID: <4360B050.5000108@roke.co.uk> Date: Thu, 27 Oct 2005 11:47:44 +0100 From: Andrew McDonald User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <435E506D.5010909@roke.co.uk><050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl><435F4348.5070703@roke.co.uk><006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> <435F5E3B.1040204@roke.co.uk> <009301c5da2b$4482d140$4c0d5982@dynamic.ewi.utwente.nl> <435FB4FB.4000208@roke.co.uk> <010301c5da51$800d0430$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <010301c5da51$800d0430$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2005 10:47:44.0542 (UTC) FILETIME=[DCB83BE0:01C5DAE3] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, Georgios Karagiannis wrote: >>>>> Georgios: but if the node accepts the QSPEC then there is no problem! >>>>> A node can process a QSPEC only if it is able to recognise it. >>>>> This means that the packet classifier is also configured. >>>> >>>> I think understand what the difference is between the 'pure local >>>> configuration' and 'QoS model defined' non-signalled packet >>>> classifier possibilities are. As I understand it, your suggestion is >>>> that the "QoS model" field in the QSpec object implicitly identifies >>>> the packet filtering rules. >>> >>> Georgios: No, my last proposal is that we do not need to signal the >>> packet classifier information at all! >> >> In that case I don't understand what you are proposing at the moment. >> I may have missed (or misunderstood) something in one of your previous >> e-mails. >> >> Can you clarify what you mean when you say "It is a QoS model issue"? >> I can see two possibilities for this: >> a) The packet classifier is determined by the QoS model used by the >> QSpec in the message >> b) The packet classifier is determined by the node receiving a message >> based on the QoS model it supports >> >> I thought you meant (a). Do you mean (b)? Or is it something else? > > Georgios: Well I have been supporting a), but Cheng (NATP translation > problems) > convinced me that we have to use the paramters of MRI as much as possible. > In addition we can allow QoS models to use local configuration of the > packet classifier > rules. In that case, there was probably some confusion from the different way I phrased it. When I said: "the "QoS model" field in the QSpec object implicitly identifies the packet filtering rules", what I was trying to say was that when a QNE receives a message it can look at the field in the QSpec header and then, based on its knowledge of the definition of that QoS model, it knows what packet classifier to use. i.e. the packet classifier is determined by the QoS model used by the QSpec in the message Is that the way you believe it should work? However, I'm still not sure I understand exactly what you mean by "In addition we can allow QoS models to use local configuration of the packet classifier rules.", which suggests that there may be something more than "just (a)". I'm not sure my understanding of the phrase "local configuration" is the same as the way you are using it. Also, I'm not entirely clear how this works as an "addition" to (a). Could you clarify? In any case, if (a) is (more or less) what we're talking about, then I do have problems with this: >>>> Some issues that spring to mind: >>>> >>>> - what happens for a QoS Model that can use different packet >>>> classifiers? e.g. in the Intserv controlled load case you could make >>>> a reservation relating to a pair of IP addresses, or one relating to >>>> the full 5-tuple, or ... >>> >>> Georgios: Well, in the previous e-mail discussions I have tried to >>> make this very clear, please check the >>> previous e-mail of this tread! >>> Furthermore, the rules of this packet classifier should be rules that >>> are related to the >>> information included in the header of the IP packets. Thus each QoS >>> model can >>> specify any additional filtering rule (note that typically it should >>> use MRI parameters) >>> it wants assuming that these rules are related to the >>> fields of the IP header. >>> Please note that the responsability of assigning packet classifier >>> rules is the responsability of the QoS model. I'm not sure how much of a problem this one may be. As far as I can see, it means that only a single set of packet classifier rules can be defined for each QoS model. However, since that definition may be "all of the MRI" that might not be so much of a problem, since different packet classifiers can be created by setting different sets of fields in the MRI. One thought that I haven't really worked out properly: Are there any NAT issues to this? i.e. might you need to set ports in the MRI to traverse a NAT properly, but only want to reserve traffic between a pair of addresses? >>>> allowing the local QoS Model to choose the packet classifier creates >>>> additional problem cases where the local view differs from the >>>> end-to-end view, e.g. you go into a domain where the QoS model uses >>>> the DSCP as part of the packet classifier, but the QNI hasn't >>>> included the DSCP in the MRI. You could possibly do some remarking, >>>> etc in this QoS model domain, but that would seem to be a situation >>>> where you should be using a separate signalling session. >>> >>> Georgios: I do not think that you will have any problems. Please see >>> my previous e-mails on this tread! At the moment I can't find any previous discussion addressing this particular issue. As a more detailed example of the problem: The QNI sets the MRI as: (IP src, IP dst) and no other fields And QoS Model X is used which defines the packet classifier as "all of the MRI", so all is well. It reaches a QNE which is at an edge between regions where two different QoS models are being used. So, it stacks QoS Model Y on top. A QNE receives the message and looks at the QSpec, and sees it is for QoS Model Y. The packet classifier for QoS Model Y uses a combination of IP source address and DSCP (to use one of your previous examples). This is where we hit the problem: The MRI doesn't contain the DSCP. What happens? >>> in the case of an unknown QoS Model? There is supposed to >>>> be a mandatory subset of the QSpec objects which allows things to >>>> proceed even if the QoS model is not understood. What do these nodes >>>> use for the packet classifier? >>> >>> Georgios: This should be specified by the QoS model! Which QoS model? For example: - the message has a single QSpec. It says "QOSM ID = 3". - the message is received by a QNE only understand QoS models 2 and 4. Since it doesn't know what the packet classifier for "QOSM 3" is, what does it do? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 27 07:54:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6LG-0001xU-SR; Thu, 27 Oct 2005 07:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6LF-0001xK-CV for nsis@megatron.ietf.org; Thu, 27 Oct 2005 07:54:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23497 for ; Thu, 27 Oct 2005 07:54:28 -0400 (EDT) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV6Ya-0007jw-Hg for nsis@ietf.org; Thu, 27 Oct 2005 08:08:34 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id j9RBsc3e019384; Thu, 27 Oct 2005 13:54:38 +0200 (MEST) Message-ID: <002401c5daed$360e2c50$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Andrew McDonald" References: <435E506D.5010909@roke.co.uk><050001c5d980$b8e2a6b0$4c0d5982@dynamic.ewi.utwente.nl><435F4348.5070703@roke.co.uk><006d01c5da0e$fc5e1a30$4c0d5982@dynamic.ewi.utwente.nl> <435F5E3B.1040204@roke.co.uk> <009301c5da2b$4482d140$4c0d5982@dynamic.ewi.utwente.nl> <435FB4FB.4000208@roke.co.uk> <010301c5da51$800d0430$4c0d5982@dynamic.ewi.utwente.nl> <4360B050.5000108@roke.co.uk> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Thu, 27 Oct 2005 13:54:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.405 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 27 Oct 2005 13:54:41 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew As I see, it will take us a lot of time to resolve this issue! I propose to disuss this in more detail during the IETF meeting in Vancouver! For the time being it is okay with me that this issue is considered as an QSPEC/QoS-NSLP open issue! Best regards, Georgios ----- Original Message ----- From: "Andrew McDonald" To: "Georgios Karagiannis" Cc: Sent: Thursday, October 27, 2005 12:47 PM Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC > Hi Georgios, > > Georgios Karagiannis wrote: >>>>>> Georgios: but if the node accepts the QSPEC then there is no problem! >>>>>> A node can process a QSPEC only if it is able to recognise it. >>>>>> This means that the packet classifier is also configured. >>>>> >>>>> I think understand what the difference is between the 'pure local >>>>> configuration' and 'QoS model defined' non-signalled packet classifier >>>>> possibilities are. As I understand it, your suggestion is that the >>>>> "QoS model" field in the QSpec object implicitly identifies the packet >>>>> filtering rules. >>>> >>>> Georgios: No, my last proposal is that we do not need to signal the >>>> packet classifier information at all! >>> >>> In that case I don't understand what you are proposing at the moment. I >>> may have missed (or misunderstood) something in one of your previous >>> e-mails. >>> >>> Can you clarify what you mean when you say "It is a QoS model issue"? I >>> can see two possibilities for this: >>> a) The packet classifier is determined by the QoS model used by the >>> QSpec in the message >>> b) The packet classifier is determined by the node receiving a message >>> based on the QoS model it supports >>> >>> I thought you meant (a). Do you mean (b)? Or is it something else? >> >> Georgios: Well I have been supporting a), but Cheng (NATP translation >> problems) >> convinced me that we have to use the paramters of MRI as much as >> possible. >> In addition we can allow QoS models to use local configuration of the >> packet classifier >> rules. > > In that case, there was probably some confusion from the different way I > phrased it. > > When I said: "the "QoS model" field in the QSpec object implicitly > identifies the packet filtering rules", what I was trying to say was that > when a QNE receives a message it can look at the field in the > QSpec header and then, based on its knowledge of the definition of that > QoS model, it knows what packet classifier to use. i.e. the packet > classifier is determined by the QoS model used by the QSpec in the message > > Is that the way you believe it should work? > > > However, I'm still not sure I understand exactly what you mean by "In > addition we can allow QoS models to use local configuration of the packet > classifier rules.", which suggests that there may be something more than > "just (a)". > > I'm not sure my understanding of the phrase "local configuration" is the > same as the way you are using it. Also, I'm not entirely clear how this > works as an "addition" to (a). Could you clarify? > > > In any case, if (a) is (more or less) what we're talking about, then I do > have problems with this: > >>>>> Some issues that spring to mind: >>>>> >>>>> - what happens for a QoS Model that can use different packet >>>>> classifiers? e.g. in the Intserv controlled load case you could make a >>>>> reservation relating to a pair of IP addresses, or one relating to the >>>>> full 5-tuple, or ... >>>> >>>> Georgios: Well, in the previous e-mail discussions I have tried to >>>> make this very clear, please check the >>>> previous e-mail of this tread! >>>> Furthermore, the rules of this packet classifier should be rules that >>>> are related to the >>>> information included in the header of the IP packets. Thus each QoS >>>> model can >>>> specify any additional filtering rule (note that typically it should >>>> use MRI parameters) >>>> it wants assuming that these rules are related to the >>>> fields of the IP header. >>>> Please note that the responsability of assigning packet classifier >>>> rules is the responsability of the QoS model. > > I'm not sure how much of a problem this one may be. As far as I can see, > it means that only a single set of packet classifier rules can be defined > for each QoS model. However, since that definition may be "all of the MRI" > that might not be so much of a problem, since different packet classifiers > can be created by setting different sets of fields in the MRI. > > One thought that I haven't really worked out properly: Are there any NAT > issues to this? i.e. might you need to set ports in the MRI to traverse a > NAT properly, but only want to reserve traffic between a pair of > addresses? > >>>>> allowing the local QoS Model to choose the packet classifier creates >>>>> additional problem cases where the local view differs from the >>>>> end-to-end view, e.g. you go into a domain where the QoS model uses >>>>> the DSCP as part of the packet classifier, but the QNI hasn't included >>>>> the DSCP in the MRI. You could possibly do some remarking, etc in this >>>>> QoS model domain, but that would seem to be a situation where you >>>>> should be using a separate signalling session. >>>> >>>> Georgios: I do not think that you will have any problems. Please see my >>>> previous e-mails on this tread! > > At the moment I can't find any previous discussion addressing this > particular issue. > > As a more detailed example of the problem: > > The QNI sets the MRI as: > (IP src, IP dst) and no other fields > And QoS Model X is used which defines the packet classifier as "all of the > MRI", so all is well. > > It reaches a QNE which is at an edge between regions where two different > QoS models are being used. So, it stacks QoS Model Y on top. > > A QNE receives the message and looks at the QSpec, and sees it is for QoS > Model Y. The packet classifier for QoS Model Y uses a combination of IP > source address and DSCP (to use one of your previous examples). > > This is where we hit the problem: The MRI doesn't contain the DSCP. > > What happens? > >>>> in the case of an unknown QoS Model? There is supposed to >>>>> be a mandatory subset of the QSpec objects which allows things to >>>>> proceed even if the QoS model is not understood. What do these nodes >>>>> use for the packet classifier? >>>> >>>> Georgios: This should be specified by the QoS model! > > Which QoS model? > > For example: > - the message has a single QSpec. It says "QOSM ID = 3". > - the message is received by a QNE only understand QoS models 2 and 4. > Since it doesn't know what the packet classifier for "QOSM 3" is, what > does it do? > > > regards, > > Andrew > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 27 08:40:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV73R-0001rp-IG; Thu, 27 Oct 2005 08:40:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV73M-0001jt-6H for nsis@megatron.ietf.org; Thu, 27 Oct 2005 08:40:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26437 for ; Thu, 27 Oct 2005 08:40:02 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV7Gd-0000f5-48 for nsis@ietf.org; Thu, 27 Oct 2005 08:54:08 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1130416794!8913649!2 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8256 invoked from network); 27 Oct 2005 12:40:01 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-120.messagelabs.com with SMTP; 27 Oct 2005 12:40:01 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA000941AC; Thu, 27 Oct 2005 08:36:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2005 07:36:37 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9593@KCCLUST06EVS1.ugd.att.com> Thread-Topic: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXa7ZhWvMQ42k6nR0ej/AAuRVoOBAABBYyQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , "Andrew McDonald" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Georgios, Andrew, All, > As I see, it will take us a lot of time to resolve this > issue! I propose to discuss this in more detail during > the IETF meeting in Vancouver! > For the time being it is okay with me that this issue > is considered as an QSPEC/QoS-NSLP open issue! That's all well and good. But IMO we're still lacking a practical, realistic example of a flow (signaled by NSIS) that would require 2 (or more) packet_classifiers within the same flow. We keep mentioning hypothetical examples and realize that these are complex (or perhaps impossible). Can someone give a real example, this will help the discussion in Vancouver (and on the list). If it's been given before, please just give it again (I can't find it now in this long thread). If we can't come up with a real example, then maybe we don't have an issue. =20 Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 27 10:50:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV95O-0003e2-Re; Thu, 27 Oct 2005 10:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV94w-0003Qj-HJ; Thu, 27 Oct 2005 10:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03904; Thu, 27 Oct 2005 10:49:47 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9IG-0004W9-CW; Thu, 27 Oct 2005 11:03:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94r-0000GK-Na; Thu, 27 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-08.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-08.txt Pages : 100 Date : 2005-10-27 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators and firewalls. This NSLP allows hosts to signal along a data path for Network Address Translators and firewalls to be configured according to the data flow needs. The network scenarios, problems and solutions for path-coupled Network Address Translator and firewall signaling are described. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-08.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-nslp-natfw-08.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-nslp-natfw-08.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: <2005-10-27081121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27081121.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Thu Oct 27 15:50:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDm5-0007xl-Vv; Thu, 27 Oct 2005 15:50:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDlI-0007e6-CI; Thu, 27 Oct 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25343; Thu, 27 Oct 2005 15:49:52 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDye-0000dr-Ln; Thu, 27 Oct 2005 16:03:58 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EVDlD-0006Qp-3B; Thu, 27 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-statemachine-01.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIST State Machine Author(s) : H. Tschofenig, et al. Filename : draft-ietf-nsis-ntlp-statemachine-01.txt,.pdf Pages : 24 Date : 2005-10-27 This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-statemachine-01.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-ntlp-statemachine-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27132111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-statemachine-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27132111.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Oct 28 06:33:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRYd-0004NS-OB; Fri, 28 Oct 2005 06:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRYZ-0004IJ-81 for nsis@megatron.ietf.org; Fri, 28 Oct 2005 06:33:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06423 for ; Fri, 28 Oct 2005 06:33:38 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRm4-0000vl-Hr for nsis@ietf.org; Fri, 28 Oct 2005 06:47:55 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9SAWPWA022906; Fri, 28 Oct 2005 11:32:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST section 4.3.2, adjacency-check Date: Fri, 28 Oct 2005 11:32:40 +0100 Message-ID: Thread-Topic: [NSIS] GIST section 4.3.2, adjacency-check Thread-Index: AcXaTR27Q8hoyEueR4OaScEq2GmTWABXAoHQ From: "Hancock, Robert" To: "Thomas Herzog" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Thomas, I'll add the need for some more clarification on the synchronous nature of the check to 4.3.2 under issue 100. In terms of how the updated payload is provided, i think the minimal requirement on an NSIS implementation is that it is done synchronously as part of the processing of the Query message. To define what=20 'synchronously' means more precisely is hard to do without going into implementation issues, or at least API issues. My assumption is that the easiest way to do this is for the return value from the NSLP to provide a pointer to the result and the updated payload;=20 another way (if the NSLP and GIST are in the same process or at least able to share memory) is for the Payload argument provided by=20 GIST in the RecvMessage call to be mutable and to contain the updated payload when the call returns. Having the application call SendMessage synchronously is another possibility, but I would say less attractive from an implementation perspective for at least the reasons you give below. Other reasons are that GIST has to correlate the two calls and to realise that the SendMessage does not lead to a new Query but a modified payload for a 'pending' one, and that the usage of SendMessage has to be very restricted (e.g. can't set the transfer attributes, or freely choose the GHC or IP TTL and so on). I think it would be possible to add some description along these lines to the API sections. cheers, robert h. > -----Original Message----- > From: Thomas Herzog [mailto:thomas.herzog@gmx.li]=20 > Sent: 26 October 2005 17:43 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] GIST section 4.3.2, adjacency-check >=20 >=20 > Hi, Robert, >=20 > You input made it all clearer, but maybe the first paragraphs=20 > auf 4.3.2 need=20 > some alteration to make it clear that:=20 >=20 > "When the initial GIST-Query is received, GIST checks with=20 > the appropriate=20 > NSLP if routing state towards the Q-Node should be=20 > established. This is done=20 > by calling the RecvMessage primitive with Adjacency-Check=20 > flag set. GIST then=20 > interprets the Return value to carry out what the NSLP has=20 > decided. This can=20 > be: > - ... > - ..." >=20 > The other irritations I had were caused by the fact that I=20 > did not recognize=20 > that the RecvMessage call is in fact a synchronous function=20 > call (with a=20 > return value). As we are implementing the API via Messages=20 > (over a UNIX=20 > domain socket), this implies some modifications to our implementation=20 > specific state machine. >=20 > But besides implementation specific issues, there is still=20 > one little quirk in=20 > the draft: >=20 > - GIST calls RecvMessage with the Adjacency-Flag set, the=20 > Return value is=20 > inspected so it will either send a response or relay the message. >=20 > This is done synchronously via the API primitive. >=20 > - The NSLP MAY provide altered data payload in both cases >=20 > How is THAT to be done? Is the FIRST SendMessage from the=20 > NSLP carrying that=20 > data? Is it defined in NSLP drafts, that there MUST be a=20 > SendMessage after a=20 > RecvMessage with Adjacency-Check flag set? >=20 > Furthermore, if GIST inspected the return code of the=20 > RecvMessage call, it=20 > would still have to wait for Data to include? >=20 > How long would it wait? What if NSLP wants to include NO=20 > UPDATED data? Will it=20 > pass a SendMessage anyway, even with the old data? >=20 > Or should there be MORE return values to RecvMessage?=20 > e.g. "relay"/"relay - data following"/"setup state"/"setup=20 > state - data=20 > following"? The return values are not defined further in the draft. >=20 > This also seems to require a "temporary" state for the R-Node=20 > state machine:=20 > "awaiting replaced data" which will be destroyed if the=20 > action (send back=20 > response or relay query, go to awaiting-confirm or dead=20 > afterwards) has been=20 > performed. >=20 > This requirement seems not to be implementation specific,=20 > SendMessage is an=20 > asynchronous primitive after all. >=20 > Cheers, > Thomas >=20 > Am Mittwoch, 26. Oktober 2005 17:29 schrieben Sie: > > hi, > > > > i've added this as > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue100 > > > > will either/both of you be in vancouver? it might be good to have > > a review of the next version (which i will probably do during the > > meeting ...) to find out whether particular parts are clearer. > > > > cheers, > > > > r. > > > > > -----Original Message----- > > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > > Behalf Of Hancock, Robert > > > Sent: 26 October 2005 14:42 > > > To: Roland Bless; Thomas Herzog > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] GIST section 4.3.2, adjacency-check > > > > > > > > > hi roland, thomas, > > > > > > i can provide some general and specific clarifications. > > > > > > 1) "adjacent" =3D "having explicit routing state towards";=20 > the key point > > > is about routing state, not messaging associations. signalling > > > applications care about being adjacent or not, but don't=20 > care about > > > messaging associations. (MAs can only be set up between > > > adjacent peers, > > > but this is logically subordinate to the adjacency, which is > > > the primary > > > concept.) > > > > > > 2) routing state is managed entirely by GIST handshake=20 > operations. so, > > > the key message is the Query - you have to accept Responses > > > to your own > > > Queries, and have to accept Responses to your own=20 > Confirms. So, the > > > choice is made during the processing of the initial Query. > > > > > > 3) the adjecency check that GIST makes with the NSLP is performed > > > *within* the processing of the Query message, i.e. during the > > > processing GIST will at some point call RecvMessage and=20 > will expect > > > a return value which tells it what to do. it then sends a Response > > > for re-forwards the Query as appropriate. There is no separate > > > SendMessage call from the NSLP to do this. > > > > > > some further detailed comments in line, > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Roland Bless [mailto:bless@tm.uka.de] > > > > Sent: 25 October 2005 15:34 > > > > To: Thomas Herzog > > > > Cc: nsis@ietf.org; Hancock, Robert > > > > Subject: Re: [NSIS] GIST section 4.3.2, adjacency-check > > > > > > > > > > > > Hi Thomas, > > > > > > > > I think section 4.3.2 needs definitely some clarifications. > > > > > > > > >> Even when a message relates to a local signaling > > > > > > application, an > > > > > > > >> adjacency MAY be required based on signaling application > > > > > > > > policy, and > > > > > > > > >> the application of this policy MAY depend on the=20 > NSLP payload. > > > > >> Therefore, when this decision has to be made, the NSLP > > > > > > payload is > > > > > > > >> delivered and the signaling application has two options: > > > > >> > > > > >> o to proceed setting up the adjacency. The application > > > > > > > > MAY provide > > > > > > > > >> an NSLP payload (which will be used in any=20 > GIST-Response). > > > > >> > > > > >> o to bypass the message and drop out of the signaling > > > > > > path. The > > > > > > > >> application MAY provide an updated NSLP payload > > > > > > (which will be > > > > > > > >> used in the message which is then forwarded by GIST). > > > > > > > > > > As the GIST API defines a "adjacency check" flag in > > > > > > > > RecvMessage, I suppose, > > > > > > > > > GIST must indicate the request of a Messaging Association > > > > > > > > ("adjacency"?!?!) > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > At least the terminology section doesn't state that > > > > > > Adjacency means or > > > > > > > is identical to an MA between two peers. IMHO it only > > > > > > defines that two > > > > > > > GIST nodes are directly adjacent with respect to GIST and NSLP. > > > > If I understood the Adjacency Check mechanism correctly it > > > > > > allows an > > > > > > > NSLP to act as a bypass if it is not interested in the exchange. > > > > > > yep. > > > > > > > A little bit confusing is the fact that section 4.3.2 doesn't > > > > specify exactly the message which may request the setup of an > > > > adjacency. > > > > Is there a difference if it is a GIST-Query, GIST-Confirm, > > > > GIST-Response > > > > or GIST-Data (maybe even received via an existing MA). > > > > > > see above (i hope). > > > > > > > Again in more detail: > > > > >> Even when a message relates to a local signaling > > > > > > application, an > > > > > > > >> adjacency MAY be required based on signaling > > > > > > application policy, > > > > > > > "an adjacency": is it an adjacency with the Querying=20 > upstream node? > > > > Could it be a different adjacency with another third node? > > > > > > with the upstream node. > > > > > > > >> o to proceed setting up the adjacency. The application > > > > > > > > MAY provide > > > > > > > > >> an NSLP payload (which will be used in any=20 > GIST-Response). > > > > > > > > So an adjacency can only be setup by a GIST-Query? What is the > > > > reaction of the local node? Does it send a GIST-Response back > > > > in this case or why says the above sentence "_any_=20 > GIST-Response"? > > > > > > the *any* refers to the fact that there may instead be a=20 > GIST-Error, > > > or retransmitted Responses, etc. > > > > > > > >> o to bypass the message and drop out of the signaling > > > > > > path. The > > > > > > > >> application MAY provide an updated NSLP payload > > > > > > (which will be > > > > > > > >> used in the message which is then forwarded by GIST). > > > > > > > > I assume that it should mean: the original message type with > > > > the updated > > > > NSLP payload is forwarded further down the path, i.e. in > > > > > > this case no > > > > > > > GIST-Response is generated. > > > > > > yes - and the original message is a Query. > > > > > > > > This raises some problems in my eyes: > > > > > > > > > > - When late state setup is used, GIST does not save any > > > > > > > > state where it later > > > > > > > > > could check if a Message Association is rightly established > > > > > > > > (it will be > > > > > > > > > established on receipt of a GIST Confirm). Only possibility > > > > > > > > would be to send > > > > > > > > > no Stack Proposal in the Response. However, some local > > > > > > > > state must be > > > > > > > > > established on Query receipt for asynchronously asking the > > > > > > > > NSLP via the > > > > > > > > > API?!?! > > > > > > > > So you mean some temporary local state until the NSLP has > > > > given an answer and a corresponding GIST-Response > > > > is created and sent back? This may be negligible because > > > > you would need some resources for processing a Query anyway. > > > > It is however important that no state is kept after the > > > > Response is sent. > > > > > > i hope this is explained by point (3) above. > > > > > > > > - When a message association is to be set up, the GIST > > > > > > > > Querier does generally > > > > > > > > > not include NSLP payload in the Query at all, because it > > > > > > > > gets queued until > > > > > > > > > the Association is set up (NSLP could have required > > > > > > > > 'reliable' or 'secure' > > > > > > > > > for the data). So GIST has no data to deliver to the NSLP > > > > > > > > when it asks if the > > > > > > > > > association should be set up. It would in general only > > > > > > > > deliver "shall I > > > > > > > > > associate", the MRI, the Session ID and the NSLPID... > > > > > > > > This is related somewhat to the problem mentioned in the thread > > > > "NSLP-Data in intial GIST-Query" and > > > >=20 > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74 > > > > > > you can easily imagine some initial data which does some=20 > capability > > > discovery at the NSLP level (which might not need to be sent > > > securely). in any case, this is a matter of NSLP design. > > > > > > > > Or is this section to be understood in a more general way? > > > > > > > > Is this "adjacency" > > > > > > > > > simply about setting up routing state in general? > > > > > > > > I think it is not clearly defined in the draft what "setting up > > > > an adjacency" really means... > > > > > > > > Regards, > > > > Roland > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 28 06:36:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRae-00069A-06; Fri, 28 Oct 2005 06:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRab-000695-Rt for nsis@megatron.ietf.org; Fri, 28 Oct 2005 06:36:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06537 for ; Fri, 28 Oct 2005 06:35:45 -0400 (EDT) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRo9-00010v-L9 for nsis@ietf.org; Fri, 28 Oct 2005 06:50:02 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j9SAYRVJ023250; Fri, 28 Oct 2005 19:34:27 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9SAYUX17396; Fri, 28 Oct 2005 19:34:30 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id j9SAYUa11440; Fri, 28 Oct 2005 19:34:30 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Fri, 28 Oct 2005 18:31:44 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD75AEAD@pslexc01.psl.local> Thread-topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXa7ZhWvMQ42k6nR0ej/AAuRVoOBAABBYyQAC2iu9A= From: "Cheng Hong" To: "Ash, Gerald R \(Jerry\), ALABS" , "Georgios Karagiannis" , "Andrew McDonald" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry, and all, I think a few things have been mixed together here. First issue is that the MRI not able to signal all the information for packet classification, e.g. when it needs to signal a port range, etc. Therefore, it is necessary to have some additional information to be signalled at NSLP layer. This is more about why/how the packet_classifier is introduced. Another issue is that when the additional information (say, packet_classifier) is used in NSLP layer, how the relevant issues should be resolved, e.g. NAT traveral, QSPEC stacking support (i.e. where to place it). Andrew has a very good summary of the issue in an earlier email. And only the second part is relevant to whether there require 2 or more packet_classifiers. Example for this case is the QSPEC stacking (assuming that MRI is not adequate, and packet_classifier has to exist). As Georgios suggested, tt would be good to have some face to face discussion during the Vancouver meeting. It may be earlier with some pirctures and drawings... cheers Cheng Hong =20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Ash, Gerald R (Jerry), ALABS > Sent: Thursday, October 27, 2005 8:37 PM > To: Georgios Karagiannis; Andrew McDonald; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >=20 > Hi Georgios, Andrew, All, >=20 > > As I see, it will take us a lot of time to resolve this issue! I=20 > > propose to discuss this in more detail during the IETF meeting in=20 > > Vancouver! > > For the time being it is okay with me that this issue is=20 > considered as=20 > > an QSPEC/QoS-NSLP open issue! >=20 > That's all well and good. But IMO we're still lacking a=20 > practical, realistic example of a flow (signaled by NSIS)=20 > that would require 2 (or > more) packet_classifiers within the same flow. We keep=20 > mentioning hypothetical examples and realize that these are=20 > complex (or perhaps impossible). >=20 > Can someone give a real example, this will help the=20 > discussion in Vancouver (and on the list). If it's been=20 > given before, please just give it again (I can't find it now=20 > in this long thread). >=20 > If we can't come up with a real example, then maybe we don't=20 > have an issue. =20 >=20 > Thanks, > Regards, > Jerry >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 28 06:48:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRmv-00058Q-8w; Fri, 28 Oct 2005 06:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRmt-0004zC-4n for nsis@megatron.ietf.org; Fri, 28 Oct 2005 06:48:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07067 for ; Fri, 28 Oct 2005 06:48:26 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVS0P-0001J3-TA for nsis@ietf.org; Fri, 28 Oct 2005 07:02:43 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j9SAmCWA027280; Fri, 28 Oct 2005 11:48:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Date: Fri, 28 Oct 2005 11:48:18 +0100 Message-ID: Thread-Topic: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME Thread-Index: AcXaQn50MW9PcZSjQ/GRpXw4sX9whgBaS4aA From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi roland, see below ... > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 26 October 2005 16:31 > To: Hancock, Robert > Cc: Thomas Herzog; nsis@ietf.org > Subject: Re: [NSIS] GIST Confirm contains no stack=20 > configuration data, which holds MA_HOLD_TIME >=20 >=20 > Hi Robert, >=20 > > the question of bidding down attacks is a really tricky > > one to work through in detail. but the basic components of > > the reasoning are as follows: > >=20 > > - if the response SCD is allowed to depend on the Query, then > > manipulation of the Query might cause a 'weak' proposal to be > > offered in the response. Saying that the response SCD MUST NOT > > depend on the Query is a 'play safe' approach - you could define > > less restrictive approaches, but actually the benefit of > > allowing more flexibility has not been clear. you *are* able to > > have different policies/offered SCDs for different NSLPs or > > interfaces (e.g. 'inside' vs. 'outside'), and this would seem > > to be sufficient (at least to me). >=20 > Yep, agreed, and I guess this point was already clear. > Though it may be good to include the explicit hint: "you *are* able to > have different policies/offered SCDs for different NSLPs or interfaces > (e.g. 'inside' vs. 'outside')" in the Spec. ok, i think this can be added as a clarification. >=20 > > - the Q-node must do a MA setup which respects the options given > > in the response SCD. so, interfering with the response-SCD could > > weaken the possible security properties of the MA. > > *if* all the following conditions apply: > > - a MITM can modify the response to weaken the set of offers > > - the Q node policy allows the use of the weaker protocol > > - the MITM is on the forward and reverse paths > > - the MITM can break the weaker protocol *in real time* >=20 > Correct analysis. >=20 > > *then there is nothing further that can be done against the > > attacker. so, the level of defence that is possible is a=20 > > combination of policy setting (at the Q-node) and verification=20 > > of the echoed R-SCD (at the R-node) - if the nodes have policies > > that minimally require selection of a MA which cannot be broken=20 > > in real time, then the rest of the protocol machinery will ensure > > that any attack is detected. >=20 > So far agreed. The only criticism I had was that > echoing the R-SCD is useless except for the situation > where you have a MITM on the reverse path (i.e., from > R-Node to Q-Node) and the MITM has no access to the > forward path. So we should simply save the bandwidth > and use it for sending back the MA-Hold-Time in an > "empty" Stack Configuration Data. I don't think this is quite right: an attack is possible whenever the MITM is on the reverse path, whether or not it is on the forward path. And the defence against the attack works whether or not the MITM is on the forward path, provided weak policies are not used. i think this is one of those security/complexity tradeoffs which are so hard to make. to me, the complexity seems not so great, and the circumstances where it is useful not so exceptional. but it=20 would be interesting to hear additional voices on this one. cheers, robert h. >=20 > > is this discussion logically coherent? should it be in the spec? > > (currently there is a reference to the sip-sec-agree spec, which > > has a very similar analysis). >=20 > Oops, sorry I must have missed that one. > However, except for the on-reverse-path-attacker-only case, I don't > see any value in "echoing" the R-SCD (it would have a real value > in case it was integrity protected by the Q-Node) and would plead > for simplification. >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 28 16:35:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVax9-0000mk-Hg; Fri, 28 Oct 2005 16:35:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVax7-0000jt-Sl for nsis@megatron.ietf.org; Fri, 28 Oct 2005 16:35:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17330 for ; Fri, 28 Oct 2005 16:35:37 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19qpabYmc3shljPcGG7tCKXXVgXZKYx77s=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVbAj-00045B-Nl for nsis@ietf.org; Fri, 28 Oct 2005 16:49:59 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EVawm-0007sY-HB; Fri, 28 Oct 2005 22:35:34 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 1E4CAB3D6; Fri, 28 Oct 2005 22:35:32 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EVawl-0007vs-R9; Fri, 28 Oct 2005 22:35:31 +0200 Message-ID: <43628B98.2000608@tm.uka.de> Date: Fri, 28 Oct 2005 22:35:36 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, > I don't think this is quite right: an attack is possible whenever > the MITM is on the reverse path, whether or not it is on the forward Right. > path. And the defence against the attack works whether or not the > MITM is on the forward path, provided weak policies are not used. To be more precise: the defence works because _weak_ policies are not used. But that was not my point. Maybe I'm wrong, but echoing the R-Node SCD does not contribute to security if the MITM is also on the forward path and is able to modify the confirm. The attacker cannot do anything if only "secure" protocols are allowed by the policy, bidding down will have no effect. In case we have proposals A,B,C and C is weak then I see the follow attack: Query: Q-Node --- A,B,C,D -> MITM - A,B,C,D --> R-Node Response: <--- C ------- MITM <-- A,B,C --- =========== MA C Setup =========> Confirm: ---- C ------- MITM --- A,B,C --> I don't see how the echoed list in the confirm lets the R-Node effectively detect that something was modified in between. In case the R-Node proposes and accepts only A,B (i.e. a proposal w/o weak protocols) there is no problem anyway. Another scenario that I described: Query: Q-Node --- A,B,C,D -> MITM - A,B,C,D --> R-Node Response: <--- C ------- MITM <-- A,B --- =========== MA C Setup =========> (this works only in case R-Node awaits C connections from other nodes etc.) Confirm: ---- C ------- MITM --- A,B ---> The R-Node should detect that something is wrong by checking that the established MA C is not acceptable by the policy for the Q-Node (this must be checked anyway). But the echo of the Stack Proposal in the Confirm will not bring you more security. > i think this is one of those security/complexity tradeoffs which > are so hard to make. to me, the complexity seems not so great, and Complexity is not a problem here, only redundancy. > the circumstances where it is useful not so exceptional. but it > would be interesting to hear additional voices on this one. One could argue that it may be slightly more difficult for an attacker to manipulate the confirm than to modify the Response. The problem is somewhat similar to the last problem mentioned in sec. 8.6. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Oct 30 18:19:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMSJ-0003uL-2M; Sun, 30 Oct 2005 18:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMSE-0003rt-NI for nsis@megatron.ietf.org; Sun, 30 Oct 2005 18:19:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24556 for ; Sun, 30 Oct 2005 18:18:52 -0500 (EST) Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWMgG-00057a-LT for nsis@ietf.org; Sun, 30 Oct 2005 18:33:43 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id C8B6511A; Mon, 31 Oct 2005 00:18:46 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37588-01; Mon, 31 Oct 2005 00:18:44 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E8006117; Mon, 31 Oct 2005 00:18:42 +0100 (MET) Message-ID: <436554D3.7030007@uni-tuebingen.de> Date: Mon, 31 Oct 2005 00:18:43 +0100 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Andreas Klenk , Tschofenig Hannes , Falko Dressler , Kappler Cornelia Subject: [NSIS] New update of the Metering NSLP drafts X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, we have submitted new versions of the Metering NSLP drafts: "Framework for Metering NSLP": http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-02.txt and "NSLP for Metering Configuration Signaling": http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-03.txt The framework document is pretty stable now. For the protocol document, we are still working on it. One of the issues that we've been discussing has been the "flow specification" for the measurement. This reminds me to the thread currently discussed in the nsis mailing list about the "PACKET_CLASSIFIER in QSPEC". Please note that for the Metering NSLP, we currently have an object called in the MSPEC and came to similar problems: - whether the flow spec should be related to the MRI? if yes, then how? - or could the be independant of the MRI? - which scenarios would be meaningful for such a "multiple packet classifier"? - which complexity do we have through a "flexible" flow spec, e.g. concerning NAT traversal and authorizing Metering NSLP messages. I'll unfortunately not be able to attend the meeting in Vancouver, but i'm sure there will be some intersting discussions on these issues! ;-) Cheers, ali. -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 31 06:47:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWY8C-00023x-Qy; Mon, 31 Oct 2005 06:47:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWY8A-00023Y-MK for nsis@megatron.ietf.org; Mon, 31 Oct 2005 06:47:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00514 for ; Mon, 31 Oct 2005 06:46:56 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWYML-0004ep-Ey for nsis@ietf.org; Mon, 31 Oct 2005 07:01:53 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9VBhFXF015839 for ; Mon, 31 Oct 2005 13:43:18 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 13:47:12 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 13:47:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2005 13:47:11 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D013D4D9D@esebe100.NOE.Nokia.com> Thread-Topic: NSIS IETF 64 Agenda Thread-Index: AcXeENSxk2SbrBNxTZGbbdL1BdC/yg== To: X-OriginalArrivalTime: 31 Oct 2005 11:47:12.0484 (UTC) FILETIME=[D507FA40:01C5DE10] X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NSIS IETF 64 Agenda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, This is the proposed Agenda. Please note that we will stick to times = for the WG items; non working group items will be dropped if we start = running short on time. thanks, John WEDNESDAY, November 9, 2005 0900-1130 Morning Session I TSV nsis Next Steps in Signaling WG Agenda bashing - chair - 10 min NATFW NSLP - Martin Stiemerling - 20 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-08.txt NATFW NSLP Implementation Status - Hannes Tschofenig - 5 min Mobility Applicability Statement for NSIS - TBA - 10 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobilit= y-signaling-03.txt GIST - Robert Hancock 20 mins=20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-08.txt Analysis of Options for Securing GIST - Hannes Tschofenig - 10 min http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-gist-security-0= 0.txt Path type support for NSIS signaling - Takako Sanda - 15 min http://www.ietf.org/internet-drafts/draft-sanda-nsis-path-type-03.txt NSIS Flow ID and packet classification Issues - Takako Sanda - 15 min http://www.ietf.org/internet-drafts/draft-cheng-nsis-flowid-issues-02.txt= =20 GIST over SCTP - Xiaming Fu - 5 min http://www.ietf.org/internet-drafts/draft-fu-nsis-ntlp-sctp-00=20 GIST over SCTP - Xiaming Fu - 5 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-statemachine-01.= txt NSIS Operation Over IP Tunnels - Henning Schulzrinne - 10 min=09 http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01.txt=20 AAA support for QoS signaling - Hannes Tschofenig - 10 min http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-05.txt http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-02.txt = =20 Metering NSLP - Jurgen Quittek- 10 min http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-02.= txt=20 http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-03.= txt=20 THURSDAY, November 10, 2005 1510-1610 Afternoon Session II TSV nsis Next Steps in Signaling WG QoS-NSLP - Jukka Manner - 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-08.txt QSPEC I-D - Jerry Ash - 10 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt Y.1541-QOSM I-D - Jerry Ash - 5 min http://ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt. User Application-to-User Plane Vertical Interface - Jerry Ash - 5 min http://ietf.org/internet-drafts/draft-ash-nsis-vertical-interface-00.txt RMD-QOSM - Attila B=E1der - 10 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-04.txt 3GPP-QOSM - TBA - 10 min http://www.ietf.org/internet-drafts/draft-jeong-nsis-3gpp-qosm-02.txt A QoS Model for Signaling IntServ Controlled-Load Service - X. Fu - 5 = min http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlle= dload-03=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 31 07:14:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWYYQ-0007IJ-1l; Mon, 31 Oct 2005 07:14:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWYYO-0007I8-8X for nsis@megatron.ietf.org; Mon, 31 Oct 2005 07:14:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01721 for ; Mon, 31 Oct 2005 07:14:01 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/ABF7prrEXFAR5bvK87Ht/4H0UGx6u/g0=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWYmW-0007BX-5r for nsis@ietf.org; Mon, 31 Oct 2005 07:28:59 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EWYYB-0006lL-PP; Mon, 31 Oct 2005 13:14:09 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 1E512B40E; Mon, 31 Oct 2005 13:14:07 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EWYYA-0004Mg-QY; Mon, 31 Oct 2005 13:14:06 +0100 Message-ID: <43660A8E.6090301@tm.uka.de> Date: Mon, 31 Oct 2005 13:14:06 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Falko Dressler , nsis , Tschofenig Hannes , Changpeng Fan , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Martin, > | OTOH I can imagine a scenario where you are configuring > | filter for packets that are normally and currently *not* > | flowing on the path from A to B. So the filter would be > | used to detect/measure some failure conditions or anomalies. In this > | case it would be even useful to configure filters along > | A->B so that they match flows that are currently not routed > | along that path. > > This would not be purely "path-coupled" anymore, since your are signaling > for flows apart your path. Is see the only envisioned use case for this Hmm, good question whether its path-coupled or not. You are signaling for flows which might be on that particular path in the future. Consider a domain with two ingress nodes A and B. Current inter-domain routing will inject a flow aggregate F at ingress A and route it to egress E. However, you might be interested when F is actually flowing into ingress B taking a different path to E. However, the current path will not lead to ingress B, and that's where it's not exactly path coupled anymore. > filter spec in Section 4.3 "Monitoring for Network Security" of the M-NSLP > framework draft. However, I do not see the value of this use case and > therefore objecting the proposed semantics. I guess I have to read this draft and this section. I'm not suggesting that this should be supported. Maybe others have such requirements. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 31 07:33:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWYqb-0003BB-OD; Mon, 31 Oct 2005 07:33:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWYqY-0003AQ-Rp for nsis@megatron.ietf.org; Mon, 31 Oct 2005 07:33:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02912 for ; Mon, 31 Oct 2005 07:32:48 -0500 (EST) Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWZ4i-0008Er-NK for nsis@ietf.org; Mon, 31 Oct 2005 07:47:46 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id B6CAE11A; Mon, 31 Oct 2005 13:32:54 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37618-03; Mon, 31 Oct 2005 13:32:52 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5094E115; Mon, 31 Oct 2005 13:32:51 +0100 (MET) Message-ID: <43660EF3.2000801@uni-tuebingen.de> Date: Mon, 31 Oct 2005 13:32:51 +0100 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] Filters for the flow specification for the measurement in the Metering NSLP References: <4358D0FA.7090509@uni-tuebingen.de> <435944AF.7070604@tm.uka.de> <43660A8E.6090301@tm.uka.de> In-Reply-To: <43660A8E.6090301@tm.uka.de> X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Martin Stiemerling , Falko Dressler , nsis , Tschofenig Hannes , Changpeng Fan , Kappler Cornelia X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1989870628==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1989870628== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070400080602070807060907" This is a cryptographically signed message in MIME format. --------------ms070400080602070807060907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Roland and Martin, Roland Bless wrote: > Hmm, good question whether its path-coupled or not. > You are signaling for flows which might be on that particular path > in the future. Consider a domain with two ingress nodes A and B. > Current inter-domain routing will inject a flow aggregate F at ingress > A and route it to egress E. However, you might be interested when F is > actually flowing into ingress B taking a different path to E. However, > the current path will not lead to ingress B, and that's where it's not > exactly path coupled anymore. that's correct. On the path from A to E, you could detect packets that are not supposed to be routed on this path, either for security reasons, or for troubleshooting. > >>filter spec in Section 4.3 "Monitoring for Network Security" of the M-NSLP >>framework draft. However, I do not see the value of this use case and >>therefore objecting the proposed semantics. > > > I guess I have to read this draft and this section. oh yeah! that would be great! :-) and feel free to send your comments about it! ;-) > I'm not suggesting that this should be supported. Maybe > others have such requirements. > > Regards, > Roland regards, ali. -- Ali Fessi University of Tuebingen, Germany --------------ms070400080602070807060907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGOTCC AvIwggJboAMCAQICAw37QTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjA3MTQxOTE3WhcNMDYwMjA3MTQxOTE3 WjBdMQ4wDAYDVQQEEwVGZXNzaTEMMAoGA1UEKhMDQWxpMRIwEAYDVQQDEwlBbGkgRmVzc2kx KTAnBgkqhkiG9w0BCQEWGmFsaS5mZXNzaUB1bmktdHVlYmluZ2VuLmRlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2SH7H2KK6H3jYVitFjxylVOsL/TRXXnwlqTjUQmPU1yl 0sK3nv5xWD2lHqL/5v+n2YjYqi2kdG6ORyks51/QKVOB0NYCEVlQFWdT5DNNw6RvjGQd715K XXO4b7XRQJFcZc1Qc8L2G/fER9fvWHfCX09KhFqrJRQ2mahZ+sWcoXZlV9k5M1/jPTECR9dC iVdtI4SYdye9Aryu/P5S6mT0XgZ4JDb41qYTlUyYQpqp77VOFG4odh0vrINac0KdlHrhCjDJ PQ1c23a8/s7VbdG44GsGw5SoFJiDXjQrLhsxh62c88qhNiqMtRPvsnxgqUvv0YKEvYCS5O0e nFiUakz/kwIDAQABozcwNTAlBgNVHREEHjAcgRphbGkuZmVzc2lAdW5pLXR1ZWJpbmdlbi5k ZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAAm748hVdHcNCjCezGHTtFHr7n/K /EnCMrAABvW3oGjM8C9xuzULk7TUubotA1GROGFIcQfDIOqDGirope4asWdEiG9NARtlJkpc JTXv0v1Dl6vEZhXLGF7efTUCI6/mANlQ3sLc22vqceYU/kDSYUijRCz68F0gyiWJ9Z/wR7ic MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxw ZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIz NTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50 aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkG A1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAkQwggJAAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMN+0EwCQYFKw4DAhoFAKCBsTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMzExMjMyNTFaMCMG CSqGSIb3DQEJBDEWBBTOOnCk9npSiET8GcSJZA3rQyl5wTBSBgkqhkiG9w0BCQ8xRTBDMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCWOYP7uRzAx+jm0EsEMPc9yjfXShPgg2in YbfcZUKIOJEZU9yKGeAEM0j/pc3N/s2laFDxwjiFlQBhHOcfzcfxkr6VvbMj2sj0hNiiL0R1 1itS1rPyNr/XL5niXAC/dCtEiSbBPMNEzkp4ZoNoksFP5M9zdzg2na3l532qHl7VLMo1P6EF dNXx4V1h8K5VsHiCNa2rf3UtzZD4pPiyWpvAZ7Xqp9e+EigT01c7z3ibu1T/x9agEo3zOwtl yHbfUfF+Lhpuup3UFq6ThNxcvVaz/G0UHciSmh8s6k5RZC/0N+vkqkD8MbFLvDSVG83IuYEP zhYqT4fx9DNMXctjfgxsAAAAAAAA --------------ms070400080602070807060907-- --===============1989870628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1989870628==--