From nsis-bounces@ietf.org Wed Aug 01 04:47:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9r8-00031S-6p; Wed, 01 Aug 2007 04:46:58 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IG9r6-00031L-7G for nsis-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 04:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9r2-000312-5l for nsis@ietf.org; Wed, 01 Aug 2007 04:46:52 -0400 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 1IG9r0-0005Lv-JR for nsis@ietf.org; Wed, 01 Aug 2007 04:46:52 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 01 Aug 2007 11:46:47 +0300 id 0005FEC8.46B04877.000018F9 Date: Wed, 1 Aug 2007 11:46:47 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] GIST: Responding Node D-Mode to C-Mode upgrade? In-Reply-To: <46AF4C4E.8080701@tm.uka.de> Message-ID: References: <46AF4C4E.8080701@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: 4b800b1eab964a31702fa68f1ff0e955 Cc: "nsis@ietf.org" , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I had a good chat yesterday with Nuutti about this, and we came to the conclusion, that point b) would be the simple and right thing to do. Of course this creates a rather problematic situation for NSLPs, but other solutions would probably lead to complex signaling scenarios. Can the NSLP query the MTU for the MA? If so, we should just stress in the GIST spec, that in case of D-mode the NSLP should ask for and respect the MTU, otherwise a local error will be indicated and the message will not be delivered. regards, Jukka On Tue, 31 Jul 2007, Roland Bless wrote: > Hi Robert, > > this is an old topic, but probably still not solved > satisfactory. Nuutti Varis, who is currently implementing > GIST at University of Helsinki, came also across this issue > again. > > Problem: in case a responding node has > to send a payload larger than the MAX_MTU size, it > currently cannot upgrade the session from D-Mode > to C-mode, because it is a responding node. > See also > http://www1.ietf.org/mail-archive/web/nsis/current/msg05672.html > and your answer here: > http://www1.ietf.org/mail-archive/web/nsis/current/msg05676.html > Same applies for requiring a reliable transfer mode on the responder > side when only an unreliable transfer was considered by the querier > so far. > > I could think of the following alternatives: > a) the responding node queues the data for transmission and sends > and informative error message to the querier who can then decide > on upgrading the session to C-mode. This has the problem that we > need a timer on the responder side and must wait until the MA > is established. Otherwise it will notify the application > with a MessageStatus() call that the message could not be sent. > Probably a part of the code could be re-used that is already > there for initial setup of an MA. Furthermore, even smaller > D-mode messages must enqueue behind this earlier message, > because in order delivery for the same session is required. > > b) indicate a local error condition > via MessageStatus that the message is too large. However, reacting > to this failure situation requires probably a similar logic that > could have been used by the application itself _before_ calling > the SendMessage() call. > > c) see it as global policy for the NSLP as in your answer. > > However, it would be good to mention the problem (and a solution) > in the draft at least. > Any other opinions? > > Regards, > Roland > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 01 07:42:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGCat-0008U1-Gp; Wed, 01 Aug 2007 07:42:23 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IGCas-0008Ta-E6 for nsis-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 07:42:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGCas-0008TJ-3J for nsis@ietf.org; Wed, 01 Aug 2007 07:42:22 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGCar-0003kh-90 for nsis@ietf.org; Wed, 01 Aug 2007 07:42:22 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IGCal-0003aK-O0; Wed, 01 Aug 2007 13:42:18 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IGCak-0007Q5-Ad; Wed, 01 Aug 2007 13:42:15 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IGCak-0001nL-34; Wed, 01 Aug 2007 13:42:14 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 9B89E2FC014; Wed, 1 Aug 2007 13:42:13 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IGCaj-0005Xc-51; Wed, 01 Aug 2007 13:42:13 +0200 Message-ID: <46B07194.9050801@tm.uka.de> Date: Wed, 01 Aug 2007 13:42:12 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] GIST: Responding Node D-Mode to C-Mode upgrade? References: <46AF4C4E.8080701@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "nsis@ietf.org" , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Jukka MJ Manner wrote: > I had a good chat yesterday with Nuutti about this, and we came to the > conclusion, that point b) would be the simple and right thing to do. Of > course this creates a rather problematic situation for NSLPs, but other > solutions would probably lead to complex signaling scenarios. At least it would give the NSLP programmer a hint that he must think twice before sending things over D-mode. > Can the NSLP query the MTU for the MA? If so, we should just stress in the As far as I know it is fixed (576 bytes) for D-mode (see sec. 4.3.3). For MAs there is probably no MTU that we need to be aware of (at least for SCTP and TCP) since reliable MAs will transport messages of an "arbitrary" size. > GIST spec, that in case of D-mode the NSLP should ask for and respect the > MTU, otherwise a local error will be indicated and the message will not be > delivered. The problem is that, there is no work around in this case. So if at some point in time the message gets too large, which can probably not be always be foreseen by the NSLP designer, the application will basically hang if this situation occurs. The history is full of system failures due to events that occurred although they were supposed to never happen (during the design and test phase)... So there is no graceful recovery or way out for an application which is the main thing that I'm concerned about. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 01 10:15:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEyX-00016t-BH; Wed, 01 Aug 2007 10:14:57 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IGEyT-00011t-Ve for nsis-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 10:14:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEyS-000119-1R; Wed, 01 Aug 2007 10:14:52 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGEyR-0000Dx-Dv; Wed, 01 Aug 2007 10:14:51 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AEF6320422; Wed, 1 Aug 2007 16:14:50 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-98-46b0955a7593 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 944EC20011; Wed, 1 Aug 2007 16:14:50 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 16:14:50 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 16:14:50 +0200 Message-ID: <46B0955A.3040900@ericsson.com> Date: Wed, 01 Aug 2007 16:14:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Janet P Gunn References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 14:14:50.0324 (UTC) FILETIME=[52AD5940:01C7D446] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [NSIS] Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Janet P Gunn skrev: > > Magnus, > > You might want to add- > > draft-polk-tsvwg-signaled-domain-id-00.txt Well, I want to be somewhat restricted in adding individual work into the liaison. Also to me it is not clear how this is applicable in the emergency context. > and > draft-polk-ecrit-local-emergency-rph-namespace-01.txt > Well, I got another comment about ECRIT WG document which we hadn't considered. I will contact the WG chairs and see what they say. > > And maybe > draft-carlberg-trip-attribute-rp-02 Well, this is in IETF last call currently. So I will put it on my list of documents to consider and try to learn more about it. > > My spelling checker says "Liaision" should be "Liaison", but it may be a > US centric dictionary. No, it is Liaison, but I think that error only is in the subject of this email. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 01 12:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGuK-00020z-FM; Wed, 01 Aug 2007 12:18:44 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IGGuI-00020P-MN for nsis-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 12:18:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGuH-00020E-R9; Wed, 01 Aug 2007 12:18:41 -0400 Received: from mail130.messagelabs.com ([216.82.250.163]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGGuH-0003c1-7H; Wed, 01 Aug 2007 12:18:41 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-130.messagelabs.com!1185985118!10207402!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 17586 invoked from network); 1 Aug 2007 16:18:39 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-6.tower-130.messagelabs.com with AES256-SHA encrypted SMTP; 1 Aug 2007 16:18:39 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l71GIqaX015895; Wed, 1 Aug 2007 12:18:54 -0400 (EDT) In-Reply-To: <46B0955A.3040900@ericsson.com> To: Magnus Westerlund MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Wed, 1 Aug 2007 12:18:34 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 08/01/2007 12:17:15 PM, Serialize complete at 08/01/2007 12:17:15 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [NSIS] Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: nsis@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="===============1019837689==" Errors-To: nsis-bounces@ietf.org This is a multipart message in MIME format. --===============1019837689== Content-Type: multipart/alternative; boundary="=_alternative 0059975B8525732A_=" This is a multipart message in MIME format. --=_alternative 0059975B8525732A_= Content-Type: text/plain; charset="US-ASCII" Magnus Westerlund wrote on 08/01/2007 10:14:50 AM: > Janet P Gunn skrev: > > > > Magnus, > > > > You might want to add- > > > > draft-polk-tsvwg-signaled-domain-id-00.txt > > Well, I want to be somewhat restricted in adding individual work into > the liaison. Also to me it is not clear how this is applicable in the > emergency context. Well, you included draft-polk-sip-rph-new-namespaces-01, and draft-polk-tsvwg-signaled-domain-id-00 addresses the same scenarios. It would make sense to include either both or neither. > > > and > > draft-polk-ecrit-local-emergency-rph-namespace-01.txt > > > > Well, I got another comment about ECRIT WG document which we hadn't > considered. I will contact the WG chairs and see what they say. Yes, ecrit should make the call. But I know at least one other stds body ( PacketCable PKT2 0-SP-RSTF-D01-060330 TCHG) is addressing it. Janet > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- --=_alternative 0059975B8525732A_= Content-Type: text/html; charset="US-ASCII"



Magnus Westerlund <magnus.westerlund@ericsson.com> wrote on 08/01/2007 10:14:50 AM:

> Janet P Gunn skrev:
> >
> > Magnus,
> >
> > You might want to add-
> >
> > draft-polk-tsvwg-signaled-domain-id-00.txt
>
> Well, I want to be somewhat restricted in adding individual work into
> the liaison. Also to me it is not clear how this is applicable in the
> emergency context.

Well, you included draft-polk-sip-rph-new-namespaces-01, and draft-polk-tsvwg-signaled-domain-id-00 addresses the same scenarios.  It would make sense to include either both or neither.
>
> > and
> > draft-polk-ecrit-local-emergency-rph-namespace-01.txt
> >
>
> Well, I got another comment about ECRIT WG document which we hadn't
> considered. I will contact the WG chairs and see what they say.

Yes, ecrit should make the call. But I know at least one other stds body (PacketCable PKT2 0-SP-RSTF-D01-060330 TCHG) is addressing it.

Janet

