From nsis-bounces@ietf.org Mon Jan 02 13:10:14 2006 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 1EtU8M-0008Az-0c; Mon, 02 Jan 2006 13:10:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtU8H-00086c-RV for nsis@megatron.ietf.org; Mon, 02 Jan 2006 13:10:12 -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 NAA28069 for ; Mon, 2 Jan 2006 13:08:55 -0500 (EST) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtUDP-0000Ii-JF for nsis@ietf.org; Mon, 02 Jan 2006 13:15:27 -0500 Received: from localhost (localhost [127.0.0.1]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP id D8A0E9C008; Mon, 2 Jan 2006 19:09:55 +0100 (CET) Received: from [172.22.0.51] (tmg51.tmg.loc [172.22.0.51]) by s2.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Mon, 2 Jan 2006 19:09:55 +0100 (CET) Message-ID: <43B96C73.3000109@cs.uni-goettingen.de> Date: Mon, 02 Jan 2006 19:09:55 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Subject: Re: [NSIS] scaling problem by trigger messages ... References: <1AA39B75171A7144A73216AED1D7478D6CED5D@esebe100.NOE.Nokia.com> <005f01c607b5$6ad3ac90$0501010a@3m1> In-Reply-To: <005f01c607b5$6ad3ac90$0501010a@3m1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by sophie+clamav (Debian) at informatik.uni-goettingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, 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 Malik, Muhammad Ali Malik wrote: > Hi John, > > I am refering to RFC 4094: "Analysis of Existing Quality-of-Service > Signaling Protocols". Sorry for not mentioning the RFC in my last e-mail. > Hi, > > The RFC states that: " On the other hand, in many of the new > applications for which a > signaling protocol is required, the user session duration can be > relatively short. The dynamics of adding/dropping user sessions > could introduce a large number of "triggered" messages in the > network. This can clearly introduce a substantial amount of > processing overhead to the routers. This is one area where a new > signaling protocol may be needed to reduce the processing complexity > in the resource reservation process." > > Can anybody please elaborate the situation where there is > overheads because of trigger messages and not by the refresh message. > Apart from processing overheads, the trigger messages also exhibit > signaling overheads. But i hardly seen any documents addressing the > issues by trigger messages only and not by the refresh messages. As the RFC text suggests, this can happen in scenarios where session duration is relatively short. [1], for example, estimates such a scenario: For example, if we estimate that during the busy hour, one fourth of the IP phones are in use and that a business call generally lasts three minutes, we would expect a call volume of about 5 BHCA (busy hour call attempts) per user, or about 100,000 outbound calls during an hour for a large campus with 20,000 phones. This is about 28 call attempts per second, which is likely to be well within the capacity of most servers. Here, as the druation of sessions is short like very few minutes, if network-layer signaling is applied, then trigger messages will overwhelm the refresh messages. I do see there is an overhead due to trigger messages. > How does NSIS address the issue of overheads due to trigger messages. In my view, the overhead of triggers may be (partially) implicitly reduced by reusing exsiting message associations at NTLP level, and some finer engineering for short-session triggers in NSLP level if necessary. [1] H. Schulzrinne et al., SIP Stone - Benchmarking SIP Server Performance, http://www.sipstone.org/files/sipstone_0402.pdf Cheers, Xiaoming > Regards, > > =Malik _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 02 23:48:55 2006 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 1Ete6R-0002fH-7u; Mon, 02 Jan 2006 23:48:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ete6O-0002ex-CX for nsis@megatron.ietf.org; Mon, 02 Jan 2006 23:48:52 -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 XAA26269 for ; Mon, 2 Jan 2006 23:47:38 -0500 (EST) 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 1EteBY-0002FB-87 for nsis@ietf.org; Mon, 02 Jan 2006 23:54:15 -0500 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 k034meiV006257; Tue, 3 Jan 2006 06:48:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 06:48:41 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 06:48:40 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 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: I-D ACTION:draft-ietf-nsis-qspec-08.txt Date: Tue, 3 Jan 2006 06:48:40 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEDBA@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-08.txt Thread-Index: AcYGcWKyaxn5Q8jlS567RUEemN+1cAAAe+9AAmtkIDA= To: , X-OriginalArrivalTime: 03 Jan 2006 04:48:40.0941 (UTC) FILETIME=[F7D299D0:01C61020] X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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, Thanks for updating this. My feeling is that we'll start WG last call=20 on this, along with the QoS NSLP as soon as that is updated. John >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Ash, Gerald R (Jerry), ALABS >Sent: 21 December, 2005 23:21 >To: nsis@ietf.org >Cc: Ash, Gerald R (Jerry), ALABS >Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-08.txt=20 > >Hi All, > >Please review and comment on the updated 'QoS-NSLP QSPEC=20 >Template' I-D at=20 >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt. > >The updates include the following: > >1. update to 'RSVP-style' reservation in Section 6.1.2 to=20 >mirror what is done in RSVP 2. modified text (from David=20 >Black) on DiffServ QSPEC example in Section >6.2 >3. update to general QSPEC parameter formats in Section 7.1=20 >(length restrictions, etc.) 4. re-numbered QSPEC parameter IDs=20 >in Section 7.2 5. modified parameter values=20 >in Section 7.2.2 6. update to reservation priority Section=20 >7.2.7 7. specify the 3 "STATS" in the parameter,=20 >Section 7.2.9.4 8. minor updates to IANA Considerations Section 9 > >There are no open issues currently identified. > >Please review and comment. > >Thanks, >Regards, >Jerry > >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of Internet-Drafts@ietf.org >Sent: Wednesday, December 21, 2005 3:50 PM >To: i-d-announce@ietf.org >Cc: nsis@ietf.org >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-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 : QoS-NSLP QSPEC Template > Author(s) : J. Ash, et al. > Filename : draft-ietf-nsis-qspec-08.txt > Pages : 47 > Date : 2005-12-21 >=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=20 >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-08.txt > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 03 10:14:05 2006 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 1EtnrR-0005CX-P1; Tue, 03 Jan 2006 10:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtnrO-00055a-Pa; Tue, 03 Jan 2006 10:14:02 -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 KAA04275; Tue, 3 Jan 2006 10:12:48 -0500 (EST) 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 1Etnwa-0006Ci-Ho; Tue, 03 Jan 2006 10:19:31 -0500 Received: from smtp-2.ci.uc.pt (localhost [127.0.0.1]) by smtp-2-relay.ci.uc.pt (Postfix) with ESMTP id D9B5B1929D1; Tue, 3 Jan 2006 15:13:36 +0000 (WET) Received: from teste-d.ci.uc.pt (sendmail.uc.pt [193.136.200.162]) by smtp-2.ci.uc.pt (Postfix) with ESMTP id 883122FD003; Tue, 3 Jan 2006 15:13:36 +0000 (WET) Received: from promidius (unknown [193.136.207.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by teste-d.ci.uc.pt (Postfix) with ESMTP id 583F74A810E; Tue, 3 Jan 2006 15:13:36 +0000 (WET) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: , Date: Tue, 3 Jan 2006 15:13:38 -0000 Message-ID: <004401c61078$473a2270$65cf88c1@promidius> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYP1TvouuZTPU1kRT6KAR8R4PH+xwAoumeg X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Subject: [NSIS] FW: 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 Hi all, Please don=92t forget to inform me of your intent to come to the next = NSIS interoperability meeting in Coimbra (Portugal) until 15 of January. Until now only Ferenc Pint=E9r and Roland Bless have replied. Best regards, Lu=EDs Cordeiro > Hi all, >=20 > Since most of the NSIS implementation groups showed interest in the > creation of a new interop meeting in January, the University of = Coimbra -=20 > Portugal (http://www.dei.uc.pt) is glad to host a new NSIS=20 > interoperability meeting. > > We propose 30 and 31 of January of 2006 for this meeting. > > If you want to participate in this interop meeting please send me an = email > indicating which application you want to interop so we are able to = create=20 > a list of possible interoperability tests. I would appreciate the = replies=20 > by 15 of January of 2006 in order to do all the arrangements. >=20 > Best regards, > Lu=EDs Cordeiro >=20 > > > _______________________________________________ > NSIS-imp mailing list > NSIS-imp at lists.ietf.org > https://www1.ietf.org/mailman/listinfo/nsis-imp _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 03 10:36:37 2006 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 1EtoDF-0002xQ-Td; Tue, 03 Jan 2006 10:36:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtoDE-0002xL-7f for nsis@megatron.ietf.org; Tue, 03 Jan 2006 10:36:36 -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 KAA06873 for ; Tue, 3 Jan 2006 10:35:22 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18kCXc7TfjiBJWmTZqXshudYGvnFqr7sAc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtoIW-0006xi-TF for nsis@ietf.org; Tue, 03 Jan 2006 10:42:05 -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 1EtoCz-0003Js-BH; Tue, 03 Jan 2006 16:36:24 +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 30CE6A004; Tue, 3 Jan 2006 16:36:21 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EtoCy-00066V-Sk; Tue, 03 Jan 2006 16:36:21 +0100 Message-ID: <43BA9A0A.60807@tm.uka.de> Date: Tue, 03 Jan 2006 16:36:42 +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: Jukka MJ Manner Subject: Re: [NSIS] New diff of QoS NSLP 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.1 (----) 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.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: 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 Jukka and all, (BTW: I wish you a happy and successful new year!) > I've made a new diff of the QoS NSLP. It is available from: > > http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html > I'll check my emails next week. If you have questions, hopefully someone > else answers, yet, if you have suggestions for clarfications, please > provide the new text, too. Thanks. > > If there are no complex and difficult comments, we'll try to go for WGLC > right after new year. Ok, I still have some additional comments and maybe you can consider them before publishing draft-09: * Terminology: Flow ID: This term is not really well defined in the document. There should be at least the definition that flow ID means MRI. * RESERVE processing (sec. 5.4.1) / REPLACE flag "If the REPLACE flag is set, the QNE SHOULD update the reservation state according to the QSPEC contained in the message." Actually, the QSPEC may be omitted in the RESERVE. This is partly covered by the "Full QSPEC required" Error. However, the corresponding paragraph (on p. 57 bottom) relates to the case when the SII is unknown which may not be the case. So I propose to add text as follows: If the REPLACE flag is set, the QNE SHOULD update the reservation state according to the QSPEC contained in the message (if the QSPEC is missing the QNE should indicate this error by replying with a RESPONSE containing the corresponding INFO_SPEC "Full QSPEC required"). * INFO_SPEC (sec. 5.1.3.6.) * 0x01 - State installation succeeded * 0x02 - Reservation created: reservation installed on complete path (sent by last node). * 0x03 - Reservation accepted: reservation installed at this QNE, but not yet installed on the rest of the path. * 0x04 - Reservation created but modified: reservation installed, but bandwidth reserved was not the maximum requested. If I'm correct some guidance on using the different codes is missing, e.g. what is the difference between 0x01 and 0x03, or implies 0x04 also 0x02? From sec. 5.3.1: If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state installation action. It does so by sending a RESPONSE with an INFO_SPEC indicating that the reservation is installed at the QNE. (it seems that it should be 0x03, but is 0x01 also allowed?) * RESPONSE processing (sec. 5.3.4) / SCOPING "A RESPONSE message MUST be sent where the QNE is the last node to process a RESERVE or QUERY message containing an RII object (based on scoping of the RESERVE or QUERY, or because this is the last node on the path). In this case, the RESPONSE MUST copy the RII object from the RESERVE or QUERY." In case of scoping: is it guaranteed that the RESPONSE will not be forwarded further upstream (I guess that there is currently no such statement)? Does it make sense to allow explicit scoping together with an RII in a RESERVE? I would recommend to set the success code at least accordingly: it must not be 0x02 if the node is not the QNR in order to distinguish it from a "far-end response". So maybe we can add the following text after the quoted text above: "In case of a successful RESPONSE carrying an INFO_SPEC class 0x02 the error code must not be set to 0x02 unless the RESPONSE is really generated by the QNR." * RESPONSE processing (sec. 5.3.4) / ACKNOWLEDGE "In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE flag is set or when an error occurs while processing a received message. If the received message contains an RII object, an error happened, and a response should be, this object MUST be put in the ^^^^^^^^^^^^^^^^^^^^^^^^^???? RESPONSE, as described above. If the RESPONSE is sent as a result of" There seems to be some text missing. I propose the following: "In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE flag is set or when an error occurs while processing a received message. If the received message contains an RII object and the ACKNOWLEDGE flag is set, a QNE generates a RESPONSE without RII if the QNE is not the QNR. In this case a succesful RESPONSE carries the INFO_SPEC with success code 0x01 and the received message is forwarded further along the path towards the QNR. In case the QNR receives a message with an ACKNOWLEDGE flag and an RII object it generates two RESPONSEs: one for the ACK towards the previous upstream hop as above (without RII) and one as RESPONSE containing the RII (and if the request was successful an INFO_SPEC with code 0x02 ??or 0x04??). * RESPONSE processing (sec. 5.3.4) / Success "If the INFO_SPEC is not used to notify error situations, see above, then the RESPONSE message MUST NOT be forwarded further along the path." I guess that this is only true for the precondition that the RESPONSE carries an RSN. If I want a confirmation back from the far end (success 0x02 - reservation created: reservation installed on complete path (sent by last node) by inserting an RII object in my RESERVE then the RESPONSE should be forwarded up to the node who inserted the RII object. Sometimes it's not so easy to determine the scope or preconditions of the statements in the draft. * Typo(s): 5.3.2. If an intermediate QNE wants to request a response for an outgoing message, but the message already included an RII when it arrive, the ^arrived 5.4.: This section provides rules for message processing. Not all possible error situation are considered. A general rule for dealing ^situations and s/sucessfull / sucessful/ throughout the text. Best regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 05 03:28:04 2006 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 1EuQTc-0000dG-Fu; Thu, 05 Jan 2006 03:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQTa-0000d7-FR for nsis@megatron.ietf.org; Thu, 05 Jan 2006 03:28:02 -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 DAA10630 for ; Thu, 5 Jan 2006 03:26:45 -0500 (EST) 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 1EuQZD-0000KX-2u for nsis@ietf.org; Thu, 05 Jan 2006 03:33:52 -0500 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; Thu, 05 Jan 2006 10:27:55 +0200 id 00070189.43BCD88B.000008FB Date: Thu, 5 Jan 2006 10:27:55 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] New diff of QoS NSLP In-Reply-To: <43BA9A0A.60807@tm.uka.de> Message-ID: References: <43BA9A0A.60807@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: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: "McDonald, Andrew" , Georgios Karagiannis , 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 Roland, Your comments sounds good to me. I'm not sure about the INFO_SPEC values you are asking about. Maybe Georgios or Andrew can answer? Cheers, Jukka On Tue, 3 Jan 2006, Roland Bless wrote: > Hi Jukka and all, > > (BTW: I wish you a happy and successful new year!) > > > I've made a new diff of the QoS NSLP. It is available from: > > > > http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html > > I'll check my emails next week. If you have questions, hopefully someone > > else answers, yet, if you have suggestions for clarfications, please > > provide the new text, too. Thanks. > > > > If there are no complex and difficult comments, we'll try to go for WGLC > > right after new year. > > Ok, I still have some additional comments and maybe you can consider > them before publishing draft-09: > > * Terminology: > Flow ID: This term is not really well defined in the document. > There should be at least the definition that flow ID means MRI. > > * RESERVE processing (sec. 5.4.1) / REPLACE flag > > "If the REPLACE flag is set, the QNE SHOULD update the reservation > state according to the QSPEC contained in the message." > > Actually, the QSPEC may be omitted in the RESERVE. This is partly > covered by the "Full QSPEC required" Error. However, the corresponding > paragraph (on p. 57 bottom) relates to the case when the SII is > unknown which may not be the case. So I propose to add text as follows: > If the REPLACE flag is set, the QNE SHOULD update the reservation > state according to the QSPEC contained in the message (if the QSPEC > is missing the QNE should indicate this error by replying with > a RESPONSE containing the corresponding INFO_SPEC "Full QSPEC > required"). > > * INFO_SPEC (sec. 5.1.3.6.) > > > * 0x01 - State installation succeeded > > * 0x02 - Reservation created: reservation installed on > complete path (sent by last node). > > * 0x03 - Reservation accepted: reservation installed at this > QNE, but not yet installed on the rest of the path. > > * 0x04 - Reservation created but modified: reservation > installed, but bandwidth reserved was not the maximum > requested. > > If I'm correct some guidance on using the different codes is missing, > e.g. what is the difference between 0x01 and 0x03, or implies 0x04 > also 0x02? > > From sec. 5.3.1: > If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state > installation action. It does so by sending a RESPONSE with an > INFO_SPEC indicating that the reservation is installed at the QNE. > > (it seems that it should be 0x03, but is 0x01 also allowed?) > > > * RESPONSE processing (sec. 5.3.4) / SCOPING > > "A RESPONSE message MUST be sent where the QNE is the last node to > process a RESERVE or QUERY message containing an RII object (based on > scoping of the RESERVE or QUERY, or because this is the last node on > the path). In this case, the RESPONSE MUST copy the RII object from > the RESERVE or QUERY." > > In case of scoping: is it guaranteed that the RESPONSE will not be > forwarded further upstream (I guess that there is currently no such > statement)? Does it make sense to allow explicit scoping together with > an RII in a RESERVE? I would recommend to set the success code > at least accordingly: it must not be 0x02 if the node is not the > QNR in order to distinguish it from a "far-end response". > So maybe we can add the following text after the quoted text above: > "In case of a successful RESPONSE carrying an INFO_SPEC class 0x02 > the error code must not be set to 0x02 unless the RESPONSE is really > generated by the QNR." > > * RESPONSE processing (sec. 5.3.4) / ACKNOWLEDGE > > "In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE > flag is set or when an error occurs while processing a received > message. If the received message contains an RII object, an error > happened, and a response should be, this object MUST be put in the > ^^^^^^^^^^^^^^^^^^^^^^^^^???? > RESPONSE, as described above. If the RESPONSE is sent as a result of" > > There seems to be some text missing. > I propose the following: > "In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE > flag is set or when an error occurs while processing a received > message. If the received message contains an RII object and the > ACKNOWLEDGE flag is set, a QNE generates a RESPONSE without RII > if the QNE is not the QNR. In this case a succesful RESPONSE > carries the INFO_SPEC with success code 0x01 and the received > message is > forwarded further along the path towards the QNR. In case the QNR > receives a message with an ACKNOWLEDGE flag and an RII object it > generates two RESPONSEs: one for the ACK towards the previous > upstream hop as above (without RII) and one as RESPONSE containing > the RII (and if the request was successful an INFO_SPEC with code > 0x02 ??or 0x04??). > > * RESPONSE processing (sec. 5.3.4) / Success > > "If the INFO_SPEC is not used to notify error situations, see above, > then the RESPONSE message MUST NOT be forwarded further along the > path." > > I guess that this is only true for the precondition that the RESPONSE > carries an RSN. If I want a confirmation back from > the far end (success 0x02 - reservation created: reservation installed > on complete path (sent by last node) by inserting an RII object in my > RESERVE then the RESPONSE should be forwarded up to the node who > inserted the RII object. > > Sometimes it's not so easy to determine the scope or preconditions > of the statements in the draft. > > * Typo(s): > 5.3.2. > If an intermediate QNE wants to request a response for an outgoing > message, but the message already included an RII when it arrive, the > ^arrived > 5.4.: > This section provides rules for message processing. Not all > possible error situation are considered. A general rule for dealing > ^situations > and > s/sucessfull / sucessful/ > throughout the text. > > Best regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jan 06 07:01:11 2006 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 1EuqHP-0001LO-Q3; Fri, 06 Jan 2006 07:01:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuqHN-0001JP-Oa for nsis@megatron.ietf.org; Fri, 06 Jan 2006 07:01:09 -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 GAA26550 for ; Fri, 6 Jan 2006 06:59:53 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuqNB-0007db-UZ for nsis@ietf.org; Fri, 06 Jan 2006 07:07:15 -0500 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 k06C0Lhb023012; Fri, 6 Jan 2006 12:00:21 GMT 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, 6 Jan 2006 12:00:20 -0000 Message-ID: Thread-Topic: [NSIS] TLS in the GIST draft Thread-Index: AcXTbmmrzpaKZGvORFOnk1y3buFk+AQcsdvABz7U8jABsZtZ4ALEWLcQ 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: 6ffdee8af20de249c24731d8414917d3 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 pasi, comments below.=20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: 23 December 2005 09:46 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] TLS in the GIST draft >=20 >=20 > Hi Robert, >=20 > A couple of comments: >=20 > - I don't think we need to make the RC4-based ciphersuites=20 > mandatory; 3DES and AES will do just fine. that's fine with me; i just copied it from diameter and have no personal love for rc4 so i'll remove them unless anyone=20 shouts (really really soon!) >=20 > - Using TLS with server-only (Responding node only)=20 > authentication sounds quite strange in this situation. To me=20 > it looks like authenticating the querying node would be much=20 > more important... =20 > so the default mandatory-to-implement mechanism should do=20 > mutual authentication. I think I agree with you, but am not sure what text change would be needed here. If the nodes have proper TLS implementations, then they will have the functionality to perform mutual=20 authentication (and the requirement for the Responding node to request a certificate means that the mutual authentication procedure will at least be started). But that is not the same as mandating that the Querying node has to have a certificate to itself send, which would seem to be a deployment/policy=20 matter. Are you suggesting that the Querying node MUST NOT offer TLS in the GIST capability exchange unless it has a certificate=20 which would enable mutual authentication to take place? >=20 > - The requirement ".. identity hints about the peer, these=20 > SHOULD be derived from the Peer-Identity provided..." is a=20 > bit strange. =20 >=20 > The spec says that the Peer-Identity is just an opaque octet=20 > string, and nodes are free to choose it however they want, as=20 > long as it has a "high probability of uniqueness". E.g. a=20 > sufficiently long and properly generated random number would=20 > do. But clearly this text assumes that Peer-Identity is=20 > something else than an opaque unique string, since that would=20 > be quite useless in this case... >=20 > Also, to get interoperable implementations for e.g. using=20 > RFC2712 for GIST, it's not sufficient to say it's somehow=20 > derived from Peer-Identity; some specification needs to say=20 > _how_ it's derived. >=20 > My recommendation would be to just define a MA-Protocol-ID=20 > for TLS-with-Certificates, and leave other kinds of TLS uses=20 > beyond the scope of the specification (with the understanding=20 > that they probably require a different MA-Protocol-ID). I think we can delete the sentence. (I think when I wrote it that I was thinking only about selecting which key to use when using PSK authentication. But having re-read 4279 I see that at least similar hint-like information is available internally from the TLS handshake, so there's no need to replicate it at the GIST level. And handling kerberos or GBA architectures seems to be intrinsically more complicated anyway.) So we can just say that use of other TLS authentication methods may=20 require additional specification of how they are embedded in GIST. (This is a general problem of specification writing: where spec A incorporates spec B in some sense, it is=20 extremely hard to be precise in spec A about what class of=20 extensions to spec B is allowed, especially where those=20 extensions haven't been written yet. I'm not sure if there is a good form of words to capture it.) i've included a new version of 5.7.3 below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.7.3. Protocol Definition: Transport Layer Security This defines the use of transport layer security as a basic channel security mechanism. Support for this protocol is mandatory; associations using it can carry messages with the transfer attribute Secure=3DTrue. For use with TCP, implementation of TLS1.0 [6] is REQUIRED and implementation of TLS1.1 [8] is RECOMMENDED. (If an unreliable transport such as DCCP or UDP is defined for GIST in the future, TLS would be implemented with it using DTLS [37].) GIST nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. The default mode of TLS authentication (which applies in particular to the above ciphersuites) is server-only or mutual authentication using certificates. The Querying node acts as a TLS client, and the Responding node acts as a TLS server. Where one of the above ciphersuites is negotiated, the GIST node acting as a server MUST provide its own certificate, and MUST request one from the GIST node acting as a TLS client. GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the negotiation of alternative ciphersuites is used to trigger alternative authentication procedures (for example, the use of pre- shared keys, [26]). The use of other authentication procedures may require additional specification work to define how they can be used as part of TLS within the GIST framework, and may or may not require the definition of additional MA-Protocol-IDs. No higher-layer-addressing data is defined for TLS. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D cheers, r. >=20 > Best regards, > Pasi=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 10 17:54:57 2006 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 1EwSOH-0004hR-GY; Tue, 10 Jan 2006 17:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSOG-0004hM-Lb for nsis@megatron.ietf.org; Tue, 10 Jan 2006 17:54:56 -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 RAA16423 for ; Tue, 10 Jan 2006 17:53:37 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18I68yPFcLKMVjBZaDFCEP+GggVWYSjd2o=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSV1-0003FA-Ib for nsis@ietf.org; Tue, 10 Jan 2006 18:01:58 -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 1EwSO3-0005Vx-LQ; Tue, 10 Jan 2006 23:54:51 +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 727A2A1CD; Tue, 10 Jan 2006 23:54:43 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EwSO2-0000nX-MJ; Tue, 10 Jan 2006 23:54:42 +0100 Message-ID: <43C43B31.6060000@tm.uka.de> Date: Tue, 10 Jan 2006 23:54:41 +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: "nsis@ietf.org" , Jukka MJ Manner X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) 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.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: Subject: [NSIS] QoS NSLP: More 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, we have some more issues on http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html * NOTIFY: still unsolved - usefulness of NOTIFY after state tear down - forwarding scope of NOTIFY for details please see prior mail from Markus Ott: http://www.ietf.org/mail-archive/web/nsis/current/msg05784.html * section 4.8 Rerouting: After the reservation on the new path is set up, the branching node or the merging node may want to tear down the reservation on the old path (faster than what would result from normal soft-state time-out). It is unclear to me why and how the merging node should tear down the reservation on the old path: Only a reserve can carry a TEAR flag and it can only be sent towards the QNR. Furthermore, the branching node will usually detect the rerouting earlier anyway, because GIST will indicate a changed SII-handle via a network notification. in the same context: * section 5.4.1: NSLP state. If the SII is different, this means that the QNE is a merge point. In that case, in addition to the operations specified above, the value REPLACE=0 is also indicating that a tearing RESERVE SHOULD NOT be sent on the old branch. As above: the merge point cannot initiate a tearing RESERVE. Furthermore, in case the QSPEC and MRI are not changed, the merging QNE need not send the RESERVE further downstream because the state along the remaining path has not changed. * section 4.8 Rerouting: A QNI or a branch node may wish to keep the reservation on the old branch. This could for instance be the case when a mobile node has experienced a mobility event and wishes to keep reservation to its old attachment point in case it moves back there. In that case, it sets the REPLACE flag in the common header to zero. Note that keeping old reservations affects the resources available to other nodes. Thus, the operator of the access network must make the final decision on whether this behavior is allowed. Also, the QNEs in the access network may add this flag even if the mobile node has not used the flag initially. It is not clear for how long the reservation should be kept, i.e. how long should the branching node keep sending refreshes? Should it do so at all? * section 5.4.3. RESPONSE Messages: forwarding of RESPONSES with RIIs: In case of a successful answer (class 0x02) forwarding should stop at the node that inserted the RII object, however in case of errors forwarding should possibly not stop at the RII inserting node, because other nodes upstream are possibly also interested in failures. Unclear is whether informational messages should be handled like success. Furthermore, some protocol errors are only meaningful between directly adjacent peers. Currently the paragraph reads: On receipt of a RESPONSE message containing an RII object, the statefull QoS-NSLP 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. If the QNE did not insert this RII itself, if must forward the RESPONSE to the next peer. Thus, forwarding should only stop if the QNE inserted the RII by itself. Should possibly be rephrased in: On receipt of a RESPONSE message containing an RII object, the stateful QoS-NSLP 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 if it contains an INFO_SPEC class informational or success. If the QNE did not insert this RII itself, if must forward the RESPONSE to the next peer. Thus, for RESPONSES indicating success, forwarding should only stop if the QNE inserted the RII by itself, If the RESPONSE carries an INFO_SPEC indicating an error, forwarding SHOULD continue upstream towards the QNI by using RSNs as described in the next paragraph. * section 7.1 "Note that we assume the SII handling in GIST [I-D.ietf-nsis-ntlp] is extended to distinguish between own and peer SII." This is not necessary, so you should delete this sentence. SendMessage(...) (Fig. 35) and RecvMessage(...) (Fig. 36) should have the same parameters as in the GIST draft. Typos: * section 4.8, p.31: receiver-initiated reservations, this involves A QNE that is notified ^a * section 5.1.3.6., p. 45: If a QNE encounters protocol erros, it MAY include additional ^^^^^ errors If the type of an object is erroneous, the following optional error- spefici information may be included at the end of the INFO_SPEC. ^^^^^^^ specific Please comment, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 11 10:22:38 2006 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 1Ewho6-00033O-Gw; Wed, 11 Jan 2006 10:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewho4-000331-BU for nsis@megatron.ietf.org; Wed, 11 Jan 2006 10:22:36 -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 KAA19856 for ; Wed, 11 Jan 2006 10:21:14 -0500 (EST) 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 1Ewhux-0006Bn-1f for nsis@ietf.org; Wed, 11 Jan 2006 10:29:46 -0500 Received: from eden.dei.uc.pt (eden-out.dei.uc.pt [193.136.212.2]) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id k0BFN7Nt015009; Wed, 11 Jan 2006 15:23:07 GMT Received: from eden.dei.uc.pt (localhost [127.0.0.1]) by eden.dei.uc.pt (8.13.5/8.13.5) with ESMTP id k0BFM1J7023460; Wed, 11 Jan 2006 15:22:01 GMT Received: from localhost (zhang@localhost) by eden.dei.uc.pt (8.13.5/8.13.1/Submit) with ESMTP id k0BFM0cQ023457; Wed, 11 Jan 2006 15:22:01 GMT Date: Wed, 11 Jan 2006 15:22:00 +0000 (WET) From: Jian Zhang To: Roland Bless Subject: Re: [NSIS] QoS NSLP: More open issues In-Reply-To: <43C43B31.6060000@tm.uka.de> Message-ID: References: <43C43B31.6060000@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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=-2.599, required 3, autolearn=not spam, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: zhang@eden.dei.uc.pt X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: 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, Roland, See my comments inline. I also report two more open issue below. * section 5.1.2.1 RESERVE: REPLACE (R) - when set, indicates that a RESERVE with different Message Routing Information (MRI) replaces an existing one, so the old one MAY be torn down immediately. This is the default situation. This flag may be unset to indicate a desire from an upstream node to keep an existing reservation on an old branch in place. This flag is also used to indicate that whether the reserved resources on the old branch should be teared down or not when the data path change happens (see, section 4.6 Rerouting). In this case, the MRI is the same and only the route path is changed. So, this feature should also be included in the above description text of REPLACE flag. * section 5.1.3.5 PACKET_CLASSIFIER: The flags indicate which fields from the MRI should be used by the packet classifier. Flags MUST only be set if the data is present in the MRI (i.e. if there is a flag for it in GIST, then that must also be set). In my understanding, which flags will be set in PACKET_CLASSIFIER should be directed by the QOS Model used becuase these flags is to indicate which fields from the MRI will be used by the packet classifier to classfy the incoming packets of this flow. Therefore, the QoS Model function should be mentioned at the above description of PACKET_CLASSIFIER and this part "(i.e. if there is a flag for it in GIST, then that must also be set)" should be removed due to it makes no sense (or even is wrong). Also, because the PACKET_CLASSIFIER is to indicate to the packet classifier at each QNE that which fields from the MRI will be used to classify the incoming packets of one flow, the PACKET_CLASSIFIER object is only needed for the RESERVE message. Only the RESERVE message will reserve the resources for the flow at the QNEs along the flow's data path and only after the reservation, the packets of the flow could be accepted into the network. Thus, including the PACKET_CLASSIFIER object in the QUERY, RESPONSE and NOTIFY messages make no sense (see sections 5.1.2.2, 5.1.2.3 and 5.1.2.4 where the QUERY, RESPONSE and NOTIFY messages also include the PACKET_CLASSIFIER object). On Tue, 10 Jan 2006, Roland Bless wrote: > Hi all, > > we have some more issues on > http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html > > * NOTIFY: > still unsolved > - usefulness of NOTIFY after state tear down > - forwarding scope of NOTIFY > for details please see prior mail from Markus Ott: > http://www.ietf.org/mail-archive/web/nsis/current/msg05784.html Agree with you. > > * section 4.8 Rerouting: > After the reservation on the new path is set up, the branching node > or the merging node may want to tear down the reservation on the old > path (faster than what would result from normal soft-state time-out). > > It is unclear to me why and how the merging node should tear down the > reservation on the old path: Only a reserve can carry a TEAR flag > and it can only be sent towards the QNR. Furthermore, the branching > node will usually detect the rerouting earlier anyway, because GIST > will indicate a changed SII-handle via a network notification. The reason why the merging node may need to tear down the reservation on the old path explicitly is because that this explicit tear down is faster than the implicit tear down via the soft-state time-out. Can the merging node initiate a tearing RESERVE message to the old branching node? I think the first merging node can, see the example below. QNI------ QNE2 ----------QNE3--------QNE4-------QNE5-----QNR | | | | |-------------QNE3'--------| Previously, flow 1 took the path QNI-QN2-QNE3-QNE4-QNE5-QNR, and after some time, its path changes to QNI-QNE2-QNE3'-QNE4-QNE5-QNR. The QNE2 and QNE4 are called the merging nodes here. Due to this is the case of sender-initiated reservation, now the path change is detected when QNE2 receives a RESPONSE message with a different SII from QNE3'. Then, the merging node QNE2 is aware of the path change and can initiate a tearing RESERVE message with TEAR flag set and send it to QNE3 to tear down the resources reserved for this flow at QNE3. QNE3 can further propagate this tearing RESERVE message to QNE4. But, the question is that how long this tearing message should be propagated. In my opinion, the merging node QNE4 must not stop propagating this tearing RESERVE message if it is already aware that it is the latter merging node of this path change, i.e., it is aware that its upstream peer is changed but the downstream peer is not. Meanwhile, the new RESERVE message sent by QNE2 to QNE3' should also be stop prapogating by QNE4. In this way, all those QNEs which are at the same path as before do not need to tear down the resources and then reserve the same resources again and again for the same flow. > > in the same context: > * section 5.4.1: > NSLP state. If the SII is different, this means that the QNE is a > merge point. In that case, in addition to the operations specified > above, the value REPLACE=0 is also indicating that a tearing RESERVE > SHOULD NOT be sent on the old branch. > > As above: the merge point cannot initiate a tearing RESERVE. > Furthermore, in case the QSPEC and MRI are not changed, the merging > QNE need not send the RESERVE further downstream because the state > along the remaining path has not changed. > See above. > * section 4.8 Rerouting: > > A QNI or a branch node may wish to keep the reservation on the old > branch. This could for instance be the case when a mobile node has > experienced a mobility event and wishes to keep reservation to its > old attachment point in case it moves back there. In that case, it > sets the REPLACE flag in the common header to zero. Note that keeping > old reservations affects the resources available to other nodes. > Thus, the operator of the access network must make the final decision > on whether this behavior is allowed. Also, the QNEs in the access > network may add this flag even if the mobile node has not used the > flag initially. > > It is not clear for how long the reservation should be kept, i.e. > how long should the branching node keep sending refreshes? Should > it do so at all? > That may depend on the local policy. > * section 5.4.3. RESPONSE Messages: > forwarding of RESPONSES with RIIs: > > In case of a successful answer (class 0x02) forwarding should stop > at the node that inserted the RII object, however in case > of errors forwarding should possibly not stop at the RII inserting > node, because other nodes upstream are possibly also interested in > failures. Unclear is whether informational messages should be handled > like success. Furthermore, some protocol errors are only meaningful > between directly adjacent peers. > > Currently the paragraph reads: > > On receipt of a RESPONSE message containing an RII object, the > statefull QoS-NSLP 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. If > the QNE did not insert this RII itself, if must forward the RESPONSE > to the next peer. Thus, forwarding should only stop if the QNE > inserted the RII by itself. > > Should possibly be rephrased in: > On receipt of a RESPONSE message containing an RII object, the > stateful QoS-NSLP 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 if > it contains an INFO_SPEC class informational or success. If > the QNE did not insert this RII itself, if must forward the RESPONSE > to the next peer. Thus, for RESPONSES indicating success, forwarding > should only stop if the QNE inserted the RII by itself, If the > RESPONSE carries an INFO_SPEC indicating an error, forwarding SHOULD > continue upstream towards the QNI by using RSNs as described in the > next paragraph. > Agree with you. Especially when the RESPONSE message is to indicate that the previous RESERVE action failed due to some severe errors (such as the authentication failure or no enough resources), the RESPONSE should be forwarded to the QNI, which then can initiate a tearing RESERVE message to inform those QNEs which have already reserved resources to release them. > * section 7.1 > > "Note that we assume the SII handling in GIST [I-D.ietf-nsis-ntlp] > is extended to distinguish between own and peer SII." > > This is not necessary, so you should delete this sentence. > > SendMessage(...) (Fig. 35) and RecvMessage(...) (Fig. 36) should have > the same parameters as in the GIST draft. Agree. Now the APIs illustrated in Fig. 35 and Fig. 36 are inconsistent with the ones defined in GIST. The editors should discuss and fix this problem. Regards, Jian Zhang > Typos: > * section 4.8, p.31: > receiver-initiated reservations, this involves A QNE that is notified > ^a > * section 5.1.3.6., p. 45: > If a QNE encounters protocol erros, it MAY include additional > ^^^^^ > errors > > If the type of an object is erroneous, the following optional error- > spefici information may be included at the end of the INFO_SPEC. > ^^^^^^^ > specific > > > Please comment, > 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 Thu Jan 12 07:52:23 2006 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 1Ex1wF-0003nv-CP; Thu, 12 Jan 2006 07:52:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex1wA-0003nk-TW for nsis@megatron.ietf.org; Thu, 12 Jan 2006 07:52:21 -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 HAA15058 for ; Thu, 12 Jan 2006 07:50:58 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/fOy+7cX1wu6G7HWmh4GhKawKGU3okErA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex23H-0002i4-Hx for nsis@ietf.org; Thu, 12 Jan 2006 07:59:40 -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 1Ex1vn-0007tM-T8; Thu, 12 Jan 2006 13:51:59 +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 A6E6D8C02; Thu, 12 Jan 2006 13:51:55 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Ex1vn-0003if-Cl; Thu, 12 Jan 2006 13:51:55 +0100 Message-ID: <43C650EA.8000203@tm.uka.de> Date: Thu, 12 Jan 2006 13:51:54 +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: Jian Zhang Subject: Re: [NSIS] QoS NSLP: More open issues References: <43C43B31.6060000@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.1 (----) 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.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: 7bit Cc: 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 Jian > See my comments inline. I also report two more open issue below. > > * section 5.1.2.1 RESERVE: > REPLACE (R) - when set, indicates that a RESERVE with different > Message Routing Information (MRI) replaces an existing one, so the > old one MAY be torn down immediately. This is the default > situation. This flag may be unset to indicate a desire from an > upstream node to keep an existing reservation on an old branch in > place. > > This flag is also used to indicate that whether the reserved resources > on the old branch should be teared down or not when the data path change > happens (see, section 4.6 Rerouting). In this case, the MRI is the same > and only the route path is changed. So, this feature should also be > included in the above description text of REPLACE flag. Agreed. > * section 5.1.3.5 PACKET_CLASSIFIER: > The flags indicate which fields from the MRI should be used by the > packet classifier. Flags MUST only be set if the data is present in > the MRI (i.e. if there is a flag for it in GIST, then that must also > be set). > > In my understanding, which flags will be set in PACKET_CLASSIFIER should > be directed by the QOS Model used becuase these flags is to indicate > which fields from the MRI will be used by the packet > classifier to classfy the incoming packets of this flow. Therefore, the > QoS Model function should be mentioned at the above description of > PACKET_CLASSIFIER and this part "(i.e. if there is a flag for it in > GIST, then that must also be set)" should be removed due to it makes no > sense (or even is wrong). I guess you're right that the sentence in parentheses is wrong. Actually problably wanted to say something like: (i.e. it is only allowed to set if there is a flag for it in GIST). > Also, because the PACKET_CLASSIFIER is to indicate to the packet > classifier at each QNE that which fields from the MRI will be used to > classify the incoming packets of one flow, the PACKET_CLASSIFIER object > is only needed for the RESERVE message. Only the RESERVE message will > reserve the resources for the flow at the QNEs along the flow's data > path and only after the reservation, the packets of the flow could be > accepted into the network. Thus, including the PACKET_CLASSIFIER object > in the QUERY, RESPONSE and NOTIFY messages make no sense (see sections > 5.1.2.2, 5.1.2.3 and 5.1.2.4 where the QUERY, RESPONSE and NOTIFY > messages also include the PACKET_CLASSIFIER object). Hmm, sounds logical to me. Maybe someone who thinks that this is necessary could speak up now, otherwise we should remove the PACKET_CLASSIFIER from all PDUs except the RESERVE. >> * section 4.8 Rerouting: >> After the reservation on the new path is set up, the branching node >> or the merging node may want to tear down the reservation on the old >> path (faster than what would result from normal soft-state time-out). >> >> It is unclear to me why and how the merging node should tear down the >> reservation on the old path: Only a reserve can carry a TEAR flag >> and it can only be sent towards the QNR. Furthermore, the branching >> node will usually detect the rerouting earlier anyway, because GIST >> will indicate a changed SII-handle via a network notification. > > > The reason why the merging node may need to tear down the reservation on > the old path explicitly is because that this explicit tear down is > faster than the implicit tear down via the soft-state time-out. Can the The draft states it already, but it mentiones > merging node initiate a tearing RESERVE message to the old branching > node? I think the first merging node can, see the example below. I guess we have a terminology problem here, because I differentiate between branching and merging nodes (as the draft does sometimes). See below. > QNI------ QNE2 ----------QNE3--------QNE4-------QNE5-----QNR > | | > | | > |-------------QNE3'--------| > > > Previously, flow 1 took the path QNI-QN2-QNE3-QNE4-QNE5-QNR, and after > some time, its path changes to QNI-QNE2-QNE3'-QNE4-QNE5-QNR. The QNE2 > and QNE4 are called the merging nodes here. Due to this is the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This would be quite confusing. If the data is flowing from QNI to QNR I would call QNE2 the branching node (flows split) and QNE4 the merging node (flows join again). The following is correct if you simply s/merging/branching. > case of sender-initiated reservation, now the path change is detected > when QNE2 receives a RESPONSE message with a different SII from QNE3'. > Then, the merging node QNE2 is aware of the path change and can > initiate a tearing RESERVE message with TEAR flag set and send it to > QNE3 to tear down the resources reserved for this flow at QNE3. QNE3 > can further propagate this tearing RESERVE message to QNE4. But, the > question is that how long this tearing message should be propagated. Usually, QNE4 will detect that it is a merging node and has another active reservation for the same SID _and_ the same flow. Tear down the old reservation should stop at QNE4 in this case. But if the flows (i.e. MRIs) are different, it must propagate the RESERVE w/ TEAR further along the path. > In my opinion, the merging node QNE4 must not stop propagating this > tearing RESERVE message if it is already aware that it is the latter > merging node of this path change, i.e., it is aware that its > upstream peer is changed but the downstream peer is not. Meanwhile, That's basically what I mean by merging node. > the new RESERVE message sent by QNE2 to QNE3' should also be stop > prapogating by QNE4. In this way, all those QNEs which are at the same > path as before do not need to tear down the resources and then reserve > the same resources again and again for the same flow. I don't understand your proposal. You say QNE4 should propagate the TEAR further downstream, but the new RESERVE should stop at QNE4? This would lead to a reservation along the new path that stops at QNE4. I guess we should better distinguish at least these cases: - Rerouting occurred without change of flowID (MRI). In this case QNE2 (as branching node) will detect the route change and initiate a new RESERVE with RII set. This new RESERVE will stop at the merging node who sends a RESPONSE w/ RII back. In case of success QNE2 will see that the new path was successfully established and starts to TEAR down the reservation along the old branch. This TEAR will nevertheless stop at QNE4 in order to prevent tearing down the reservation along the unchanged path. - The flowID changed. We assume that the old flow and the new flow will share some parts of their paths, i.e. both flows traverse a common set of nodes. In this case, QNE4 should neither stop propagating the new RESERVE nor stop to forward the tearing reserve. - FlowID stays the same, but QSPEC has changed. In this case QNE4 should forward the new RESERVE, but not the RESERVE w/ TEAR. >> in the same context: >> * section 5.4.1: >> NSLP state. If the SII is different, this means that the QNE is a >> merge point. In that case, in addition to the operations specified >> above, the value REPLACE=0 is also indicating that a tearing RESERVE >> SHOULD NOT be sent on the old branch. >> >> As above: the merge point cannot initiate a tearing RESERVE. >> Furthermore, in case the QSPEC and MRI are not changed, the merging >> QNE need not send the RESERVE further downstream because the state >> along the remaining path has not changed. >> > See above. The above sentence says that QNE4 is not able to tear down the old branch (only QNE2 may do so). >> * section 4.8 Rerouting: >> >> A QNI or a branch node may wish to keep the reservation on the old >> branch. This could for instance be the case when a mobile node has >> experienced a mobility event and wishes to keep reservation to its >> old attachment point in case it moves back there. In that case, it >> sets the REPLACE flag in the common header to zero. Note that keeping >> old reservations affects the resources available to other nodes. >> Thus, the operator of the access network must make the final decision >> on whether this behavior is allowed. Also, the QNEs in the access >> network may add this flag even if the mobile node has not used the >> flag initially. >> >> It is not clear for how long the reservation should be kept, i.e. >> how long should the branching node keep sending refreshes? Should >> it do so at all? >> > That may depend on the local policy. Sure, however. one must implement something... I would then suggest to add something like: How long an old reservation is kept depends on local policy. > Agree with you. Especially when the RESPONSE message is to indicate that > the previous RESERVE action failed due to some severe errors (such as > the authentication failure or no enough resources), the RESPONSE should > be forwarded to the QNI, which then can initiate a tearing RESERVE > message to inform those QNEs which have already reserved resources to > release them. But even if upstream nodes only sent regular refreshing RESERVEs it may be necessary. Consider a rerouting event like in the above scenario. In case the new RESERVE along the new branch fails due to resource shortage, upstream nodes should be notified of this failure. In this case they will get "unsolicited" RESPONSEs (which match the RSN of the refreshing RESERVE). >> * section 7.1 >> >> "Note that we assume the SII handling in GIST [I-D.ietf-nsis-ntlp] >> is extended to distinguish between own and peer SII." >> >> This is not necessary, so you should delete this sentence. >> >> SendMessage(...) (Fig. 35) and RecvMessage(...) (Fig. 36) should have >> the same parameters as in the GIST draft. > > > Agree. Now the APIs illustrated in Fig. 35 and Fig. 36 are inconsistent > with the ones defined in GIST. The editors should discuss and fix this > problem. Seems to be fixed now. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 12 08:24:55 2006 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 1Ex2Rj-0004Wi-R8; Thu, 12 Jan 2006 08:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2Ri-0004WO-RU for nsis@megatron.ietf.org; Thu, 12 Jan 2006 08:24:55 -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 IAA17262 for ; Thu, 12 Jan 2006 08:23:33 -0500 (EST) Received: from webmail-outgoing2.us4.outblaze.com ([205.158.62.67] helo=webmail-outgoing.us4.outblaze.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex2Yo-0003mq-0i for nsis@ietf.org; Thu, 12 Jan 2006 08:32:16 -0500 Received: from unknown (unknown [192.168.9.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id EB82118001DA for ; Thu, 12 Jan 2006 13:24:40 +0000 (GMT) X-OB-Received: from unknown (205.158.62.51) by wfilter.us4.outblaze.com; 12 Jan 2006 13:24:39 -0000 Received: by ws1-5.us4.outblaze.com (Postfix, from userid 1001) id 6608E8402B; Thu, 12 Jan 2006 13:24:39 +0000 (GMT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: "Markus Ott" To: "Jian Zhang" Date: Thu, 12 Jan 2006 08:24:38 -0500 Subject: Re: [NSIS] QoS NSLP: More open issues Received: from [141.3.70.162] by ws1-5.us4.outblaze.com with http for markus@minister.com; Thu, 12 Jan 2006 08:24:38 -0500 X-Originating-Ip: 141.3.70.162 X-Originating-Server: ws1-5.us4.outblaze.com Message-Id: <20060112132439.6608E8402B@ws1-5.us4.outblaze.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: 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 Jian, Please see comment below. > > * section 4.8 Rerouting: > > After the reservation on the new path is set up, the branching node > > or the merging node may want to tear down the reservation on the old > > path (faster than what would result from normal soft-state time-out). > > > > It is unclear to me why and how the merging node should tear down the > > reservation on the old path: Only a reserve can carry a TEAR flag > > and it can only be sent towards the QNR. Furthermore, the branching > > node will usually detect the rerouting earlier anyway, because GIST > > will indicate a changed SII-handle via a network notification. >=20 > The reason why the merging node may need to tear down the=20 > reservation on the old path explicitly is because that this=20 > explicit tear down is faster than the implicit tear down via the=20 > soft-state time-out. Can the merging node initiate a tearing=20 > RESERVE message to the old branching node? I think the first=20 > merging node can, see the example below. >=20 > QNI------ QNE2 ----------QNE3--------QNE4-------QNE5-----QNR > | | > | | > |-------------QNE3'--------| >=20 >=20 > Previously, flow 1 took the path QNI-QN2-QNE3-QNE4-QNE5-QNR, and after > some time, its path changes to QNI-QNE2-QNE3'-QNE4-QNE5-QNR. The QNE2 > and QNE4 are called the merging nodes here. Due to this is the > case of sender-initiated reservation, now the path change is detected > when QNE2 receives a RESPONSE message with a different SII from QNE3'. > Then, the merging node QNE2 is aware of the path change and can > initiate a tearing RESERVE message with TEAR flag set and send it to > QNE3 to tear down the resources reserved for this flow at QNE3. QNE3 > can further propagate this tearing RESERVE message to QNE4. But, the > question is that how long this tearing message should be propagated. >=20 > In my opinion, the merging node QNE4 must not stop propagating this > tearing RESERVE message if it is already aware that it is the latter > merging node of this path change, i.e., it is aware that its > upstream peer is changed but the downstream peer is not. Meanwhile, > the new RESERVE message sent by QNE2 to QNE3' should also be stop > prapogating by QNE4. In this way, all those QNEs which are at the same > path as before do not need to tear down the resources and then reserve > the same resources again and again for the same flow. I always thought that the merging node is defined as node where two flows= =20 merge (join). In the example above this is the node QNE4. The QNE2 is the branching node (not the merging node) that means that=20 one flow branches here (will be split into two flows). Or do you=20 consider the QNE2 as a merging node in upstream direction? >From my point of view the question of Roland Bless makes sense. Regards, Markus --=20 ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 12 10:04:26 2006 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 1Ex402-0005AI-08; Thu, 12 Jan 2006 10:04:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex400-0005AD-0I for nsis@megatron.ietf.org; Thu, 12 Jan 2006 10:04:24 -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 KAA23151 for ; Thu, 12 Jan 2006 10:03:02 -0500 (EST) 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 1Ex474-0006h5-EH for nsis@ietf.org; Thu, 12 Jan 2006 10:11:43 -0500 Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.136.212.3]) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id k0CF54gb004883; Thu, 12 Jan 2006 15:05:04 GMT 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 k0CF3qJD004383; Thu, 12 Jan 2006 15:03:52 GMT Received: (from nobody@localhost) by mail.dei.uc.pt (8.13.5/8.12.5/Submit) id k0CF3l6h004382; Thu, 12 Jan 2006 15:03:47 GMT X-Authentication-Warning: mail.dei.uc.pt: nobody set sender to zhang@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 ; Thu, 12 Jan 2006 15:03:47 +0000 Message-ID: <1137078227.43c66fd3cebc9@mail.dei.uc.pt> Date: Thu, 12 Jan 2006 15:03:47 +0000 From: Jian Zhang To: Roland Bless Subject: Re: [NSIS] QoS NSLP: More open issues References: <43C43B31.6060000@tm.uka.de> <43C650EA.8000203@tm.uka.de> In-Reply-To: <43C650EA.8000203@tm.uka.de> 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=-2.599, required 3, autolearn=not spam, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: zhang@dei.uc.pt X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: 8bit Cc: 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, Roland, See comments below. Quoting Roland Bless : > Hi Jian > > > See my comments inline. I also report two more open issue below. > > > > * section 5.1.2.1 RESERVE: > > REPLACE (R) - when set, indicates that a RESERVE with different > > Message Routing Information (MRI) replaces an existing one, so the > > old one MAY be torn down immediately. This is the default > > situation. This flag may be unset to indicate a desire from an > > upstream node to keep an existing reservation on an old branch in > > place. > > > > This flag is also used to indicate that whether the reserved resources > > on the old branch should be teared down or not when the data path change > > happens (see, section 4.6 Rerouting). In this case, the MRI is the same > > and only the route path is changed. So, this feature should also be > > included in the above description text of REPLACE flag. > > Agreed. > > > * section 5.1.3.5 PACKET_CLASSIFIER: > > The flags indicate which fields from the MRI should be used by the > > packet classifier. Flags MUST only be set if the data is present in > > the MRI (i.e. if there is a flag for it in GIST, then that must also > > be set). > > > > In my understanding, which flags will be set in PACKET_CLASSIFIER should > > be directed by the QOS Model used becuase these flags is to indicate > > which fields from the MRI will be used by the packet > > classifier to classfy the incoming packets of this flow. Therefore, the > > QoS Model function should be mentioned at the above description of > > PACKET_CLASSIFIER and this part "(i.e. if there is a flag for it in > > GIST, then that must also be set)" should be removed due to it makes no > > sense (or even is wrong). > > I guess you're right that the sentence in parentheses is wrong. > Actually problably wanted to say something like: > (i.e. it is only allowed to set if there is a flag for it in GIST). The sentense in the parentheses probably wanted to say something like you mentioned above. But I think it is also redundant because the MRI is sent by the QoS-NSLP to GIST and then QoS-NSLP can check the consistency between the PACKET_CLASSIFIER and MRI at the QoS-NSLP level and need not bother the GIST. > > Also, because the PACKET_CLASSIFIER is to indicate to the packet > > classifier at each QNE that which fields from the MRI will be used to > > classify the incoming packets of one flow, the PACKET_CLASSIFIER object > > is only needed for the RESERVE message. Only the RESERVE message will > > reserve the resources for the flow at the QNEs along the flow's data > > path and only after the reservation, the packets of the flow could be > > accepted into the network. Thus, including the PACKET_CLASSIFIER object > > in the QUERY, RESPONSE and NOTIFY messages make no sense (see sections > > 5.1.2.2, 5.1.2.3 and 5.1.2.4 where the QUERY, RESPONSE and NOTIFY > > messages also include the PACKET_CLASSIFIER object). > > Hmm, sounds logical to me. Maybe someone who thinks that > this is necessary could speak up now, otherwise we should > remove the PACKET_CLASSIFIER from all PDUs except the RESERVE. Agree. > > >> * section 4.8 Rerouting: > >> After the reservation on the new path is set up, the branching node > >> or the merging node may want to tear down the reservation on the old > >> path (faster than what would result from normal soft-state time-out). > >> > >> It is unclear to me why and how the merging node should tear down the > >> reservation on the old path: Only a reserve can carry a TEAR flag > >> and it can only be sent towards the QNR. Furthermore, the branching > >> node will usually detect the rerouting earlier anyway, because GIST > >> will indicate a changed SII-handle via a network notification. > > > > > > The reason why the merging node may need to tear down the reservation on > > the old path explicitly is because that this explicit tear down is > > faster than the implicit tear down via the soft-state time-out. Can the > > The draft states it already, but it mentiones > > > merging node initiate a tearing RESERVE message to the old branching > > node? I think the first merging node can, see the example below. > > I guess we have a terminology problem here, because I differentiate > between branching and merging nodes (as the draft does sometimes). > See below. > > > QNI------ QNE2 ----------QNE3--------QNE4-------QNE5-----QNR > > | | > > | | > > |-------------QNE3'--------| > > > > > > Previously, flow 1 took the path QNI-QN2-QNE3-QNE4-QNE5-QNR, and after > > some time, its path changes to QNI-QNE2-QNE3'-QNE4-QNE5-QNR. The QNE2 > > and QNE4 are called the merging nodes here. Due to this is the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This would be quite confusing. If the data is flowing from QNI to QNR > I would call QNE2 the branching node (flows split) and QNE4 the merging > node (flows join again). The following is correct if you simply > s/merging/branching. Ok with me if the QNE2 is called the branching node and the QNE4 the mergering node. In this case, I agree with you that only the branching node should and can initiate the tearing RESERVE message to tear down the reservation on the old path. > > > case of sender-initiated reservation, now the path change is detected > > when QNE2 receives a RESPONSE message with a different SII from QNE3'. > > Then, the merging node QNE2 is aware of the path change and can > > initiate a tearing RESERVE message with TEAR flag set and send it to > > QNE3 to tear down the resources reserved for this flow at QNE3. QNE3 > > can further propagate this tearing RESERVE message to QNE4. But, the > > question is that how long this tearing message should be propagated. > > Usually, QNE4 will detect that it is a merging node and has another > active reservation for the same SID _and_ the same flow. Tear down > the old reservation should stop at QNE4 in this case. But if the flows > (i.e. MRIs) are different, it must propagate the RESERVE w/ TEAR further > along the path. > > > In my opinion, the merging node QNE4 must not stop propagating this > > tearing RESERVE message if it is already aware that it is the latter > > merging node of this path change, i.e., it is aware that its > > upstream peer is changed but the downstream peer is not. Meanwhile, > > That's basically what I mean by merging node. > > > the new RESERVE message sent by QNE2 to QNE3' should also be stop > > prapogating by QNE4. In this way, all those QNEs which are at the same > > path as before do not need to tear down the resources and then reserve > > the same resources again and again for the same flow. > > I don't understand your proposal. You say QNE4 should propagate the > TEAR further downstream, but the new RESERVE should stop at QNE4? No. What I proposed is that the QNE4 should stop propagating both the tearing RESERVE from QNE3 and the new RESERVE from QNE3' when the MRI remains the same. For the case that the MRI has changed and the old flow and the new flow shares some parts of their pathes, the merging node QNE4 should propagate both the tearing RESERVE from QNE3 and the new RESERVE from QNE3'. > This would lead to a reservation along the new path that stops at QNE4. > > I guess we should better distinguish at least these cases: > - Rerouting occurred without change of flowID (MRI). > In this case QNE2 (as branching node) will detect > the route change and initiate a new RESERVE with RII set. > This new RESERVE will stop at the merging node > who sends a RESPONSE w/ RII back. In case of success > QNE2 will see that the new path was successfully established > and starts to TEAR down the reservation along the old branch. > This TEAR will nevertheless stop at QNE4 in order to prevent > tearing down the reservation along the unchanged path. > - The flowID changed. We assume that the old flow and the new > flow will share some parts of their paths, i.e. both flows > traverse a common set of nodes. In this case, QNE4 should > neither stop propagating the new RESERVE nor stop to forward > the tearing reserve. > - FlowID stays the same, but QSPEC has changed. In this case > QNE4 should forward the new RESERVE, but not the RESERVE w/ TEAR. Agree. > >> in the same context: > >> * section 5.4.1: > >> NSLP state. If the SII is different, this means that the QNE is a > >> merge point. In that case, in addition to the operations specified > >> above, the value REPLACE=0 is also indicating that a tearing RESERVE > >> SHOULD NOT be sent on the old branch. > >> > >> As above: the merge point cannot initiate a tearing RESERVE. > >> Furthermore, in case the QSPEC and MRI are not changed, the merging > >> QNE need not send the RESERVE further downstream because the state > >> along the remaining path has not changed. > >> > > See above. > > The above sentence says that QNE4 is not able to tear down > the old branch (only QNE2 may do so). Yes, only QNE2 can initiate the tearing RESERVE message to tear down the reservations on the old path. If we agree to call the QNE2 the branching node and the QNE4 the merging node, then some descriptions about rerouting in the draft have to be updated/changed. > >> * section 4.8 Rerouting: > >> > >> A QNI or a branch node may wish to keep the reservation on the old > >> branch. This could for instance be the case when a mobile node has > >> experienced a mobility event and wishes to keep reservation to its > >> old attachment point in case it moves back there. In that case, it > >> sets the REPLACE flag in the common header to zero. Note that keeping > >> old reservations affects the resources available to other nodes. > >> Thus, the operator of the access network must make the final decision > >> on whether this behavior is allowed. Also, the QNEs in the access > >> network may add this flag even if the mobile node has not used the > >> flag initially. > >> > >> It is not clear for how long the reservation should be kept, i.e. > >> how long should the branching node keep sending refreshes? Should > >> it do so at all? > >> > > That may depend on the local policy. > > Sure, however. one must implement something... > I would then suggest to add something like: > How long an old reservation is kept depends on local policy. Agree. > > > Agree with you. Especially when the RESPONSE message is to indicate that > > the previous RESERVE action failed due to some severe errors (such as > > the authentication failure or no enough resources), the RESPONSE should > > be forwarded to the QNI, which then can initiate a tearing RESERVE > > message to inform those QNEs which have already reserved resources to > > release them. > > But even if upstream nodes only sent regular refreshing RESERVEs > it may be necessary. Consider a rerouting event like in the above > scenario. In case the new RESERVE along the new branch fails due to > resource shortage, upstream nodes should be notified of this failure. > In this case they will get "unsolicited" RESPONSEs (which match the > RSN of the refreshing RESERVE). I agree with you. What I tried to say above is that, on receipt of a RESPONSE message containing an RII object and carring an INFO_SPEC indicating an error, whether this RESPONSE message will be forwarded further until the QNI should depend on the error code and subcode contained in the INFO_SPEC. If the error code and subcode indicate some severe errors (e.g., the authentication failure or resource shortage, etc), then this RESPONSE should be forwared further until the QNI even one QNE matches the RII successfully. Regards, Jian > >> * section 7.1 > >> > >> "Note that we assume the SII handling in GIST [I-D.ietf-nsis-ntlp] > >> is extended to distinguish between own and peer SII." > >> > >> This is not necessary, so you should delete this sentence. > >> > >> SendMessage(...) (Fig. 35) and RecvMessage(...) (Fig. 36) should have > >> the same parameters as in the GIST draft. > > > > > > Agree. Now the APIs illustrated in Fig. 35 and Fig. 36 are inconsistent > > with the ones defined in GIST. The editors should discuss and fix this > > problem. > > Seems to be fixed now. > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 12 10:36:24 2006 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 1Ex4Uy-0005eo-9D; Thu, 12 Jan 2006 10:36:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4Uw-0005ea-DP for nsis@megatron.ietf.org; Thu, 12 Jan 2006 10:36:22 -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 KAA24873 for ; Thu, 12 Jan 2006 10:35:00 -0500 (EST) Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex4c4-0007Ys-8I for nsis@ietf.org; Thu, 12 Jan 2006 10:43:44 -0500 Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.136.212.3]) by smtp.dei.uc.pt (8.13.4/8.13.4) with ESMTP id k0CFd1CD023319; Thu, 12 Jan 2006 15:39:01 GMT 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 k0CFZcbc004723; Thu, 12 Jan 2006 15:35:38 GMT Received: (from nobody@localhost) by mail.dei.uc.pt (8.13.5/8.12.5/Submit) id k0CFZNaL004722; Thu, 12 Jan 2006 15:35:23 GMT X-Authentication-Warning: mail.dei.uc.pt: nobody set sender to zhang@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 ; Thu, 12 Jan 2006 15:35:23 +0000 Message-ID: <1137080123.43c6773b9f102@mail.dei.uc.pt> Date: Thu, 12 Jan 2006 15:35:23 +0000 From: Jian Zhang To: Markus Ott Subject: Re: [NSIS] QoS NSLP: More open issues References: <20060112132439.6608E8402B@ws1-5.us4.outblaze.com> In-Reply-To: <20060112132439.6608E8402B@ws1-5.us4.outblaze.com> 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=-2.599, required 3, autolearn=not spam, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: zhang@dei.uc.pt X-Spam-Score: 0.7 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 8bit Cc: 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, Markus, Please see comment below. Quoting Markus Ott : > Hi Jian, > > Please see comment below. > > > > * section 4.8 Rerouting: > > > After the reservation on the new path is set up, the branching node > > > or the merging node may want to tear down the reservation on the old > > > path (faster than what would result from normal soft-state time-out). > > > > > > It is unclear to me why and how the merging node should tear down the > > > reservation on the old path: Only a reserve can carry a TEAR flag > > > and it can only be sent towards the QNR. Furthermore, the branching > > > node will usually detect the rerouting earlier anyway, because GIST > > > will indicate a changed SII-handle via a network notification. > > > > The reason why the merging node may need to tear down the > > reservation on the old path explicitly is because that this > > explicit tear down is faster than the implicit tear down via the > > soft-state time-out. Can the merging node initiate a tearing > > RESERVE message to the old branching node? I think the first > > merging node can, see the example below. > > > > QNI------ QNE2 ----------QNE3--------QNE4-------QNE5-----QNR > > | | > > | | > > |-------------QNE3'--------| > > > > > > Previously, flow 1 took the path QNI-QN2-QNE3-QNE4-QNE5-QNR, and after > > some time, its path changes to QNI-QNE2-QNE3'-QNE4-QNE5-QNR. The QNE2 > > and QNE4 are called the merging nodes here. Due to this is the > > case of sender-initiated reservation, now the path change is detected > > when QNE2 receives a RESPONSE message with a different SII from QNE3'. > > Then, the merging node QNE2 is aware of the path change and can > > initiate a tearing RESERVE message with TEAR flag set and send it to > > QNE3 to tear down the resources reserved for this flow at QNE3. QNE3 > > can further propagate this tearing RESERVE message to QNE4. But, the > > question is that how long this tearing message should be propagated. > > > > In my opinion, the merging node QNE4 must not stop propagating this > > tearing RESERVE message if it is already aware that it is the latter > > merging node of this path change, i.e., it is aware that its > > upstream peer is changed but the downstream peer is not. Meanwhile, > > the new RESERVE message sent by QNE2 to QNE3' should also be stop > > prapogating by QNE4. In this way, all those QNEs which are at the same > > path as before do not need to tear down the resources and then reserve > > the same resources again and again for the same flow. > > > > I always thought that the merging node is defined as node where two flows > merge (join). In the example above this is the node QNE4. > The QNE2 is the branching node (not the merging node) that means that > one flow branches here (will be split into two flows). Or do you > consider the QNE2 as a merging node in upstream direction? > Ok with me if we agree with that the QNE4 is called the merging node and the QNE2 the branching node. In this case, the question Roland Bless raised does make sense, i.e., only the branching node (QNE2) should and can initiate a tearing RESERVE message to tear down the reservations on the old path and the merging node (QNE4) cannot. Regards, Jian > >From my point of view the question of Roland Bless makes sense. > > Regards, > Markus > > > > > > > -- > ___________________________________________________ > Play 100s of games for FREE! http://games.mail.com/ > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jan 12 13:21:07 2006 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 1Ex74N-0002Wv-Gl; Thu, 12 Jan 2006 13:21:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex74M-0002We-1K for nsis@megatron.ietf.org; Thu, 12 Jan 2006 13:21: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 NAA05201 for ; Thu, 12 Jan 2006 13:19:45 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex7BQ-0003y3-D7 for nsis@ietf.org; Thu, 12 Jan 2006 13:28:27 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k0CIKpah016019; Thu, 12 Jan 2006 19:20:51 +0100 Received: from mhpahx2c.ww002.siemens.net (mhpahx2c.mch.sbs.de [139.25.165.55]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k0CIKoEt018073; Thu, 12 Jan 2006 19:20:50 +0100 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx2c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jan 2006 19:20:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jan 2006 19:20:48 +0100 Message-ID: <391E6FBF5E786940B9E2F7CA6376C708012F526A@blns00fa.ww002.siemens.net> Thread-Topic: NSIS & Mobility Thread-Index: AcYXpOlInmhNX5cWS5qBkFcFq/rWtA== From: "Kappler, Cornelia" To: "Seong-Ho Jeong" , X-OriginalArrivalTime: 12 Jan 2006 18:20:49.0803 (UTC) FILETIME=[EA349DB0:01C617A4] X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: nsis@ietf.org Subject: [NSIS] NSIS & Mobility 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="===============1204171717==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1204171717== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C617A4.E9BB1F82" This is a multi-part message in MIME format. ------_=_NextPart_001_01C617A4.E9BB1F82 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sung-Hyuck and Seong-Ho, and other "NSIS & Mobility" authors,=20 recently I've been studying your draft http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobili ty-signaling-03.txt and have some questions: Apparently you are proposing three enhancement to the existing NSIS protocols. I am not sure they are necessary, see below. Furthermore - and this is another main feedback - it should be made very clear in the draft where you are proposing new things, and where you are discussing already existing NSIS features. Very helpful would be a conclusion section that states "this draft proposes the following enhancements to the GIST and NSLP specifications.. " - "CD flag bit" (Sec. 5.1.4.1). I think this is set by the Crossover Node (CRN) when it discovers it is the CRN. Appart from the name (bit AND flag is redundant), I dont understand what the use is of this flag.=20 (i) Is it to prevent other NEs to wrongly think they are the CRN? I dont think so: To my understanding a CRN identifies itself as being the CRN because it has two interfaces to which the same session seems to be incoming/outgoing, with a different flow ID attached to each interface. There is no danger of any NE wrongly thinking it might be the CRN. This situation is not changed in tunnelling scenarios.=20 (ii) Is it to inform the NI or NR (or NEs) that the CRN has been found? I dont think NEs in general are interested in this information. The NI may have use for this in order to start tearing down the reservation along the old section of the path. However I am not sure we are at all considering this scenario (the NI initiating the tear down), particularly since the NI may not be able to access the old path anymore because it moved to a new access router. - "NSLP_Br_ID" (Sec 4.2.2). This is an identifier for identifying different branches of the same session on a given NE (i.e. a CRN). I think this is redundant information. On GIST level, differnent branches are already identified by different Message Routing State (i.e. the next / previous NSIS peers are different). It is interesting though that for the CRN the table containing message routing state may need two entries for next/previous NSIS peer for a single session, as long as the old section of the path is not yet torn down. Even if the branch identifier was useful it doesnt seem clear who sets it, i.e. which node determines it is currently signaling along a new branch for an existing NSIS session. Finally, it seems to me two branches for one session should be a rather transient phenomenon. I.e. only one of them should really be active at a given time.=20 - "mobility object" (Sec 4.2.2). This is included (by the NI?) to alert some other node (which?) that a mobility event took place. It is defined to "expedite CRN discovery" - how? Why would the discovery be more rapid? Such an object may indeed be useful, however the motivation given relates mostly to solving the problem of ping-pong type handover which I am not sure is such an urgent problem to solve. Another motivation is (Sec. 5.5) apparently preventing time out of a session during the time a mobile node is performing the handover. Is the idea that before handover starts, the mobile node includes this object in order to inform all NEs that they should not tear down the state even if the next refresh fails? Probably it would be sufficient to inform the access router, because it can reply to refreshes. No need to inform all NEs. But even if you restrict it to the access router, I am sure there are security problems with it (DoS attacks etc). Or may be I'be been misinterpreting your intention. Looking forward to your feedback, best regards, Cornelia ------_=_NextPart_001_01C617A4.E9BB1F82 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NSIS & Mobility

Hi Sung-Hyuck and = Seong-Ho, and other "NSIS & Mobility" authors, =

recently I've been = studying your draft http://www.ietf.org/internet-drafts/draft-ietf-nsis-applic= ability-mobility-signaling-03.txt and have some = questions:

Apparently you are = proposing three enhancement to the existing NSIS protocols. I am not = sure they are necessary, see below. Furthermore - and this is another = main feedback - it should be made very clear in the draft where you are = proposing new things, and where you are discussing already existing NSIS = features. Very helpful would be a conclusion section that states = "this draft proposes the following enhancements to the GIST and = NSLP specifications.. "

- "CD flag = bit" (Sec. 5.1.4.1). I think this is set by the Crossover Node = (CRN) when it discovers it is the CRN. Appart from the name (bit AND = flag is redundant), I dont understand what the use is of this flag. =

(i) Is it to prevent = other NEs to wrongly think they are the CRN? I dont think so: To my = understanding a CRN identifies itself as being the CRN because it has = two interfaces to which the same session seems to be incoming/outgoing, = with a different flow ID attached to each interface. There is no danger = of any NE wrongly thinking it might be the CRN. This situation is not = changed in tunnelling scenarios.

(ii) Is it to inform = the NI or NR (or NEs) that the CRN has been found? I dont think NEs in = general are interested in this information. The NI may have use for this = in order to start tearing down the reservation along the old section of = the path. However I am not sure we are at all considering this scenario = (the NI initiating the tear down), particularly since the NI may not be = able to access the old path anymore because it moved to a new access = router.

- = "NSLP_Br_ID" (Sec 4.2.2). This is an identifier for = identifying different branches of the same session on a given NE (i.e. a = CRN). I think this is redundant information. On GIST level, differnent = branches are already identified by different Message Routing State (i.e. = the next / previous NSIS peers are different). It is interesting though = that for the CRN the table containing message routing state may need two = entries for next/previous NSIS peer for a single session, as long as the = old section of the path is not yet torn down. Even if the branch = identifier was useful it doesnt seem clear who sets it, i.e. which node = determines it is currently signaling along a new branch for an existing = NSIS session. Finally, it seems to me two branches for one session = should be a rather transient phenomenon. I.e. only one of them should = really be active at a given time.

- "mobility = object" (Sec 4.2.2). This is included (by the NI?) to alert some = other node (which?) that a mobility event took place. It is defined to = "expedite CRN discovery" - how? Why would the discovery be = more rapid? Such an object may indeed be useful, however the motivation = given relates mostly to solving the problem of ping-pong type handover = which I am not sure is such an urgent problem to solve. Another = motivation is (Sec. 5.5) apparently preventing time out of a session = during the time a mobile node is performing the handover. Is the idea = that before handover starts, the mobile node includes this object in = order to inform all NEs that they should not tear down the state even if = the next refresh fails? Probably it would be sufficient to inform the = access router, because it can reply to refreshes. No need to inform all = NEs. But even if you restrict it to the access router, I am sure there = are security problems with it (DoS attacks etc). Or may be I'be been = misinterpreting your intention.

Looking forward to = your feedback, best regards, Cornelia

------_=_NextPart_001_01C617A4.E9BB1F82-- --===============1204171717== 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 --===============1204171717==-- From nsis-bounces@ietf.org Fri Jan 13 10:14:30 2006 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 1ExQdK-00012E-Bl; Fri, 13 Jan 2006 10:14:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExQdJ-000129-8N for nsis@megatron.ietf.org; Fri, 13 Jan 2006 10:14:29 -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 KAA12259 for ; Fri, 13 Jan 2006 10:13:04 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExQka-0007D6-MZ for nsis@ietf.org; Fri, 13 Jan 2006 10:22:02 -0500 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 k0DFEJHL010785 for ; Fri, 13 Jan 2006 16:14:19 +0100 (MET) Message-ID: <024b01c61854$0760ed30$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Nsis \(E-mail\)" Date: Fri, 13 Jan 2006 16:14:15 +0100 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.646 () ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,UPPERCASE_25_50 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, 13 Jan 2006 16:14:19 +0100 (MET) X-Spam-Score: 0.7 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [NSIS] PACKET_CLASSIFIER in RESERVE adn 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: , Content-Type: multipart/mixed; boundary="===============1100400274==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1100400274== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0248_01C6185C.660DDC00" This is a multi-part message in MIME format. ------=_NextPart_000_0248_01C6185C.660DDC00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all=20 During some previous discussions have been emphasized that the = PACKET_CLASSIFIER is only usefull=20 if it is carried by RESERVE messages.=20 The other three QOS-NSLP messages, i.e., QUERY, NOTIFY and RESPONSE = messages do not need=20 to carry the PACKET_CLASSIFIER object. I think that I would agree that the messages NOTIFY and RESPONSE do not = need to carry=20 the PACKET_CLASSIFIER=20 object, but I think that we should provide the=20 ability to future QoS models to use the PACKET_CLASSIFIER also in the = QUERY messages. Thus my proposal is: * Provide the possibility to use the PACKET_CLASSIFIER in RESERVE and = QUERY messages.=20 Best Regards, Georgios ------=_NextPart_000_0248_01C6185C.660DDC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all
 
During some previous discussions have = been=20 emphasized that the PACKET_CLASSIFIER is only usefull
if it is carried by RESERVE messages. =
The other three QOS-NSLP messages, = i.e., QUERY,=20 NOTIFY and RESPONSE messages do not need
to carry the PACKET_CLASSIFIER = object.
I think that I would agree that the = messages NOTIFY=20 and RESPONSE do not need to carry
the PACKET_CLASSIFIER
object, but I think that we should = provide the=20
ability to future QoS models to use the = PACKET_CLASSIFIER also in the QUERY messages.
 
Thus my proposal is:
 
* Provide the possibility to use the=20 PACKET_CLASSIFIER in RESERVE and QUERY messages. 
 
Best Regards,
Georgios
 
------=_NextPart_000_0248_01C6185C.660DDC00-- --===============1100400274== 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 --===============1100400274==-- From nsis-bounces@ietf.org Sun Jan 15 16:29:09 2006 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 1EyFQz-0008CT-8z; Sun, 15 Jan 2006 16:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFQx-0008CM-KA for nsis@megatron.ietf.org; Sun, 15 Jan 2006 16:29:08 -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 QAA16367 for ; Sun, 15 Jan 2006 16:27:44 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFYj-0003ei-Ux for nsis@ietf.org; Sun, 15 Jan 2006 16:37:11 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLRxTv007754; Sun, 15 Jan 2006 22:27:59 +0100 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 k0FLRwiT031259; Sun, 15 Jan 2006 22:27:58 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 22:27:55 +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: Sun, 15 Jan 2006 22:27:54 +0100 Message-ID: Thread-Topic: Diameter QoS Draft: Issue #11 Thread-Index: AcYaGMkkt7GVHep4SJ2PjeXaD0KnSQ== From: "Tschofenig, Hannes" To: , "Jukka MJ Manner" , X-OriginalArrivalTime: 15 Jan 2006 21:27:55.0818 (UTC) FILETIME=[8CABD0A0:01C61A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , nsis@ietf.org Subject: [NSIS] Diameter QoS Draft: Issue #11 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 would like to resolve issue 11 ('Authorization of Query messages').=20 The resolution of this issue depends on the semantic of the query message.=20 Case A: A response to a Query message means that these are the available resources from a admission control point of view. Whether the user is actually be allowed to request these resource is not verified=20 Case B: Same as Case A but a response to a Query indicates that the user will actually be authorized to request the indicated resources.=20 The authorization decision might take place at different places: a) QoS aware router b) Local AAA server c) User's home AAA server =20 In case of (a) we do not need to add anything to the Diameter QoS draft itself (but maybe to the QoS NSLP document).=20 I wonder what we should write in the Diameter QoS draft in order to address this issue? Is it likely that AAA interaction will be triggered for a query message? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jan 15 16:29:14 2006 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 1EyFR4-0008FX-6t; Sun, 15 Jan 2006 16:29:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR2-0008FB-Vg for nsis@megatron.ietf.org; Sun, 15 Jan 2006 16:29: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 QAA16390 for ; Sun, 15 Jan 2006 16:27:49 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFYq-0003fC-3i for nsis@ietf.org; Sun, 15 Jan 2006 16:37:16 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLT2Pc013676; Sun, 15 Jan 2006 22:29:02 +0100 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 k0FLSxHV007091; Sun, 15 Jan 2006 22:29:01 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 22:28:35 +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: Sun, 15 Jan 2006 22:28:34 +0100 Message-ID: Thread-Topic: Diameter QoS Draft: Issue #16, #20, #22 Thread-Index: AcYaC85mJCwfhNw9TCa7JEZv72INhg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 15 Jan 2006 21:28:35.0301 (UTC) FILETIME=[A4347150:01C61A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , nsis@ietf.org Subject: [NSIS] Diameter QoS Draft: Issue #16, #20, #22 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,=20 you provided feedback for the Diameter QoS application draft. We would like to close the open issues based on the draft version -05:=20 http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt We created the following issues after your review. We updated the draft based on your feedback and reflected your comment.=20 Two party authorization model http://www.tschofenig.priv.at:8080/diameter-qos/issue16 Suggestion:Close Gating http://www.tschofenig.priv.at:8080/diameter-qos/issue20 Suggestion:Close Session Identifier http://www.tschofenig.priv.at:8080/diameter-qos/issue22 Suggestion:Close Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jan 15 16:29:15 2006 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 1EyFR5-0008GX-2q; Sun, 15 Jan 2006 16:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR3-0008FD-1M for nsis@megatron.ietf.org; Sun, 15 Jan 2006 16:29: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 QAA16388 for ; Sun, 15 Jan 2006 16:27:49 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFYp-0003f9-TU for nsis@ietf.org; Sun, 15 Jan 2006 16:37:16 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLT1V7008135; Sun, 15 Jan 2006 22:29:01 +0100 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 k0FLSxHR007091; Sun, 15 Jan 2006 22:29:01 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 22:28: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 Date: Sun, 15 Jan 2006 22:28:33 +0100 Message-ID: Thread-Topic: Diameter QoS Draft: Issue #12 Thread-Index: AcYaCvBXlR9VtW4pRgyHM4GZMMrK4g== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 15 Jan 2006 21:28:33.0661 (UTC) FILETIME=[A33A32D0:01C61A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , nsis@ietf.org Subject: [NSIS] Diameter QoS Draft: Issue #12 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,=20 currently the draft does not describe a potential interworking between Diameter Credit Control and the Diameter QoS application.=20 This issue is document in issue#12:=20 http://www.tschofenig.priv.at:8080/diameter-qos/issue12 Do you have a suggestion whether a description is useful or even necessary? If we need to provide some text do you have some suggestions? Ciao Hannes Ps: Note that the interworking with Diameter CC was also discussed in issue #15 (see http://www.tschofenig.priv.at:8080/diameter-qos/issue15) regarding the support for volume based charging. Currently, the draft only discusses time-based charging. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jan 15 16:29:15 2006 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 1EyFR5-0008Gw-HE; Sun, 15 Jan 2006 16:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR3-0008FS-Ot for nsis@megatron.ietf.org; Sun, 15 Jan 2006 16:29: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 QAA16395 for ; Sun, 15 Jan 2006 16:27:50 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFYr-0003fD-3R for nsis@ietf.org; Sun, 15 Jan 2006 16:37:17 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLT2mp013689; Sun, 15 Jan 2006 22:29:02 +0100 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 k0FLSxZC031433; Sun, 15 Jan 2006 22:29:02 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 22:28:35 +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: Sun, 15 Jan 2006 22:28:34 +0100 Message-ID: Thread-Topic: Diameter QoS Draft: Issue #19 Thread-Index: AcYaDArJdSIGgHxYQTm0a2LLLUllrw== From: "Tschofenig, Hannes" To: "Kappler, Cornelia" X-OriginalArrivalTime: 15 Jan 2006 21:28:35.0520 (UTC) FILETIME=[A455DC00:01C61A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , nsis@ietf.org Subject: [NSIS] Diameter QoS Draft: Issue #19 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,=20 you provided feedback for the Diameter QoS application draft. We would like to close the open issues based on the draft version -05:=20 http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt We created the following issue related to your review:=20 QoS Accounting http://www.tschofenig.priv.at:8080/diameter-qos/issue19 We updated the draft based on your feedback and reflected your comment.=20 We suggest to close the issue based on the draft update.=20 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jan 15 16:29:16 2006 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 1EyFR6-0008HL-87; Sun, 15 Jan 2006 16:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR4-0008Fz-Lv for nsis@megatron.ietf.org; Sun, 15 Jan 2006 16:29: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 QAA16398 for ; Sun, 15 Jan 2006 16:27:51 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFYr-0003fG-VI for nsis@ietf.org; Sun, 15 Jan 2006 16:37:18 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLT1pa008136; Sun, 15 Jan 2006 22:29:01 +0100 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 k0FLSxYq031433; Sun, 15 Jan 2006 22:29:01 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 22:28:34 +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: Sun, 15 Jan 2006 22:28:33 +0100 Message-ID: Thread-Topic: Diameter QoS Draft: Issue #25 Thread-Index: AcYaCvKZ8BzxvCNuTCKsTvxVOp/ZCQ== From: "Tschofenig, Hannes" To: "Elwyn Davies" X-OriginalArrivalTime: 15 Jan 2006 21:28:34.0098 (UTC) FILETIME=[A37CE120:01C61A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , nsis@ietf.org Subject: [NSIS] Diameter QoS Draft: Issue #25 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,=20 you provided feedback for the Diameter QoS application draft. We would like to close the open issues based on the draft version -05:=20 http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt Sending final accounting messages after the end of the authorization session http://www.tschofenig.priv.at:8080/diameter-qos/issue25 We updated the draft based on your feedback and reflected your comment.=20 We suggest to close the issue based on the draft update.=20 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 16 05:17:02 2006 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 1EyRQ6-0005lr-Bv; Mon, 16 Jan 2006 05:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyRQ3-0005ld-4M for nsis@megatron.ietf.org; Mon, 16 Jan 2006 05:17:00 -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 FAA00322 for ; Mon, 16 Jan 2006 05:15:35 -0500 (EST) 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 1EyRXx-0002ow-69 for nsis@ietf.org; Mon, 16 Jan 2006 05:25:09 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EyRPd-0004d3-TA; Mon, 16 Jan 2006 10:16:34 +0000 Message-ID: <43CB7301.8090804@dial.pipex.com> Date: Mon, 16 Jan 2006 10:18:41 +0000 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA00322 Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , nsis@ietf.org Subject: [NSIS] Re: Diameter QoS Draft: Issue #25 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 just reviewed the updated draft against my previous comments: As regards your specific question, I think Issue 25 is adequately covered. Most of my other comments are covered. However, there are a couple of=20 points that aren't covered. Regards, Elwyn Remaining Issues: The document (still) doesn't have an explicit IANA considerations=20 section. There are IANA considerations distributed in the document (s6=20 and s7.1 at least). Unidirectional vs bidirectional flows: I made the comment on the=20 previous version that it should be made clear early on in the doc=20 whether it was dealing with uni- or bi-directional flows. There was a=20 paragraph right at the end of s8 which said: If the data communication might be necessary in both directions, from Host A to Host B and vice versa, a separate QoS signaling communication is required for the reverse direction (with path- coupled signaling). This message exchange is not shown in this example. This has been removed and there is now nothing about the type of data=20 flows. I think this ought to be remedied. I made some comments about s5 (regarding whether time based accounting=20 was being mandated or not): Nothong has changed and I can't remember=20 whether this was discussed or not.. I still don't feel I have a good=20 understanding of this section. I made a couple of comments on s9 (security considerations) which I=20 don't think have been addressed (including 'But what about any specific=20 threats or risks associated with what is going on here=85 should we just=20 say that RFC3588 covers it all?'). I haven't changed my view that the refs to -nsis-qos-nslp and=20 -nsis-qspec are normative. Editorial: s4.2: NAI - Unexpanded acronym. s4.2: Not sure if rules require a title for the table :-( s4.2: s/generated Acc-Multi-Session-Id AVP Section 7.3/generated=20 Acc-Multi-Session-Id AVP (see Section 7.3)/ s4.2: s/Result-Code =3D DIAMETER_LIMITED_SUCCESS, Section 7.1/Result-Code= =20 =3D DIAMETER_LIMITED_SUCCESS - see Section 7.1/ s4.4: s/to update already authorized flow status/the update of the=20 already authorized flow status/ s4.4(end): s/.(mostly applicable for local scenarios)/(mostly applicable=20 for local scenarios)./ s4.5.1: s/Diameter base protocol functionality/Diameter base protocol=20 function/ s4.5.1 (fig 9): s/TearOn/Delete QoS reservation/ (It got fixed in one=20 place but there are several other instances) s4.5.1 (fig 9): where are QoS Reserve and QoS Response messages at the=20 bottom terminated? s4.5.2 (fig 10): same comments as for s4.5.1 (fig 9). s10: s/Robert already provided us already/Robert also provided us with/ Tschofenig, Hannes wrote: >Hi Elwyn,=20 > >you provided feedback for the Diameter QoS application draft. We would >like to close the open issues based on the draft version -05:=20 >http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt > >Sending final accounting messages after the end of the authorization >session >http://www.tschofenig.priv.at:8080/diameter-qos/issue25 > >We updated the draft based on your feedback and reflected your comment.=20 > >We suggest to close the issue based on the draft update.=20 > >Ciao >Hannes > =20 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 16 06:04:23 2006 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 1EyS9v-0000cc-RH; Mon, 16 Jan 2006 06:04:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyS9u-0000c5-Gx; Mon, 16 Jan 2006 06:04:22 -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 GAA03244; Mon, 16 Jan 2006 06:02:58 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EySHo-00049D-26; Mon, 16 Jan 2006 06:12:33 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0GB4E2j009302; Mon, 16 Jan 2006 05:04:17 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Jan 2006 12:04:12 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550915483F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Aaa-Wg (E-mail)" , dime@ietf.org, nsis@ietf.org Date: Mon, 16 Jan 2006 12:04:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "David Kessens \(E-mail\)" Subject: [NSIS] Looking for candidates for (co-)chairing the (new) DIME WG 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 [posted to AAA, DIME and NSIS mailing lists since we expect that those mailing lists have the most relevant participants.] All, The new DIME WG (see charter at the bottom) has been approved by the IESG. The actual instantiation of the WG is pending the appointment of WG chair(s). The ADs have decided to write down a brief profile for the WG chair(s). We would like you to consider this profile and either nominate yourself or other people that you think that would fit well in this role by sending mail to the OPS ADs. ( and ). We do not intend to disclose the names of the nominees in public, but we will probably sollicit for feedback with various other people. If you have a problem with your name being mentioned in this context, pls let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent, so don't hesitate to nominate somebody who in your opinion would fit this role quite well but doesn't fit this profile 100%. And the intend is to select two co-chairs that can complement each other and work together. As for the profile: - Good management and process skills, including but not limited to choosing and supervising editors, commitment and followthrough on the charter, active management of the working group discussions, and handling IETF process steps in prompt fashion. - Good basic knowledge of the AAA protocols. That not only includes Diameter, but also Radius. - Understanding of the requirements/needs/applications of AAA protocols. Specifically, understanding the needs of other organizations (like 3GPP) is a useful asset. - Operational background/experience is very desirable. - Enough available time. For example, preferable not more than one other working chair role in IETF. - There is no requirement that the candidate has been an IETF working group chair before, but it helps if there is some evidence that the candidate can fullfill such a role (eg. other management role in other places than IETF etc.) We would like to receive your comments & nominations by Jan 30th 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your nomination mail how you or the nominated candidate fits this profile as best as possible. And last but not least, we would like to thank John Loughney for leading/guiding the work to develop the DIME WG charter. He also started a new mailing list: dime@ietf.org David Kessens & Bert Wijnen _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 16 06:16:49 2006 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 1EySLx-0003gu-3K; Mon, 16 Jan 2006 06:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySLv-0003fd-Cc for nsis@megatron.ietf.org; Mon, 16 Jan 2006 06:16:47 -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 GAA04028 for ; Mon, 16 Jan 2006 06:15:23 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EySTo-0004VC-Gd for nsis@ietf.org; Mon, 16 Jan 2006 06:24:58 -0500 Received: (qmail invoked by alias); 16 Jan 2006 11:16:24 -0000 Received: from ip-80-226-200-169.vodafone-net.de (EHLO [10.226.208.137]) [80.226.200.169] by mail.gmx.net (mp039) with SMTP; 16 Jan 2006 12:16:24 +0100 X-Authenticated: #29516787 Message-ID: <43CB805E.1080208@gmx.net> Date: Mon, 16 Jan 2006 12:15:42 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elwyn Davies Subject: Re: [NSIS] Re: Diameter QoS Draft: Issue #25 References: <43CB7301.8090804@dial.pipex.com> In-Reply-To: <43CB7301.8090804@dial.pipex.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA04028 Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi elwyn, thanks for the quick response. Elwyn Davies wrote: > I just reviewed the updated draft against my previous comments: >=20 > As regards your specific question, I think Issue 25 is adequately cover= ed. >=20 > Most of my other comments are covered. However, there are a couple of=20 > points that aren't covered. >=20 > Regards, > Elwyn >=20 > Remaining Issues: >=20 > The document (still) doesn't have an explicit IANA considerations=20 > section. There are IANA considerations distributed in the document (s6=20 > and s7.1 at least). issue added: http://www.tschofenig.priv.at:8080/diameter-qos/issue27 >=20 > Unidirectional vs bidirectional flows: I made the comment on the=20 > previous version that it should be made clear early on in the doc=20 > whether it was dealing with uni- or bi-directional flows. There was a=20 > paragraph right at the end of s8 which said: > If the data communication might be necessary in both directions, from > Host A to Host B and vice versa, a separate QoS signaling >` communication is required for the reverse direction (with path- > coupled signaling). This message exchange is not shown in this > example. > This has been removed and there is now nothing about the type of data=20 > flows. I think this ought to be remedied. i think we need to add some text about this aspect. i personally think=20 that a discussion about this aspect should go into section 4.4. since=20 bi-directional qos reservations are most likely applicable there. issue added: http://www.tschofenig.priv.at:8080/diameter-qos/issue28 >=20 > I made some comments about s5 (regarding whether time based accounting=20 > was being mandated or not): Nothong has changed and I can't remember=20 > whether this was discussed or not.. I still don't feel I have a good=20 > understanding of this section. this is still an open issue. http://www.tschofenig.priv.at:8080/diameter-qos/issue15 >=20 > I made a couple of comments on s9 (security considerations) which I=20 > don't think have been addressed (including 'But what about any specific= =20 > threats or risks associated with what is going on here=85 should we jus= t=20 > say that RFC3588 covers it all?'). the security of the diameter qos application is related to the security=20 of the qos architecture itself. hence, the threats and security=20 mechanisms are scattered a little bit over the place (e.g., qos nslp,=20 gist, ...). with issue # 4 (see http://www.tschofenig.priv.at:8080/diameter-qos/issue4) we address one of the aspects that requirements more discussion in the=20 document: 1. Bind-Authentication-Session AVP - carries the Diameter session id of=20 NASREQ session for network access authentication. i have created an issue: http://www.tschofenig.priv.at:8080/diameter-qos/issu= e29 >=20 > I haven't changed my view that the refs to -nsis-qos-nslp and=20 > -nsis-qspec are normative. the qspec is normativ but the qos nslp isn't (and it does not have to=20 be). we use the content of the qspec for the description of the qos=20 parameters but there is no dependency on the qos nslp. >=20 > Editorial: > s4.2: NAI - Unexpanded acronym. > s4.2: Not sure if rules require a title for the table :-( > s4.2: s/generated Acc-Multi-Session-Id AVP Section 7.3/generated=20 > Acc-Multi-Session-Id AVP (see Section 7.3)/ > s4.2: s/Result-Code =3D DIAMETER_LIMITED_SUCCESS, Section 7.1/Result-Co= de=20 > =3D DIAMETER_LIMITED_SUCCESS - see Section 7.1/ >=20 > s4.4: s/to update already authorized flow status/the update of the=20 > already authorized flow status/ > s4.4(end): s/.(mostly applicable for local scenarios)/(mostly applicabl= e=20 > for local scenarios)./ >=20 > s4.5.1: s/Diameter base protocol functionality/Diameter base protocol=20 > function/ >=20 > s4.5.1 (fig 9): s/TearOn/Delete QoS reservation/ (It got fixed in one=20 > place but there are several other instances) > s4.5.1 (fig 9): where are QoS Reserve and QoS Response messages at the=20 > bottom terminated? >=20 > s4.5.2 (fig 10): same comments as for s4.5.1 (fig 9). >=20 > s10: s/Robert already provided us already/Robert also provided us with/ >=20 will be fixed. thanks again. ciao hannes >=20 >=20 >=20 > Tschofenig, Hannes wrote: >=20 >> Hi Elwyn, >> you provided feedback for the Diameter QoS application draft. We would >> like to close the open issues based on the draft version -05:=20 >> http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt >> >> Sending final accounting messages after the end of the authorization >> session >> http://www.tschofenig.priv.at:8080/diameter-qos/issue25 >> >> We updated the draft based on your feedback and reflected your comment. >> We suggest to close the issue based on the draft update. >> Ciao >> Hannes >> =20 >> >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jan 16 07:05:31 2006 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 1EyT75-0008Nu-RA; Mon, 16 Jan 2006 07:05:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyT75-0008Nm-4U for nsis@megatron.ietf.org; Mon, 16 Jan 2006 07:05:31 -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 HAA06906 for ; Mon, 16 Jan 2006 07:04:06 -0500 (EST) 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 1EyTEz-000644-VD for nsis@ietf.org; Mon, 16 Jan 2006 07:13:42 -0500 Received: from smtp-2.ci.uc.pt (localhost [127.0.0.1]) by smtp-2-relay.ci.uc.pt (Postfix) with ESMTP id 5A4C419422D for ; Mon, 16 Jan 2006 12:05:10 +0000 (WET) Received: from teste-d.ci.uc.pt (sendmail.uc.pt [193.136.200.162]) by smtp-2.ci.uc.pt (Postfix) with ESMTP id 116D82FD007 for ; Mon, 16 Jan 2006 12:05:10 +0000 (WET) Received: from promidius (gtDEI-NATgw2.dei.uc.pt [193.137.203.230]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by teste-d.ci.uc.pt (Postfix) with ESMTP id F3F194A8124 for ; Mon, 16 Jan 2006 12:05:09 +0000 (WET) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: Date: Mon, 16 Jan 2006 12:05:31 -0000 Message-ID: <00a301c61a95$26338e00$43cf88c1@promidius> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYalSW+XcwgGE7hQ+KAxHIDXXy14Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [NSIS] Handshake 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="===============1186144404==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1186144404== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01C61A95.26338E00" This is a multi-part message in MIME format. ------=_NextPart_000_00A4_01C61A95.26338E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have a last minute dough about the usage of the handshake (query and response messages) when a NSLP requests GIST to send a message with no security and no reliability (UDP case). =20 I see in here two approaches: =20 1) Because we don=92t want reliability and security the message is sent = in a data message and no handshake is needed. (in the receiver GIST the NSLP payload is directly sent to the NSLP and no states are stored) =20 2) Before sending the NSLP payload the handshake must be done (query and response messages) and only after the data massage can be sent. In this = case all data messages received that don=92t have any MRS state will result = in a =93No Routing State=94 error message. =20 Best regards, Lu=EDs Cordeiro =20 ------=_NextPart_000_00A4_01C61A95.26338E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have a last minute dough about the usage of = the handshake (query and response messages) when a NSLP requests GIST to send a = message with no security and no reliability (UDP case).

 

I see in here two = approaches:

 

1) Because we don’t want reliability and = security the message is sent in a data message and no handshake is needed. (in = the receiver GIST the NSLP payload is directly sent to the NSLP and no = states are stored)

 

2) Before sending the NSLP payload the = handshake must be done (query and response messages) and only after the data massage = can be sent. In this case all data messages received that don’t have any = MRS state will result in a “No Routing State” error = message.

 

Best regards,

Lu=EDs Cordeiro

 

------=_NextPart_000_00A4_01C61A95.26338E00-- --===============1186144404== 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 --===============1186144404==-- From nsis-bounces@ietf.org Tue Jan 17 13:21:35 2006 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 1EyvSY-00053y-TR; Tue, 17 Jan 2006 13:21:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvSX-00053G-6L; Tue, 17 Jan 2006 13:21:33 -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 NAA06508; Tue, 17 Jan 2006 13:20:08 -0500 (EST) 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 1EyvaZ-0001T6-JM; Tue, 17 Jan 2006 13:30:00 -0500 Received: from smtp-2.ci.uc.pt (localhost [127.0.0.1]) by smtp-2-relay.ci.uc.pt (Postfix) with ESMTP id 1ABFA19276C; Tue, 17 Jan 2006 18:20:56 +0000 (WET) Received: from teste-d.ci.uc.pt (sendmail.uc.pt [193.136.200.162]) by smtp-2.ci.uc.pt (Postfix) with ESMTP id E9CEE2FD00A; Tue, 17 Jan 2006 18:20:55 +0000 (WET) Received: from promidius (unknown [193.136.207.120]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by teste-d.ci.uc.pt (Postfix) with ESMTP id 595C94A8124; Tue, 17 Jan 2006 18:20:54 +0000 (WET) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: , Date: Tue, 17 Jan 2006 18:21:05 -0000 Message-ID: <006201c61b92$c903c340$78cf88c1@promidius> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYbksee5EruNNynQdOvdib9IPO0kA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Subject: [NSIS] NSIS interoperability 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="===============1598451448==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1598451448== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C61B92.C903C340" This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C61B92.C903C340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 The deadline for registration to the NSIS interoperability meeting in Coimbra ended and only three different implementations registered = (besides the UoC team). =20 I discussed with the registered teams and we agreed in trying to have interoperability tests remotely through the Internet.=20 =20 Therefore there will be no NSIS interoperability meeting in the 30 and = 31 of January. =20 Best regards, Lu=EDs Cordeiro =20 ------=_NextPart_000_0063_01C61B92.C903C340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The deadline for registration to the NSIS interoperability meeting in Coimbra ended and only three different implementations registered (besides the = UoC team).

 

I discussed with the registered teams and we = agreed in trying to have interoperability tests remotely through the Internet. =

 

Therefore there will be no NSIS = interoperability meeting in the 30 and 31 of January.

 

Best regards,

Lu=EDs = Cordeiro

 

------=_NextPart_000_0063_01C61B92.C903C340-- --===============1598451448== 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 --===============1598451448==-- From nsis-bounces@ietf.org Tue Jan 17 14:12:29 2006 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 1EywFp-000839-2z; Tue, 17 Jan 2006 14:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EywFn-000833-Mp for nsis@megatron.ietf.org; Tue, 17 Jan 2006 14:12:27 -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 OAA10365 for ; Tue, 17 Jan 2006 14:11:02 -0500 (EST) Received: from pfwhqs1.ncr.disa.mil ([209.22.99.17] helo=pfwhqs100.ncr.disa.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EywNx-0003Bc-N6 for nsis@ietf.org; Tue, 17 Jan 2006 14:20:55 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0E5208D7@emshqs1.ncr.disa.mil> From: "Nguyen, An P CIV NCS NC2" To: "'Tschofenig, Hannes'" Subject: RE: [NSIS] Diameter QoS Draft: Issue #16, #20, #22 Date: Tue, 17 Jan 2006 14:12:22 -0500 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: 8b431ad66d60be2d47c7bfeb879db82c 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 Hannes, I don't know if this is the time to raise the authentication issue of priority users. As far as QSPEC and RMD are concerned, how are resource priority headers such as ETS and WPS in document http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-10 be accomodated in this draft? Regards, An -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Sunday, January 15, 2006 4:29 PM To: robert.hancock@roke.co.uk Cc: falfano@lucent.com; mccap@lucent.com; Tseno Tsenov; nsis@ietf.org Subject: [NSIS] Diameter QoS Draft: Issue #16, #20, #22 Hi Robert, you provided feedback for the Diameter QoS application draft. We would like to close the open issues based on the draft version -05: http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt We created the following issues after your review. We updated the draft based on your feedback and reflected your comment. Two party authorization model http://www.tschofenig.priv.at:8080/diameter-qos/issue16 Suggestion:Close Gating http://www.tschofenig.priv.at:8080/diameter-qos/issue20 Suggestion:Close Session Identifier http://www.tschofenig.priv.at:8080/diameter-qos/issue22 Suggestion:Close 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 Wed Jan 18 05:16:12 2006 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 1EzAMO-0007w6-3L; Wed, 18 Jan 2006 05:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzAM0-0007ug-Jc for nsis@megatron.ietf.org; Wed, 18 Jan 2006 05:16:10 -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 FAA25171 for ; Wed, 18 Jan 2006 05:14:21 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzAUG-0002kU-Hw for nsis@ietf.org; Wed, 18 Jan 2006 05:24:23 -0500 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 k0IADX95027947; Wed, 18 Jan 2006 10:14:13 GMT Received: from [193.118.197.110] ([193.118.197.110]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 10:13:33 +0000 Message-ID: <43CE14CD.9030604@roke.co.uk> Date: Wed, 18 Jan 2006 10:13:33 +0000 From: Andrew McDonald 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-OriginalArrivalTime: 18 Jan 2006 10:13:33.0020 (UTC) FILETIME=[D63411C0:01C61C17] X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Content-Transfer-Encoding: 7bit Cc: Georgios Karagiannis , Jukka MJ Manner Subject: [NSIS] QoS NSLP: rerouting 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 all, I did a review of the rerouting aspects of the QoS NSLP, and came across some potential problems. (NB: some of these also relate to the "GIST Refresh Mechanism eventually breaks upstream pathonCrossover Router" thread). A summary of the issues is below, followed by proposed updates to the draft. - There isn't currently a mechanism for a node to tell its upstream peer that it thinks its upstream route has changed (this concept is referenced in the GIST draft, but didn't exist in the QoS NSLP). This requires an additional notification code, and some rules for propagating such a message upstream. - There is possibly an issue where the old path continues to send refreshes after a route change. Some extra text is needed to avoid oscillating between the old/new paths (i.e. need to look at SIIs), which should also ensure that it will fall back to the old path if rerouting back to the old path really does occur (e.g. fall back if continue to get refreshes after some time, though you do have to be careful about this). - Another issue is that of making sure that a TEAR down the old path doesn't go too far (and tear down reservations at nodes that should still exist because they are on the common path). The solution is that the TEAR shouldn't be sent until you've received an end-to-end ack of the RESERVE on the new path. Earlier versions of the draft also had a mechanism to do with counting backwards (RSN-1) for the TEAR to sort out problems where a route change wasn't really a route change (but, e.g., a change in the interfaces between the same two nodes). This got removed (the need for it looked like it had gone away), but I think it is still needed (though restricted to a particular use). I also came some editorial issues in the rerouting text. In my proposed updates, I've created a new section in section 5 on processing related to rerouting. This includes the changes described above, and also includes some normative text from 3.2.10 (which is meant to be an informative section). Proposed updates: ##### section 3.2.10 ##### .sh 3 "Rerouting" QoS NSLP needs to adapt to route changes in the data path. This assumes the capability to detect rerouting events, perform QoS reservation on the new path and optionally tear down reservations on the old path. Rerouting detection can be performed at three levels. First, routing modules may detect route changes through their interaction with routing protocols. Certain QNEs or GIST implementations may interact with local routing module to receive quick notification of route changes. This is largely implementation-specific and outside of the scope of NSIS. Second, route changes may be detected at the GIST layer. GIST is able to provide information on such events over the API. This is outside the scope of the QoS NSLP specification. Third, rerouting may be detected at the NSLP layer. A QoS NSLP node is able to detect changes in its QoS NSLP peers by keeping track of a Source Identification Information (SII) handle that provides information similar in nature to the RSVP_HOP object described in RFC 2205 [RFC2205]. When a RESERVE message with an existing SESSION_ID and a different SII is received, the QNE knows its upstream or downstream peer has changed, for sender- and receiver-oriented reservations, respectively. Reservation on the new path happens when a refreshing RESERVE message arrives at the QNE where the old and the new path diverge. The refreshing RESERVE will be interpreted as a new RESERVE on the new path. Depending on the transfer mode, this may require installation of a new messaging association. Rapid recovery at the NSLP layer therefore requires short refresh periods. Detection before the next RESERVE message arrives is only possible at the IP layer or through monitoring of GIST peering relations (e.g. by TTL counting the number of GIST hops between NSLP peers or the observing changes in the outgoing interface towards GIST peer). These mechanisms can provide implementation specific optimisations, and are outside the scope of this specification. When the QoS NSLP is aware of the route change, it needs to set up the reservation on the new path. This is done by incrementing the RSN and then sending a new RESERVE message. On links that are common to the old and the new path, this RESERVE message is interpreted as a refreshing RESERVE. On new links, it creates the reservation. After the reservation on the new path is set up, the branching node or the merging node may want to tear down the reservation on the old path (faster than what would result from normal soft-state time-out). This functionality is supported by keeping track of the old SII. This specification requests GIST design to provide support for an SII that is interpreted as a random identifier at the QoS NSLP but that allows, when passed over the API, to forward QoS NSLP messages to the QNE identified by that SII. A QNI or a branch node may wish to keep the reservation on the old branch. This could for instance be the case when a mobile node has experienced a mobility event and wishes to keep reservation to its old attachment point in case it moves back there. For this purpose, a REPLACE flag is foreseen in the common header, which, when set to FALSE, indicates that the reservation on the old branch should be kept. The design of the QoS-NSLP allows reservations to be installed at a subset of the nodes along a path, including cases where those nodes might not included the endpoints of the application data flow. In the case where the data flow receiver does not support the QoS-NSLP, some particular considerations must be given to node discovery and rerouting at the end of the signalling path. There are three cases for the last node on the signalling path: 1) Last node is the data receiver 2) Last node is a configured proxy for the data receiver 3) Last node is not the data receiver and is not explicitly configured to act as a signalling proxy on behalf of the data receiver. Cases (1) and (2) can be handled by the QoS-NSLP itself during the initial path setup, since the QNE knows that it should terminate the signalling. Case (3) requires some assistance from GIST which provides messages across the API to indicate that no further QoS-NSLP supporting GIST nodes are present downstream, and downstream route change probing needs to continue once the reservation is installed to detect any changes in this situation. ##### section 4.8 ##### .sh 2 "Rerouting scenario" The QoS NSLP needs to adapt to route changes in the data path. This assumes the capability to detect rerouting events, perform QoS reservation on the new path and optionally tear down reservations on the old path. When the QoS NSLP is aware of the route change, it needs to set up the reservation on the new path. This is done by incrementing the RSN and sending a RESERVE message. On links that are common to the old and the new path, this RESERVE message is interpreted as a refreshing RESERVE. On new links, it creates the reservation. After the reservation on the new path is set up, the branching node or the merging node may want to tear down the reservation on the old path (faster than what would result from normal soft-state time-out). This functionality is supported by keeping track of the old SII, as provided over the GIST API. The SII is opaque to the QoS NSLP, i.e. QoS NSLP does not make any assumptions on how this identifier is constructed. When passed over the API from the NSLP to GIST, it allows QoS NSLP to indicate that its messages should be sent to the QNE identified by that SII. In case of a receiver-initiated reservation, a QNE can detect a route change by receiving a RESERVE message with a different SII. In case of a sender-initiated reservation, the same information is learned from a RESPONSE message, or from a NOTIFY message sent by the downstream peer. A QNE that has detected the route change via the SII change sends a RESERVE message towards the QNR on the old path (using the old SII) with the TEAR flag set. Note that in case of receiver-initiated reservations, this involves a QNE that is notified of the route change in another way and wants to tear down the old branch needs to send the RESERVE on the new path with an RII object. When it receives the RESPONSE message back, it can check whether its peer has effectively changed and send a RESERVE with the TEAR flag set if it has. Otherwise, teardown is not needed. A QNE that is unable to support an RII or does not receive a RESPONSE needs to rely on soft-state timeout on the old branch. A QNI or a branch node may wish to keep the reservation on the old branch. This could for instance be the case when a mobile node has experienced a mobility event and wishes to keep reservation to its old attachment point in case it moves back there. In that case, it sets the REPLACE flag in the common header to zero. Note that keeping old reservations affects the resources available to other nodes. Thus, the operator of the access network must make the final decision on whether this behavior is allowed. Also, the QNEs in the access network may add this flag even if the mobile node has not used the flag initially. ##### section 5.2.5 (new) ##### .sh 3 "Rerouting" .sh 4 "Last node behaviour" As discussed in section 3.2.10 particular mechanisms need to be used at the QNR when it is not also the data receiver or a configured proxy for the data receiver. Two particular cases for rerouting need to be considered in this situation. In the first, referred to as "Path Extension", rerouting occurs such that an additional QNE is inserted into the signalling path between the old last node and the data receiver, as shown in Figure 4. .nf /-------\\ Initial route / v /-\\ /--|B|--\\ +-+ / \\-/ \\ |x| = QoS-NSLP aware +-+ /-\\ +-+ ----|A| |D| +-+ \\-/ /-\\ \\ +-+ / |x| = QoS-NSLP unaware \\--|C|--/ \\-/ +-+ \\ ^ \\-------/ Updated route .fi .ce Figure 4: Path Extension When rerouting occurs, the data path changes from A-B-D to A-C-D. Initially the signalling path ends at A. Despite initially being the last node, node A MUST continue to attempt to send messages downstream to probe for path changes, unless it has been explicitly configured as a signalling proxy for the data flow receiver. This is required so that the signalling path change is detected, and C will become the new last QNE. In a second case, referred to as "Path Truncation", rerouting occurs such that the QNE that was the last node on the signalling path is no longer on the data path. This is shown in Figure 5. .bp .nf /-------\\ Initial route / v +-+ /--|B|--\\ +-+ / +-+ \\ |x| = QoS-NSLP aware +-+ /-\\ +-+ ----|A| |D| +-+ \\-/ /-\\ \\ /-\\ / |x| = QoS-NSLP unaware \\--|C|--/ \\-/ \\-/ \\ ^ \\-------/ Updated route .fi .ce Figure 5: Path Truncation .fi When rerouting occurs, the data path again changes from A-B-D to A-C-D. The signalling path initially ends at C, but this node is not on the new path. In this case, the normal GIST path change detection procedures at A will detect the path change and notify the QoS-NSLP. GIST will also notify the signalling application that no downstream GIST nodes supporting the QoS-NSLP are present. Node A MUST take over as the last node on the signalling path. .sh 4 "Reservation maintenance on route change" QoS NSLP is notified by GIST when GIST believes that a rerouting event may have occurred. As part of the API, GIST provides an SII-Handle which can be used by the NSLP to direct a signalling message to a particular peer. The current SII-Handle will change if the signalling peer changes. However, it is not guaranteed to remain the same after a rerouting event where the peer does not change. Therefore, the QoS NSLP mechanism for reservation maintenance after a route change includes robustness mechanisms to avoid accidentally tearing down a reservation in situations where the peer QNE has remained the same after a 'route change' notification from GIST. When a QNE detects that its neighbour QNE in the direction of the QNR has changed, it SHOULD send a RESERVE message, including the full QSPEC. This RESERVE message MUST include an RII, to request a response from the QNR. When sending this message the RSN MUST be incremented by two (and this becomes the current RSN value). An SII MUST NOT be specified when passing this message over the API to GIST, so that it is correctly routed to the new peer QNE. When the QNE receives the RESPONSE message that relates to that the RESERVE message sent down the new path, it SHOULD send a RESERVE message with the TEAR flag sent down the old path, by specifying the SII relating to the old peer QNE. When sending this RESERVE message the RSN field MUST be set to one less than the current RSN value (and the current RSN value remains unchanged). This 'RSN-1' will cause the message to be reject by the next peer if the old and new next peers are actually the same. Depending on the particular route change, there may be a 'merge point' (or 'crossover node') where the old and new paths merge. Initially this has a reservation installed by the old peer QNE, identified by an old SII. When the new reservation is installed after the route change the new peer QNE will be identified by a new SII. At a later point the crossover node may receive a RESERVE message with the TEAR flag set from the QNE identified by the old SII. A node receiving a RESERVE message with the TEAR flag set which does not come from the current peer QNE, identified by its SII, MUST be ignored and MUST NOT be forwarded. .sh 4 "Upstream route change notification" GIST may notify QoS NSLP that a possible upstream route change has occurred over the GIST API. On receiving such a notification, QoS NSLP SHOULD send a NOTIFY message with Informational code ????? for signalling sessions associated with the identified MRI. On receiving such a NOTIFY message, QoS NSLP SHOULD use the InvalidateRoutingState API call to inform GIST that routing state may be out of date. QoS NSLP SHOULD send a NOTIFY message upstream. .sh 4 "Route change oscillation" In some circumstances a route change may occur, but the path than falls back to the original route. After a route change the routers on the old path will continue to refresh the reservation until soft state times out, or an explicit TEAR is received. After detecting an upstream route change a QNE SHOULD consider the new upstream peer as current and not fall back to the old upstream peer unless: - it stops receiving refreshes from the old upstream peer for at least the soft state timeout period - or, it stops receiving refreshes from the new upstream peer for at least the soft state timeout period GIST routing state keeps track of the latest upstream peer it has seen, and so may spuriously indicate route changes occur when the old upstream peer refreshes its routing state until the state at that node is explicitly torn down or times out. Any comments? Best regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 18 15:51:05 2006 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 1EzKGn-0004DZ-IF; Wed, 18 Jan 2006 15:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKFt-0003xG-5t; Wed, 18 Jan 2006 15:50:09 -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 PAA22378; Wed, 18 Jan 2006 15:48:41 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzKOB-0000yQ-IU; Wed, 18 Jan 2006 15:58:46 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EzKFl-0007IU-UD; Wed, 18 Jan 2006 15:50:01 -0500 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, 18 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-05.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-05.txt Pages : 66 Date : 2006-1-18 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 and preemption function 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-05.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-05.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-05.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: <2006-1-18122550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-18122550.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 Jan 23 09:51:10 2006 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 1F132E-00025Y-Tm; Mon, 23 Jan 2006 09:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F132D-000240-3z for nsis@megatron.ietf.org; Mon, 23 Jan 2006 09:51:09 -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 JAA24920 for ; Mon, 23 Jan 2006 09:49:38 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13BY-0000hD-Fj for nsis@ietf.org; Mon, 23 Jan 2006 10:00:50 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0NEoqtO002496; Mon, 23 Jan 2006 15:50:52 +0100 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 k0NEon07025382; Mon, 23 Jan 2006 15:50:52 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 15:50:49 +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: AW: [NSIS] Diameter QoS Draft: Issue #16, #20, #22 Date: Mon, 23 Jan 2006 15:50:48 +0100 Message-ID: Thread-Topic: [NSIS] Diameter QoS Draft: Issue #16, #20, #22 Thread-Index: AcYbme8i7QPUDN6CRAmLEhQJsCUxWAEjTwFg From: "Tschofenig, Hannes" To: "Nguyen, An P CIV NCS NC2" X-OriginalArrivalTime: 23 Jan 2006 14:50:49.0512 (UTC) FILETIME=[66640A80:01C6202C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 an,=20 initially i thought you would ask how we the interworking between rfc 3181 alike parameters and the diameter qos document looks like. btw, the rfc3181 parameters are also carried in the qspec as described in section 7.2.7.1. =20 but now you ask me how the interworking between the priority parameters defined in draft-ietf-sip-resource-priority-10 and the diameter qos draft looks like. in fact the parameters lists in=20 draft-ietf-sip-resource-priority are also available with the qspect as described in section 7.2.7.3.=20 some time ago we had long discussion on how the draft-ietf-sip-resource-priority-10 and the rfc 3181 parameters work together. you can find these discussions entitled with 'Questions regarding ' starting with the following posting: http://www1.ietf.org/mail-archive/web/nsis/current/msg03869.html with regard to the aaa interaction you asked for: no matter which parameters you use it seems that you need to interact with the aaa infrastructure in order to determine whether you are allowed to use these values or not. the policies at the aaa server will indicate whether the reservation request is successfull or not. ciao hannes 7.2.7.3=20 > Hannes, >=20 > I don't know if this is the time to raise the authentication issue of > priority users. As far as QSPEC and RMD are concerned, how=20 > are resource > priority headers such as ETS and WPS in document > http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-pr > iority-10 be > accomodated in this draft? >=20 > Regards, >=20 > An=20 >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Sunday, January 15, 2006 4:29 PM > To: robert.hancock@roke.co.uk > Cc: falfano@lucent.com; mccap@lucent.com; Tseno Tsenov; nsis@ietf.org > Subject: [NSIS] Diameter QoS Draft: Issue #16, #20, #22 >=20 >=20 > Hi Robert,=20 >=20 > you provided feedback for the Diameter QoS application draft. We would > like to close the open issues based on the draft version -05:=20 > http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt >=20 > We created the following issues after your review. We updated=20 > the draft > based on your feedback and reflected your comment.=20 >=20 > Two party authorization model > http://www.tschofenig.priv.at:8080/diameter-qos/issue16 >=20 > Suggestion:Close >=20 > Gating > http://www.tschofenig.priv.at:8080/diameter-qos/issue20 >=20 > Suggestion:Close >=20 > Session Identifier > http://www.tschofenig.priv.at:8080/diameter-qos/issue22 >=20 > Suggestion:Close >=20 > Ciao > Hannes >=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 Jan 24 12:00:44 2006 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 1F1RXA-00018X-6m; Tue, 24 Jan 2006 12:00:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1RX8-00018A-R5 for nsis@megatron.ietf.org; Tue, 24 Jan 2006 12:00:42 -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 LAA29925 for ; Tue, 24 Jan 2006 11:59:12 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Rgi-0002Oq-0a for nsis@ietf.org; Tue, 24 Jan 2006 12:10:37 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k0OGxdq7017666; Tue, 24 Jan 2006 16:59:42 GMT 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] Handshake Date: Tue, 24 Jan 2006 16:59:39 -0000 Message-ID: Thread-Topic: [NSIS] Handshake Thread-Index: AcYhB5J2ECzWPnNiSfSeAf+T88IuIQ== From: "Hancock, Robert" To: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 luis, basically, you are correct that there are two options that GIST could = take. which one is appropriate depends on the needs of the signalling = application that is sending the message; my feeling is that your option = (2) is the natural default (since if you strictly follow option (1) you = will not get any replies since there is no reverse routing state = installed). with this in mind, the API allows the signalling application to express = the fact that there is no need for routing state to be set up (see = section B.1) as a special case. BTW we detected that some of the discussion of the validation checks in = sections 4.3.1/2 was possibly somewhat confusing/overlapping; the = updated text proposed for version -09 is attached below. hope this helps, robert h. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4.3.1. Message Reception Messages can be received in connection or datagram mode, and in the latter case with two types of message encapsulation. Reception in connection mode is simple: incoming packets undergo the security and transport treatment associated with the messaging association, and the messaging association provides complete messages to the GIST layer for further processing. Reception in datagram mode depends on the message type. 'Normal' messages arrive UDP encapsulated and addressed directly to the receiving signaling node, at an address and port learned previously. Each datagram contains a single message which is passed to the GIST layer for further processing, just as in the connection mode case. Where GIST is sending messages to be intercepted by the appropriate peer rather than directly addressed to it (in particular, Query messages), these are UDP encapsulated with an IP router alert option. Each signaling node will therefore 'see' all such messages. The case where the NSLPID does not match a local signaling application at all is considered below in Section 4.3.4; otherwise, it is again passed up to the GIST layer for further processing. 4.3.2. Local Processing and Validation Once a message has been received, it is processed locally within the GIST layer. The GIST hop count MUST be decremented immediately the message has been received. Further processing depends on the message type and payloads carried; most of the GIST payloads are associated with state maintenance and details are covered in Section 4.4. In the case of a GIST-Query, there is an interaction with signaling application policy to determine which of two courses to follow: 1. The signaling application wishes to become a signaling peer with the Querying node. GIST MUST continue with the handshake process to set up message routing state, as described in Section 4.4.1. The application MAY provide an NSLP payload for the same NSLPID, which GIST will transfer in the GIST-Response. 2. The signaling application does not wish to set up state with the Querying node and become its peer. GIST MUST propagate the Query, similar to the case described in Section 4.3.4. No message is sent back to the Querying node. The application MAY provide an updated NSLP payload for the same NSLPID (which will be used in the Query message forwarded by GIST). This interaction with the signaling application, including the generation or update of an NSLP payload, SHOULD take place synchronously as part of the Query message processing . In terms of the GIST service interface, this can be implemented by providing appropriate return values for the primitive that is triggered when such a message is received; see Appendix B.2 for further discussion. For all other message types, the GIST payloads are processed as described in Section 4.4. The remainder of the GIST message consists of an NSLP payload, which is delivered locally to the signaling application identified by the NSLPID. The format of the payload is not constrained by GIST, and the content is not interpreted. Delivery is subject to the following validation checks: o if the message was explicitly routed (see Section 7.1.4) or is a Data message delivered without routing state (see Section 5.3.2), the payload is delivered but flagged to the receiving NSLP to indicate that routing state was not validated; o else, if there is no routing state for the MRI/SID/NSLPID the message MUST be rejected with a "No Routing State" error message (Appendix A.4.4.5); o else, if the message arrived on an association which is not associated with the MRI/NSLPID/SID combination given in the message, the message MUST be rejected with an "Incorrectly Delivered Message" error message (Appendix A.4.4.4); o else, the payload is delivered as normal. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Lu=EDs Cordeiro > Sent: 16 January 2006 12:06 > To: nsis@ietf.org > Subject: [NSIS] Handshake >=20 >=20 > Hi all, > =20 > I have a last minute dough about the usage of the handshake=20 > (query and response messages) when a NSLP requests GIST to=20 > send a message with no security and no reliability (UDP case). > =20 > I see in here two approaches: > =20 > 1) Because we don't want reliability and security the message=20 > is sent in a data message and no handshake is needed. (in the=20 > receiver GIST the NSLP payload is directly sent to the NSLP=20 > and no states are stored) > =20 > 2) Before sending the NSLP payload the handshake must be done=20 > (query and response messages) and only after the data massage=20 > can be sent. In this case all data messages received that=20 > don't have any MRS state will result in a "No Routing State"=20 > error message. > =20 > Best regards, > Lu=EDs Cordeiro > =20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 24 12:30:48 2006 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 1F1S0G-0004Of-8N; Tue, 24 Jan 2006 12:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1S0D-0004JE-O0 for nsis@megatron.ietf.org; Tue, 24 Jan 2006 12:30:46 -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 MAA02680 for ; Tue, 24 Jan 2006 12:29:14 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1S9l-0003gw-LO for nsis@ietf.org; Tue, 24 Jan 2006 12:40:39 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k0OHTpq7026689; Tue, 24 Jan 2006 17:29:52 GMT 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, 24 Jan 2006 17:29:51 -0000 Message-ID: Thread-Topic: Diameter QoS Draft: Issue #16, #20, #22 Thread-Index: AcYaC85mJCwfhNw9TCa7JEZv72INhgG/AmUA From: "Hancock, Robert" To: "Tschofenig, Hannes" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov , nsis@ietf.org Subject: [NSIS] RE: Diameter QoS Draft: Issue #16, #20, #22 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 haven't re-read the full draft, but checked the issues below. > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: 15 January 2006 21:29 > To: Hancock, Robert > Cc: mccap@lucent.com; falfano@lucent.com; Tseno Tsenov; nsis@ietf.org > Subject: Diameter QoS Draft: Issue #16, #20, #22 >=20 >=20 > Hi Robert,=20 >=20 > you provided feedback for the Diameter QoS application draft.=20 > We would like to close the open issues based on the draft=20 > version -05:=20 > http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt >=20 > We created the following issues after your review. We updated=20 > the draft based on your feedback and reflected your comment.=20 >=20 > Two party authorization model=20 > http://www.tschofenig.priv.at:8080/diameter-qos/issue16 in 3.2 the final part of the first paragraph reads: "With the 'Two party model' the QoS resource requesting entity is authenticated by the Network Element and the authorization decision is made either locally at the Network Element itself or offloaded to a trusted entity (most likely within the same administrative domain). In the former case no Diameter QoS protocol interaction is required." which i parse as "In the two party model, the requesting entity is authenticated by the NE and there are two cases former) authorization decision is made locally at the Network=20 Element itself latter) the authorization decision is offloaded to a trusted=20 entity (most likely within the same administrative domain) In the former case no Diameter QoS protocol interaction is required." So ... is the Diameter QoS protocol interaction required in the=20 *latter* case? Is it in the scope of this document? (And why the expectation that such an interaction would not cross a domain boundary?) Or is the entire scenario out of scope? >=20 > Suggestion:Close >=20 > Gating > http://www.tschofenig.priv.at:8080/diameter-qos/issue20 i think what is still needed (what i was originally confused about) is a clarification that 'disabled' really means 'packets are blocked' (if this is what you mean). the origin of my confusion is that I assumed that the document is about authorising reservations in a network environment where the default is 'best efforts', whereas the gating discussion seems to imply an environment where the default is 'blocked'. >=20 > Suggestion:Close >=20 > Session Identifier http://www.tschofenig.priv.at:8080/diameter-qos/issue22 i think i understand the proposal, but the ABNF is quite confusing. AFAICT the QoS-Auth-Resources AVP can optionally (syntactically) have a=20 Signaling-Session-ID AVP and a Flows AVP, and the Flows AVP can have a set of IND-Flows AVPs each of which can have any/all of a Flow-Id, QoS-Filter-Rule and SPI. would it be possible to structure things so that the fact that Signaling-Session-ID, Flow-ID and the combination of {QoSFilter-Rule with SPI} were alternatives? (i.e. A|B|C format)? or is it not that simple? >=20 > Suggestion:Close >=20 > Ciao > Hannes >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 24 13:36:42 2006 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 1F1T21-0006Xx-UK; Tue, 24 Jan 2006 13:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1T20-0006Xs-8t for nsis@megatron.ietf.org; Tue, 24 Jan 2006 13:36:40 -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 NAA07927 for ; Tue, 24 Jan 2006 13:35:09 -0500 (EST) From: jia@dei.uc.pt Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1TBb-0006Dx-1t for nsis@ietf.org; Tue, 24 Jan 2006 13:46:35 -0500 Received: from mail.dei.uc.pt (mail.dei.uc.pt [193.136.212.3]) by smtp.dei.uc.pt (8.13.4/8.13.4) with ESMTP id k0OIa0Lf003873; Tue, 24 Jan 2006 18:36:00 GMT 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 k0OIbM7M020844; Tue, 24 Jan 2006 18:37:22 GMT Received: (from nobody@localhost) by mail.dei.uc.pt (8.13.5/8.13.1/Submit) id k0OIbLWI020843; Tue, 24 Jan 2006 18:37:21 GMT 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 (Horde MIME library) with HTTP; Tue, 24 Jan 2006 18:37:21 +0000 Message-ID: <20060124183721.cv4y8w72g40ogkow@mail.dei.uc.pt> Date: Tue, 24 Jan 2006 18:37:21 +0000 To: "Hancock, Robert" Subject: RE: [NSIS] Handshake References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-WebMail-Company: University of Coimbra, Portugal, DEI X-Originating-IP: 193.137.203.230 X-Remote-Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) 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=-1.638, required 3, 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: 963faf56c3a5b6715f0b71b66181e01a 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, After read your reply careful, I had more doubts and want to discuss more about that with you. According to section 5.5 "Message Type/Encapsulation Relationships" of draft-ietf-nsis-ntlp-08, I don't see there is the need to have a handshake (query/response) first before sending out one NSLP data which does not request reliability and security. Section 5.5 states that the gist should use the "D-Mode Normal" encapsulation method to send a GIST-Data "if routing state exists for the flow but no appropriate messaging association" and should use the "D-Mode Query" encapsulation method to send it "if no routing state exists and the MRI can be used to derive the query encapsulation". As for Path-Coupled MRM, the MRI certainly can be used to derive the query encapsulation (i.e., the destination address of the flow), thus according to section 5.5, gist does not need to have any handshake first and can send the Gist-Data directly via the "D-Mode Query" encapsulation. Moreover, if the Gist-Data is received via interception by the downstream NSIS node, it can obtain the peer information (peer identity and peer interface) from the NLI object of the received Gist-Data message and then set up one-time upstream routing state if wanted (depending on local policy), i.e., if the NSLP has message to sent back to the upstream peer, it can send it via "D-Mode Normal" encapsulation to that peer while without the overhead cost of handshake. Then, does it mean that option (1) should be preferred? Anyway, if we decide that option (2) should be prefered, then I think the description texts about Message Type/Encapsulation Relationships in section 5.5 also need be changed accordingly like this: "if no routing state exists and no routing state needs to be established and the MRI can be used to derive the query encapsulation", then Gist-Data should be sent via the "D-Mode Query" encapsulation method. Regards, Jia Quoting "Hancock, Robert" : > hi luis, > > basically, you are correct that there are two options that GIST could > take. which one is appropriate depends on the needs of the signalling > application that is sending the message; my feeling is that your > option (2) is the natural default (since if you strictly follow > option (1) you will not get any replies since there is no reverse > routing state installed). > > with this in mind, the API allows the signalling application to > express the fact that there is no need for routing state to be set up > (see section B.1) as a special case. > > BTW we detected that some of the discussion of the validation checks > in sections 4.3.1/2 was possibly somewhat confusing/overlapping; the > updated text proposed for version -09 is attached below. > > hope this helps, > > robert h. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 4.3.1. Message Reception > > Messages can be received in connection or datagram mode, and in the > latter case with two types of message encapsulation. > > Reception in connection mode is simple: incoming packets undergo the > security and transport treatment associated with the messaging > association, and the messaging association provides complete messages > to the GIST layer for further processing. > > Reception in datagram mode depends on the message type. 'Normal' > messages arrive UDP encapsulated and addressed directly to the > receiving signaling node, at an address and port learned previously. > Each datagram contains a single message which is passed to the GIST > layer for further processing, just as in the connection mode case. > > Where GIST is sending messages to be intercepted by the appropriate > peer rather than directly addressed to it (in particular, Query > messages), these are UDP encapsulated with an IP router alert option. > Each signaling node will therefore 'see' all such messages. The case > where the NSLPID does not match a local signaling application at all > is considered below in Section 4.3.4; otherwise, it is again passed > up to the GIST layer for further processing. > > 4.3.2. Local Processing and Validation > > Once a message has been received, it is processed locally within the > GIST layer. The GIST hop count MUST be decremented immediately the > message has been received. Further processing depends on the message > type and payloads carried; most of the GIST payloads are associated > with state maintenance and details are covered in Section 4.4. > > In the case of a GIST-Query, there is an interaction with signaling > application policy to determine which of two courses to follow: > > 1. The signaling application wishes to become a signaling peer with > the Querying node. GIST MUST continue with the handshake process > to set up message routing state, as described in Section 4.4.1. > The application MAY provide an NSLP payload for the same NSLPID, > which GIST will transfer in the GIST-Response. > > 2. The signaling application does not wish to set up state with the > Querying node and become its peer. GIST MUST propagate the > Query, similar to the case described in Section 4.3.4. No > message is sent back to the Querying node. The application MAY > provide an updated NSLP payload for the same NSLPID (which will > be used in the Query message forwarded by GIST). > > This interaction with the signaling application, including the > generation or update of an NSLP payload, SHOULD take place > synchronously as part of the Query message processing . In terms of > the GIST service interface, this can be implemented by providing > appropriate return values for the primitive that is triggered when > such a message is received; see Appendix B.2 for further discussion. > > For all other message types, the GIST payloads are processed as > described in Section 4.4. The remainder of the GIST message consists > of an NSLP payload, which is delivered locally to the signaling > application identified by the NSLPID. The format of the payload is > not constrained by GIST, and the content is not interpreted. > Delivery is subject to the following validation checks: > > o if the message was explicitly routed (see Section 7.1.4) or is a > Data message delivered without routing state (see Section 5.3.2), > the payload is delivered but flagged to the receiving NSLP to > indicate that routing state was not validated; > > o else, if there is no routing state for the MRI/SID/NSLPID the > message MUST be rejected with a "No Routing State" error message > (Appendix A.4.4.5); > > o else, if the message arrived on an association which is not > associated with the MRI/NSLPID/SID combination given in the > message, the message MUST be rejected with an "Incorrectly > Delivered Message" error message (Appendix A.4.4.4); > > o else, the payload is delivered as normal. > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >> Behalf Of Lu=EDs Cordeiro >> Sent: 16 January 2006 12:06 >> To: nsis@ietf.org >> Subject: [NSIS] Handshake >> >> >> Hi all, >> >> I have a last minute dough about the usage of the handshake >> (query and response messages) when a NSLP requests GIST to >> send a message with no security and no reliability (UDP case). >> >> I see in here two approaches: >> >> 1) Because we don't want reliability and security the message >> is sent in a data message and no handshake is needed. (in the >> receiver GIST the NSLP payload is directly sent to the NSLP >> and no states are stored) >> >> 2) Before sending the NSLP payload the handshake must be done >> (query and response messages) and only after the data massage >> can be sent. In this case all data messages received that >> don't have any MRS state will result in a "No Routing State" >> error message. >> >> Best regards, >> Lu=EDs Cordeiro >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 25 04:19:16 2006 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 1F1gk5-0002Xd-MM; Wed, 25 Jan 2006 04:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1gk3-0002WN-Rx for nsis@megatron.ietf.org; Wed, 25 Jan 2006 04:15:03 -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 EAA23029 for ; Wed, 25 Jan 2006 04:13:31 -0500 (EST) 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 1F1gtl-0008WD-D9 for nsis@ietf.org; Wed, 25 Jan 2006 04:25:06 -0500 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; Wed, 25 Jan 2006 11:14:55 +0200 id 000702DB.43D7418F.00002B9D Date: Wed, 25 Jan 2006 11:14:45 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [NSIS] Yet a new diff of the 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, especially Roland, Markus and Jian, I've made a new diff of the QoS NSLP. It includes as many updates I could figure clearly out from all your emails. In addition, Andrew sent new and updated text to discuss the issues and effects of mobility - this should answer some of your earlier comments in various emails. http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html If I have missed some of your comments, please let me know (again). Otherwise, I'll submit this version to the I-D Admin and we'll start a WGLC soon. Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 25 06:27:36 2006 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 1F1ioJ-0002U3-UO; Wed, 25 Jan 2006 06:27:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ioI-0002SZ-A1 for nsis@megatron.ietf.org; Wed, 25 Jan 2006 06:27:34 -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 GAA02434 for ; Wed, 25 Jan 2006 06:26:03 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1iy2-0004dY-0S for nsis@ietf.org; Wed, 25 Jan 2006 06:37:38 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k0PBQsq7023569; Wed, 25 Jan 2006 11:26:55 GMT 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] Handshake Date: Wed, 25 Jan 2006 11:26:54 -0000 Message-ID: Thread-Topic: [NSIS] Handshake Thread-Index: AcYhFS+JVrLSJxIfTFmHzJNLPJWnewAiE4tw 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: a4cdc653ecdd96665f2aa1c1af034c9e 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, please see in-line. > -----Original Message----- > From: jia@dei.uc.pt [mailto:jia@dei.uc.pt]=20 > Sent: 24 January 2006 18:37 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] Handshake >=20 >=20 > Hi, Robert, >=20 > After read your reply careful, I had more doubts and want to discuss=20 > more about that with you. >=20 > According to section 5.5 "Message Type/Encapsulation=20 > Relationships" of=20 > draft-ietf-nsis-ntlp-08, I don't see there is the need to have a=20 > handshake (query/response) first before sending out one NSLP=20 > data which=20 > does not request reliability and security. Section 5.5 states=20 > that the=20 > gist should=20 ^^^^^^ this is a misinterpretation of the table. section 5.5 says what is *possible*; it does not say what GIST SHOULD or MUST do.=20 elsewhere in the specification (e.g. 6.1) it is stated that routing state should be created unless the signalling application says otherwise. > use the "D-Mode Normal" encapsulation method to send a=20 > GIST-Data "if routing state exists for the flow but no appropriate=20 > messaging association" and should use the "D-Mode Query"=20 > encapsulation=20 > method to send it "if no routing state exists and the MRI can be used=20 > to derive the query encapsulation". As for Path-Coupled MRM, the MRI=20 > certainly can be used to derive the query encapsulation (i.e., the=20 > destination address of the flow), thus according to section 5.5, gist=20 > does not need to have any handshake first and can send the Gist-Data=20 > directly via the "D-Mode Query" encapsulation. but note that the message will be delivered at the far end flagged as=20 coming from a source which has gone through no type of validation of routing correctness (see B.2). so the signalling application may choose to disregard it etc. =20 >=20 > Moreover, if the Gist-Data is received via interception by the=20 > downstream NSIS node, it can obtain the peer information=20 > (peer identity=20 > and peer interface) from the NLI object of the received Gist-Data=20 > message and then set up one-time upstream routing state if wanted=20 > (depending on local policy), i.e., if the NSLP has message to=20 > sent back=20 > to the upstream peer, it can send it via "D-Mode Normal"=20 > encapsulation=20 > to that peer while without the overhead cost of handshake. Then, does=20 > it mean that option (1) should be preferred? no: although it is logically possible to infer upstream routing state from a single message, the specification basically does not allow this because of the vulnerabilities it opens to spoofing attacks, which can affect both the node receiving the message and the node receiving the reply. the only exception is for error messages (which are a special case, since error messages never lead directly to further messages or state creation and can always be ignored). >=20 > Anyway, if we decide that option (2) should be prefered, then I think=20 > the description texts about Message Type/Encapsulation=20 > Relationships in=20 > section 5.5 also need be changed accordingly like this: "if=20 > no routing=20 > state exists and no routing state needs to be established and the MRI=20 > can be used to derive the query encapsulation", then Gist-Data should=20 > be sent via the "D-Mode Query" encapsulation method. i have added some text to 5.5 stating that the rest of the specification is authoritative for working out when routing/MA state should be = created. cheers, robert h. >=20 > Regards, >=20 > Jia >=20 > Quoting "Hancock, Robert" : >=20 > > hi luis, > > > > basically, you are correct that there are two options that=20 > GIST could > > take. which one is appropriate depends on the needs of the=20 > signalling=20 > > application that is sending the message; my feeling is that your=20 > > option (2) is the natural default (since if you strictly follow=20 > > option (1) you will not get any replies since there is no reverse=20 > > routing state installed). > > > > with this in mind, the API allows the signalling application to > > express the fact that there is no need for routing state to=20 > be set up=20 > > (see section B.1) as a special case. > > > > BTW we detected that some of the discussion of the validation checks > > in sections 4.3.1/2 was possibly somewhat=20 > confusing/overlapping; the=20 > > updated text proposed for version -09 is attached below. > > > > hope this helps, > > > > robert h. > > > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 4.3.1. Message Reception > > > > Messages can be received in connection or datagram mode,=20 > and in the > > latter case with two types of message encapsulation. > > > > Reception in connection mode is simple: incoming packets=20 > undergo the > > security and transport treatment associated with the messaging > > association, and the messaging association provides=20 > complete messages > > to the GIST layer for further processing. > > > > Reception in datagram mode depends on the message type. 'Normal' > > messages arrive UDP encapsulated and addressed directly to the > > receiving signaling node, at an address and port learned=20 > previously. > > Each datagram contains a single message which is passed=20 > to the GIST > > layer for further processing, just as in the connection mode case. > > > > Where GIST is sending messages to be intercepted by the=20 > appropriate > > peer rather than directly addressed to it (in particular, Query > > messages), these are UDP encapsulated with an IP router=20 > alert option. > > Each signaling node will therefore 'see' all such=20 > messages. The case > > where the NSLPID does not match a local signaling=20 > application at all > > is considered below in Section 4.3.4; otherwise, it is=20 > again passed > > up to the GIST layer for further processing. > > > > 4.3.2. Local Processing and Validation > > > > Once a message has been received, it is processed locally=20 > within the > > GIST layer. The GIST hop count MUST be decremented=20 > immediately the > > message has been received. Further processing depends on=20 > the message > > type and payloads carried; most of the GIST payloads are=20 > associated > > with state maintenance and details are covered in Section 4.4. > > > > In the case of a GIST-Query, there is an interaction with=20 > signaling > > application policy to determine which of two courses to follow: > > > > 1. The signaling application wishes to become a=20 > signaling peer with > > the Querying node. GIST MUST continue with the=20 > handshake process > > to set up message routing state, as described in=20 > Section 4.4.1. > > The application MAY provide an NSLP payload for the=20 > same NSLPID, > > which GIST will transfer in the GIST-Response. > > > > 2. The signaling application does not wish to set up=20 > state with the > > Querying node and become its peer. GIST MUST propagate the > > Query, similar to the case described in Section 4.3.4. No > > message is sent back to the Querying node. The=20 > application MAY > > provide an updated NSLP payload for the same NSLPID=20 > (which will > > be used in the Query message forwarded by GIST). > > > > This interaction with the signaling application, including the > > generation or update of an NSLP payload, SHOULD take place > > synchronously as part of the Query message processing . =20 > In terms of > > the GIST service interface, this can be implemented by providing > > appropriate return values for the primitive that is triggered when > > such a message is received; see Appendix B.2 for further=20 > discussion. > > > > For all other message types, the GIST payloads are processed as > > described in Section 4.4. The remainder of the GIST=20 > message consists > > of an NSLP payload, which is delivered locally to the signaling > > application identified by the NSLPID. The format of the=20 > payload is > > not constrained by GIST, and the content is not interpreted. > > Delivery is subject to the following validation checks: > > > > o if the message was explicitly routed (see Section=20 > 7.1.4) or is a > > Data message delivered without routing state (see=20 > Section 5.3.2), > > the payload is delivered but flagged to the receiving NSLP to > > indicate that routing state was not validated; > > > > o else, if there is no routing state for the MRI/SID/NSLPID the > > message MUST be rejected with a "No Routing State"=20 > error message > > (Appendix A.4.4.5); > > > > o else, if the message arrived on an association which is not > > associated with the MRI/NSLPID/SID combination given in the > > message, the message MUST be rejected with an "Incorrectly > > Delivered Message" error message (Appendix A.4.4.4); > > > > o else, the payload is delivered as normal. > > > >> -----Original Message----- > >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > On Behalf=20 > >> Of Lu=EDs Cordeiro > >> Sent: 16 January 2006 12:06 > >> To: nsis@ietf.org > >> Subject: [NSIS] Handshake > >> > >> > >> Hi all, > >> > >> I have a last minute dough about the usage of the handshake (query=20 > >> and response messages) when a NSLP requests GIST to send a message=20 > >> with no security and no reliability (UDP case). > >> > >> I see in here two approaches: > >> > >> 1) Because we don't want reliability and security the=20 > message is sent=20 > >> in a data message and no handshake is needed. (in the=20 > receiver GIST=20 > >> the NSLP payload is directly sent to the NSLP and no states are=20 > >> stored) > >> > >> 2) Before sending the NSLP payload the handshake must be=20 > done (query=20 > >> and response messages) and only after the data massage can=20 > be sent.=20 > >> In this case all data messages received that don't have=20 > any MRS state=20 > >> will result in a "No Routing State" error message. > >> > >> Best regards, > >> Lu=EDs Cordeiro > >> > >> > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 >=20 >=20 > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 25 07:10:00 2006 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 1F1jTL-0007zP-6a; Wed, 25 Jan 2006 07:09:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1hdv-0003Ss-OM for nsis@megatron.ietf.org; Wed, 25 Jan 2006 05:12:47 -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 FAA27978 for ; Wed, 25 Jan 2006 05:11:15 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1hnf-0002LB-0g for nsis@ietf.org; Wed, 25 Jan 2006 05:22:51 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0PACbf4021170; Wed, 25 Jan 2006 04:12:39 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Jan 2006 11:12:35 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550922C9A9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: dime@ietf.org Date: Wed, 25 Jan 2006 11:12:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-Mailman-Approved-At: Wed, 25 Jan 2006 07:09:57 -0500 Cc: Subject: [NSIS] Repeat: Looking for candidates for (co-)chairing the (new) DIME W G 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 [bcc: aaa-doctors, nsis WG, radiusext] Sofar, the number of reactions/nominations has been minimal. So do we not have people who are willing to work hard and chair this WG-to-be? Besides, I have not seen much discussion on the DIME WG mailing list lately. Is there no interest to discuss the 5 internet-drafts listed in the DIME WG charter? Does this all mean that there is no real support/willingness-to-work on this after all? It is easy to withdraw the WG at this stage. And non-activity or non-reaction to the poll for WG chairs is (for me) a good reason to cancel before we start. Bert -----Original Message----- From: owner-aaa-doctors@ops.ietf.org [mailto:owner-aaa-doctors@ops.ietf.org]On Behalf Of Wijnen, Bert (Bert) Sent: Monday, January 16, 2006 12:04 To: Aaa-Wg (E-mail); dime@ietf.org; nsis@ietf.org Cc: David Kessens (E-mail) Subject: Looking for candidates for (co-)chairing the (new) DIME WG [posted to AAA, DIME and NSIS mailing lists since we expect that those mailing lists have the most relevant participants.] All, The new DIME WG (see charter at the bottom) has been approved by the IESG. The actual instantiation of the WG is pending the appointment of WG chair(s). The ADs have decided to write down a brief profile for the WG chair(s). We would like you to consider this profile and either nominate yourself or other people that you think that would fit well in this role by sending mail to the OPS ADs. ( and ). We do not intend to disclose the names of the nominees in public, but we will probably sollicit for feedback with various other people. If you have a problem with your name being mentioned in this context, pls let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent, so don't hesitate to nominate somebody who in your opinion would fit this role quite well but doesn't fit this profile 100%. And the intend is to select two co-chairs that can complement each other and work together. As for the profile: - Good management and process skills, including but not limited to choosing and supervising editors, commitment and followthrough on the charter, active management of the working group discussions, and handling IETF process steps in prompt fashion. - Good basic knowledge of the AAA protocols. That not only includes Diameter, but also Radius. - Understanding of the requirements/needs/applications of AAA protocols. Specifically, understanding the needs of other organizations (like 3GPP) is a useful asset. - Operational background/experience is very desirable. - Enough available time. For example, preferable not more than one other working chair role in IETF. - There is no requirement that the candidate has been an IETF working group chair before, but it helps if there is some evidence that the candidate can fullfill such a role (eg. other management role in other places than IETF etc.) We would like to receive your comments & nominations by Jan 30th 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your nomination mail how you or the nominated candidate fits this profile as best as possible. And last but not least, we would like to thank John Loughney for leading/guiding the work to develop the DIME WG charter. He also started a new mailing list: dime@ietf.org David Kessens & Bert Wijnen +++ Diameter Maintenance and Extensions (dime) =========================================== Current Status: Proposed Working Group WG Chair(s): TBD Operations and Management Area Director(s): Bert Wijnen David Kessens Operations and Management Area Advisor: Bert Wijnen Description of Working Group: The Diameter Maintanence and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. There is on-going work on defining RADIUS extensions. The work done in the DiME WG will ensure that work done in RADext is also available for Diameter. The immediate goals of the DiME working group are to address the following issues: - Maintaining and/or progressing, along the standards track, the Diameter procotol and Diameter Applications. Every revised document to be "maintained" requires explicit approval before it will be accepted as a WG document. - An informational RFC on a Diameter API. - Diameter Application design guidelines. This document will provide guidelines for design of new Diameter Applications. It will detail when to consider reusing an existing application and when to develop a new application. Interaction between vendor & SDO specific extensions and applications will be covered. - Diameter QoS application. This document will develop a new Diameter application for supporting QoS in AAA deployments. The NSIS WG will be consulted on proper design of QoS attributes. - Diameter URI. RFC 3588 defines an AAA URI which has some know problems. A document revising the AAA URI as a specific Diameter URI will be developed. - Diameter extensions for MIPv6. This may include support for Mobile IP extensions, like FMIP; as well as support for MIP bootstrapping. Additionally, AAA systems require interoperability in order to work. Uncontrolled extensibility is not a mechanism for interoperability. Therefore, the working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Drafts http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-04.txt http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-03.txt http://tools.ietf.org/wg/aaa/draft-ietf-aaa-uri/draft-ietf-aaa-uri-01.txt http://www.tschofenig.priv.at/drafts/draft-tschofenig-mip6-aaa-ha-diameter-00.txt http://www.watersprings.org/pub/id/draft-le-aaa-diameter-mobileipv6-04.txt Milestones Mar 06 Submit Diameter API to IESG as an information RFC. May 06 Submit Diameter URI to IESG as an information RFC. Sep 06 Submit Diameter QoS Application to IESG as a Proposed Standard. Sep 06 Submit Diameter Application Design Guidelines to IESG as an informational RFC. Jan 07 Submit Diameter Base to IESG as a Draft Standard _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jan 25 07:10:01 2006 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 1F1jTM-00080T-VR; Wed, 25 Jan 2006 07:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1j4m-0007yT-KK; Wed, 25 Jan 2006 06:44:36 -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 GAA03469; Wed, 25 Jan 2006 06:43:06 -0500 (EST) 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 1F1jEU-0005Bj-Bj; Wed, 25 Jan 2006 06:54:40 -0500 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 k0PBiSiT024665; Wed, 25 Jan 2006 13:44:28 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jan 2006 13:44:25 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jan 2006 13:44:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Diameter QoS Draft: Issue #16, #20, #22 Date: Wed, 25 Jan 2006 13:44:24 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D019AB352@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] RE: Diameter QoS Draft: Issue #16, #20, #22 Thread-Index: AcYaC85mJCwfhNw9TCa7JEZv72INhgG/AmUAACcmacA= To: , X-OriginalArrivalTime: 25 Jan 2006 11:44:25.0573 (UTC) FILETIME=[B111E150:01C621A4] X-Spam-Score: 0.4 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Jan 2006 07:09:57 -0500 Cc: falfano@lucent.com, mccap@lucent.com, dime@ietf.org, tseno.tsenov@gmail.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, Its fine to discuss some QoS issues for this draft, but since this is a potential work item for the DiME (Diameter Maintanence and Extentions) Working Group, perhaps it would be good to have some discussions there. DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime=20 thanks, John PS - I BCC:ed the NSIS mailing list, to avoid cross-posted replies. >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 >Behalf Of ext Hancock, Robert >Sent: 24 January, 2006 19:30 >To: Tschofenig, Hannes >Cc: falfano@lucent.com; mccap@lucent.com; Tseno Tsenov; nsis@ietf.org >Subject: [NSIS] RE: Diameter QoS Draft: Issue #16, #20, #22 > >hi all, > >i haven't re-read the full draft, but checked the issues below. > >> -----Original Message----- >> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >> Sent: 15 January 2006 21:29 >> To: Hancock, Robert >> Cc: mccap@lucent.com; falfano@lucent.com; Tseno Tsenov; nsis@ietf.org >> Subject: Diameter QoS Draft: Issue #16, #20, #22 >>=20 >>=20 >> Hi Robert, >>=20 >> you provided feedback for the Diameter QoS application draft.=20 >> We would like to close the open issues based on the draft=20 >version -05: >> http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt >>=20 >> We created the following issues after your review. We updated the=20 >> draft based on your feedback and reflected your comment. >>=20 >> Two party authorization model >> http://www.tschofenig.priv.at:8080/diameter-qos/issue16 > >in 3.2 the final part of the first paragraph reads: > "With the 'Two party model' the QoS resource requesting > entity is authenticated by the Network Element and the authorization > decision is made either locally at the Network Element itself or > offloaded to a trusted entity (most likely within the same > administrative domain). In the former case no Diameter QoS protocol > interaction is required." > >which i parse as > >"In the two party model, the requesting entity is=20 >authenticated by the NE and there are two cases >former) authorization decision is made locally at the Network=20 > Element itself >latter) the authorization decision is offloaded to a trusted=20 > entity (most likely within the same administrative=20 >domain) In the former case no Diameter QoS protocol=20 >interaction is required." > >So ... is the Diameter QoS protocol interaction required in the >*latter* case? Is it in the scope of this document? (And why=20 >the expectation that such an interaction would not cross a domain >boundary?) Or is the entire scenario out of scope? > >>=20 >> Suggestion:Close >>=20 >> Gating >> http://www.tschofenig.priv.at:8080/diameter-qos/issue20 > >i think what is still needed (what i was originally confused >about) is a clarification that 'disabled' really means=20 >'packets are blocked' (if this is what you mean). the origin=20 >of my confusion is that I assumed that the document is about=20 >authorising reservations in a network environment where the=20 >default is 'best efforts', whereas the gating discussion seems=20 >to imply an environment where the default is 'blocked'. > >>=20 >> Suggestion:Close >>=20 >> Session Identifier=20 >http://www.tschofenig.priv.at:8080/diameter-qos/issue22 > >i think i understand the proposal, but the ABNF is quite confusing. >AFAICT the QoS-Auth-Resources AVP can optionally=20 >(syntactically) have a Signaling-Session-ID AVP and a Flows=20 >AVP, and the Flows AVP can have a set of IND-Flows AVPs each=20 >of which can have any/all of a Flow-Id, QoS-Filter-Rule and=20 >SPI. would it be possible to structure things so that the fact=20 >that Signaling-Session-ID, Flow-ID and the combination of=20 >{QoSFilter-Rule with SPI} were alternatives? (i.e. A|B|C format)? >or is it not that simple? > >>=20 >> Suggestion:Close >>=20 >> Ciao >> Hannes >>=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 Tue Jan 31 03:17:50 2006 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 1F3qhx-00086o-SB; Tue, 31 Jan 2006 03:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3qhv-00085U-8T for nsis@megatron.ietf.org; Tue, 31 Jan 2006 03:17:47 -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 DAA24076 for ; Tue, 31 Jan 2006 03:16:01 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3qsh-0001ST-Mg for nsis@ietf.org; Tue, 31 Jan 2006 03:28:56 -0500 Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 90E5C23968 for ; Tue, 31 Jan 2006 09:17:20 +0100 (CET) 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, 31 Jan 2006 09:17:20 +0100 Mime-Version: 1.0 (Apple Message framework v746.2) To: nsis Message-Id: <9B1621AC-8611-4A61-81A6-BFF56482F8DF@netlab.nec.de> From: Martin Stiemerling Date: Tue, 31 Jan 2006 09:17:16 +0100 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 31 Jan 2006 08:17:20.0518 (UTC) FILETIME=[C1A37260:01C6263E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [NSIS] 3GPP2 and NSIS' 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: , Content-Type: multipart/mixed; boundary="===============1615671673==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1615671673== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-37--673036625; protocol="application/pkcs7-signature" --Apple-Mail-37--673036625 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear all, You still remember the draft "Requirements for Firewall Configuration Protocol" (draft-bajko-nsis-FW-reqs-04.txt) on 3GPP2's requirements wrt the NATFW NSLP. 3GPP2 is calling this protocol NFCCP (Network Firewall Configuration and Control Protocol). Based on this draft and further discussions between 3GPP2 members (mainly Gabor) and the NATFW NSLP authors, the NSIS WG has been invited by the 3GPP2 TSG-X WG 31 (PSN, packet switched networks) to present the NATFW NSLP protocol. This 3GPP2 WG is looking for firewall signaling protocol, running mainly between the mobile terminal and the 3GPP2 network firewalls. The NATFW NSLP authors and John have prepared a slide set and finally John has presented the slides at the last 3GPP2 meeting in Vancouver (Jan 17th). There has been second proposal for the NFCCP by Qualcom (http://www.ietf.org/internet-drafts/draft-paddon-pfcp-00.txt) which is client/server based. The WG had to decided whether is goes for a client/server or path-coupled approach. The presentation worked out fine and almost all questions by 3GPP2 have been answered. The WG is in favour of the path-coupled NSIS approach, i.e., the NSIS NATFW NSLP will be the NFCCP. Only some open issues remained in the end (see below for a list of them). The slide set is available here: http://www.stiemerling.org/ietf/nsis/ 3gpp2/3gpp2_nsis_natfw_overview_final.ppt The open issues to clarify are: 1) port range parameter field 2) ICMP support 3) Query method for firewall capabilities 4) Mobile IPv6 support (later, probably in draft 10) 5) Wildcarding, i.e., one shot signaling message to teardown a whole set of policy rules belonging to a specific IP address 6) Roaming All issues are currently being discussed and will be posted issue by issue to the mailing list soon. Issue 6 is subject to further discussions with 3GPP2, since the exact technical background is not yet fully understood by the NATFW authors. Issue 1) has been discussed at the last IETF meeting and has been agreed to include this feature. Issue 2) will have a separated email thread With best regards, Martin Stiemerling NEC Europe Ltd. -- Network Laboratories stiemerling@netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg WWW: http://www.netlab.nec.de --Apple-Mail-37--673036625 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDEzMTA4MTcxN1owIwYJKoZIhvcNAQkEMRYEFMJNtncwqclOvuomcmmM kUTG48CVMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBADyZtuCL2PW2+3anaxxa QX0/Zcx4ndBoYKXzkEOgQ9JGxHkzt3jVB3Umw/igmS1iAzQ46AO6ldL2kTak8UV2F/ztnrfq85gI 11MsiXKcZyQQKUm855Zt7FO9GroJ+sJMn7T+bOK0myKsyDzx2FC5xzjB+wQgGIXkdTxmwHyKZAec pgx7MgBHZ9PsMOOA9TJhU5sYvXdnUACW4ykVykJYRTSppQ2w4VO6lG6Z7AZYv+RPqvLZ0WvgRC89 FINzknut1k9umP991/yM0tMet9CxoRmEShxMFgg4FlStj2Vo/3nBcJGVcuI1Uuu7z9oJvj7R8Sgn 9Qul54fnMmuvdUV0F0oAAAAAAAA= --Apple-Mail-37--673036625-- --===============1615671673== 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 --===============1615671673==-- From nsis-bounces@ietf.org Tue Jan 31 04:22:40 2006 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 1F3rih-000863-Mw; Tue, 31 Jan 2006 04:22:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rig-00083g-3t; Tue, 31 Jan 2006 04:22:38 -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 EAA28184; Tue, 31 Jan 2006 04:20:54 -0500 (EST) 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 1F3rtT-0003WU-To; Tue, 31 Jan 2006 04:33:49 -0500 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 k0V9HPaq024256; Tue, 31 Jan 2006 11:17:25 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 11:22:18 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 11:22:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jan 2006 11:22:16 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D019AC0C6@esebe100.NOE.Nokia.com> Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA Thread-Index: AcYi/6AMDxDEqhsjSJGvbaIAr/D0NgDSCjCg To: , X-OriginalArrivalTime: 31 Jan 2006 09:22:17.0794 (UTC) FILETIME=[D4989220:01C62647] X-Spam-Score: 0.4 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Subject: [NSIS] FW: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA 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 >There are two (2) Internet-Draft cutoff dates for the 65th=20 >IETF Meeting in Dallas, TX, USA: > >February 27th: Cutoff Date for Initial (i.e., version -00)=20 >Internet-Draft Submissions=20 > >All initial Internet-Drafts (version -00) must be submitted by=20 >Monday, February 27th at 9:00 AM ET. As always, all initial=20 >submissions with a filename beginning with "draft-ietf" must=20 >be approved by the appropriate WG Chair before they can be=20 >processed or announced. The Secretariat would appreciate=20 >receiving WG Chair approval by Monday, February 20th at 9:00 AM ET. > >March 6th: Cutoff Date for Revised (i.e., version -01 and=20 >higher) Internet-Draft Submissions=20 > >All revised Internet-Drafts (version -01 and higher) must be=20 >submitted by Monday, March 6th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their=20 >respective cutoff dates will not be made available in the=20 >Internet-Drafts directory or announced until on or after=20 >Monday, March 20th at 9:00 AM ET, when Internet-Draft posting=20 >resumes. Please do not wait until the last minute to submit. > >Thank you for your understanding and cooperation. If you have=20 >any questions or concerns, then please send a message to=20 >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other=20 >significant dates for the 65th IETF Meeting can be found at=20 >http://www.ietf.org/meetings/cutoff_dates_65.html. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 31 05:22:02 2006 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 1F3seA-0004fa-NT; Tue, 31 Jan 2006 05:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3se6-0004cY-UA for nsis@megatron.ietf.org; Tue, 31 Jan 2006 05:22:01 -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 FAA02374 for ; Tue, 31 Jan 2006 05:20:14 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3sos-0005Qg-Rz for nsis@ietf.org; Tue, 31 Jan 2006 05:33:08 -0500 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 k0VALUQs020874; Tue, 31 Jan 2006 11:21:30 +0100 (MET) Message-ID: <00c101c62650$1b0af560$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Ash, Gerald R \(Jerry\), ALABS" , , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= Date: Tue, 31 Jan 2006 11:21:26 +0100 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.514 () 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, 31 Jan 2006 11:21:31 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: "Nsis \(E-mail\)" Subject: [NSIS] QSPEC - admission priority parameter 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 Hello Jerry, Attila and Cornelia In section 7.2.7.2 of the QSPEC template draft you mention that the Admission Priority parameter should have only three priorities, see below: Admission Priority: 0 - high priority flow 1 - normal priority flow 2 - best-effort priority flow Why is that? Three admission priorities are not enough! Suppose that we would like to map the 6 priorities required by Defense Red Switched Network (DRSN) ([SIP-PRIORITY]) into the admission priority parameter. Then this will not be possible! My proposal will be to allow the specification of a higher number of admission priorities! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 31 05:38:58 2006 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 1F3suY-0001eE-8u; Tue, 31 Jan 2006 05:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3suW-0001dK-Cb for nsis@megatron.ietf.org; Tue, 31 Jan 2006 05:38:56 -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 FAA03432 for ; Tue, 31 Jan 2006 05:37:11 -0500 (EST) Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3t5G-0005ti-6L for nsis@ietf.org; Tue, 31 Jan 2006 05:50:05 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-124.messagelabs.com!1138703893!6568504!4 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25898 invoked from network); 31 Jan 2006 10:38:31 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-124.messagelabs.com with SMTP; 31 Jan 2006 10:38:31 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 43D3BB520011544F; Tue, 31 Jan 2006 05:38:29 -0500 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: Tue, 31 Jan 2006 04:38:28 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9A18@KCCLUST06EVS1.ugd.att.com> Thread-Topic: QSPEC - admission priority parameter Thread-Index: AcYmUCELeuXZXGK8TK6iCRxW+QcYSQAAYFow From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Nsis \(E-mail\)" , cornelia.kappler@siemens.com Subject: [NSIS] RE: QSPEC - admission priority parameter 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, > In section 7.2.7.2 of the QSPEC template > draft you mention that the Admission Priority parameter > should have only three priorities, see below: >=20 > Admission Priority: >=20 > 0 - high priority flow > 1 - normal priority flow > 2 - best-effort priority flow >=20 > Why is that? >=20 > Three admission priorities are not enough! > Suppose that we would like to map the > 6 priorities required by Defense Red Switched Network (DRSN)=20 > ([SIP-PRIORITY]) into > the admission priority parameter. > Then this will not be possible! > My proposal will be to allow the specification of a higher > number of admission priorities! Note that Section 7.2.7.3 " Parameter" maps all of the = [SIP-PRIORITY] values into the QSPEC, including the DRSN values. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 31 06:07:23 2006 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 1F3tM3-0000c4-29; Tue, 31 Jan 2006 06:07:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tLw-0000Vx-Qs for nsis@megatron.ietf.org; Tue, 31 Jan 2006 06:07:21 -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 GAA05591 for ; Tue, 31 Jan 2006 06:05:33 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3tWl-0006pU-2K for nsis@ietf.org; Tue, 31 Jan 2006 06:18:28 -0500 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 k0VB72YC024189; Tue, 31 Jan 2006 12:07:02 +0100 (MET) Message-ID: <004101c62656$773569f0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Ash, Gerald R \(Jerry\), ALABS" References: <9473683187ADC049A855ED2DA739ABCA09FA9A18@KCCLUST06EVS1.ugd.att.com> Subject: Re: [NSIS] RE: QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 12:06:58 +0100 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.463 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, 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]); Tue, 31 Jan 2006 12:07:03 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id k0VB72YC024189 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , cornelia.kappler@siemens.com, "Nsis \(E-mail\)" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= 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 Yes I agree that the " can provide this mapping, but what I= =20 would like to have is the possibility to use more than three priorities in the Admission=20 Priority parameter. For more info, please see: http://www.watersprings.org/pub/id/draft-lefaucheur-emergency-rsvp-00.txt Best regards, Georgios ----- Original Message -----=20 From: "Ash, Gerald R (Jerry), ALABS" To: "Georgios Karagiannis" Cc: "Ash, Gerald R (Jerry), ALABS" ; "Attila B=E1der (IJ/ET= H)"=20 ; "Nsis (E-mail)" ;=20 Sent: Tuesday, January 31, 2006 11:38 AM Subject: [NSIS] RE: QSPEC - admission priority parameter > Hi Georgios, > >> In section 7.2.7.2 of the QSPEC template >> draft you mention that the Admission Priority parameter >> should have only three priorities, see below: >> >> Admission Priority: >> >> 0 - high priority flow >> 1 - normal priority flow >> 2 - best-effort priority flow >> >> Why is that? >> >> Three admission priorities are not enough! >> Suppose that we would like to map the >> 6 priorities required by Defense Red Switched Network (DRSN) >> ([SIP-PRIORITY]) into >> the admission priority parameter. >> Then this will not be possible! >> My proposal will be to allow the specification of a higher >> number of admission priorities! > > Note that Section 7.2.7.3 " Parameter" maps all of the=20 > [SIP-PRIORITY] values into the QSPEC, including the DRSN values. > > Thanks, > Jerry > > _______________________________________________ > 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 Jan 31 07:04:59 2006 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 1F3uFn-0005jo-8r; Tue, 31 Jan 2006 07:04:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3uFl-0005du-7D for nsis@megatron.ietf.org; Tue, 31 Jan 2006 07:04:57 -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 HAA09547 for ; Tue, 31 Jan 2006 07:03:21 -0500 (EST) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3uQf-0000Dv-KL for nsis@ietf.org; Tue, 31 Jan 2006 07:16:16 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1138708965!7054496!17 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 3856 invoked from network); 31 Jan 2006 12:04:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-121.messagelabs.com with SMTP; 31 Jan 2006 12:04:43 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 43D3BB5200116EDF; Tue, 31 Jan 2006 07:04:42 -0500 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] RE: QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 06:04:41 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9A19@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] RE: QSPEC - admission priority parameter Thread-Index: AcYmVn62W/3ULwbtRW6qQSoW4wnzcwABUhUg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , cornelia.kappler@siemens.com, "Nsis \(E-mail\)" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= 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, > Yes I agree that the " can provide this mapping, but > what I would like to have is the possibility to use more than three > priorities in the Admission Priority parameter. > For more info, please see: > = http://www.watersprings.org/pub/id/draft-lefaucheur-emergency-rsvp-00.txt= We specified 3 levels of admission priority in the QSPEC I-D = http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-08.txt based on = the requirements agreed to in several standards bodies, for example: [PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels for = IP Networks and Services," T1A1/2003-196 R3, November 2004. Furthermore, Section 9 "IANA Considerations" in the QSPEC I-D specifies: Admission Priority Parameter (8 bits): The following values are allocated by this specification: 0-2: assigned as specified in Section 7.2.6.2 The allocation policies for further values are as follows: 3-63: Standards Action 64-255: Reserved Therefore, ample space (256 possible admission priority parameter = values) is allocated for additional admission priority parameters to be = defined, should requirements arise. The procedures for the 16-bit admission priority parameter defined in = http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t appears to derive heavily on procedures specified for RSVP Preemption = Priority: [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy = Element", RFC 3181, October 2001. The QSPEC I-D specifies preemption/defending priority parameters in = Section 7.2.7.1 (Preemption Priority> & Parameters = [RFC 3181]). Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 31 07:10:51 2006 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 1F3uLT-0007fV-TW; Tue, 31 Jan 2006 07:10:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3uLR-0007ck-Pj for nsis@megatron.ietf.org; Tue, 31 Jan 2006 07:10:49 -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 HAA09929 for ; Tue, 31 Jan 2006 07:09:05 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3uWE-0000ON-Vo for nsis@ietf.org; Tue, 31 Jan 2006 07:22:01 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0F0011BAC4D for ; Tue, 31 Jan 2006 13:10:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) To: nsis Message-Id: From: Martin Stiemerling Date: Tue, 31 Jan 2006 13:10:22 +0100 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [NSIS] =?iso-8859-1?q?NATFW_NSLP=3A=A0Signaling_for_ICMP_policy_?= =?iso-8859-1?q?rules?= 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="===============0160316856==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0160316856== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-47--659050541; protocol="application/pkcs7-signature" --Apple-Mail-47--659050541 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear all, The NSIS working group has received some request from a 3GPP2 working group to add features to the NATFW NSLP, as said in my email sent before. One of the features is the ability to signaling for ICMP policy rules. Up to now, the NATFW NSLP can signal for IP only, TCP, and UDP flows by using the NTLP path-coupled MRM and the LE-MRM. It's possible to signal for ICMP flows by using the PC-MRM and setting the 'protocol' field to 'ICMP'. However, it is currently not possible to specify anything beyond that, for instance, the ICMP code to be used. Here is the proposed extension to the NATFW NSLP: - Add a new object 'icmp' that carries solely the ICMP code - This object can be included in CREATE messages where the NTLP is carrying a MRM with IP addresses only, protocol set to ICMP. - For REA and REA-F, the "Data Terminal Information Object" must be modified to carry the ICMP code. This proposed change does *NOT* require any change to the NTLP but *ONLY* to the NATFW NSLP. Any view on this? Thanks, Martin --Apple-Mail-47--659050541 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGSTCCAwIw ggJroAMCAQICAw8BOzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjI0MDkyNzMwWhcNMDYwNjI0MDkyNzMwWjBuMRQwEgYDVQQE EwtTdGllbWVybGluZzEPMA0GA1UEKhMGTWFydGluMRswGQYDVQQDExJNYXJ0aW4gU3RpZW1lcmxp bmcxKDAmBgkqhkiG9w0BCQEWGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDIdKncWwqQck8qYN+xvFwxSJqdZrf9zUATYsokkTe2h8B3Zvv6 8Xbyg0Zt4sG6ygQEB+pZodppRngNWsOY7bdUOb9ENCYAHAV+dbve0qx8JjakiiS8CjVv1q/W6xj7 mFIg32QdbOKzvkBi/FrA8G8KpJnymjsPkpcj1+18dHG9vY9VyjQUxTnfEkEEwjcKrxfGaukYNI/P XJm+sEx2ni39gDroHIx8Tql/jdNwjSQw1p+TqUP28UUPXwn4P/jrsCWwp1XXKLOUcfRCrcO3qMx2 k9a2FUfDjsBNiZg1ed2giEoJf+DdZUbrfbtPR+GW+g50nt59f59FUvubuVdgvH0pAgMBAAGjNjA0 MCQGA1UdEQQdMBuBGXN0aWVtZXJsaW5nQG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQC8bBqzxUKFH/gdvs4hTELn5WdR5sPp3A0iY+7DaKtR+XdyuYPyqzWDoonQ KXgks2QGxj6kyTUTWWYl7lvyc+GnTEFpi5/nJBcgVnNtmMI0UxpKUJqwxD5uLcdFGRybDerzoyxa OQEq7gYjgylUlvgB9KwTq5PkjBQa3Jd9E+yeWTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDDwE7MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA2MDEzMTEyMTAyM1owIwYJKoZIhvcNAQkEMRYEFNqwkvBQbhnKknOLfffR Domy/uJ+MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPATswegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDwE7MA0GCSqGSIb3DQEBAQUABIIBAKbYeBi69jNCXOHatq30 zVNkYovyVQ9VOe+XEYNkFXka9woDB1Xwcy8BFoY95MHYNSLPCn4FDlgywM855fGO7+ECwoWx+WwP tlxaSj1DxdR+qcCvSo65Gpj4/BnWJsDPhU8Py1Mn/3AOjzCx8SrSXzMH9KfCtQYS7cPi2V51G85J Kg8Inw/asC+dYxw79CUi0RUaVCkJD2JRmsC7vwcKf/b5IdKtcpkfXke9/1o0WYhE4ZKaqW3DgyIJ d+dB+4dwQOEHAI8Ne/qvYirMdniWtvqTSxH7XIH7d3s+dcp6bB2cTlI25+CXnPAGayMWWMk0PF54 YdHnBb8tMZayPstdKQEAAAAAAAA= --Apple-Mail-47--659050541-- --===============0160316856== 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 --===============0160316856==-- From nsis-bounces@ietf.org Tue Jan 31 09:11:43 2006 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 1F3wER-0007Wj-3h; Tue, 31 Jan 2006 09:11:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3wEN-0007UQ-Ep for nsis@megatron.ietf.org; Tue, 31 Jan 2006 09:11:41 -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 JAA19205 for ; Tue, 31 Jan 2006 09:09:49 -0500 (EST) 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 1F3wP7-0004QK-Iy for nsis@ietf.org; Tue, 31 Jan 2006 09:22:46 -0500 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id ; Tue, 31 Jan 2006 09:11:44 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0E5208E4@emshqs1.ncr.disa.mil> From: "Nguyen, An P CIV NCS NC2" To: "'Georgios Karagiannis'" , "Ash, Gerald R (Jerry), ALABS" , cornelia.kappler@siemens.com, =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= Subject: RE: [NSIS] QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 09:11:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: "Nsis \(E-mail\)" 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 Georgeois, I think you are talking about three levels of admission priority in the public networks with ETS being the highest.=20 And DRSN is a private network. Six levels of admission control for DRSN should be allowed. Regards, An -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of Georgios Karagiannis Sent: Tuesday, January 31, 2006 5:21 AM To: Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: [NSIS] QSPEC - admission priority parameter Hello Jerry, Attila and Cornelia In section 7.2.7.2 of the QSPEC template draft you mention that the Admission Priority parameter should have only three priorities, see below: Admission Priority: 0 - high priority flow 1 - normal priority flow 2 - best-effort priority flow Why is that? Three admission priorities are not enough! Suppose that we would like to map the 6 priorities required by Defense Red Switched Network (DRSN)=20 ([SIP-PRIORITY]) into the admission priority parameter. Then this will not be possible! My proposal will be to allow the specification of a higher number of admission priorities! Best Regards, Georgios=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 Tue Jan 31 09:29:53 2006 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 1F3wW1-000492-36; Tue, 31 Jan 2006 09:29:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3wVz-00048C-B9 for nsis@megatron.ietf.org; Tue, 31 Jan 2006 09:29:51 -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 JAA20625 for ; Tue, 31 Jan 2006 09:28:04 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3wgk-00052g-TR for nsis@ietf.org; Tue, 31 Jan 2006 09:41:02 -0500 X-VirusChecked: Checked X-Env-Sender: tarapore@att.com X-Msg-Ref: server-12.tower-126.messagelabs.com!1138717658!9102899!27 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6821 invoked from network); 31 Jan 2006 14:29:26 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-126.messagelabs.com with SMTP; 31 Jan 2006 14:29:26 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 43D3BB520011C643; Tue, 31 Jan 2006 09:29:25 -0500 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] QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 08:29:25 -0600 Message-ID: Thread-Topic: [NSIS] QSPEC - admission priority parameter Thread-Index: AcYmca13jzRV8uMjSRWKdB4RP3aCSwAADdpA From: "Tarapore, Percy S, ALABS" To: "Nguyen, An P CIV NCS NC2" , "Georgios Karagiannis" , "Ash, Gerald R \(Jerry\), ALABS" , , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: "Nsis \(E-mail\)" 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 critical point to note is this. Within a DRSN domain, having = multiple priority levels is permitted by the SIP RPH header. However, = DRSN messages if carried over public IP networks, would be considered to = be a single High priority class of traffic over the public domain. The = same is true for ETS services. The rationale is that the total volume of = High priority traffic (whether it is ETS or WPS or DRSN) is dwarfed by = the rest of the traffic over public IP networks, especially Best Effort = traffic. Percy =20 -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of = Nguyen, An P CIV NCS NC2 Sent: Tuesday, January 31, 2006 9:11 AM To: 'Georgios Karagiannis'; Ash, Gerald R (Jerry), ALABS; = cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: RE: [NSIS] QSPEC - admission priority parameter Georgeois, I think you are talking about three levels of admission priority in the public networks with ETS being the highest.=20 And DRSN is a private network. Six levels of admission control for DRSN should be allowed. Regards, An -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of Georgios Karagiannis Sent: Tuesday, January 31, 2006 5:21 AM To: Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: [NSIS] QSPEC - admission priority parameter Hello Jerry, Attila and Cornelia In section 7.2.7.2 of the QSPEC template draft you mention that the Admission Priority parameter should have only three priorities, see below: Admission Priority: 0 - high priority flow 1 - normal priority flow 2 - best-effort priority flow Why is that? Three admission priorities are not enough! Suppose that we would like to map the 6 priorities required by Defense Red Switched Network (DRSN)=20 ([SIP-PRIORITY]) into the admission priority parameter. Then this will not be possible! My proposal will be to allow the specification of a higher number of admission priorities! Best Regards, Georgios=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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 31 11:57:25 2006 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 1F3yon-0005Oj-0y; Tue, 31 Jan 2006 11:57:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yol-0005JI-OG for nsis@megatron.ietf.org; Tue, 31 Jan 2006 11:57:23 -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 LAA06467 for ; Tue, 31 Jan 2006 11:55:40 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yzd-00034y-Py for nsis@ietf.org; Tue, 31 Jan 2006 12:08:38 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0VGutYR021584; Tue, 31 Jan 2006 17:56:55 +0100 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 k0VGutQH027871; Tue, 31 Jan 2006 17:56:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 17:56:55 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] RE: QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 17:56:54 +0100 Message-ID: Thread-Topic: [NSIS] RE: QSPEC - admission priority parameter Thread-Index: AcYmV4EskwipcohnTbq/qg2NRfqgFAAKwcyQ From: "Tschofenig, Hannes" To: "Georgios Karagiannis" , "Ash, Gerald R \(Jerry\), ALABS" X-OriginalArrivalTime: 31 Jan 2006 16:56:55.0388 (UTC) FILETIME=[574F19C0:01C62687] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Nsis \(E-mail\)" , "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 -- OFFLIST.=20 hi jerry,=20 hi georgios,=20 i agree with georgios that we should align our work with the most recent = enhancements to rsvp.=20 as such, we should consider drafts like the one listed below.=20 ciao hannes=20 > -----Urspr=FCngliche Nachricht----- > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > Auftrag von Georgios Karagiannis > Gesendet: Dienstag, 31. Januar 2006 12:07 > An: Ash, Gerald R (Jerry), ALABS > Cc: Ash, Gerald R (Jerry), ALABS; Kappler, Cornelia; Nsis=20 > (E-mail); Attila B=E1der (IJ/ETH) > Betreff: Re: [NSIS] RE: QSPEC - admission priority parameter >=20 > Hi Jerry >=20 > Yes I agree that the " can provide this=20 > mapping, but what I=20 > would like to have > is the possibility to use more than three priorities in the Admission=20 > Priority parameter. > For more info, please see: > http://www.watersprings.org/pub/id/draft-lefaucheur-emergency- > rsvp-00.txt >=20 > Best regards, > Georgios >=20 >=20 > ----- Original Message -----=20 > From: "Ash, Gerald R (Jerry), ALABS" > To: "Georgios Karagiannis" > Cc: "Ash, Gerald R (Jerry), ALABS" ; "Attila=20 > B=E1der (IJ/ETH)"=20 > ; "Nsis (E-mail)" ;=20 > > Sent: Tuesday, January 31, 2006 11:38 AM > Subject: [NSIS] RE: QSPEC - admission priority parameter >=20 >=20 > > Hi Georgios, > > > >> In section 7.2.7.2 of the QSPEC template > >> draft you mention that the Admission Priority parameter > >> should have only three priorities, see below: > >> > >> Admission Priority: > >> > >> 0 - high priority flow > >> 1 - normal priority flow > >> 2 - best-effort priority flow > >> > >> Why is that? > >> > >> Three admission priorities are not enough! > >> Suppose that we would like to map the > >> 6 priorities required by Defense Red Switched Network (DRSN) > >> ([SIP-PRIORITY]) into > >> the admission priority parameter. > >> Then this will not be possible! > >> My proposal will be to allow the specification of a higher > >> number of admission priorities! > > > > Note that Section 7.2.7.3 " Parameter" maps=20 > all of the=20 > > [SIP-PRIORITY] values into the QSPEC, including the DRSN values. > > > > Thanks, > > Jerry > > > > _______________________________________________ > > 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 Jan 31 11:57:25 2006 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 1F3yon-0005QJ-KH; Tue, 31 Jan 2006 11:57:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yol-0005JJ-Sn for nsis@megatron.ietf.org; Tue, 31 Jan 2006 11:57:23 -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 LAA06466 for ; Tue, 31 Jan 2006 11:55:40 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yzd-00034x-Hj for nsis@ietf.org; Tue, 31 Jan 2006 12:08:38 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0VGutjR021583; Tue, 31 Jan 2006 17:56:55 +0100 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 k0VGutlZ027866; Tue, 31 Jan 2006 17:56:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 17:56: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] RE: QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 17:56:54 +0100 Message-ID: Thread-Topic: [NSIS] RE: QSPEC - admission priority parameter Thread-Index: AcYmUCELeuXZXGK8TK6iCRxW+QcYSQAAYFowAAvm2bA= From: "Tschofenig, Hannes" To: "Ash, Gerald R \(Jerry\), ALABS" , "Georgios Karagiannis" X-OriginalArrivalTime: 31 Jan 2006 16:56:54.0873 (UTC) FILETIME=[57008490:01C62687] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: "Kappler, Cornelia" , "Nsis \(E-mail\)" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= 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,=20 is is actually correct to carry the parameters carried in sip (as listed = in draft-ietf-sip-resource-priority-10.txt) in the qos signaling protocol? based on a previous mailing list = discussion (a year ago) i got the impression that this is not correct. instead the sip priority/preemption parameters are different to the one = used in sip. rsvp, for example, provides only support for [RFC 3181] = alike parameters (defined in section 7.2.7.1 of = draft-ietf-nsis-qspec-08.txt). i don't recall that the parameters = defined in draft-ietf-sip-resource-priority-10.txt are carried in rsvp. = am i wrong?=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > Auftrag von Ash, Gerald R (Jerry), ALABS > Gesendet: Dienstag, 31. Januar 2006 11:38 > An: Georgios Karagiannis > Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); Nsis=20 > (E-mail); Kappler, Cornelia > Betreff: [NSIS] RE: QSPEC - admission priority parameter >=20 > Hi Georgios, >=20 > > In section 7.2.7.2 of the QSPEC template > > draft you mention that the Admission Priority parameter > > should have only three priorities, see below: > >=20 > > Admission Priority: > >=20 > > 0 - high priority flow > > 1 - normal priority flow > > 2 - best-effort priority flow > >=20 > > Why is that? > >=20 > > Three admission priorities are not enough! > > Suppose that we would like to map the > > 6 priorities required by Defense Red Switched Network (DRSN)=20 > > ([SIP-PRIORITY]) into > > the admission priority parameter. > > Then this will not be possible! > > My proposal will be to allow the specification of a higher > > number of admission priorities! >=20 > Note that Section 7.2.7.3 " Parameter" maps all=20 > of the [SIP-PRIORITY] values into the QSPEC, including the=20 > DRSN values. >=20 > Thanks, > 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 Tue Jan 31 12:29:41 2006 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 1F3zK1-0004P8-JF; Tue, 31 Jan 2006 12:29:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zJz-0004OO-Cz for nsis@megatron.ietf.org; Tue, 31 Jan 2006 12:29:39 -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 MAA09401 for ; Tue, 31 Jan 2006 12:28:03 -0500 (EST) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zUy-0004OH-5z for nsis@ietf.org; Tue, 31 Jan 2006 12:41:01 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 31 Jan 2006 10:04:20 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006013110041914533 ; Tue, 31 Jan 2006 10:04:19 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 31 Jan 2006 10:04:19 -0500 Message-Id: From: "Roy, Radhika R." To: "Tarapore, Percy S, ALABS" , "Nguyen, An P CIV NCS NC2" , Georgios Karagiannis , "Ash, Gerald R (Jerry), ALABS" , cornelia.kappler@siemens.com, =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= Subject: RE: [NSIS] QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 10:04:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: "Nsis \(E-mail\)" 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 Folks: SIP provides the indication for "PRIORITY" how a call (indication in signaling messages) will be handled for admission in the network. However, a SIP call may transfer more than one media: Audio = (real-time), video (real-time), and/or data (non-real-time). The call level priority = in signaling messages does NOT explain how each media (audio, video, data) payload type will be handled to provide QoS in terms of PRIORITIES. It may so happen audio may have to be treated with highest priority, = while video may have the lowest priority, etc. In the light of the above, let us synthesize where the chips fall in = terms of providing "priority treatments" of different traffic over the IP = network from the call level to the IP packet/media payload level.=20 Cheers, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Tarapore, Percy S, ALABS Sent: Tuesday, January 31, 2006 9:29 AM To: Nguyen, An P CIV NCS NC2; Georgios Karagiannis; Ash, Gerald R = (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: RE: [NSIS] QSPEC - admission priority parameter The critical point to note is this. Within a DRSN domain, having = multiple priority levels is permitted by the SIP RPH header. However, DRSN = messages if carried over public IP networks, would be considered to be a single = High priority class of traffic over the public domain. The same is true for = ETS services. The rationale is that the total volume of High priority = traffic (whether it is ETS or WPS or DRSN) is dwarfed by the rest of the = traffic over public IP networks, especially Best Effort traffic. Percy =20 -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Nguyen, An P CIV NCS NC2 Sent: Tuesday, January 31, 2006 9:11 AM To: 'Georgios Karagiannis'; Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: RE: [NSIS] QSPEC - admission priority parameter Georgeois, I think you are talking about three levels of admission priority in the public networks with ETS being the highest.=20 And DRSN is a private network. Six levels of admission control for DRSN should be allowed. Regards, An -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of Georgios Karagiannis Sent: Tuesday, January 31, 2006 5:21 AM To: Ash, Gerald R (Jerry), ALABS; cornelia.kappler@siemens.com; Attila B=E1der (IJ/ETH) Cc: Nsis (E-mail) Subject: [NSIS] QSPEC - admission priority parameter Hello Jerry, Attila and Cornelia In section 7.2.7.2 of the QSPEC template draft you mention that the Admission Priority parameter should have only three priorities, see below: Admission Priority: 0 - high priority flow 1 - normal priority flow 2 - best-effort priority flow Why is that? Three admission priorities are not enough! Suppose that we would like to map the 6 priorities required by Defense Red Switched Network (DRSN)=20 ([SIP-PRIORITY]) into the admission priority parameter. Then this will not be possible! My proposal will be to allow the specification of a higher number of admission priorities! Best Regards, Georgios=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 _______________________________________________ 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 Jan 31 12:58:37 2006 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 1F3zm1-0004iq-63; Tue, 31 Jan 2006 12:58:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zlz-0004hV-6H for nsis@megatron.ietf.org; Tue, 31 Jan 2006 12:58:35 -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 MAA13082 for ; Tue, 31 Jan 2006 12:56:59 -0500 (EST) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zwz-0005r7-50 for nsis@ietf.org; Tue, 31 Jan 2006 13:09:58 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 31 Jan 2006 12:16:49 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006013112164922607 ; Tue, 31 Jan 2006 12:16:49 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 31 Jan 2006 12:16:49 -0500 Message-Id: From: "Roy, Radhika R." To: "Tschofenig, Hannes" , "Ash, Gerald R (Jerry), ALABS" , Georgios Karagiannis Subject: RE: [NSIS] RE: QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 12:16:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Nsis \(E-mail\)" , "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 Hannes: Let us make clear further before make a mess out of it as explained in = my earlier email. RSVP deals with QoS properties of media payload, not of the call = (object) itself. SIP call provides the indication of the call itself how a given call to = be admitted in the network from different priority category point of view. = For example, a high priority call can preempt a low priority call or a high priority call will be handled first while a low priority call will be = served later.=20 SIP level priority does NOT tell anything how each media of a given = call needs to be dealt with from priority point of view. So, how do you expect that RSVP needs to carry the priority indication = that has been provided in the SIP call signaling messages whose only concern = is to deal with the call itself, not media? Cheers, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Tschofenig, Hannes Sent: Tuesday, January 31, 2006 11:57 AM To: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis Cc: Kappler, Cornelia; Nsis (E-mail); Attila B=E1der (IJ/ETH) Subject: AW: [NSIS] RE: QSPEC - admission priority parameter hi jerry,=20 is is actually correct to carry the parameters carried in sip (as = listed in draft-ietf-sip-resource-priority-10.txt) in the qos signaling protocol? based on a previous mailing list = discussion (a year ago) i got the impression that this is not correct. instead the sip priority/preemption parameters are different to the one = used in sip. rsvp, for example, provides only support for [RFC 3181] alike parameters (defined in section 7.2.7.1 of = draft-ietf-nsis-qspec-08.txt). i don't recall that the parameters defined in draft-ietf-sip-resource-priority-10.txt are carried in rsvp. am i = wrong?=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > Auftrag von Ash, Gerald R (Jerry), ALABS > Gesendet: Dienstag, 31. Januar 2006 11:38 > An: Georgios Karagiannis > Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); Nsis=20 > (E-mail); Kappler, Cornelia > Betreff: [NSIS] RE: QSPEC - admission priority parameter >=20 > Hi Georgios, >=20 > > In section 7.2.7.2 of the QSPEC template > > draft you mention that the Admission Priority parameter > > should have only three priorities, see below: > >=20 > > Admission Priority: > >=20 > > 0 - high priority flow > > 1 - normal priority flow > > 2 - best-effort priority flow > >=20 > > Why is that? > >=20 > > Three admission priorities are not enough! > > Suppose that we would like to map the > > 6 priorities required by Defense Red Switched Network (DRSN)=20 > > ([SIP-PRIORITY]) into > > the admission priority parameter. > > Then this will not be possible! > > My proposal will be to allow the specification of a higher > > number of admission priorities! >=20 > Note that Section 7.2.7.3 " Parameter" maps all=20 > of the [SIP-PRIORITY] values into the QSPEC, including the=20 > DRSN values. >=20 > Thanks, > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 31 13:18:37 2006 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 1F405M-0001ai-WB; Tue, 31 Jan 2006 13:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F405L-0001Yn-Kw for nsis@megatron.ietf.org; Tue, 31 Jan 2006 13:18:35 -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 NAA14933 for ; Tue, 31 Jan 2006 13:16:41 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F40G4-0006cM-GT for nsis@ietf.org; Tue, 31 Jan 2006 13:29:41 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0VII0fj006709; Tue, 31 Jan 2006 19:18:00 +0100 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 k0VIHx11029477; Tue, 31 Jan 2006 19:17:59 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 19:17: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] RE: QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 19:17:51 +0100 Message-ID: Thread-Topic: [NSIS] RE: QSPEC - admission priority parameter Thread-Index: AcYmj/nTwkKXKzhsQHm9DpljGuhvKwAAgjSA From: "Tschofenig, Hannes" To: , "Ash, Gerald R \(Jerry\), ALABS" , "Georgios Karagiannis" X-OriginalArrivalTime: 31 Jan 2006 18:17:58.0206 (UTC) FILETIME=[A9C63DE0:01C62692] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Nsis \(E-mail\)" , "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 radhika,=20 i guess we are on the same page with our thoughts.=20 in the past a bit confusion was caused by the fact that the same term = (priority and preemption) is used in two different contexts.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: royrr@us.saic.com [mailto:royrr@us.saic.com]=20 > Gesendet: Dienstag, 31. Januar 2006 18:17 > An: Tschofenig, Hannes; Ash, Gerald R (Jerry), ALABS;=20 > Georgios Karagiannis > Cc: Kappler, Cornelia; Nsis (E-mail); Attila B=E1der (IJ/ETH) > Betreff: RE: [NSIS] RE: QSPEC - admission priority parameter >=20 > Hannes: >=20 > Let us make clear further before make a mess out of it as=20 > explained in my > earlier email. >=20 > RSVP deals with QoS properties of media payload, not of the=20 > call (object) > itself. >=20 > SIP call provides the indication of the call itself how a=20 > given call to be > admitted in the network from different priority category=20 > point of view. For > example, a high priority call can preempt a low priority call=20 > or a high > priority call will be handled first while a low priority call=20 > will be served > later.=20 >=20 > SIP level priority does NOT tell anything how each media of a=20 > given call > needs to be dealt with from priority point of view. >=20 > So, how do you expect that RSVP needs to carry the priority=20 > indication that > has been provided in the SIP call signaling messages whose=20 > only concern is > to deal with the call itself, not media? >=20 > Cheers, > Radhika >=20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of > Tschofenig, Hannes > Sent: Tuesday, January 31, 2006 11:57 AM > To: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis > Cc: Kappler, Cornelia; Nsis (E-mail); Attila B=E1der (IJ/ETH) > Subject: AW: [NSIS] RE: QSPEC - admission priority parameter >=20 > hi jerry,=20 >=20 > is is actually correct to carry the parameters carried in sip=20 > (as listed in > draft-ietf-sip-resource-priority-10.txt) > in the qos signaling protocol? based on a previous mailing=20 > list discussion > (a year ago) i got the impression that this is not correct. >=20 > instead the sip priority/preemption parameters are different=20 > to the one used > in sip. rsvp, for example, provides only support for [RFC 3181] alike > parameters (defined in section 7.2.7.1 of=20 > draft-ietf-nsis-qspec-08.txt). i > don't recall that the parameters defined in > draft-ietf-sip-resource-priority-10.txt are carried in rsvp.=20 > am i wrong?=20 >=20 > ciao > hannes > =20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > > Auftrag von Ash, Gerald R (Jerry), ALABS > > Gesendet: Dienstag, 31. Januar 2006 11:38 > > An: Georgios Karagiannis > > Cc: Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH); Nsis=20 > > (E-mail); Kappler, Cornelia > > Betreff: [NSIS] RE: QSPEC - admission priority parameter > >=20 > > Hi Georgios, > >=20 > > > In section 7.2.7.2 of the QSPEC template > > > draft you mention that the Admission Priority parameter > > > should have only three priorities, see below: > > >=20 > > > Admission Priority: > > >=20 > > > 0 - high priority flow > > > 1 - normal priority flow > > > 2 - best-effort priority flow > > >=20 > > > Why is that? > > >=20 > > > Three admission priorities are not enough! > > > Suppose that we would like to map the > > > 6 priorities required by Defense Red Switched Network (DRSN)=20 > > > ([SIP-PRIORITY]) into > > > the admission priority parameter. > > > Then this will not be possible! > > > My proposal will be to allow the specification of a higher > > > number of admission priorities! > >=20 > > Note that Section 7.2.7.3 " Parameter" maps all=20 > > of the [SIP-PRIORITY] values into the QSPEC, including the=20 > > DRSN values. > >=20 > > Thanks, > > Jerry > >=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 Jan 31 16:01:24 2006 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 1F42cu-0007li-Ow; Tue, 31 Jan 2006 16:01:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42cr-0007ka-H5 for nsis@megatron.ietf.org; Tue, 31 Jan 2006 16:01:23 -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 PAA27261 for ; Tue, 31 Jan 2006 15:59:34 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F42ng-0004pX-5E for nsis@ietf.org; Tue, 31 Jan 2006 16:12:36 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-126.messagelabs.com!1138741224!8856428!7 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 4115 invoked from network); 31 Jan 2006 21:00:53 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-126.messagelabs.com with SMTP; 31 Jan 2006 21:00:53 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 43D3BB5200135DBB; Tue, 31 Jan 2006 16:00:51 -0500 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] RE: QSPEC - admission priority parameter Date: Tue, 31 Jan 2006 15:00:51 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9A28@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] RE: QSPEC - admission priority parameter Thread-Index: AcYmUCELeuXZXGK8TK6iCRxW+QcYSQAAYFowAAvm2bAACXdm4A== From: "Ash, Gerald R \(Jerry\), ALABS" To: "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , "Kappler, Cornelia" , "Nsis \(E-mail\)" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= 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, > is actually correct to carry the parameters carried in sip=20 > (as listed in draft-ietf-sip-resource-priority-10.txt) > in the qos signaling protocol? based on a previous mailing=20 > list discussion (a year ago) i got the impression that this=20 > is not correct. It is correct... I'm not sure what 'discussion' you're referring to a = year ago. There was an exchange with Ken Carlberg regarding the format, = but that's it. I believe the RSVP draft = http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-00.tx= t was inspired by suggestions from An Nguyen of NCS (see = acknowledgements), to align RSVP priority capabilities with NSIS = capabilities in the 'priority signaling' area. IMO there is no = functionality proposed in the RSVP document not already possible in the = NSIS/QSPEC. =20 > instead the sip priority/preemption parameters are different=20 > to the one used in sip. rsvp, for example, provides only=20 > support for [RFC 3181] alike parameters (defined in section=20 > 7.2.7.1 of draft-ietf-nsis-qspec-08.txt). i don't recall that=20 > the parameters defined in=20 > draft-ietf-sip-resource-priority-10.txt are carried in rsvp.=20 > am i wrong?=20 I agree, I'm not aware that sip-resource-priority parameters are carried = (or proposed) as yet in RSVP. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jan 31 23:24:29 2006 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 1F49Xh-0005ge-AD; Tue, 31 Jan 2006 23:24:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F49Xe-0005dW-VK for nsis@megatron.ietf.org; Tue, 31 Jan 2006 23:24:27 -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 XAA04935 for ; Tue, 31 Jan 2006 23:22:31 -0500 (EST) Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F49iR-0004Ny-2Y for nsis@ietf.org; Tue, 31 Jan 2006 23:35:37 -0500 Received: (qmail 23533 invoked from network); 31 Jan 2006 18:00:39 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 31 Jan 2006 18:00:39 -0000 Received: from 134.76.81.25 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Tue, 31 Jan 2006 19:00:39 +0100 (CET) Message-ID: <36694.134.76.81.25.1138730439.squirrel@mail.piranho.net> In-Reply-To: References: Date: Tue, 31 Jan 2006 19:00:39 +0100 (CET) Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules From: "Henning Peters" To: "Martin Stiemerling" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 8bit Cc: 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, can you specify an application for the signaling of ICMP policy rules? Don't ICMP messages already refer to a certain data flow? I don't see a reason why a firewall or NAT should deny or drop them. And if they are configured to behave like this, a different configuration might not be wanted in the first place?! But probably the 3GPP2 guys already have sth. particular in mind that I am currently not seeing. How does the change affect NAT? As this might have impacts on the (de)multiplexing behavior of NATs. If adding a new code object to NAT/FW NSLP, allowing multiple codes in a single message might be valuable to save unnecessary signaling traffic. > - For REA and REA-F, the "Data Terminal Information Object" must be > modified to carry the ICMP code. Why do you want to have a new code object _and_ an additional code field in the DTInfo object? Wouldn't it make sense to set the protocol to ICMP in DTInfo protocol field and add the new ICMP code object regularly? Henning Martin Stiemerling sagte Di, 31.01.2006, 13:10: > Dear all, > > The NSIS working group has received some request from a 3GPP2 working > group to add features to the NATFW NSLP, as said in my email sent > before. > > One of the features is the ability to signaling for ICMP policy > rules. Up to now, the NATFW NSLP can signal for IP only, TCP, and UDP > flows by using the NTLP path-coupled MRM and the LE-MRM. It's > possible to signal for ICMP flows by using the PC-MRM and setting the > 'protocol' field to 'ICMP'. However, it is currently not possible to > specify anything beyond that, for instance, the ICMP code to be used. > > Here is the proposed extension to the NATFW NSLP: > - Add a new object 'icmp' that carries solely the ICMP code > - This object can be included in CREATE messages where the NTLP is > carrying a MRM with IP addresses only, protocol set to ICMP. > - For REA and REA-F, the "Data Terminal Information Object" must be > modified to carry the ICMP code. > > This proposed change does *NOT* require any change to the NTLP but > *ONLY* to the NATFW NSLP. > > Any view on this? > > Thanks, > > 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