>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
 --=_alternative 0059975B8525732A_=-- --===============1019837689== 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 --===============1019837689==-- From nsis-bounces@ietf.org Thu Aug 02 04:50:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGWNo-0006Wy-RF; Thu, 02 Aug 2007 04:50:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IGWNl-0006UL-KP for nsis-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 04:50:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGWNj-0006SZ-V9; Thu, 02 Aug 2007 04:50:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGWNj-0002JT-8y; Thu, 02 Aug 2007 04:50:07 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 455D52071D; Thu, 2 Aug 2007 10:50:06 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-aa-46b19abe2e83 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E4DB2133C; Thu, 2 Aug 2007 10:50:06 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 10:50:05 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 10:50:05 +0200 Message-ID: <46B19ABC.9080909@ericsson.com> Date: Thu, 02 Aug 2007 10:50:04 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <46AF5370.9020304@ericsson.com> <200708012031.l71KVZBv016565@dragon.ariadne.com> In-Reply-To: <200708012031.l71KVZBv016565@dragon.ariadne.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 02 Aug 2007 08:50:05.0234 (UTC) FILETIME=[1F125120:01C7D4E2] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip@ietf.org, sipping@ietf.org, tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Sip] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dale.Worley@comcast.net skrev: > This is a response to the liaison request made by Q3/13 regarding=20 >=20 > It looks like that should be "Q.3/13". >=20 > emergency telecommunications (REF: NGN-GSI/DOC =E2=80=93 60 Rev.2). = We would=20 > first like to apologize for failing to meet the deadline in respondi= ng.=20 > We do hope that the late answer still can be of some use. >=20 > The liaison request was made to the following working groups (WG):=20 > IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG ha= s=20 > concluded. In addition to the WGs from which information was request= ed,=20 > we also think that work performed by the SIP and SIPPING WG may be o= f=20 > relevance. >=20 > Pursuant to ITU-T Study Group 13 request for information on relevant= and=20 > related work in the IETF regarding emergency communications, we list= =20 > below RFCs and works in progress that we feel may be of interest to = your=20 > group. Some of the completed work is Informational, and others are = in=20 > the category of Standards Track. >=20 > Q.3/13 also requested that we keep you informed of any developments = in=20 > regards to emergency telecommunications. In those regards we would l= ike=20 > to make you aware that IETF mailing list participation and document=20 > information is free and open for anyone. Allowing participants in Q.= 3/13=20 >=20 > "... free and open to anyone, allowing ..." >=20 > to keep them selves informed of any developments. If Q.3/13 desire t= o=20 >=20 > "... themselves ..." (unless that's a US-ism) >=20 > get further information about specific ongoing work, then please sen= d a=20 > liaison request to the responsible WG for those specific documents. >=20 > The following list is divided under the associated working groups fr= om=20 > which the work has been done within the IETF. >=20 > Dale >=20 Thanks, incorporated. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 02 08:33:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGZrm-0002EZ-8o; Thu, 02 Aug 2007 08:33:22 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IGKr4-00049O-UV for nsis-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 16:31:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKr4-000492-9e; Wed, 01 Aug 2007 16:31:38 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGKr3-0002Vr-T8; Wed, 01 Aug 2007 16:31:38 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070801203136b1400pgtsle>; Wed, 1 Aug 2007 20:31:37 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l71KVZ8t016569; Wed, 1 Aug 2007 16:31:35 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l71KVZBv016565; Wed, 1 Aug 2007 16:31:35 -0400 Date: Wed, 1 Aug 2007 16:31:35 -0400 Message-Id: <200708012031.l71KVZBv016565@dragon.ariadne.com> From: Dale.Worley@comcast.net To: magnus.westerlund@ericsson.com In-reply-to: <46AF5370.9020304@ericsson.com> (magnus.westerlund@ericsson.com) References: <46AF5370.9020304@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 02 Aug 2007 08:33:21 -0400 Cc: sip@ietf.org, sipping@ietf.org, tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Sip] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a response to the liaison request made by Q3/13 regarding It looks like that should be "Q.3/13". emergency telecommunications (REF: NGN-GSI/DOC – 60 Rev.2). We would first like to apologize for failing to meet the deadline in responding. We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG): IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has concluded. In addition to the WGs from which information was requested, we also think that work performed by the SIP and SIPPING WG may be of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and related work in the IETF regarding emergency communications, we list below RFCs and works in progress that we feel may be of interest to your group. Some of the completed work is Informational, and others are in the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in regards to emergency telecommunications. In those regards we would like to make you aware that IETF mailing list participation and document information is free and open for anyone. Allowing participants in Q.3/13 "... free and open to anyone, allowing ..." to keep them selves informed of any developments. If Q.3/13 desire to "... themselves ..." (unless that's a US-ism) get further information about specific ongoing work, then please send a liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from which the work has been done within the IETF. Dale _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 03 08:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGw4u-0002qV-Au; Fri, 03 Aug 2007 08:16:24 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IGkes-0003JI-U6 for nsis-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 20:04:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGkem-0003E5-Tc; Thu, 02 Aug 2007 20:04:41 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGkem-0006jy-0T; Thu, 02 Aug 2007 20:04:40 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l7304Ohr007049; Thu, 2 Aug 2007 19:04:24 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 19:04:24 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 02:04:21 +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: Fri, 3 Aug 2007 02:04:20 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014EED0F@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 onEmergency Telecommunications Thread-Index: AcfUV6mjGtO5TKErQSCBtjCYHVYrNAAx//qA References: <46B0955A.3040900@ericsson.com> From: "DRAGE, Keith \(Keith\)" To: "Janet P Gunn" , "Magnus Westerlund" X-OriginalArrivalTime: 03 Aug 2007 00:04:21.0197 (UTC) FILETIME=[D7C5FFD0:01C7D561] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Fri, 03 Aug 2007 08:16:22 -0400 Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [NSIS] RE: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 onEmergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org While I wish to make no comment on the inclusion of other documents, I would point out that the two drafts: draft-polk-sip-rph-new-namespaces-01 and draft-ietf-sip-rph-response were both discussed by the SIP WG and agreed that we would work on them. This is still awaiting AD approval of the new milestones, but apart from that, these are now essentially WG items. This does place them in a different position to other author drafts. Regards Keith ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Wednesday, August 01, 2007 5:19 PM To: Magnus Westerlund Cc: sip@ietf.org; IETF SIPPING WG; tsvwg; NSIS Subject: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 onEmergency Telecommunications =09 =09 =09 =09 =09 Magnus Westerlund wrote on 08/01/2007 10:14:50 AM: =09 > Janet P Gunn skrev: > >=20 > > Magnus, > >=20 > > You might want to add- > >=20 > > draft-polk-tsvwg-signaled-domain-id-00.txt >=20 > Well, I want to be somewhat restricted in adding individual work into=20 > the liaison. Also to me it is not clear how this is applicable in the=20 > emergency context.=20 =09 Well, you included draft-polk-sip-rph-new-namespaces-01, and draft-polk-tsvwg-signaled-domain-id-00 addresses the same scenarios. It would make sense to include either both or neither. >=20 > > and > > draft-polk-ecrit-local-emergency-rph-namespace-01.txt > > >=20 > Well, I got another comment about ECRIT WG document which we hadn't=20 > considered. I will contact the WG chairs and see what they say.=20 =09 Yes, ecrit should make the call. But I know at least one other stds body (PacketCable PKT2 0-SP-RSTF-D01-060330 TCHG) is addressing it. =09 Janet =09 >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- =09 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 03 08:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGwSe-00024j-IL; Fri, 03 Aug 2007 08:40:56 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IGwSc-00023E-BW for nsis-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 08:40:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGwSb-00021u-Vb; Fri, 03 Aug 2007 08:40:54 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGwSa-0001At-T2; Fri, 03 Aug 2007 08:40:53 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm10446b38725; Fri, 03 Aug 2007 20:52:26 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1746ae36b2; Tue, 31 Jul 2007 02:29:43 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 31 Jul 2007 02:29:42 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZmK-0005R0-Je; Mon, 30 Jul 2007 14:15:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZmH-0005P7-1R; Mon, 30 Jul 2007 14:15:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFZmG-00058N-Hm; Mon, 30 Jul 2007 14:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 646FE2AC6B; Mon, 30 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IFZlm-0007W4-2j; Mon, 30 Jul 2007 14:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 30 Jul 2007 14:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-15.txt X-BeenThere: nsis@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSLP for Quality-of-Service Signaling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-15.txt Pages : 97 Date : 2007-7-30 This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qos-nslp-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qos-nslp-15.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: <2007-7-30130540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-30130540.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Tue Aug 07 07:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIMqz-0000MC-25; Tue, 07 Aug 2007 07:03:57 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIMqy-0000M7-4h for nsis-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 07:03:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIMqx-0000Lz-Q7 for nsis@ietf.org; Tue, 07 Aug 2007 07:03:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIMqx-0008Og-0i for nsis@ietf.org; Tue, 07 Aug 2007 07:03:55 -0400 Received: (qmail invoked by alias); 07 Aug 2007 11:03:48 -0000 Received: from unknown (EHLO [10.41.156.35]) [82.113.121.1] by mail.gmx.net (mp045) with SMTP; 07 Aug 2007 13:03:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+CwOgcg4WC2E9ZqlU75jCbcMWnqrheQ28ahd5wDL 03BDL5Yeyosh8h Message-ID: <46B85190.1050308@gmx.net> Date: Tue, 07 Aug 2007 13:03:44 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" , cornelia.kappler@nsn.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [NSIS] "Encapsulated Initiator QSPEC" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Figure 3 at draft-ietf-nsis-qspec-17.txt gave me the impression that the "Encapsulated Initiator QSPEC" is dumped in some other container. Here is the figure: +--------------------------------+\ | QSPEC Type | \ +--------------------------------+ / Common QQSPEC Header | Init./Local QSPEC bit=Local |/ +================================+\ | Local-QSPEC Parameter 1 | \ +--------------------------------+ \ | .... | Local-QSPEC Parameters +--------------------------------+ / | Local-QSPEC Parameter n | / +--------------------------------+/ | +----------------------------+ | | | QSPEC Type | | | +----------------------------+ | | | Init./Local QSPEC bit=Init.| | | +============================+ | | | | | Encapsulated Initiator QSPEC | | .... | | | +----------------------------+ | +--------------------------------+ Here is an example how I believe it should look like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+====== | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|r|r|r| Object Type |r|r|r|r| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |1|E|0|r| 1 |r|r|r|r| 4 | Local +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QSPEC | TMOD Rate-1 [r] (32-bit IEEE floating point number) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TMOD Size-1 [b] (32-bit IEEE floating point number) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+====== | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|r|r|r| Object Type |r|r|r|r| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Init. |M|E|0|r| 14 |r|r|r|r| 1 | QSPEC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Y.1541 QoS Cls.| (Reserved) | v +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+====== Is this correct? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 07 08:40:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOMG-0007Sd-U4; Tue, 07 Aug 2007 08:40:20 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIOMG-0007SY-6O for nsis-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 08:40:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOMF-0007SQ-Rs for nsis@ietf.org; Tue, 07 Aug 2007 08:40:19 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIOMF-00033k-6l for nsis@ietf.org; Tue, 07 Aug 2007 08:40:19 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IIOMC-0005NA-9L; Tue, 07 Aug 2007 14:40:18 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IIOMB-0004yL-1b; Tue, 07 Aug 2007 14:40:16 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IIOMA-0004Oj-7h; Tue, 07 Aug 2007 14:40:14 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id AB6FB2FC015; Tue, 7 Aug 2007 14:40:13 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IIOM9-00067f-6K; Tue, 07 Aug 2007 14:40:13 +0200 Message-ID: <46B8682C.2060705@tm.uka.de> Date: Tue, 07 Aug 2007 14:40:12 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] "Encapsulated Initiator QSPEC" References: <46B85190.1050308@gmx.net> In-Reply-To: <46B85190.1050308@gmx.net> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: cornelia.kappler@nsn.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: , Errors-To: nsis-bounces@ietf.org Hannes Tschofenig wrote: > Hi all, > > Figure 3 at draft-ietf-nsis-qspec-17.txt gave me the impression that the > "Encapsulated Initiator QSPEC" is dumped in some other container. > > Here is the figure: > > +--------------------------------+\ > | QSPEC Type | \ > +--------------------------------+ / Common QQSPEC Header > | Init./Local QSPEC bit=Local |/ > +================================+\ > | Local-QSPEC Parameter 1 | \ > +--------------------------------+ \ > | .... | Local-QSPEC Parameters > +--------------------------------+ / > | Local-QSPEC Parameter n | / > +--------------------------------+/ > | +----------------------------+ | > | | QSPEC Type | | > | +----------------------------+ | > | | Init./Local QSPEC bit=Init.| | > | +============================+ | > | | | | Encapsulated Initiator QSPEC > | | .... | | > | +----------------------------+ | > +--------------------------------+ > > > Here is an example how I believe it should look like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+====== > | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |E|r|r|r| Object Type |r|r|r|r| Length | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |1|E|0|r| 1 |r|r|r|r| 4 | Local > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QSPEC > | TMOD Rate-1 [r] (32-bit IEEE floating point number) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | TMOD Size-1 [b] (32-bit IEEE floating point number) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+====== > | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |E|r|r|r| Object Type |r|r|r|r| Length | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Init. > |M|E|0|r| 14 |r|r|r|r| 1 | QSPEC > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |Y.1541 QoS Cls.| (Reserved) | v > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+====== > > Is this correct? Yep. At least to my understanding. But different layouts are possible, too. The only thing is that you must know how long your local QSPEC data is and where the Initiator QSPEC starts. The offset may be fixed for some local QSPECs. Whether you use another container for encapsulating the Initiator QSPEC or not like above depends on your local QSPEC design. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 07 08:43:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOPF-00082a-HK; Tue, 07 Aug 2007 08:43:25 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIOPD-00082T-VB for nsis-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 08:43:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOPD-00082L-L0 for nsis@ietf.org; Tue, 07 Aug 2007 08:43:23 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIOPD-0003C2-AL for nsis@ietf.org; Tue, 07 Aug 2007 08:43:23 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IIOPA-0005hl-Sa; Tue, 07 Aug 2007 14:43:22 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IIOP9-0005LK-Id; Tue, 07 Aug 2007 14:43:20 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IIOP9-0004r0-94; Tue, 07 Aug 2007 14:43:19 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 059602FC015; Tue, 7 Aug 2007 14:43:18 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IIOP7-00067v-Ls; Tue, 07 Aug 2007 14:43:17 +0200 Message-ID: <46B868E4.8010108@tm.uka.de> Date: Tue, 07 Aug 2007 14:43:16 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST: Responding Node D-Mode to C-Mode upgrade? References: <46AF4C4E.8080701@tm.uka.de> In-Reply-To: <46AF4C4E.8080701@tm.uka.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: nsis-bounces@ietf.org Hi Robert, Roland Bless wrote: > Problem: in case a responding node has > to send a payload larger than the MAX_MTU size, it > currently cannot upgrade the session from D-Mode > to C-mode, because it is a responding node. Just as an add-on: The same is true for upgrading from unsecure to secure mode. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 07 09:22:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIP1C-0000A7-N1; Tue, 07 Aug 2007 09:22:38 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIP1B-0000A0-UF for nsis-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 09:22:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIP1B-00009o-K3 for nsis@ietf.org; Tue, 07 Aug 2007 09:22:37 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIP1B-0005kp-2c for nsis@ietf.org; Tue, 07 Aug 2007 09:22:37 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IIP18-0002HY-AQ; Tue, 07 Aug 2007 15:22:36 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IIP17-0001ey-2o; Tue, 07 Aug 2007 15:22:34 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IIP16-0002IC-S3; Tue, 07 Aug 2007 15:22:32 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6F09A2FC014; Tue, 7 Aug 2007 15:22:32 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IIP15-0006E9-V0; Tue, 07 Aug 2007 15:22:32 +0200 Message-ID: <46B87217.40508@tm.uka.de> Date: Tue, 07 Aug 2007 15:22:31 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "nsis@ietf.org" Subject: [NSIS] Querier Node SM X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, what would be the correct state in the Querying SM (section 6.2) when state is already established and tg_NSLPData requires upgrading from D-Mode to C-Mode or from unsecure C-Mode to secure C-Mode? Would it be Awaiting Refresh or Awaiting Response? Since this Query/Response/Confirm handshake is not a refresh I would say it's more Awaiting Response. This is currently not shown in the SM. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 07 11:13:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQkC-0003lL-1s; Tue, 07 Aug 2007 11:13:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIQkA-0003lA-1R for nsis-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:13:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQk9-0003jV-MG for nsis@ietf.org; Tue, 07 Aug 2007 11:13:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIQk9-0003R8-Ct for nsis@ietf.org; Tue, 07 Aug 2007 11:13:09 -0400 Received: (qmail invoked by alias); 07 Aug 2007 15:13:06 -0000 Received: from unknown (EHLO [10.41.3.150]) [82.113.121.1] by mail.gmx.net (mp036) with SMTP; 07 Aug 2007 17:13:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19KK4wsSZ1Ki+rRiIC2QraBSlnr68OiXX/XyUVLV3 BIDIYI5Mk1uUEU Message-ID: <46B88C07.1070509@gmx.net> Date: Tue, 07 Aug 2007 17:13:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [NSIS] draft-ietf-nsis-y1541-qosm-04.txt Comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I read through the draft and I have only one high-level comment: I noticed that this document does not fulfill the minimum requirements for a QOSM specification listed in Section 4.1 of draft-ietf-nsis-qspec-17.txt Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 07 11:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQkh-00045L-PN; Tue, 07 Aug 2007 11:13:43 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIQkg-00045C-HN for nsis-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:13:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQkg-000453-7H for nsis@ietf.org; Tue, 07 Aug 2007 11:13:42 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIQkf-0003SK-Lg for nsis@ietf.org; Tue, 07 Aug 2007 11:13:42 -0400 Received: (qmail invoked by alias); 07 Aug 2007 15:13:38 -0000 Received: from unknown (EHLO [10.41.3.150]) [82.113.121.1] by mail.gmx.net (mp020) with SMTP; 07 Aug 2007 17:13:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Cey056TMCm/1HoS28YBRfEJdOmMQ1Vm++sV33O3 Hnb6qJmivcFJzg Message-ID: <46B88C25.20007@gmx.net> Date: Tue, 07 Aug 2007 17:13:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Xiaoming Fu , cornelia.kappler@nsn.com Subject: [NSIS] Controlled Load QOSM Comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I went through . This document is in good shape. Still, I have a few comments: * Section 5.: Requirements for QOSM specification is not inline with the text in Section 4.1 of draft-ietf-nsis-qspec-17.txt * Section 5.2.2. QSPEC Objects There are two TMOD parameters in draft-ietf-nsis-qspec-17.txt. You only talk about TMOD as there would be only one. * is required for receiver-initiated reservations, and MAY be used in sender-initiated reservations. Section 5.3.2 of draft-ietf-nsis-qspec-17.txt does not indicate that QoS Available is optional for receiver-initiated reservations. * Among them, and MUST be supported by all QOSM implementations, as defined in [3]. I thought that all need to be implemented and understood by a QoS aware node. * is optional. optional to implement or optional to use? * I am not sure I understand your text in Section 6.1. It seems that you compute the admission control decision as a comparison between TMOD parameters rather than the TMOD parameter received with the RESERVE message against the available resources. * Section 7: Preemption Isn't the problem to determine which reservation to terminate rather than the actual act of terminating a reservation. * Section 9: "This Internet Draft raises no new security issues." I would write. "This document does not raise additional security issues beyond those described in [QoS-NSLP]." Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 07 11:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQl7-0004E1-GM; Tue, 07 Aug 2007 11:14:09 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIQl5-0004Dl-Kd for nsis-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:14:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQl5-0004Dd-Aa for nsis@ietf.org; Tue, 07 Aug 2007 11:14:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIQl5-0003TA-1c for nsis@ietf.org; Tue, 07 Aug 2007 11:14:07 -0400 Received: (qmail invoked by alias); 07 Aug 2007 15:14:05 -0000 Received: from unknown (EHLO [10.41.3.150]) [82.113.121.1] by mail.gmx.net (mp049) with SMTP; 07 Aug 2007 17:14:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19FEMo3ABtFKJjYC1vNzgTtSDMQOIPAzg1paftv64 +ysV/ipGip35V7 Message-ID: <46B88C42.8090104@gmx.net> Date: Tue, 07 Aug 2007 17:14:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [NSIS] QSPEC Extensibility Question X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Reading through the QSPEC draft I have a question: Is it allowed to define new QoS parameters without defining a QOSM? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 08 04:59:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhMg-00079X-7u; Wed, 08 Aug 2007 04:58:02 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIhMf-00079R-1S for nsis-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 04:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIhMe-00079F-Ex for nsis@ietf.org; Wed, 08 Aug 2007 04:58:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIhMd-0002M4-45 for nsis@ietf.org; Wed, 08 Aug 2007 04:58:00 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 34986215E8; Wed, 8 Aug 2007 10:57:58 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-99-46b98596e6d4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 18B26211FF; Wed, 8 Aug 2007 10:57:58 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 10:57:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 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 Extensibility Question Date: Wed, 8 Aug 2007 10:57:57 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E91D08524@esealmw116.eemea.ericsson.se> In-Reply-To: <46B88C42.8090104@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Extensibility Question Thread-Index: AcfZBZxsCkAsgz7LTwS1KhywBPVWUgAkoBZw References: <46B88C42.8090104@gmx.net> From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Hannes Tschofenig" , X-OriginalArrivalTime: 08 Aug 2007 08:57:57.0713 (UTC) FILETIME=[372B6410:01C7D99A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: nsis-bounces@ietf.org Hi Hannes,=20 I assume not. My understanding is that if you want to use a new = parameter with NSIS you need to specify how to interprete it in = different conditions, which is actually a QOSM. On the other hand you = need a parameter ID from IANA, that should be specified in also this = doc. Best regards, Attila >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Tuesday, August 07, 2007 5:14 PM >To: nsis@ietf.org >Subject: [NSIS] QSPEC Extensibility Question > >Reading through the QSPEC draft I have a question: > >Is it allowed to define new QoS parameters without defining a QOSM? > >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 Aug 08 06:19:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIicC-0007rS-0C; Wed, 08 Aug 2007 06:18:08 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIicA-0007rG-DG for nsis-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 06:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIicA-0007r8-3Z for nsis@ietf.org; Wed, 08 Aug 2007 06:18:06 -0400 Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIic8-0004E7-Nw for nsis@ietf.org; Wed, 08 Aug 2007 06:18:06 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id D0DEEB8180 for ; Wed, 8 Aug 2007 12:18:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from [137.194.20.26] (pptp20-26.enst.fr [137.194.20.26]) by smtp2.enst.fr (Postfix) with ESMTP id 91BE1B81A0 for ; Wed, 8 Aug 2007 12:18:03 +0200 (CEST) Message-ID: <46B99857.2020502@enst.fr> Date: Wed, 08 Aug 2007 12:17:59 +0200 From: LIN hai User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] RESERVE message delay X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi everybody, I am working on analyzing NSIS performance. Could anybody give me some ideal about one hop delay for different type of RESERVE messages? These delays should consider different operations for different messages. For example, creating RESERVE message should consider the time needed for policy control and admission control, and the time needed to create routing state if none of existing routing states can be reused, while refresh RESERVE need not consider all above procedures. Your help will be appreciated Hai LIN _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 08 08:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIl5Z-0001lK-ML; Wed, 08 Aug 2007 08:56:37 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIl5W-0001ke-8c for nsis-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 08:56:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIl5V-0001kV-V9 for nsis@ietf.org; Wed, 08 Aug 2007 08:56:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIl5U-0007ft-CQ for nsis@ietf.org; Wed, 08 Aug 2007 08:56:33 -0400 Received: (qmail 8618 invoked by uid 0); 8 Aug 2007 12:56:31 -0000 Received: from 82.113.106.1 by www027.gmx.net with HTTP; Wed, 08 Aug 2007 14:56:31 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 08 Aug 2007 14:56:31 +0200 From: "Hannes Tschofenig" In-Reply-To: <53CCFDD6E346CB43994852666C210E91D08524@esealmw116.eemea.ericsson.se> Message-ID: <20070808125631.76850@gmx.net> MIME-Version: 1.0 References: <46B88C42.8090104@gmx.net> <53CCFDD6E346CB43994852666C210E91D08524@esealmw116.eemea.ericsson.se> Subject: Re: RE: [NSIS] QSPEC Extensibility Question To: =?iso-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , nsis@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+DnslAqmaDFi8nnRbh3apLgPOsS5i8/QQCjuvF3n XjQgBY7DY3ppofeT1+rn5EilGHtJavdP3eSg== Content-Transfer-Encoding: 8bit X-GMX-UID: GdnRCz5/bHIhQ4Fb+zU0IXYiJihyapCv X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: nsis-bounces@ietf.org Hmm. I wonder what other WG members think. Strictly speaking, the QSPEC document also defines QoS parameters without being a QOSM. My question, however, is more from the background of the current work in DIME and the usage of the QSPEC there. It would be very helpful for me to have a very clear answer to this question since it will have an impact on the DIME documents since we envision extensions being defined that do not have any relationship to NSIS as well. Ciao Hannes -------- Original-Nachricht -------- Datum: Wed, 8 Aug 2007 10:57:57 +0200 Von: "Attila Báder (IJ/ETH)" An: "Hannes Tschofenig" , nsis@ietf.org Betreff: RE: [NSIS] QSPEC Extensibility Question > Hi Hannes, > > I assume not. My understanding is that if you want to use a new parameter > with NSIS you need to specify how to interprete it in different conditions, > which is actually a QOSM. On the other hand you need a parameter ID from > IANA, that should be specified in also this doc. > > Best regards, Attila > > >-----Original Message----- > >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >Sent: Tuesday, August 07, 2007 5:14 PM > >To: nsis@ietf.org > >Subject: [NSIS] QSPEC Extensibility Question > > > >Reading through the QSPEC draft I have a question: > > > >Is it allowed to define new QoS parameters without defining a QOSM? > > > >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 Aug 08 09:32:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlcf-0002JE-Ot; Wed, 08 Aug 2007 09:30:49 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIlce-0002J8-Ai for nsis-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 09:30:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlcd-0002Iy-WF for nsis@ietf.org; Wed, 08 Aug 2007 09:30:48 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIlcd-0007Oj-IA for nsis@ietf.org; Wed, 08 Aug 2007 09:30:47 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 08 Aug 2007 06:30:46 -0700 X-IronPort-AV: i="4.19,236,1183359600"; d="scan'208"; a="12591053:sNHT22995456" Received: from [10.32.245.154] ([10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l78CAGAG021938; Wed, 8 Aug 2007 05:10:16 -0700 In-Reply-To: <20070808125631.76850@gmx.net> References: <46B88C42.8090104@gmx.net> <53CCFDD6E346CB43994852666C210E91D08524@esealmw116.eemea.ericsson.se> <20070808125631.76850@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [NSIS] QSPEC Extensibility Question Date: Wed, 8 Aug 2007 09:30:41 -0400 To: "Hannes Tschofenig" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2451; t=1186575017; x=1187439017; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20QSPEC=20Extensibility=20Question |Sender:=20 |To:=20=22Hannes=20Tschofenig=22=20; bh=7S49VIPx048FpWyBd7Rqi+4vBD+/3ZMRsr/AgMdtd9g=; b=Ipfc24SLGzK1niY/EnLH8uD3QMHRsw4vvoXmSN63F6FlktXn06YfRKsUefcl3ev9hUbxWXSX s1YtswQwgv/z1ZIEmlVqynYG/fYc3SNOpNIKqSU/aJlb3kPe4bM7+Gpv; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: nsis@ietf.org, =?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: , Errors-To: nsis-bounces@ietf.org On Aug 8, 2007, at 8:56 AM, Hannes Tschofenig wrote: > Hmm. > > I wonder what other WG members think. > > Strictly speaking, the QSPEC document also defines QoS parameters =20 > without being a QOSM. > What seems relevant is what you have to do from a standardization and =20= interoperability point of view to extend NSIS, in this case by adding =20= QoS parameters. I think the intent is that you have to write a =20 standards-track RFC to add QoS parameters or make other extensions to =20= a QSPEC. Whether doing so constitutes a new or modified QOSM seems of =20= secondary importance, and is possibly irrelevant (depending on one's =20 opinions on the importance of QOSMs to the NSIS design). > My question, however, is more from the background of the current =20 > work in DIME and the usage of the QSPEC there. > > It would be very helpful for me to have a very clear answer to this =20= > question since it will have an impact on the DIME documents since =20 > we envision extensions being defined that do not have any =20 > relationship to NSIS as well. > > Ciao > Hannes > > > -------- Original-Nachricht -------- > Datum: Wed, 8 Aug 2007 10:57:57 +0200 > Von: "Attila B=E1der (IJ/ETH)" > An: "Hannes Tschofenig" , nsis@ietf.org > Betreff: RE: [NSIS] QSPEC Extensibility Question > >> Hi Hannes, >> >> I assume not. My understanding is that if you want to use a new =20 >> parameter >> with NSIS you need to specify how to interprete it in different =20 >> conditions, >> which is actually a QOSM. On the other hand you need a parameter =20 >> ID from >> IANA, that should be specified in also this doc. >> >> Best regards, Attila >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Tuesday, August 07, 2007 5:14 PM >>> To: nsis@ietf.org >>> Subject: [NSIS] QSPEC Extensibility Question >>> >>> Reading through the QSPEC draft I have a question: >>> >>> Is it allowed to define new QoS parameters without defining a QOSM? >>> >>> Ciao >>> Hannes >>> >>> >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 08 09:36:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlgs-0006Ld-J1; Wed, 08 Aug 2007 09:35:10 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIlgr-0006LX-IL for nsis-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 09:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIlgr-0006LJ-8V for nsis@ietf.org; Wed, 08 Aug 2007 09:35:09 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIlgp-0000L6-Q3 for nsis@ietf.org; Wed, 08 Aug 2007 09:35:09 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IIlgm-0007HU-Rn; Wed, 08 Aug 2007 15:35:06 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IIlgl-000601-In; Wed, 08 Aug 2007 15:35:04 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IIlgk-0005OE-Gg; Wed, 08 Aug 2007 15:35:02 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C56832FC014; Wed, 8 Aug 2007 15:35:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IIlgi-0007qW-FO; Wed, 08 Aug 2007 15:35:00 +0200 Message-ID: <46B9C683.7060205@tm.uka.de> Date: Wed, 08 Aug 2007 15:34:59 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST Draft-14 Refresh/Confirm References: <46AF0433.3060606@tm.uka.de> In-Reply-To: <46AF0433.3060606@tm.uka.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: nsis-bounces@ietf.org Hi Robert, Roland Bless wrote: > - Is it necessary for a _refreshing_ Query to contain > a stack proposal in order to indicate C-mode usage? This one is easier than I thought. The answer is yes, because this is essentially the GIST probing mechanism and may hit/discover a new peer. So the refreshing Query for C-Mode usage needs to carry stack proposal. This could be added to the SPEC. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 08 12:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIoBk-0006ST-1k; Wed, 08 Aug 2007 12:15:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IIoBb-0006IL-SQ for nsis-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 12:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIoBb-0006HJ-Gw; Wed, 08 Aug 2007 12:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIoBa-0004A0-CK; Wed, 08 Aug 2007 12:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 583B5328DC; Wed, 8 Aug 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IIoBa-00081l-8T; Wed, 08 Aug 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Aug 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-11.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: , 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-11.txt Pages : 97 Date : 2007-8-8 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 pre-emption 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-11.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-11.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-11.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: <2007-8-8114542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-8114542.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Thu Aug 09 05:08:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3y8-0007jV-Be; Thu, 09 Aug 2007 05:06:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IJ3y6-0007jQ-TW for nsis-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 05:06:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3y6-0007jI-IK for nsis@ietf.org; Thu, 09 Aug 2007 05:06:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJ3y4-0005Bo-VX for nsis@ietf.org; Thu, 09 Aug 2007 05:06:10 -0400 Received: (qmail invoked by alias); 09 Aug 2007 09:06:04 -0000 Received: from unknown (EHLO [10.41.54.69]) [82.113.121.1] by mail.gmx.net (mp039) with SMTP; 09 Aug 2007 11:06:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+E+zEpC6KE066GoS388+BlQOsb+HKo7OwNJsXcXg 4vwHXfDb+9/H+l Message-ID: <46BAD903.7080807@gmx.net> Date: Thu, 09 Aug 2007 11:06:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [NSIS] QoS NSLP -- 4.7. Reduced State or Stateless Interior Nodes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I do not quite understand how the stateless interior nodes work. I understand that you do not store GIST state for reverse routing. I also understand that there is a desire not to install per-flow reservations. But if there is no state stored at all, as mentioned in Section 4.7 of the QoS NSLP, then what's the point of signaling? I also believe that Section 4.7 is missing an important point: If a reservation request fails then the RESERVE message is forwarded until it hits the egress node. In standard QoS NSLP operation a RESPONSE message would be returned immediately when an error is detected. Here is a figure: Please view in a fixed-width font such as Courier. QNE QNE QNE QNE ingress interior interior egress GIST stateful GIST stateless GIST stateless GIST stateful | A B | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | RESPONSE' | |<---------------------------------------------+ | | | | RESERVE | | | +--------> | | | | RESPONSE | | | |<-------- | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | Assume that the RESERVE' message fails at node A. Then, a RESPONSE cannot be sent back to the ingress but instead the message continues its way towards the egress node. It is, however, necessary to mark the message in a way that subsequent nodes (in this case node B) does not attempt to make a reservation but just forwards the message as is. When the egress node receives the message it then constructs a RESPONSE' message indicating the failure of the reservation attempt. This procedure requires additional protocol mechanisms to support a) marking a message as failed b) allow the state machine to forward the message in this particular mode even though the reservation failed. I don't see any of these things in the document. A bug or intention? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 09 07:07:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ5pE-0002MA-Vd; Thu, 09 Aug 2007 07:05:08 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IJ5pD-0002M2-G4 for nsis-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 07:05:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ5pC-0002LI-BU for nsis@ietf.org; Thu, 09 Aug 2007 07:05:06 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IJ5p8-0000Ca-UF for nsis@ietf.org; Thu, 09 Aug 2007 07:05:03 -0400 Received: (qmail invoked by alias); 09 Aug 2007 11:04:59 -0000 Received: from unknown (EHLO [10.42.198.246]) [82.113.121.1] by mail.gmx.net (mp045) with SMTP; 09 Aug 2007 13:04:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/zs3kJthrzA0B2SGM0jBN24gwb5uTL8CV8CJ8zmN xBG0YUFXtf/8X7 Message-ID: <46BAF4E2.5030208@gmx.net> Date: Thu, 09 Aug 2007 13:05:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [NSIS] INFO_SPEC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Section 5.1.3.6 of the draft-ietf-nsis-qos-nslp-15.txt specifies the INFO_SPEC. For the Object Value Info the text says: Offset: The byte in the object at which the QNE found the error. When this byte is set to "0", the complete object is included. I assume that the entire object is always included but when the value of '0' is put in there then it means that the entire object was broken rather than a specific value inside the object. Correct? If so, then you might want to change the sentence from above slightly. You also say: " This object carries information about a TLV object which was found to be invalid in the original message. An error message may contain more than one Object Value Info object. " With "this object" I assume you refer to the invalid object rather than to the entire Object Value Info object. The latter sentence, however, confuses me. Do you refer to the fact that an RESPONSE message may contain more than one INFO_SPEC object or to the fact that one INFO_SPEC object may contain multiple Object Value Info objects or that the Object Value Info object may contain multiple invalid objects (unless the length field of the invalid object became invalid -- which is pretty easy to check). Ciao Hannes Btw, the figure corresponding to Error Source Identifier Type: 0x02 is garbled. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 09 07:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ624-0005kF-Sn; Thu, 09 Aug 2007 07:18:24 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IJ623-0005kA-AP for nsis-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 07:18:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ623-0005k2-0a for nsis@ietf.org; Thu, 09 Aug 2007 07:18:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IJ622-0000UA-ID for nsis@ietf.org; Thu, 09 Aug 2007 07:18:22 -0400 Received: (qmail invoked by alias); 09 Aug 2007 11:18:17 -0000 Received: from unknown (EHLO [10.42.198.246]) [82.113.121.1] by mail.gmx.net (mp058) with SMTP; 09 Aug 2007 13:18:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/lJ/UL7Fbli6+yOBbkEx7fjrB4ZrEV7A1YYfvUXQ FDV41yl+xFdjmD Message-ID: <46BAF7F1.30702@gmx.net> Date: Thu, 09 Aug 2007 13:18:09 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] draft-ietf-nsis-tunnel-02.txt Comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I have read through draft-ietf-nsis-tunnel-02.txt and here are a few comments: * I don't know why you need the "Tunnel Signaling Capability Discovery" * The document should not contain RFC 2119 language since the base functionality is already in GIST and in the NSLPs. * In many sections I got the impression that there is no real conclusion or suggestion since there cannot be one. The right answer to many of the issues is "It depends on the deployment and some policy decisions". Hence, I wasn't quite sure how much value a lot of text will be for the reader at the end. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 09 08:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ6vE-0001CO-KK; Thu, 09 Aug 2007 08:15:24 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IJ6vD-00017y-7B for nsis-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 08:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ6vB-00016l-Ac for nsis@ietf.org; Thu, 09 Aug 2007 08:15:22 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ6v9-0000NQ-Qw for nsis@ietf.org; Thu, 09 Aug 2007 08:15:21 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l79CFILL005306; Thu, 9 Aug 2007 14:15:18 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l79CFHMU022119; Thu, 9 Aug 2007 14:15:18 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 14:15:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Aug 2007 14:15:10 +0200 Message-ID: In-Reply-To: <46B85190.1050308@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Encapsulated Initiator QSPEC" Thread-Index: AcfY4qdzzzLKI0NqQ/KD9sZZW3d7dQBnD68w References: <46B85190.1050308@gmx.net> From: "Kappler, Cornelia" To: "ext Hannes Tschofenig" , X-OriginalArrivalTime: 09 Aug 2007 12:15:15.0135 (UTC) FILETIME=[F13C64F0:01C7DA7E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [NSIS] AW: "Encapsulated Initiator QSPEC" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org ...looks ok to me this way. Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Dienstag, 7. August 2007 13:04 > An: nsis@ietf.org; Kappler, Cornelia > Betreff: "Encapsulated Initiator QSPEC" >=20 > Hi all, >=20 > Figure 3 at draft-ietf-nsis-qspec-17.txt gave me the=20 > impression that the=20 > "Encapsulated Initiator QSPEC" is dumped in some other container. >=20 > Here is the figure: >=20 > +--------------------------------+\ > | QSPEC Type | \ > +--------------------------------+ / Common QQSPEC Header > | Init./Local QSPEC bit=3DLocal |/ > = +=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+\ > | Local-QSPEC Parameter 1 | \ > +--------------------------------+ \ > | .... | Local-QSPEC Parameters > +--------------------------------+ / > | Local-QSPEC Parameter n | / > +--------------------------------+/ > | +----------------------------+ | > | | QSPEC Type | | > | +----------------------------+ | > | | Init./Local QSPEC bit=3DInit.| | > | = +=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+ | > | | | | Encapsulated Initiator QSPEC > | | .... | | > | +----------------------------+ | > +--------------------------------+ >=20 >=20 > Here is an example how I believe it should look like: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+=3D=3D=3D=3D=3D=3D > | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |E|r|r|r| Object Type |r|r|r|r| Length | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |1|E|0|r| 1 |r|r|r|r| 4 =20 > | Local > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ QSPEC > | TMOD Rate-1 [r] (32-bit IEEE floating point number) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | TMOD Size-1 [b] (32-bit IEEE floating point number) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+=3D=3D=3D=3D=3D=3D > | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |E|r|r|r| Object Type |r|r|r|r| Length | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ Init. > |M|E|0|r| 14 |r|r|r|r| 1 =20 > | QSPEC > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > |Y.1541 QoS Cls.| (Reserved) | v > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+=3D=3D=3D=3D=3D=3D >=20 > Is this correct? >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 10 14:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZFs-0004Nd-TH; Fri, 10 Aug 2007 14:30:36 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IJZFr-0004NX-8J for nsis-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 14:30:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZFq-0004NO-Tk for nsis@ietf.org; Fri, 10 Aug 2007 14:30:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IJZFq-0002XJ-2M for nsis@ietf.org; Fri, 10 Aug 2007 14:30:34 -0400 Received: (qmail 20927 invoked by uid 0); 10 Aug 2007 18:30:32 -0000 Received: from 82.113.106.1 by www075.gmx.net with HTTP; Fri, 10 Aug 2007 20:30:32 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 10 Aug 2007 20:30:32 +0200 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20070810183032.36650@gmx.net> MIME-Version: 1.0 References: <46B85190.1050308@gmx.net> To: "Kappler, Cornelia" , nsis@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19u0nskR5tukk5UhxVqSSNQpKhvzPjmHS0ywAxfpt kORjfWIWfOQKsTzXpSHqNPMrDuKhdzcHa0RQ== Content-Transfer-Encoding: 8bit X-GMX-UID: /JyOdWA5PTR+C8RQ8zMwgE85c2tpZAuq X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [NSIS] AW: "Encapsulated Initiator QSPEC" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Does the first length field cover the length of the local QSPEC only or the entire length of the two objects, namely the local and the initiator QSPEC? Ciao Hannes -------- Original-Nachricht -------- Datum: Thu, 9 Aug 2007 14:15:10 +0200 Von: "Kappler, Cornelia" An: "ext Hannes Tschofenig" , nsis@ietf.org Betreff: AW: "Encapsulated Initiator QSPEC" > ...looks ok to me this way. Cornelia > > > -----Ursprüngliche Nachricht----- > > Von: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Dienstag, 7. August 2007 13:04 > > An: nsis@ietf.org; Kappler, Cornelia > > Betreff: "Encapsulated Initiator QSPEC" > > > > Hi all, > > > > Figure 3 at draft-ietf-nsis-qspec-17.txt gave me the > > impression that the > > "Encapsulated Initiator QSPEC" is dumped in some other container. > > > > Here is the figure: > > > > +--------------------------------+\ > > | QSPEC Type | \ > > +--------------------------------+ / Common QQSPEC Header > > | Init./Local QSPEC bit=Local |/ > > +================================+\ > > | Local-QSPEC Parameter 1 | \ > > +--------------------------------+ \ > > | .... | Local-QSPEC Parameters > > +--------------------------------+ / > > | Local-QSPEC Parameter n | / > > +--------------------------------+/ > > | +----------------------------+ | > > | | QSPEC Type | | > > | +----------------------------+ | > > | | Init./Local QSPEC bit=Init.| | > > | +============================+ | > > | | | | Encapsulated Initiator QSPEC > > | | .... | | > > | +----------------------------+ | > > +--------------------------------+ > > > > > > Here is an example how I believe it should look like: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+====== > > | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > |E|r|r|r| Object Type |r|r|r|r| Length | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > |1|E|0|r| 1 |r|r|r|r| 4 > > | Local > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ QSPEC > > | TMOD Rate-1 [r] (32-bit IEEE floating point number) | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | TMOD Size-1 [b] (32-bit IEEE floating point number) | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | v > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+====== > > | Vers.|Q.Type | QSPEC Proc. |I|R|R|R| Length | ^ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > |E|r|r|r| Object Type |r|r|r|r| Length | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ Init. > > |M|E|0|r| 14 |r|r|r|r| 1 > > | QSPEC > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > |Y.1541 QoS Cls.| (Reserved) | v > > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > > --+====== > > > > Is this correct? > > > > Ciao > > Hannes > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 10 15:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZwB-0004ca-9R; Fri, 10 Aug 2007 15:14:19 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IJZw9-0004cV-Hg for nsis-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 15:14:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZw9-0004cM-7g for nsis@ietf.org; Fri, 10 Aug 2007 15:14:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IJZw8-0003X1-OO for nsis@ietf.org; Fri, 10 Aug 2007 15:14:16 -0400 Received: (qmail invoked by alias); 10 Aug 2007 19:14:12 -0000 Received: from unknown (EHLO [10.41.168.149]) [82.113.121.1] by mail.gmx.net (mp030) with SMTP; 10 Aug 2007 21:14:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19FYSw9s+dFmXxDxFLpZuU8j0lm9oea0SMOVm88pq bx7nfCeaOHlqh2 Message-ID: <46BCB911.4050600@gmx.net> Date: Fri, 10 Aug 2007 21:14:25 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [NSIS] Y.1541 Question X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org For the Y.1541 QOSM which QSPEC parameters are mandatory to include in a RESERVE message? Is there a short and easy to read paper about Y.1541 somewhere? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Aug 12 14:58:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKIc5-0007NC-28; Sun, 12 Aug 2007 14:56:33 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IKIc3-0007GM-DQ for nsis-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 14:56:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKIc3-0007E2-2v for nsis@ietf.org; Sun, 12 Aug 2007 14:56:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKIc2-0007DS-CV for nsis@ietf.org; Sun, 12 Aug 2007 14:56:30 -0400 Received: (qmail invoked by alias); 12 Aug 2007 18:56:28 -0000 Received: from unknown (EHLO [192.168.1.2]) [84.152.72.82] by mail.gmx.net (mp032) with SMTP; 12 Aug 2007 20:56:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18+p1FGa9Y+F3I3e0S0nY8gfTAjGKLk+ckC3QNr8T DaY7TzYeQ1M4r6 Message-ID: <46BF57EB.9040805@gmx.net> Date: Sun, 12 Aug 2007 20:56:43 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [NSIS] The QSPEC draft violates 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: , Errors-To: nsis-bounces@ietf.org Strictly speaking the QSPEC document with the currently defined QSPEC hiding procedure violates the QoS NSLP draft: The QoS NSLP draft defines the RESERVE and the RESPONSE as follows: RESERVE = COMMON_HEADER RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] [ SESSION_ID_LIST [ RSN_LIST ] ] [ MSG_ID / BOUND_MSG_ID ] [ INFO_SPEC ] [ [ PACKET_CLASSIFIER ] QSPEC ] RESPONSE = COMMON_HEADER [ RII / RSN ] INFO_SPEC [SESSION_ID_LIST [ RSN_LIST ] ] [ QSPEC ] I assume that the QSPEC hiding is applicable for the QUERY and the NOTIFY message as well. The QSPEC may appear 0 or 1 times. With the QSPEC hiding it would be correct to indicate for the RESERVE and the RESPONSE that the object may appear 0 to 2 times. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Aug 12 22:18:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKPUH-0007ux-SO; Sun, 12 Aug 2007 22:16:57 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IKPUG-0007ur-CD for nsis-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 22:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKPUG-0007uj-2e for nsis@ietf.org; Sun, 12 Aug 2007 22:16:56 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKPUF-0006hl-PQ for nsis@ietf.org; Sun, 12 Aug 2007 22:16:56 -0400 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-146.messagelabs.com!1186971410!7516382!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 28441 invoked from network); 13 Aug 2007 02:16:50 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-6.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 13 Aug 2007 02:16:50 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7D2Gn6X006027 for ; Sun, 12 Aug 2007 19:16:49 -0700 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7D2GlAI006020 for ; Sun, 12 Aug 2007 19:16:47 -0700 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7D2Glkg022583 for ; Sun, 12 Aug 2007 19:16:47 -0700 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7D2Gig0022570 for ; Sun, 12 Aug 2007 19:16:44 -0700 Message-Id: <200708130216.l7D2Gig0022570@flph023.ffdc.sbc.com> Received: from acmt.att.com (unknown[135.210.97.219](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20070813021643gw10010gf9e>; Mon, 13 Aug 2007 02:16:43 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Aug 2007 22:15:44 -0400 To: Hannes Tschofenig , "nsis@ietf.org" From: Al Morton Subject: Re: [NSIS] Y.1541 Question In-Reply-To: <46BCB911.4050600@gmx.net> References: <46BCB911.4050600@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.5 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: nsis-bounces@ietf.org At 03:14 PM 8/10/2007, Hannes Tschofenig wrote: >For the Y.1541 QOSM which QSPEC parameters are mandatory to include >in a RESERVE message? I think it depends on the class you wish to reserve, since some classes don't use all parameters. >Is there a short and easy to read paper about Y.1541 somewhere? Neal Seitz wrote a tutorial in the June 2003 IEEE Comm Mag. Al _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 13 03:39:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKUV2-0006I9-D1; Mon, 13 Aug 2007 03:38:04 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IKUV1-0006I2-BT for nsis-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 03:38:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKUUx-0006Hk-LE for nsis@ietf.org; Mon, 13 Aug 2007 03:37:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKUUw-0003Hk-RQ for nsis@ietf.org; Mon, 13 Aug 2007 03:37:59 -0400 Received: (qmail invoked by alias); 13 Aug 2007 07:37:57 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp049) with SMTP; 13 Aug 2007 09:37:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ih4pa+OHiP3XTBRDztABOhnfA17Wt/JX8jmzblr LrDZ5ZNNwb8PoE Message-ID: <46C00A3D.60808@gmx.net> Date: Mon, 13 Aug 2007 09:37:33 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Al Morton Subject: Re: [NSIS] Y.1541 Question References: <46BCB911.4050600@gmx.net> <200708130216.l7D2GiHh030103@mlph070.sfdc.sbc.com> In-Reply-To: <200708130216.l7D2GiHh030103@mlph070.sfdc.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: nsis-bounces@ietf.org Hi Al, Al Morton wrote: > At 03:14 PM 8/10/2007, Hannes Tschofenig wrote: >> For the Y.1541 QOSM which QSPEC parameters are mandatory to include >> in a RESERVE message? > > I think it depends on the class you wish to reserve, > since some classes don't use all parameters. But you need to indicate what is optional and what is mandatory. Is it possible to categorize the different "usage" scenarios? Ciao hannes > Al _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 15 18:44:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRZM-00022G-VG; Wed, 15 Aug 2007 18:42:28 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ILRZL-00022B-Bo for nsis-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 18:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRZL-000223-2L for nsis@ietf.org; Wed, 15 Aug 2007 18:42:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILRZJ-0004jZ-Pm for nsis@ietf.org; Wed, 15 Aug 2007 18:42:27 -0400 Received: (qmail invoked by alias); 15 Aug 2007 22:42:24 -0000 Received: from p5498784B.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.120.75] by mail.gmx.net (mp017) with SMTP; 16 Aug 2007 00:42:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19F2klob1VFZh7p79ENAbR4mHH4rwkCZwwP+Wlq5I Arrdfl+2KM9AWC Message-ID: <46C38151.1010201@gmx.net> Date: Thu, 16 Aug 2007 00:42:25 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 2.9 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [NSIS] Meeting Minutes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Please check the meeting minutes: http://www3.ietf.org/proceedings/07jul/minutes/nsis.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 16 10:54:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgiP-0007iK-FP; Thu, 16 Aug 2007 10:52:49 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IKyPG-0002BZ-Ul for nsis-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 11:34:06 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IKyPG-0002BL-Ki for nsis@ietf.org; Tue, 14 Aug 2007 11:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyNv-0001u6-I1 for nsis@ietf.org; Tue, 14 Aug 2007 11:32:43 -0400 Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKyNu-0004nm-2h for nsis@ietf.org; Tue, 14 Aug 2007 11:32:43 -0400 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 8CB11E543 for ; Tue, 14 Aug 2007 17:32:40 +0200 (CEST) Received: from 193.49.124.107 (SquirrelMail authenticated user goaregue) by webmail.chalmers.se with HTTP; Tue, 14 Aug 2007 17:32:40 +0200 (CEST) Message-ID: <5463.193.49.124.107.1187105560.squirrel@webmail.chalmers.se> Date: Tue, 14 Aug 2007 17:32:40 +0200 (CEST) From: "Bertrand Goareguer" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.6-7.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-TMDA-Confirmed: Tue, 14 Aug 2007 11:34:06 -0400 X-Mailman-Approved-At: Thu, 16 Aug 2007 10:52:47 -0400 Subject: [NSIS] receiver initiated reservation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hello, When a node receives a QUERY message with the RESERVE-INIT flag set, it i= s supposed to build a RESERVE message and send it back along the path. But if the desired bandwidth (specified in the QSPEC) is too high for the first link (greater than the available bandwidth), what should the node d= o ? I guess it should send some kind of reply to the node who sent him the QUERY, but in section 4.3 of draft-ietf-nsis-qos-nslp-15.txt it is specified that "the QNI must not include the RII object". So no RESPONSE message can be sent back. Thanks for your comments. Bertrand _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 16 13:29:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILj83-0000KF-5S; Thu, 16 Aug 2007 13:27:27 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ILj82-0000K6-4u for nsis-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 13:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILj81-0000Jx-RS for nsis@ietf.org; Thu, 16 Aug 2007 13:27:25 -0400 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 1ILj80-0005nQ-Cy for nsis@ietf.org; Thu, 16 Aug 2007 13:27:25 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 16 Aug 2007 20:27:23 +0300 id 00060152.46C488FB.00006DD1 Date: Thu, 16 Aug 2007 20:27:23 +0300 (EEST) From: Jukka MJ Manner To: Bertrand Goareguer Subject: Re: [NSIS] receiver initiated reservation In-Reply-To: <5463.193.49.124.107.1187105560.squirrel@webmail.chalmers.se> Message-ID: References: <5463.193.49.124.107.1187105560.squirrel@webmail.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: nsis-bounces@ietf.org Hi Bertrand, Good point. I would expect that the QNI sends a NOTIFY with a suitable error code, either from the Transient or the QoS Model error class. Since the QUERY has passed and set up the reserve path, you can still a NOTIFY to the QNR (the node that sent the QUERY). Jukka On Tue, 14 Aug 2007, Bertrand Goareguer wrote: > Hello, > > When a node receives a QUERY message with the RESERVE-INIT flag set, it is > supposed to build a RESERVE message and send it back along the path. But > if the desired bandwidth (specified in the QSPEC) is too high for the > first link (greater than the available bandwidth), what should the node do > ? > I guess it should send some kind of reply to the node who sent him the > QUERY, but in section 4.3 of draft-ietf-nsis-qos-nslp-15.txt it is > specified that "the QNI must not include the RII object". So no RESPONSE > message can be sent back. > > Thanks for your comments. > > Bertrand > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 17 04:12:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILwur-0006OT-7m; Fri, 17 Aug 2007 04:10:45 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ILwup-0006MK-BS for nsis-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 04:10:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILwuo-0006M9-3u for nsis@ietf.org; Fri, 17 Aug 2007 04:10:42 -0400 Received: from anubis.medic.chalmers.se ([129.16.30.218]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILwun-0007an-Hf for nsis@ietf.org; Fri, 17 Aug 2007 04:10:41 -0400 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 86856E747; Fri, 17 Aug 2007 10:10:40 +0200 (CEST) Received: from 193.49.124.107 (SquirrelMail authenticated user goaregue) by webmail.chalmers.se with HTTP; Fri, 17 Aug 2007 10:10:40 +0200 (CEST) Message-ID: <12490.193.49.124.107.1187338240.squirrel@webmail.chalmers.se> In-Reply-To: References: <5463.193.49.124.107.1187105560.squirrel@webmail.chalmers.se> Date: Fri, 17 Aug 2007 10:10:40 +0200 (CEST) Subject: Re: [NSIS] receiver initiated reservation From: "Bertrand Goareguer" To: "Jukka MJ Manner" User-Agent: SquirrelMail/1.4.6-7.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Bertrand Goareguer , 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: , Errors-To: nsis-bounces@ietf.org Thanks for your answer Jukka. I modified the NSIS implementation I'm using (the one from the Goettingen university) to send a NOTIFY instead of a RESPONSE in that particular case. I also had to change the state to IDLE and not WAIT_RESPONSE after receiving the NOTIFY. draft-ietf-nsis-qos-nslp-15 specifies that "NOTIFY messages do not cause any state to be installed". Then I wonder if my solution is good (althoug= h it's working). Since I want to be as close as possible to the standard, can you tell me if the draft will be changed to add this case in the state machine ? Regards, Bertrand > > Hi Bertrand, > > Good point. I would expect that the QNI sends a NOTIFY with a suitable > error code, either from the Transient or the QoS Model error class. Sin= ce > the QUERY has passed and set up the reserve path, you can still a NOTIF= Y > to the QNR (the node that sent the QUERY). > > Jukka > > On Tue, 14 Aug 2007, Bertrand Goareguer wrote: > >> Hello, >> >> When a node receives a QUERY message with the RESERVE-INIT flag set, i= t >> is >> supposed to build a RESERVE message and send it back along the path. B= ut >> if the desired bandwidth (specified in the QSPEC) is too high for the >> first link (greater than the available bandwidth), what should the nod= e >> do >> ? >> I guess it should send some kind of reply to the node who sent him the >> QUERY, but in section 4.3 of draft-ietf-nsis-qos-nslp-15.txt it is >> specified that "the QNI must not include the RII object". So no RESPON= SE >> message can be sent back. >> >> Thanks for your comments. >> >> Bertrand >> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 17 05:06:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILxl1-0002b7-0v; Fri, 17 Aug 2007 05:04:39 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ILxkz-0002b2-6h for nsis-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 05:04:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILxky-0002au-S9 for nsis@ietf.org; Fri, 17 Aug 2007 05:04:36 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILxky-0000Id-9O for nsis@ietf.org; Fri, 17 Aug 2007 05:04:36 -0400 Received: from s4.ifi.informatik.uni-goettingen.de ([134.76.81.226] helo=smtp.stud.informatik.uni-goettingen.de) by mailer.gwdg.de with esmtp (Exim 4.67) (envelope-from ) id 1ILxkp-00063D-Io; Fri, 17 Aug 2007 11:04:27 +0200 Received: from [172.22.99.38] (ltbschloer1.tmg.loc [172.22.99.38]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Fri, 17 Aug 2007 11:04:27 +0200 (CEST) Message-ID: <46C5645A.6010303@cs.uni-goettingen.de> Date: Fri, 17 Aug 2007 11:03:22 +0200 From: Bernd Schloer User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Bertrand Goareguer Subject: Re: [NSIS] receiver initiated reservation References: <5463.193.49.124.107.1187105560.squirrel@webmail.chalmers.se> <12490.193.49.124.107.1187338240.squirrel@webmail.chalmers.se> In-Reply-To: <12490.193.49.124.107.1187338240.squirrel@webmail.chalmers.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: nsis-bounces@ietf.org Hi Bertrand, I will add this to the QoS-FSM draft. Best regards, Bernd Bertrand Goareguer wrote: > Thanks for your answer Jukka. > > I modified the NSIS implementation I'm using (the one from the Goettingen > university) to send a NOTIFY instead of a RESPONSE in that particular > case. I also had to change the state to IDLE and not WAIT_RESPONSE after > receiving the NOTIFY. > > draft-ietf-nsis-qos-nslp-15 specifies that "NOTIFY messages do not cause > any state to be installed". Then I wonder if my solution is good (although > it's working). > > Since I want to be as close as possible to the standard, can you tell me > if the draft will be changed to add this case in the state machine ? > > Regards, > > Bertrand > >> Hi Bertrand, >> >> Good point. I would expect that the QNI sends a NOTIFY with a suitable >> error code, either from the Transient or the QoS Model error class. Since >> the QUERY has passed and set up the reserve path, you can still a NOTIFY >> to the QNR (the node that sent the QUERY). >> >> Jukka >> >> On Tue, 14 Aug 2007, Bertrand Goareguer wrote: >> >>> Hello, >>> >>> When a node receives a QUERY message with the RESERVE-INIT flag set, it >>> is >>> supposed to build a RESERVE message and send it back along the path. But >>> if the desired bandwidth (specified in the QSPEC) is too high for the >>> first link (greater than the available bandwidth), what should the node >>> do >>> ? >>> I guess it should send some kind of reply to the node who sent him the >>> QUERY, but in section 4.3 of draft-ietf-nsis-qos-nslp-15.txt it is >>> specified that "the QNI must not include the RII object". So no RESPONSE >>> message can be sent back. >>> >>> Thanks for your comments. >>> >>> Bertrand >>> >>> >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 23 08:39:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBwT-0002Tp-HR; Thu, 23 Aug 2007 08:37:41 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IOBwS-0002Tk-Nd for nsis-confirm+ok@megatron.ietf.org; Thu, 23 Aug 2007 08:37:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBwS-0002Tc-Cx for nsis@ietf.org; Thu, 23 Aug 2007 08:37:40 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOBwR-0005G0-RW for nsis@ietf.org; Thu, 23 Aug 2007 08:37:40 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l7NCbcgd025884; Thu, 23 Aug 2007 14:37:38 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l7NCbcQ4015167; Thu, 23 Aug 2007 14:37:38 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 14:37:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] The QSPEC draft violates the QoS NSLP Date: Thu, 23 Aug 2007 14:37:31 +0200 Message-ID: In-Reply-To: <46BF57EB.9040805@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] The QSPEC draft violates the QoS NSLP Thread-Index: AcfdEoqzEy9A8LX9TeWbyDiO5h4BEgIb5exw References: <46BF57EB.9040805@gmx.net> From: "Kappler, Cornelia" To: "ext Hannes Tschofenig" , X-OriginalArrivalTime: 23 Aug 2007 12:37:34.0686 (UTC) FILETIME=[617427E0:01C7E582] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: nsis-bounces@ietf.org I agree, the QoS NSLP draft should be updated to specify that the QSPEC = can appear several times as Hannes described below.=20 Cornelia > -----Urspr=FCngliche Nachricht----- > Von: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Sonntag, 12. August 2007 20:57 > An: nsis@ietf.org > Betreff: [NSIS] The QSPEC draft violates the QoS NSLP >=20 > Strictly speaking the QSPEC document with the currently defined QSPEC=20 > hiding procedure violates the QoS NSLP draft: >=20 > The QoS NSLP draft defines the RESERVE and the RESPONSE as follows: >=20 > RESERVE =3D COMMON_HEADER > RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ] > [ SESSION_ID_LIST [ RSN_LIST ] ] > [ MSG_ID / BOUND_MSG_ID ] [ INFO_SPEC ] > [ [ PACKET_CLASSIFIER ] QSPEC ] >=20 > RESPONSE =3D COMMON_HEADER > [ RII / RSN ] INFO_SPEC [SESSION_ID_LIST [=20 > RSN_LIST ] ] > [ QSPEC ] >=20 > I assume that the QSPEC hiding is applicable for the QUERY and the=20 > NOTIFY message as well. >=20 > The QSPEC may appear 0 or 1 times. >=20 > With the QSPEC hiding it would be correct to indicate for the RESERVE=20 > and the RESPONSE that the object may appear 0 to 2 times. >=20 > Ciao > Hannes >=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 Mon Aug 27 11:06:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg9F-0007ci-0Q; Mon, 27 Aug 2007 11:05:01 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IPg9B-0007Yn-Eq for nsis-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 11:04:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg99-0007X2-UV; Mon, 27 Aug 2007 11:04:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPg98-00077c-Eg; Mon, 27 Aug 2007 11:04:55 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C8653207B1; Mon, 27 Aug 2007 17:04:47 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-c3-46d2e80fde06 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C94C20671; Mon, 27 Aug 2007 17:04:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 17:04:46 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 17:04:46 +0200 Message-ID: <46D2E80E.8000001@ericsson.com> Date: Mon, 27 Aug 2007 17:04:46 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Magnus Westerlund References: <46AF5370.9020304@ericsson.com> In-Reply-To: <46AF5370.9020304@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 27 Aug 2007 15:04:46.0546 (UTC) FILETIME=[9B4E0B20:01C7E8BB] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [NSIS] Re: Draft Liaison response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I have now updated this liaison reply to take the comments into account.=20 According to the ECRIT chairs they don't think what they are working is=20 related to the ongoing work Q.3/13 is working on. If you have any final=20 comments please provide them no later then the Wednesday 29th at 16.00 CE= ST. Magnus Westerlund Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =E2=80=93 60 Rev.2). We wo= uld=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the SIP and SIPPING WG may be of=20 relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. SIPPING Working Group The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 27 13:45:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidI-0002JZ-8i; Mon, 27 Aug 2007 13:44:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IPidH-0002Iw-5y for nsis-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 13:44:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidG-0002Ii-Pa; Mon, 27 Aug 2007 13:44:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPidF-0003fu-6e; Mon, 27 Aug 2007 13:44:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Aug 2007 10:44:08 -0700 X-IronPort-AV: i="4.19,312,1183359600"; d="scan'208"; a="8948966:sNHT37752318" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7RHi8I9018831; Mon, 27 Aug 2007 10:44:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7RHi7lH024692; Mon, 27 Aug 2007 17:44:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:43:58 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.91.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:43:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2007 12:43:56 -0500 To: Magnus Westerlund , Magnus Westerlund From: "James M. Polk" In-Reply-To: <46D2E80E.8000001@ericsson.com> References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 27 Aug 2007 17:43:58.0357 (UTC) FILETIME=[D8A0BC50:01C7E8D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13773; t=1188236648; x=1189100648; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20Draft=20Liaison=20response=20to=20SG1 3=20on=20Emergency=0A=20=20Telecommunications |Sender:=20; bh=sD60hnFy/1jeEK1NSSply5RPrbOwmB6enSRDS4sAZwA=; b=NJ5rCWq1ZGUUY+eJFusmZiG9HMDYbUGWMPHFX+snThPELoZWBHziyWTEWKUzwvNCia6c+Xib Su+2TerJMq4GI4YlehPPQ+olRzN0EU6a4fDGso7kncfj3xpvjujDn5RU; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [NSIS] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Magnus comments in-line below about from which WG certain documents originated At 10:04 AM 8/27/2007, Magnus Westerlund wrote: >Hi, > >I have now updated this liaison reply to take=20 >the comments into account. According to the=20 >ECRIT chairs they don't think what they are=20 >working is related to the ongoing work Q.3/13 is=20 >working on. If you have any final comments=20 >please provide them no later then the Wednesday 29th at 16.00 CEST. > >Magnus Westerlund > > >Submission >Date: , 2007 > >From: IETF Working groups TSVWG, NSIS, SIP and SIPPING > >To: Georges Sebek , > Keith Knightson > >Cc: Magnus Westerlund , > Lars Eggert , > James Polk , > Martin Stiemerling , > John Loughney > Dean Willis , > Keith Drage , > Mary Barnes , > Gonzalo Camarillo , > Scott Bradner , > Kimberly King , > Scott Brim > >Response >Contact: TSV WG (tsv-chairs@tools.ietf.org) > NSIS (nsis-chairs@tools.ietf.org) > SIPPING (sipping-chairs@tools.ietf.org) > SIP (sip-chairs@tools.ietf.org) > >Purpose: Response to Liaison Request > >Deadline: None > >Title: Response to liaison request from ITU-T=20 >Study Group 13 work on emergency telecommunications > >This is a response to the liaison request made=20 >by Q.3/13 regarding emergency telecommunications=20 >(REF: NGN-GSI/DOC =AD 60 Rev.2). We woould first=20 >like to apologize for failing to meet the=20 >deadline in responding. We do hope that the late=20 >answer still can be of some use. > >The liaison request was made to the following=20 >working groups (WG): IEPREP, TSVWG, and NSIS.=20 >Since the request was sent the IEPREP WG has=20 >concluded. In addition to the WGs from which=20 >information was requested, we also think that=20 >work performed by the SIP and SIPPING WG may be of relevance. > >Pursuant to ITU-T Study Group 13 request for=20 >information on relevant and related work in the=20 >IETF regarding emergency communications, we list=20 >below RFCs and works in progress that we feel=20 >may be of interest to your group. Some of the=20 >completed work is Informational, and others are=20 >in the category of Standards Track. > >Q.3/13 also requested that we keep you informed=20 >of any developments in regards to emergency=20 >telecommunications. In those regards we would=20 >like to make you aware that IETF mailing list=20 >participation and document information is free=20 >and open to anyone, allowing participants in=20 >Q.3/13 to keep themselves informed of any=20 >developments. If Q.3/13 desire to get further=20 >information about specific ongoing work, then=20 >please send a liaison request to the responsible=20 >WG for those specific documents. > >The following list is divided under the=20 >associated working groups from which the work has been done within the= IETF. > > >SIP Working Group > >RFC 4411 RFC4411 is from SIPPING >Title: > Extending the Session Initiation Protocol (SIP) > Reason Header for Preemption Events > >Abstract: > This document proposes an IANA Registration extension to the Session > Initiation Protocol (SIP) Reason Header to be included in a BYE > Method Request as a result of a session preemption event, either at a > user agent (UA), or somewhere in the network involving a > reservation-based protocol such as the Resource ReSerVation Protocol > (RSVP) or Next Steps in Signaling (NSIS). This document does not > attempt to address routers failing in the packet path; instead, it > addresses a deliberate tear down of a flow between UAs, and informs > the terminated UA(s) with an indication of what occurred. > >RFC 4412 > >Title: > Communications Resource Priority for the Session Initiation > Protocol (SIP) > >Abstract: > This document defines two new Session Initiation Protocol (SIP) > header fields for communicating resource priority, namely, > "Resource-Priority" and "Accept-Resource-Priority". The > "Resource-Priority" header field can influence the behavior of SIP > user agents (such as telephone gateways and IP telephones) and SIP > proxies. It does not directly influence the forwarding behavior of > IP routers. > > > >SIPPING Working Group both IDs below are SIP WG items, not SIPPING > The below two documents are proposed=20 > work items accepted to become IETF WG items are=20 > likely of interest as they update RFC 4412. > >Work In Progress: draft-polk-sip-rph-in-responses-00 > >Title: >Allowing SIP Resource Priority Header in SIP Responses > >Abstract: > The Session Initiation Protocol (SIP) Resource Priority Header > (RPH), in its current form, is ignored in SIP responses. This was a > design choice during RFC 4412's development. This is now considered > a bad design choice in certain scenarios. This document corrects > RFC 4412's communications model by optionally allowing a SIP server > or user agent client to process the Resource-Priority Header in a > response. > >Work In Progress: draft-polk-sip-rph-new-namespaces--00 > >Title: >New Session Initiation Protocol=20 >Resource-Priority Header Namespaces for the Defense Information Systems= Agency > >Abstract: > This document creates additional Session Initiation Protocol > Resource-Priority header namespaces, to be IANA registered. This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. > >IEPREP Working Group > >RFC 3487 > >Title: > Requirements for Resource Priority Mechanisms for the > Session Initiation Protocol (SIP) > >Abstract: > This document summarizes requirements for prioritizing access to > circuit-switched network, end system and proxy resources for > emergency preparedness communications using the Session Initiation > Protocol (SIP). > >RFC 3689 > >Title: > General Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of general requirements in support of > Emergency Telecommunications Service (ETS). Solutions to these > requirements are not presented in this document. Additional > requirements pertaining to specific applications, or types of > applications, are to be specified in separate document(s). > >RFC 3690 > >Title: > IP Telephony Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within the context of IP telephony. > It is an extension to the general requirements presented in RFC 3689. > Solutions to these requirements are not presented in this document. > >RFC 4190 > >Title: > Framework for Supporting Emergency Telecommunications > Service (ETS) in IP Telephony > >Abstract: > This document presents a framework for supporting authorized, > emergency-related communication within the context of IP telephony. > We present a series of objectives that reflect a general view of how > authorized emergency service, in line with the Emergency > Telecommunications Service (ETS), should be realized within today's > IP architecture and service models. From these objectives, we > present a corresponding set of protocols and capabilities, which > provide a more specific set of recommendations regarding existing > IETF protocols. Finally, we present two scenarios that act as > guiding models for the objectives and functions listed in this > document. These models, coupled with an example of an existing > service in the Public Switched Telephone Network (PSTN), contribute > to a constrained solution space. > >RFC 4375 > >Title: > Emergency Telecommunications Services (ETS) Requirements > for a Single Administrative Domain > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within a single administrative > domain. This document focuses on a specific set of administrative > constraints and scope. Solutions to these requirements are not > presented in this document. > > >TSV Working Group > >RFC 4542 > >Title: > Implementing an Emergency Telecommunications Service (ETS) > for Real-Time Services in the Internet Protocol Suite > >Abstract: > RFCs 3689 and 3690 detail requirements for an Emergency > Telecommunications Service (ETS), of which an Internet Emergency > Preparedness Service (IEPS) would be a part. Some of these types of > services require call preemption; others require call queuing or > other mechanisms. IEPS requires a Call Admission Control (CAC) > procedure and a Per Hop Behavior (PHB) for the data that meet the > needs of this architecture. Such a CAC procedure and PHB is > appropriate to any service that might use H.323 or SIP to set up > real-time sessions. The key requirement is to guarantee an elevated > probability of call completion to an authorized user in time of > crisis. > > This document primarily discusses supporting ETS in the context of > the US Government and NATO, because it focuses on the Multi-Level > Precedence and Preemption (MLPP) and Government Emergency > Telecommunication Service (GETS) standards. The architectures > described here are applicable beyond these organizations. > >Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt > >Title: > Resource ReSerVation Protovol (RSVP) Extensions for > Emergency Services > >Abstract: > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may be > facilitated through a network layer admission control solution, which > supports prioritized access to resources (e.g., bandwidth). These > resources may be explicitly set aside for emergency services, or they > may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note that > these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > >NSIS Working Group > >Work In Progress: draft-ietf-nsis-qos-nslp-14.txt > >Title: >NSLP for Quality-of-Service Signaling > >Abstract: >This specification describes the NSIS Signaling=20 >Layer Protocol (NSLP) for signaling QoS=20 >reservations in the Internet. It is in=20 >accordance with the framework and requirements=20 >developed in NSIS. Together with GIST, it=20 >provides functionality similar to RSVP and=20 >extends it. The QoS NSLP is independent of the=20 >underlying QoS specification or architecture and=20 >provides support for different reservation=20 >models. It is simplified by the elimination of=20 >support for multicast flows. This specification=20 >explains the overall protocol approach, design=20 >decisions made and provides examples. It=20 >specifies object, message formats and processing rules. > >Non-WG Documents > > Approved for publication: draft-carlberg-trip-attribute-rp-02.txt > > Title: > TRIP Attribute for Resource Priority > >Abstract: > This document defines a new attribute for the TRIP protocol. The > attribute associates protocols/services in the PSTN offering > authorized prioritization during call setup that are reachable > through a TRIP gateway. Current examples of preferential service in > the PSTN are Government Emergency Telecommunications Service (GETS) > in the U.S. and Government Telephone Preference Scheme (GTPS) in the > U.K. The proposed attribute for TRIP is based on the NameSpace.Value > tupple defined for the SIP resource Priority field. > > > >-- > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 28 03:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPva6-0007Bz-IF; Tue, 28 Aug 2007 03:33:46 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IPva3-0007B5-6x for nsis-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:33:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvZy-00078U-2t; Tue, 28 Aug 2007 03:33:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvZw-0008UK-Bj; Tue, 28 Aug 2007 03:33:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1B9C210F1; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-42-46d3cfcfa7e9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CCBF203FB; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Message-ID: <46D3CFCF.6070308@ericsson.com> Date: Tue, 28 Aug 2007 09:33:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 28 Aug 2007 07:33:35.0545 (UTC) FILETIME=[BE24DA90:01C7E945] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.6 (+) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: sip@ietf.org, dime@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [NSIS] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi again, I have received some more comments. So here is an updated version adding=20 DIME documents and correcting origin of documents. Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim , Hannes Tschofenig , David Frascone Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) DIME (dime-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =96 60 Rev.2). We would=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the DIME, SIP and SIPPING WG may be=20 of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. SIPPING Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. DIME Working Group Work In Progress: draft-ietf-dime-diameter-qos-01.txt Title: Diameter Quality of Service Application Abstract: This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Work In Progress: draft-ietf-dime-qos-parameters-00.txt Title: Quality of Service Parameters for Usage with the AAA Framework Abstract: This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Work In Progress: draft-ietf-dime-qos-attributes-01.txt Title: Quality of Service Attributes for Diameter and RADIUS Abstract: This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 28 14:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Lh-0004xP-Re; Tue, 28 Aug 2007 13:59:33 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IQ5Lg-0004wn-Mu for nsis-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:59:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Lg-0004wc-Ac; Tue, 28 Aug 2007 13:59:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ5Le-0000b0-OY; Tue, 28 Aug 2007 13:59:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2007 10:59:29 -0700 X-IronPort-AV: i="4.19,317,1183359600"; d="scan'208"; a="15348078:sNHT40240212" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7SHxTN2013270; Tue, 28 Aug 2007 10:59:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7SHxClh008831; Tue, 28 Aug 2007 17:59:29 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:59:21 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.123.166]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:59:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Aug 2007 12:59:22 -0500 To: Magnus Westerlund From: "James M. Polk" Subject: Re: [NSIS] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications In-Reply-To: <46D3CFCF.6070308@ericsson.com> References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> <46D3CFCF.6070308@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 28 Aug 2007 17:59:21.0205 (UTC) FILETIME=[2919EA50:01C7E99D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14975; t=1188323969; x=1189187969; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[NSIS]=20Re=3A=20[Tsvwg]=20Re=3A=20[Sip]=20Re=3A=20Dr aft=20Liaison=20response=20to=0A=20=20SG13=20on=20Emergency=20Telecommunic ations |Sender:=20; bh=m99wFMraDniP/oabHCb59sGhsw2Bm5NRjjTI8QPmPjQ=; b=bODCQI96h2iutBG4vGsYcbj1e/Oo4s0WfBpHF2E8WSTSIdETsS+MhpFOBid8YxpSICPCI97d sdgboM6xqHbePJ1KuM3XLQaNN2jxktMXOXQIgqArKt8G+EV6TaxcEWe+; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: sip@ietf.org, IETF SIPPING WG , dime@ietf.org, tsvwg , 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: , Errors-To: nsis-bounces@ietf.org this is good with me At 02:33 AM 8/28/2007, Magnus Westerlund wrote: >Hi again, > >I have received some more comments. So here is=20 >an updated version adding DIME documents and correcting origin of= documents. > > >Submission >Date: , 2007 > >From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING > >To: Georges Sebek , > Keith Knightson > >Cc: Magnus Westerlund , >Lars Eggert , >James Polk , >Martin Stiemerling , >John Loughney >Dean Willis , >Keith Drage , >Mary Barnes , >Gonzalo Camarillo , >Scott Bradner , >Kimberly King , >Scott Brim , >Hannes Tschofenig , >David Frascone > >Response >Contact: TSV WG (tsv-chairs@tools.ietf.org) > NSIS (nsis-chairs@tools.ietf.org) > SIPPING (sipping-chairs@tools.ietf.org) > SIP (sip-chairs@tools.ietf.org) > DIME (dime-chairs@tools.ietf.org) > >Purpose: Response to Liaison Request > >Deadline: None > >Title: Response to liaison request from ITU-T=20 >Study Group 13 work on emergency telecommunications > >This is a response to the liaison request made=20 >by Q.3/13 regarding emergency telecommunications=20 >(REF: NGN-GSI/DOC =AD 60 Rev.2). We would first=20 >like to apologize for failing to meet the=20 >deadline in responding. We do hope that the late=20 >answer still can be of some use. > >The liaison request was made to the following=20 >working groups (WG): IEPREP, TSVWG, and NSIS.=20 >Since the request was sent the IEPREP WG has=20 >concluded. In addition to the WGs from which=20 >information was requested, we also think that=20 >work performed by the DIME, SIP and SIPPING WG may be of relevance. > >Pursuant to ITU-T Study Group 13 request for=20 >information on relevant and related work in the=20 >IETF regarding emergency communications, we list=20 >below RFCs and works in progress that we feel=20 >may be of interest to your group. Some of the=20 >completed work is Informational, and others are=20 >in the category of Standards Track. > >Q.3/13 also requested that we keep you informed=20 >of any developments in regards to emergency=20 >telecommunications. In those regards we would=20 >like to make you aware that IETF mailing list=20 >participation and document information is free=20 >and open to anyone, allowing participants in=20 >Q.3/13 to keep themselves informed of any=20 >developments. If Q.3/13 desire to get further=20 >information about specific ongoing work, then=20 >please send a liaison request to the responsible=20 >WG for those specific documents. > >The following list is divided under the=20 >associated working groups from which the work has been done within the= IETF. > > >SIP Working Group > >RFC 4412 > >Title: > Communications Resource Priority for the Session Initiation > Protocol (SIP) > >Abstract: > This document defines two new Session Initiation Protocol (SIP) > header fields for communicating resource priority, namely, > "Resource-Priority" and "Accept-Resource-Priority". The > "Resource-Priority" header field can influence the behavior of SIP > user agents (such as telephone gateways and IP telephones) and SIP > proxies. It does not directly influence the forwarding behavior of > IP routers. > > The below two documents are proposed=20 > work items accepted to become IETF WG items are=20 > likely of interest as they update RFC 4412. > >Work In Progress: draft-polk-sip-rph-in-responses-00 > >Title: >Allowing SIP Resource Priority Header in SIP Responses > >Abstract: > The Session Initiation Protocol (SIP) Resource Priority Header > (RPH), in its current form, is ignored in SIP responses. This was a > design choice during RFC 4412's development. This is now considered > a bad design choice in certain scenarios. This document corrects > RFC 4412's communications model by optionally allowing a SIP server > or user agent client to process the Resource-Priority Header in a > response. > >Work In Progress: draft-polk-sip-rph-new-namespaces--00 > >Title: >New Session Initiation Protocol=20 >Resource-Priority Header Namespaces for the Defense Information Systems= Agency > >Abstract: > This document creates additional Session Initiation Protocol > Resource-Priority header namespaces, to be IANA registered. This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. > > > >SIPPING Working Group > >RFC 4411 > >Title: > Extending the Session Initiation Protocol (SIP) > Reason Header for Preemption Events > >Abstract: > This document proposes an IANA Registration extension to the Session > Initiation Protocol (SIP) Reason Header to be included in a BYE > Method Request as a result of a session preemption event, either at a > user agent (UA), or somewhere in the network involving a > reservation-based protocol such as the Resource ReSerVation Protocol > (RSVP) or Next Steps in Signaling (NSIS). This document does not > attempt to address routers failing in the packet path; instead, it > addresses a deliberate tear down of a flow between UAs, and informs > the terminated UA(s) with an indication of what occurred. > >IEPREP Working Group > >RFC 3487 > >Title: > Requirements for Resource Priority Mechanisms for the > Session Initiation Protocol (SIP) > >Abstract: > This document summarizes requirements for prioritizing access to > circuit-switched network, end system and proxy resources for > emergency preparedness communications using the Session Initiation > Protocol (SIP). > >RFC 3689 > >Title: > General Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of general requirements in support of > Emergency Telecommunications Service (ETS). Solutions to these > requirements are not presented in this document. Additional > requirements pertaining to specific applications, or types of > applications, are to be specified in separate document(s). > >RFC 3690 > >Title: > IP Telephony Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within the context of IP telephony. > It is an extension to the general requirements presented in RFC 3689. > Solutions to these requirements are not presented in this document. > >RFC 4190 > >Title: > Framework for Supporting Emergency Telecommunications > Service (ETS) in IP Telephony > >Abstract: > This document presents a framework for supporting authorized, > emergency-related communication within the context of IP telephony. > We present a series of objectives that reflect a general view of how > authorized emergency service, in line with the Emergency > Telecommunications Service (ETS), should be realized within today's > IP architecture and service models. From these objectives, we > present a corresponding set of protocols and capabilities, which > provide a more specific set of recommendations regarding existing > IETF protocols. Finally, we present two scenarios that act as > guiding models for the objectives and functions listed in this > document. These models, coupled with an example of an existing > service in the Public Switched Telephone Network (PSTN), contribute > to a constrained solution space. > >RFC 4375 > >Title: > Emergency Telecommunications Services (ETS) Requirements > for a Single Administrative Domain > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within a single administrative > domain. This document focuses on a specific set of administrative > constraints and scope. Solutions to these requirements are not > presented in this document. > > >TSV Working Group > >RFC 4542 > >Title: > Implementing an Emergency Telecommunications Service (ETS) > for Real-Time Services in the Internet Protocol Suite > >Abstract: > RFCs 3689 and 3690 detail requirements for an Emergency > Telecommunications Service (ETS), of which an Internet Emergency > Preparedness Service (IEPS) would be a part. Some of these types of > services require call preemption; others require call queuing or > other mechanisms. IEPS requires a Call Admission Control (CAC) > procedure and a Per Hop Behavior (PHB) for the data that meet the > needs of this architecture. Such a CAC procedure and PHB is > appropriate to any service that might use H.323 or SIP to set up > real-time sessions. The key requirement is to guarantee an elevated > probability of call completion to an authorized user in time of > crisis. > > This document primarily discusses supporting ETS in the context of > the US Government and NATO, because it focuses on the Multi-Level > Precedence and Preemption (MLPP) and Government Emergency > Telecommunication Service (GETS) standards. The architectures > described here are applicable beyond these organizations. > >Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt > >Title: > Resource ReSerVation Protovol (RSVP) Extensions for > Emergency Services > >Abstract: > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may be > facilitated through a network layer admission control solution, which > supports prioritized access to resources (e.g., bandwidth). These > resources may be explicitly set aside for emergency services, or they > may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note that > these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > >NSIS Working Group > >Work In Progress: draft-ietf-nsis-qos-nslp-14.txt > >Title: >NSLP for Quality-of-Service Signaling > >Abstract: >This specification describes the NSIS Signaling=20 >Layer Protocol (NSLP) for signaling QoS=20 >reservations in the Internet. It is in=20 >accordance with the framework and requirements=20 >developed in NSIS. Together with GIST, it=20 >provides functionality similar to RSVP and=20 >extends it. The QoS NSLP is independent of the=20 >underlying QoS specification or architecture and=20 >provides support for different reservation=20 >models. It is simplified by the elimination of=20 >support for multicast flows. This specification=20 >explains the overall protocol approach, design=20 >decisions made and provides examples. It=20 >specifies object, message formats and processing rules. > >DIME Working Group > >Work In Progress: draft-ietf-dime-diameter-qos-01.txt > >Title: > Diameter Quality of Service Application > >Abstract: > This document describes a Diameter application that performs > Authentication, Authorization, and Accounting for Quality of Service > (QoS) reservations. This protocol is used by elements along the path > of a given application flow to authenticate a reservation request, > ensure that the reservation is authorized, and to account for > resources consumed during the lifetime of the application flow. > Clients that implement the Diameter QoS application contact an > authorizing entity/application server that is located somewhere in > the network, allowing for a wide variety of flexible deployment > models. > >Work In Progress: draft-ietf-dime-qos-parameters-00.txt > >Title: > Quality of Service Parameters for Usage with the AAA Framework > >Abstract: > This document defines a number of Quality of Service (QoS) parameters > that can be reused for conveying QoS information within RADIUS and > Diameter. > > The payloads used to carry these QoS parameters are opaque for the > AAA client and the AAA server itself and interpreted by the > respective Resource Management Function. > >Work In Progress: draft-ietf-dime-qos-attributes-01.txt > >Title: > Quality of Service Attributes for Diameter and RADIUS > >Abstract: > This document extends the functionality of the Diameter Base protocol > and other Diameter applications with respect to their ability to > convey Quality of Service information. The AVPs defined in this > document are also available for Remote Authentication Dial In User > Service (RADIUS). > > >Non-WG Documents > > Approved for publication: draft-carlberg-trip-attribute-rp-02.txt > > Title: > TRIP Attribute for Resource Priority > >Abstract: > This document defines a new attribute for the TRIP protocol. The > attribute associates protocols/services in the PSTN offering > authorized prioritization during call setup that are reachable > through a TRIP gateway. Current examples of preferential service in > the PSTN are Government Emergency Telecommunications Service (GETS) > in the U.S. and Government Telephone Preference Scheme (GTPS) in the > U.K. The proposed attribute for TRIP is based on the NameSpace.Value > tupple defined for the SIP resource Priority field. > > > > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >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