From exim@www1.ietf.org Mon Feb 2 12:04:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22738 for ; Mon, 2 Feb 2004 12:04:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhU2-0008CR-IM for ieprep-archive@odin.ietf.org; Mon, 02 Feb 2004 12:03:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12H3cVc031513 for ieprep-archive@odin.ietf.org; Mon, 2 Feb 2004 12:03:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhU2-0008CC-D7 for ieprep-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 12:03:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22694 for ; Mon, 2 Feb 2004 12:03:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnhU1-00000l-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 12:03:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnhT2-0007iT-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 12:02:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnhS3-0007aT-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 12:01:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhRg-0007jp-Cy; Mon, 02 Feb 2004 12:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhRH-0007an-2i for ieprep@optimus.ietf.org; Mon, 02 Feb 2004 12:00:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22647 for ; Mon, 2 Feb 2004 12:00:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnhRF-0007YS-00 for ieprep@ietf.org; Mon, 02 Feb 2004 12:00:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnhQK-0007TU-00 for ieprep@ietf.org; Mon, 02 Feb 2004 11:59:48 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1AnhPr-0007Nl-00; Mon, 02 Feb 2004 11:59:19 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12H0OsQ004101; Mon, 2 Feb 2004 12:00:24 -0500 (EST) Subject: In-band soft-state control plane?RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: "James M. Polk" Cc: ieprep@ietf.org, ieprep-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 2 Feb 2004 12:02:44 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/02/2004 11:57:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 James, Can you explain to me exactly what is meant by "In_band soft_state control plane ". It sounds great but I am having difficulty envisioning exactly what it is. (Or refer me to the appropriate section of an ID or RFC) Thanks ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "James M. Polk" @cisco.com> cc: Sent by: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt ieprep-admin 01/29/2004 06:04 PM ... It is Fred Baker's and my opinion that an In_band soft_state control plane would be the very best of all worlds to provide all manners of offered load to capacity analysis at the congestion point - and not continue to rely on some server architecture to maintain the congestive state of all interfaces for 1000s of router interfaces (in rear-time). ... cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 2 16:45:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14876 for ; Mon, 2 Feb 2004 16:45:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlsV-00035w-Rm for ieprep-archive@odin.ietf.org; Mon, 02 Feb 2004 16:45:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12LjBp7011892 for ieprep-archive@odin.ietf.org; Mon, 2 Feb 2004 16:45:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlsV-00035j-Na for ieprep-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 16:45:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14821 for ; Mon, 2 Feb 2004 16:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnlsT-00005Q-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 16:45:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnlrS-0007im-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 16:44:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnlqY-0007an-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 16:43:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlqO-00031A-Lf; Mon, 02 Feb 2004 16:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anlq0-00030r-SU for ieprep@optimus.ietf.org; Mon, 02 Feb 2004 16:42:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14651 for ; Mon, 2 Feb 2004 16:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anlpy-0007T1-00 for ieprep@ietf.org; Mon, 02 Feb 2004 16:42:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anlp7-0007HT-00 for ieprep@ietf.org; Mon, 02 Feb 2004 16:41:42 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1Anlns-000714-00 for ieprep@ietf.org; Mon, 02 Feb 2004 16:40:24 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12LfEsQ009257; Mon, 2 Feb 2004 16:41:15 -0500 (EST) Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: "Ken Carlberg" Cc: ieprep@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 2 Feb 2004 16:43:33 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/02/2004 04:38:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Picky is fine. I have been known to be picky! Remaining comments in line. ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "Ken Carlberg" @g11.org.uk> cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt 01/28/2004 01:40 PM Janet, The following response may be a bit picky on some issues/comments, but I feel it will be helpful to clarify things a bit. > I think that, under "normal" circumstances, the QoS mechanisms for > conventional VoIP will be more than adequate to support ETS, and "special > treatment" in Call Admission Control is what will be needed for ETS. Within the context of what we have written in the past in the IETF, ETS is an umbrella term that is meant to cover a wide variety of applications. Some of these applications (eg, I-Am-Alive) do not support the concept of CAC. So to say that "special treatment" (whatever that is) of CAC is what will be needed for ETS is rather too specific a statement to make. I think we can agree that in those applications used to support ETS and dependent on CAC, an ability to distinguish and perform CAC is of high interest and needs to be supported. [jpg] you are right, I should have said voice (and video) ETS applications. Which prompts me to ask if there will be a single domain IP telephony ETS requirements document. > As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call > admission is working properly, traffic marking is not needed in normal > operations. It is when there are route changes - typically due to network > failures - that marking is needed. Keep in mind that Fred's draft is in respect to MLPP. Arguments from the draft may be applied to other circumstances, but I would refrain from treating it as a blanket statement for all applications and situations. [jpg] Agree, not a blanket statement. But my point is that when something happens to/in the network, that is the time when "extraordinary" treatment may make sense (recognizing that even without extraordinary treatment, this is still vastly superior to the PSTN situation, where ANY disruption to the network (on the particular call path) makes the call go away). This is particularly true for voice and video applications. Less so, I agree, for elastic applications. I've worked on systems in the past where "marking" was used to separate traffic into either different physical subnets or different virtuals paths -- neither case where the route changes existed because of network failures. > When there are network failures, the > capacity and route assignments on which call admission was based no longer > apply, the QoS cannot be guaranteed until the new routes are stabilized, > and the call admission process adapts to the new capacity and routes. > This may be a very local effect, of quite short duration. But it has a > significant impact on the call quality of the calls that are affected. > While that paper addresses an IP implementation of MLPP, many of the same > concerns apply to ETS. Ok > Network failures, and/or massive and sustained statistical anomalies > (large, local bursts), and the associated route changes, are the problems > we need to focus on. > > It is in this context that ETS calls must be given a high probability of > meeting the QoS criteria, even when network congestion and or damage are > severe. Ok. > The requirements in draft-ietf-ieprep-domain-req-00.txt don't seem to > address this, and the framework in draft-ietf-ieprep-domain-frame-00.txt > doesn't seem to solve it. Actually, that's fine. The former draft is not aimed at a specific application or system (this is stated in the draft). It is admittedly broad and acts as a foundation for the context of a single domain. The latter draft is not meant to offer solutions, but rather to discuss applicable and related protocols that one *could* encounter within the specific scope of a single domain. I will expand this below where you have a specific question. [jpg] I guess my unwritten question here is "Are you planning to have a document which DOES address this." I agree that it is somewhat out-of-scpoe for the two new documents. > In draft-gunn-ieprep-ip-telephony-gap-00.txt we address the need to > support ETS SLAs to provide High Probability Toll-Quality Voice - ETS > calls > must be given adequate resources through the network to ensure a high > probability that their packets suffer loss, delay, and jitter consistent > with achieving toll-quality voice even when network congestion and / or > damage are severe. > What is the appropriate way to reflect these concerns? Through a draft (and I state it with no intention of being obnoxiously obvious). If your question is, how does one deal with the three seemingly related drafts? 1. draft-ietf-ieprep-domain-req-00.txt, 2. draft-ietf-ieprep-domain-frame-00.txt, and 3. draft-gunn-ieprep-ip-telephony-gap-00.txt, then I would follow the position I stated above and have (3) simply be a more specific continuation of what has been stated in (1) and (2) above. In my view it may be more constructive to be very specific and identify specific systems/efforts like GETS or NS/EP or WPS. If the chairs or AD feel differently, I'm sure they'll chime in. [jpg] Thanks, that is encouraging. Janet Cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 2 17:14:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17628 for ; Mon, 2 Feb 2004 17:14:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmKg-0005WT-Ex for ieprep-archive@odin.ietf.org; Mon, 02 Feb 2004 17:14:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MEIoG021223 for ieprep-archive@odin.ietf.org; Mon, 2 Feb 2004 17:14:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmKg-0005WE-At for ieprep-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 17:14:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17579 for ; Mon, 2 Feb 2004 17:14:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmKd-0004Il-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:14:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmJN-00049o-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:12:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnmIQ-0003zs-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmIR-0005JI-S3; Mon, 02 Feb 2004 17:11:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmHr-0005HS-Eg for ieprep@optimus.ietf.org; Mon, 02 Feb 2004 17:11:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17343 for ; Mon, 2 Feb 2004 17:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmHp-0003se-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmGo-0003im-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:10:18 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1AnmFv-0003aR-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:09:23 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12MATsQ029059 for ; Mon, 2 Feb 2004 17:10:29 -0500 (EST) Subject: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: Fred Baker Cc: ieprep@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 2 Feb 2004 17:12:48 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/02/2004 05:07:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Comments in line. ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- Fred Baker To: Janet P Gunn cc: ieprep@ietf.org 01/27/2004 09:35 Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt PM At 12:32 PM 1/27/2004, Janet P Gunn wrote: >As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call >admission is working properly, traffic marking is not needed in normal >operations. lest I be misunderstood, let me restate that. What I wrote was: One will ask the value of the multiple DSCPs. They are, in fact, of limited to no value in normal operation, as all vice and video traffic should have been admitted, and therefore capacity will have been assigned to them. The behavior of this service will be indistinguishable from the EF PHB regardless of traffic marking. In retrospect, I wonder what the vice traffic would be :^) [jpg] Maybe all that "organ enlargement" spam? This is not to be understood as saying "no traffic marking is required"; one still needs RFC 3246. But if bandwidth admission is operating correctly, having N different marks will be operationally indistinguishable from having a single EF mark, as the total number of bytes on the wire will be the same. jpg], I did understand that. I was oversimplifying to make my point. >It is in this context that ETS calls must be given a high probability of >meeting the QoS criteria, even when network congestion and or damage are >severe. I wonder if we are communicating here. RFC 3246 is designed to operate in a congested network, and to operate in a network in which routing may change. The comment in the mlpp-that-works draft - which if it is giving cause for confusion I will happily remove - is basically me bending over backwards to be intellectually honest and see if I can find a case where CAC may be insufficient. [jpg] And I was blatantly taking advantage of your "bending over backwards" - to identify a case where CAC may not be sufficient for the ETS Voice application. Think about this for a moment: the argument being placed for MLEF is that even in the presence of some loss, voice is intelligible. If that is true, then just after a route change, during the brief interval between the data flow being switched to a new path and the CAC following that and either OKing the flow or deciding to shut down the call, when there may be some loss, voice should be equally intelligible, no? Or does the argument that voice is able to work around a modest level of loss only work when it comes from the proponents of multiple code points? [jpg] In the ETS voice scenario, I am NOT trying to say that "voice is able to work around a modest level of loss". I am taking the highly elitist position that, if there is a situation where SOME "calls" are going to have to lose packets, I want it to be the non-ETS calls (whether or not the non-ETS calls remain intelligible or not) that lose packets, and not the ETS calls. [jpg] I further agree that, in any situation where "calls" are losing packets, it is highly desirable to "do something" so that you have some calls that remain up and intelligible, and so that other calls go away, rather than using up bandwidth sending packets that are not "useful" from the end user's perspective. And whatever that "something" is, I want it to be able (assuming the appropriate business agreements are in place) to slant the odds in favor of the ETS calls being the ones that stay up and intelligible. Janet << Attachment Removed : C.DTF >> _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 2 17:25:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18325 for ; Mon, 2 Feb 2004 17:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmUz-0006fI-76 for ieprep-archive@odin.ietf.org; Mon, 02 Feb 2004 17:24:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MOvIL025614 for ieprep-archive@odin.ietf.org; Mon, 2 Feb 2004 17:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmUz-0006f3-37 for ieprep-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 17:24:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18288 for ; Mon, 2 Feb 2004 17:24:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmUw-0005eR-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:24:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmU0-0005Wp-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:23:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnmT7-0005QS-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT8-0006TF-75; Mon, 02 Feb 2004 17:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT4-0006PY-7y for ieprep@optimus.ietf.org; Mon, 02 Feb 2004 17:22:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18143 for ; Mon, 2 Feb 2004 17:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmT1-0005PW-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:22:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmSA-0005K5-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:22:03 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AnmRk-0005Dc-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:21:36 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2004 14:26:57 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i12ML2DK026882; Mon, 2 Feb 2004 14:21:03 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id APX03652; Mon, 2 Feb 2004 14:21:01 -0800 (PST) Message-Id: <6.0.1.1.2.20040202140203.05ceaab0@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 02 Feb 2004 14:02:48 -0800 To: Janet P Gunn From: Fred Baker Subject: Re: In-band soft-state control plane?RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: ieprep@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-==-==--=--==--------==-=-=-==-==-=====-==--==-"; protocol="application/pgp-signature"; micalg=pgp-sha1 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.8 required=5.0 tests=AWL,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 --=-==-==--=--==--------==-=-=-==-==-=====-==--==- Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:02 AM 2/2/2004, Janet P Gunn wrote: >Can you explain to me exactly what is meant by "In_band soft_state >control plane". RSVP is an example of one. --=-==-==--=--==--------==-=-=-==-==-=====-==--==- Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP 7.0.1 iQA/AwUBQB7JCG4xHWxyLJtDEQJh3gCfYNszG1QeG0zi79oxKshTLm5TaBcAn1Wx QO5FVoyq1IMIfz0GcP90AuYD =mAf1 -----END PGP MESSAGE----- --=-==-==--=--==--------==-=-=-==-==-=====-==--==--- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 2 17:26:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18409 for ; Mon, 2 Feb 2004 17:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmVz-0006lj-UA for ieprep-archive@odin.ietf.org; Mon, 02 Feb 2004 17:25:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MPxiP026013 for ieprep-archive@odin.ietf.org; Mon, 2 Feb 2004 17:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmVz-0006lU-Pq for ieprep-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 17:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18356 for ; Mon, 2 Feb 2004 17:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmVx-0005nM-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:25:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmUz-0005ev-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:24:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnmU3-0005XI-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmU5-0006b9-4m; Mon, 02 Feb 2004 17:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmTz-0006a4-IB for ieprep@optimus.ietf.org; Mon, 02 Feb 2004 17:23:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18253 for ; Mon, 2 Feb 2004 17:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmTx-0005WG-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:23:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmT3-0005Po-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:22:58 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1AnmSI-0005KN-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:22:10 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12MNGsQ006999 for ; Mon, 2 Feb 2004 17:23:16 -0500 (EST) Subject: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: "James M. Polk" Cc: "Fred Baker" , ieprep@ietf.org, "Steve Silverman" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 2 Feb 2004 17:25:28 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/02/2004 05:20:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Comments in line- trying to make sure I understand what you are saying. ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "James M. Polk" , "Fred Baker" , @cisco.com> Janet P Gunn/FED/CSC@CSC, cc: 01/29/2004 01:25 Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt PM comments below At 11:33 AM 1/29/2004 -0500, Steve Silverman wrote: >If the offered load exceeds the network capacity, some packets will be >dropped. If a line is at >95% of capacity, a 10% surge would cause 5% of the packets to be >dropped, degrading most of the conversations. ( I am simplifying here >but I think this is clear.) > >The benefit of multiple DSCPs is that the sessions designated most >critical are unaffected. without active feedback to those lower priority sessions.... >Actual experiment has shown that this does >work. yes it does - but without regard to any call quality. If the surge is 25 or 50 or 75% above maximum load possible, then what happens to the lower priority calls? There isn't any feedback to the users (other than pure silence). Further, there isn't any feedback (signaling) to their devices what's happening or to hang up the call. There's nothing. How long is this expected to last for? No one knows. Further, no one can test the system (because of no feedback). No one can point to where there might be potential problems with this architecture either (is the system behaving correctly?). There is no feedback to discover or monitor its performance. Where is it supposed to be discovered that a link between any two routers isn't fast enough (because there are perhaps frequent silence periods)? >In draft-baker-tsvwg-mlpp-that-works.00 it is assumed that the CAC >will ensure that voice is not overloaded. >Two problems with this are: > > 1) If silence suppression is used and the bandwidth "oversubscribed" >(standard practice) then sometimes, more people on one end will talk >and cause congestion. > > 2) If the area controlled by the CAC is large, propagation delay >will limit the reaction time of the system where's the propagation delay? the surge won't happen without the signaling having already occurred through the congestion point; meaning the system (read: routers) already know about all the call (flow) attempts - even when there is too much offered load for an interface. The router can either say "sorry, not enough resources available to complete your call attempt" or "sorry, but there was another call with higher priority, and I have to shut your call down now". BTW - these are device signals, this isn't a .wav file playing to the user or anything. [jpg] I think I understand how CAC says "not enough resources available to complete your call attempt" at call setup time. [jpg] It is not clear to me how CAC says "sorry, but there was another call with higher priority, and I have to shut your call down now" once the call has been established. I was under the impression that, once the call was established, the router did not distinguish between individual calls. I would be glad to be enlightened on that point. >and the computation to >oversee the entire theatre may also be a limiting factor. see above, computation occurs at the router that is experiencing this surge. It is in charge of the packet forwarding. It is aware of all the existing flows it has accepted. It is in charge of accepting new flows and preempting lesser priority ones if multilevel offered load exceeds the maximum load possible. >This may >cause short congestion incidents (several seconds long) which could be >mitigated by MLEF. I'm not saying you don't also need the CAC. I'm >saying >you need something local and fast reacting In the router itself isn't fast enough...? >(at the packet level rather >than the call level) packet level = Layer 3 Call level = what? Layer 4, 5 or 7? >to ensure that the high priority packets get >thru. I am a believer in high priority calls getting through, and for all calls that remain up - having all their packets arrive safely too. [jpg] Me too Janet >Steve Silverman cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 2 17:30:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18620 for ; Mon, 2 Feb 2004 17:30:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmZn-00076E-HC for ieprep-archive@odin.ietf.org; Mon, 02 Feb 2004 17:29:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MTtMd027284 for ieprep-archive@odin.ietf.org; Mon, 2 Feb 2004 17:29:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmZn-00075z-DH for ieprep-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 17:29:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18584 for ; Mon, 2 Feb 2004 17:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmZk-0006Fp-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmYm-00068M-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:28:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnmXv-000620-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 17:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmXx-0006sK-En; Mon, 02 Feb 2004 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmX6-0006qY-1Y for ieprep@optimus.ietf.org; Mon, 02 Feb 2004 17:27:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18450 for ; Mon, 2 Feb 2004 17:27:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmX3-0005vG-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:27:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmW5-0005oe-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:26:06 -0500 Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx with esmtp (Exim 4.12) id 1AnmVJ-0005hc-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:25:17 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta01.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i12MRmXN028592 for ; Mon, 2 Feb 2004 17:27:48 -0500 (EST) Subject: Re: In-band soft-state control plane?RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: Fred Baker Cc: ieprep@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Mon, 2 Feb 2004 17:28:39 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 02/02/2004 05:23:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Thanks- clearer now. ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- Fred Baker To: Janet P Gunn/FED/CSC@CSC cc: ieprep@ietf.org 02/02/2004 05:02 Subject: Re: In-band soft-state control plane?RE: [Ieprep] I-D PM ACTION:draft-ietf-ieprep-domain-req-00.txt At 09:02 AM 2/2/2004, Janet P Gunn wrote: >Can you explain to me exactly what is meant by "In_band soft_state >control plane". RSVP is an example of one. << Attachment Removed : C.DTF >> _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 2 18:03:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20320 for ; Mon, 2 Feb 2004 18:03:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ann5j-0002hE-Bq for ieprep-archive@odin.ietf.org; Mon, 02 Feb 2004 18:02:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12N2tiE010356 for ieprep-archive@odin.ietf.org; Mon, 2 Feb 2004 18:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ann5j-0002gt-7I for ieprep-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 18:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20309 for ; Mon, 2 Feb 2004 18:02:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ann5g-0002G9-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 18:02:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ann4o-0002BP-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 18:01:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ann3s-00026M-00 for ieprep-web-archive@ietf.org; Mon, 02 Feb 2004 18:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ann3s-0001F3-Vu; Mon, 02 Feb 2004 18:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ann2x-0000zB-1f for ieprep@optimus.ietf.org; Mon, 02 Feb 2004 18:00:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20202 for ; Mon, 2 Feb 2004 17:59:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ann2u-0001zi-00 for ieprep@ietf.org; Mon, 02 Feb 2004 18:00:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ann27-0001uM-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:59:12 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ann1d-0001lf-00 for ieprep@ietf.org; Mon, 02 Feb 2004 17:58:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2004 15:04:43 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i12MvgfG013061; Mon, 2 Feb 2004 14:57:42 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA07077; Mon, 2 Feb 2004 14:57:39 -0800 (PST) Message-Id: <4.3.2.7.2.20040202164429.071ea3f0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Feb 2004 16:57:51 -0600 To: Janet P Gunn From: "James M. Polk" Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: "Fred Baker" , ieprep@ietf.org, "Steve Silverman" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Janet My comparison in the quotes was a poor attempt at what occurs within MLPP Switches today (preemption tone or an announcement), and from an IP POV - the tone behavior is doable with my recent ID into SIPPING (Reason Header for Preemption), but the latter (the announcement) isn't doable to inform a user with words about which router was the culprit in not letting a call get through or the preemptor of a call. The GSCR clearly call out these two behaviors, and they are probably appropriate for TDM networks, but IMO are not for IP networks where the congestion event happened at a router - but this distinction isn't made in the GSCR, both behaviors are still mandated (and I don't know how we're going to accomplish the announcement regarding a specific identifiable router causing a call to fail on purpose). If this is an "IP at the Start" scenario, and the congestion event occurs within the TDM infrastructure, then I believe that announcement or tone MUST be communicated back to the IP phone and user on that call to inform them of what they get today I know this is (slightly) off topic for this list At 05:25 PM 2/2/2004 -0500, Janet P Gunn wrote: >Comments in line- trying to make sure I understand what you are saying. > > >---------------------------------------------------------------------------------------- > >This is a PRIVATE message. If you are not the intended recipient, please >delete without copying and kindly advise us by e-mail of the mistake in >delivery. NOTE: Regardless of content, this e-mail shall not operate to >bind CSC to any order or other contract unless pursuant to explicit written >agreement or government initiative expressly permitting the use of e-mail >for such purpose. >---------------------------------------------------------------------------------------- > > > > > > > "James M. > Polk" > > , "Fred Baker" , > @cisco.com> Janet P Gunn/FED/CSC@CSC, > > cc: > > 01/29/2004 01:25 Subject: RE: [Ieprep] I-D > ACTION:draft-ietf-ieprep-domain-req-00.txt > PM > > > > > > > > > >comments below > >At 11:33 AM 1/29/2004 -0500, Steve Silverman wrote: > >If the offered load exceeds the network capacity, some packets will be > >dropped. If a line is at > >95% of capacity, a 10% surge would cause 5% of the packets to be > >dropped, degrading most of the conversations. ( I am simplifying here > >but I think this is clear.) > > > >The benefit of multiple DSCPs is that the sessions designated most > >critical are unaffected. > >without active feedback to those lower priority sessions.... > > >Actual experiment has shown that this does > >work. > >yes it does - but without regard to any call quality. > >If the surge is 25 or 50 or 75% above maximum load possible, then what >happens to the lower priority calls? There isn't any feedback to the users >(other than pure silence). Further, there isn't any feedback (signaling) to > >their devices what's happening or to hang up the call. There's nothing. How > >long is this expected to last for? No one knows. > >Further, no one can test the system (because of no feedback). > >No one can point to where there might be potential problems with this >architecture either (is the system behaving correctly?). There is no >feedback to discover or monitor its performance. Where is it supposed to be > >discovered that a link between any two routers isn't fast enough (because >there are perhaps frequent silence periods)? > > > >In draft-baker-tsvwg-mlpp-that-works.00 it is assumed that the CAC > >will ensure that voice is not overloaded. > >Two problems with this are: > > > > 1) If silence suppression is used and the bandwidth >"oversubscribed" > >(standard practice) then sometimes, more people on one end will talk > >and cause congestion. > > > > 2) If the area controlled by the CAC is large, propagation delay > >will limit the reaction time of the system > >where's the propagation delay? the surge won't happen without the signaling > >having already occurred through the congestion point; meaning the system >(read: routers) already know about all the call (flow) attempts - even when > >there is too much offered load for an interface. The router can either say >"sorry, not enough resources available to complete your call attempt" or >"sorry, but there was another call with higher priority, and I have to shut > >your call down now". BTW - these are device signals, this isn't a .wav file > >playing to the user or anything. > >[jpg] I think I understand how CAC says "not enough resources available to >complete your call attempt" at call setup time. > >[jpg] It is not clear to me how CAC says "sorry, but there was another call >with higher priority, and I have to shut your call down now" once the call >has been established. I was under the impression that, once the call was >established, the router did not distinguish between individual calls. I >would be glad to be enlightened on that point. > > >and the computation to > >oversee the entire theatre may also be a limiting factor. > >see above, computation occurs at the router that is experiencing this >surge. It is in charge of the packet forwarding. It is aware of all the >existing flows it has accepted. It is in charge of accepting new flows and >preempting lesser priority ones if multilevel offered load exceeds the >maximum load possible. > > >This may > >cause short congestion incidents (several seconds long) which could be > >mitigated by MLEF. I'm not saying you don't also need the CAC. I'm > >saying > >you need something local and fast reacting > >In the router itself isn't fast enough...? > > >(at the packet level rather > >than the call level) > >packet level = Layer 3 > >Call level = what? Layer 4, 5 or 7? > > >to ensure that the high priority packets get > >thru. > >I am a believer in high priority calls getting through, and for all calls >that remain up - having all their packets arrive safely too. > >[jpg] Me too > >Janet > > > >Steve Silverman > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Feb 3 08:03:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07489 for ; Tue, 3 Feb 2004 08:03:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0D4-0001yE-0N for ieprep-archive@odin.ietf.org; Tue, 03 Feb 2004 08:03:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13D3Lck007568 for ieprep-archive@odin.ietf.org; Tue, 3 Feb 2004 08:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0D3-0001xz-Rt for ieprep-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 08:03:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07484 for ; Tue, 3 Feb 2004 08:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0D2-0006AS-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 08:03:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao0C6-00065z-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 08:02:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0Bk-00061X-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 08:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0Bj-0001te-L5; Tue, 03 Feb 2004 08:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0BA-0001sg-P7 for ieprep@optimus.ietf.org; Tue, 03 Feb 2004 08:01:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07452 for ; Tue, 3 Feb 2004 08:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0B9-00060x-00 for ieprep@ietf.org; Tue, 03 Feb 2004 08:01:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao0AF-0005w8-00 for ieprep@ietf.org; Tue, 03 Feb 2004 08:00:27 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1Ao09V-0005kl-00 for ieprep@ietf.org; Tue, 03 Feb 2004 07:59:41 -0500 Received: (qmail 24954 invoked from network); 3 Feb 2004 12:59:04 -0000 Received: from pool-141-157-19-111.balt.east.verizon.net (HELO albers) (141.157.19.111) by phobos.simply.net with SMTP; 3 Feb 2004 12:59:04 -0000 From: "Ken Carlberg" To: "'Janet P Gunn'" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Tue, 3 Feb 2004 07:58:30 -0500 Message-ID: <000101c3ea55$6d1f1860$7301a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [jpg] I guess my unwritten question here is "Are you planning to have a > document which DOES address this." I agree that it is somewhat > out-of-scpoe for the two new documents. My plans with respect to potential IEPREP documents is to work within the scope of the charter. Lets discuss this offline to make sure I know exactly what you are looking for and I'll see if I can provide assistance. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Feb 3 08:35:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08243 for ; Tue, 3 Feb 2004 08:35:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0i3-0004C9-83 for ieprep-archive@odin.ietf.org; Tue, 03 Feb 2004 08:35:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13DZNGj016119 for ieprep-archive@odin.ietf.org; Tue, 3 Feb 2004 08:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0i3-0004Bu-2d for ieprep-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 08:35:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08237 for ; Tue, 3 Feb 2004 08:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0i1-0001Ln-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 08:35:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao0h6-0001H7-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 08:34:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0gj-0001CW-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 08:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0gj-0003zP-Ce; Tue, 03 Feb 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao0gH-0003yr-IE for ieprep@optimus.ietf.org; Tue, 03 Feb 2004 08:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08211 for ; Tue, 3 Feb 2004 08:33:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao0gG-0001BT-00 for ieprep@ietf.org; Tue, 03 Feb 2004 08:33:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao0fO-00015c-00 for ieprep@ietf.org; Tue, 03 Feb 2004 08:32:38 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1Ao0et-0000yF-00 for ieprep@ietf.org; Tue, 03 Feb 2004 08:32:07 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 7657FFCE06; Tue, 3 Feb 2004 08:31:32 -0500 (EST) To: jgunn6@csc.com, jmpolk@cisco.com Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: fred@cisco.com, ieprep@ietf.org, steves@shentel.net In-Reply-To: Message-Id: <20040203133132.7657FFCE06@newdev.harvard.edu> Date: Tue, 3 Feb 2004 08:31:32 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > [jpg] It is not clear to me how CAC says "sorry, but there was another call > with higher priority, and I have to shut your call down now" once the call > has been established. I was under the impression that, once the call was > established, the router did not distinguish between individual calls. I > would be glad to be enlightened on that point. note that the router is not involved in establishing the call - its all packets to the router but if the call QoS is maintained by RSVP (as Fred suggested) there is less of an issue - a router can reject RSVP sessions even after they have started Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Feb 3 10:47:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15047 for ; Tue, 3 Feb 2004 10:47:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2l4-0001i8-E1 for ieprep-archive@odin.ietf.org; Tue, 03 Feb 2004 10:46:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13FkcMY006572 for ieprep-archive@odin.ietf.org; Tue, 3 Feb 2004 10:46:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2l4-0001hv-9t for ieprep-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 10:46:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15020 for ; Tue, 3 Feb 2004 10:46:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao2l1-0000GJ-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 10:46:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao2kH-0000AJ-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 10:45:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao2jX-00001t-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 10:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2jW-0001K6-97; Tue, 03 Feb 2004 10:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao2jI-0001GH-1U for ieprep@optimus.ietf.org; Tue, 03 Feb 2004 10:44:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14917 for ; Tue, 3 Feb 2004 10:44:44 -0500 (EST) From: steve.norreys@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao2jF-0007nT-00 for ieprep@ietf.org; Tue, 03 Feb 2004 10:44:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao2iN-0007dr-00 for ieprep@ietf.org; Tue, 03 Feb 2004 10:43:52 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138] helo=i2kc03-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1Ao2hL-0007Mc-00 for ieprep@ietf.org; Tue, 03 Feb 2004 10:42:47 -0500 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 15:42:14 +0000 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 15:42:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Tue, 3 Feb 2004 15:42:12 -0000 Message-ID: <9D598A34672DF24F89FF4F851A416195085DC021@i2km08-ukbr.domain1.systemhost.net> Thread-Topic: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Thread-Index: AcPp2ZlNmHiZ8TERTYeD3y4hZzbyAwAiCF8Q To: Cc: X-OriginalArrivalTime: 03 Feb 2004 15:42:13.0050 (UTC) FILETIME=[4AE699A0:01C3EA6C] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Janet and all I have been biting my tongue (ops fingers) for some time now with regards to the MLPP service for supporting ETS in IP networks. As this service has a potential problem as shown by the following scenario: If a call/session is in progress between a non authorised ETS user and a emergency service then this should never be subject to pre-emption by a authorised ETS user, it could have fatal consequences. This by extension could be applied to a call/session in progress between non authorised ETS users, as this contact could be the only point of hope for someone in trouble. In other words the only justification for a pre-emption by a authorised ETS user is that it is only applied to call/session if both the content and context have been analysed. This seems to be a lot of work in a congested network. I have no problems with multiple precedence's or priorities if they are required but I only see the need for two a 'normal' call/session and a 'ETS' call/session.=20 This shows that there maybe a need to take into account the consequences of the requirement to support MLPP especially in regard to pre-emption.=20 Regards Steve Norreys =20 Signalling and Protocols Tel: +441277323220 email steve.norreys@bt.com -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Janet P Gunn Sent: 02 February 2004 22:13 To: Fred Baker Cc: ieprep@ietf.org Subject: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Comments in line. ------------------------------------------------------------------------ ---------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ------------------------------------------------------------------------ ---------------- =20 Fred Baker To: Janet P Gunn =20 cc: ieprep@ietf.org 01/27/2004 09:35 Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt =20 PM =20 =20 At 12:32 PM 1/27/2004, Janet P Gunn wrote: >As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call >admission is working properly, traffic marking is not needed in normal=20 >operations. lest I be misunderstood, let me restate that. What I wrote was: One will ask the value of the multiple DSCPs. They are, in fact, of limited to no value in normal operation, as all vice and video traffic should have been admitted, and therefore capacity will have been assigned to them. The behavior of this service will be indistinguishable from the EF PHB regardless of traffic marking. In retrospect, I wonder what the vice traffic would be :^) [jpg] Maybe all that "organ enlargement" spam? This is not to be understood as saying "no traffic marking is required"; one still needs RFC 3246. But if bandwidth admission is operating correctly, having N different marks will be operationally indistinguishable from having a single EF mark, as the total number of bytes on the wire will be the same. jpg], I did understand that. I was oversimplifying to make my point. >It is in this context that ETS calls must be given a high probability=20 >of meeting the QoS criteria, even when network congestion and or damage >are severe. I wonder if we are communicating here. RFC 3246 is designed to operate in a congested network, and to operate in a network in which routing may change. The comment in the mlpp-that-works draft - which if it is giving cause for confusion I will happily remove - is basically me bending over backwards to be intellectually honest and see if I can find a case where CAC may be insufficient. [jpg] And I was blatantly taking advantage of your "bending over backwards" - to identify a case where CAC may not be sufficient for the ETS Voice application. Think about this for a moment: the argument being placed for MLEF is that even in the presence of some loss, voice is intelligible. If that is true, then just after a route change, during the brief interval between the data flow being switched to a new path and the CAC following that and either OKing the flow or deciding to shut down the call, when there may be some loss, voice should be equally intelligible, no? Or does the argument that voice is able to work around a modest level of loss only work when it comes from the proponents of multiple code points? [jpg] In the ETS voice scenario, I am NOT trying to say that "voice is able to work around a modest level of loss". I am taking the highly elitist position that, if there is a situation where SOME "calls" are going to have to lose packets, I want it to be the non-ETS calls (whether or not the non-ETS calls remain intelligible or not) that lose packets, and not the ETS calls. [jpg] I further agree that, in any situation where "calls" are losing packets, it is highly desirable to "do something" so that you have some calls that remain up and intelligible, and so that other calls go away, rather than using up bandwidth sending packets that are not "useful" from the end user's perspective. And whatever that "something" is, I want it to be able (assuming the appropriate business agreements are in place) to slant the odds in favor of the ETS calls being the ones that stay up and intelligible. Janet << Attachment Removed : C.DTF >> _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Feb 3 15:51:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00530 for ; Tue, 3 Feb 2004 15:51:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7VG-0000O6-JB for ieprep-archive@odin.ietf.org; Tue, 03 Feb 2004 15:50:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KocLJ001486 for ieprep-archive@odin.ietf.org; Tue, 3 Feb 2004 15:50:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7VG-0000Nt-BC for ieprep-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:50:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00486 for ; Tue, 3 Feb 2004 15:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7VE-0001tA-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 15:50:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7UJ-0001ny-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 15:49:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Th-0001ip-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 15:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Tg-0008TS-SW; Tue, 03 Feb 2004 15:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7TH-0008SR-PA for ieprep@optimus.ietf.org; Tue, 03 Feb 2004 15:48:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00331 for ; Tue, 3 Feb 2004 15:48:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7TG-0001hP-00 for ieprep@ietf.org; Tue, 03 Feb 2004 15:48:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7SH-0001b5-00 for ieprep@ietf.org; Tue, 03 Feb 2004 15:47:34 -0500 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7RN-0001Uu-00 for ieprep@ietf.org; Tue, 03 Feb 2004 15:46:37 -0500 Received: from huey.psp.pas.earthlink.net ([207.217.78.220]) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ao7R7-0004mu-00; Tue, 03 Feb 2004 12:46:21 -0800 Message-ID: <28213461.1075841181503.JavaMail.root@huey.psp.pas.earthlink.net> Date: Tue, 3 Feb 2004 15:46:03 -0500 (GMT-05:00) From: Janet Gunn Reply-To: Janet Gunn To: steve.norreys@bt.com, jgunn6@csc.com Subject: RE: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve, I completely agree that pre-emption has no role in ETS voice applications. In addition to (or perhaps in part because of) your points, anything resembling pre-emption on a service connected with the US PSTN is a political/legal non-starter. Even if the governement wanted it (which they don't) the provider's lawyers would soon put a stop to it. I was/am simply trying to extract anything that may be useful in the voice ETS domain from the discussion of MLPP over IP. HOWEVER- In a circuit switched network, if a link or node (switch) goes down, all calls using the node or link are lost. But in an IP network, if a link or switch goes down, it is possible to reroute the calls on the fly. If there is sufficient capacity, all is well, and all calls remain up, and intelligible. But if there is insufficient capacity available after rerouting, you have (at least) 3 choices 1) leave all the calls up, each one will have a significant drop rate, resulting in poor intelligibility. Hope that some of the calls will hang up and try again, leaving additional capacity for the calls that didn't hang up (the most stubborn users win). 2) randomly "shut down" affected calls, until the remaining calls have enough capacity to be intelligible. 3) use some sort of priority scheme to determine which calls to shut down and which to leave up. I don't think I would call any of those three options "pre-emption". Janet -----Original Message----- From: steve.norreys@bt.com Sent: Feb 3, 2004 10:42 AM To: jgunn6@csc.com Cc: ieprep@ietf.org Subject: RE: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Janet and all I have been biting my tongue (ops fingers) for some time now with regards to the MLPP service for supporting ETS in IP networks. As this service has a potential problem as shown by the following scenario: If a call/session is in progress between a non authorised ETS user and a emergency service then this should never be subject to pre-emption by a authorised ETS user, it could have fatal consequences. This by extension could be applied to a call/session in progress between non authorised ETS users, as this contact could be the only point of hope for someone in trouble. In other words the only justification for a pre-emption by a authorised ETS user is that it is only applied to call/session if both the content and context have been analysed. This seems to be a lot of work in a congested network. I have no problems with multiple precedence's or priorities if they are required but I only see the need for two a 'normal' call/session and a 'ETS' call/session. This shows that there maybe a need to take into account the consequences of the requirement to support MLPP especially in regard to pre-emption. Regards Steve Norreys Signalling and Protocols Tel: +441277323220 email steve.norreys@bt.com -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Janet P Gunn Sent: 02 February 2004 22:13 To: Fred Baker Cc: ieprep@ietf.org Subject: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Comments in line. ------------------------------------------------------------------------ ---------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ------------------------------------------------------------------------ ---------------- Fred Baker To: Janet P Gunn cc: ieprep@ietf.org 01/27/2004 09:35 Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt PM At 12:32 PM 1/27/2004, Janet P Gunn wrote: >As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call >admission is working properly, traffic marking is not needed in normal >operations. lest I be misunderstood, let me restate that. What I wrote was: One will ask the value of the multiple DSCPs. They are, in fact, of limited to no value in normal operation, as all vice and video traffic should have been admitted, and therefore capacity will have been assigned to them. The behavior of this service will be indistinguishable from the EF PHB regardless of traffic marking. In retrospect, I wonder what the vice traffic would be :^) [jpg] Maybe all that "organ enlargement" spam? This is not to be understood as saying "no traffic marking is required"; one still needs RFC 3246. But if bandwidth admission is operating correctly, having N different marks will be operationally indistinguishable from having a single EF mark, as the total number of bytes on the wire will be the same. jpg], I did understand that. I was oversimplifying to make my point. >It is in this context that ETS calls must be given a high probability >of meeting the QoS criteria, even when network congestion and or damage >are severe. I wonder if we are communicating here. RFC 3246 is designed to operate in a congested network, and to operate in a network in which routing may change. The comment in the mlpp-that-works draft - which if it is giving cause for confusion I will happily remove - is basically me bending over backwards to be intellectually honest and see if I can find a case where CAC may be insufficient. [jpg] And I was blatantly taking advantage of your "bending over backwards" - to identify a case where CAC may not be sufficient for the ETS Voice application. Think about this for a moment: the argument being placed for MLEF is that even in the presence of some loss, voice is intelligible. If that is true, then just after a route change, during the brief interval between the data flow being switched to a new path and the CAC following that and either OKing the flow or deciding to shut down the call, when there may be some loss, voice should be equally intelligible, no? Or does the argument that voice is able to work around a modest level of loss only work when it comes from the proponents of multiple code points? [jpg] In the ETS voice scenario, I am NOT trying to say that "voice is able to work around a modest level of loss". I am taking the highly elitist position that, if there is a situation where SOME "calls" are going to have to lose packets, I want it to be the non-ETS calls (whether or not the non-ETS calls remain intelligible or not) that lose packets, and not the ETS calls. [jpg] I further agree that, in any situation where "calls" are losing packets, it is highly desirable to "do something" so that you have some calls that remain up and intelligible, and so that other calls go away, rather than using up bandwidth sending packets that are not "useful" from the end user's perspective. And whatever that "something" is, I want it to be able (assuming the appropriate business agreements are in place) to slant the odds in favor of the ETS calls being the ones that stay up and intelligible. Janet << Attachment Removed : C.DTF >> _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Feb 3 18:43:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13350 for ; Tue, 3 Feb 2004 18:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAC4-0002T5-Ac for ieprep-archive@odin.ietf.org; Tue, 03 Feb 2004 18:43:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Nh0cE009483 for ieprep-archive@odin.ietf.org; Tue, 3 Feb 2004 18:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAC4-0002Ss-6U for ieprep-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 18:43:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13344 for ; Tue, 3 Feb 2004 18:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAC1-0000z3-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 18:42:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAB5-0000rg-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 18:42:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoAAB-0000kR-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 18:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAA8-0002Kr-JH; Tue, 03 Feb 2004 18:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoA9s-0002KE-K6 for ieprep@optimus.ietf.org; Tue, 03 Feb 2004 18:40:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13261 for ; Tue, 3 Feb 2004 18:40:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoA9p-0000h4-00 for ieprep@ietf.org; Tue, 03 Feb 2004 18:40:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoA8q-0000af-00 for ieprep@ietf.org; Tue, 03 Feb 2004 18:39:41 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AoA7s-0000QQ-00 for ieprep@ietf.org; Tue, 03 Feb 2004 18:38:40 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Feb 2004 15:44:13 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i13NbxfI019510; Tue, 3 Feb 2004 15:38:07 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id APY23335; Tue, 3 Feb 2004 15:37:58 -0800 (PST) Message-Id: <6.0.1.1.2.20040203152648.056cc958@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 15:37:55 -0800 To: Janet P Gunn From: Fred Baker Subject: Re: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: ieprep@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=---===----=-=----=--==---=-========----=-=-----"; protocol="application/pgp-signature"; micalg=pgp-sha1 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.8 required=5.0 tests=AWL,FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 --=---===----=-=----=--==---=-========----=-=----- Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:12 PM 2/2/2004, Janet P Gunn wrote: >[jpg] In the ETS voice scenario, I am NOT trying to say that "voice is >able to work around a modest level of loss". I am taking the highly >elitist position that, if there is a situation where SOME "calls" are >going to have to lose packets, I want it to be the non-ETS calls (whether >or not the non-ETS calls remain intelligible or not) that lose packets, >and not the ETS calls. I'll agree that it is elitist :^) However, I'll submit that if there is bandwidth-aware CAC, there should not be a great amount of loss. Loss will come from periods in which variable rate codecs (VAD etc) happen to all have an "up" moment and go over the top, resulting in a few packets lost from each call, or from the normal conditions (say "wireless") that cause random loss in networks. If there is not bandwidth-aware CAC, then we are discussing the depth of overprovisioning - either you did enough or you didn't. If you did, I'm not sure what we're discussing - there is going to be plenty of bandwidth, and the SIP reason code and resource priority stuff handles call collisions. If you didn't, we're not talking about occasional dropped packets, we're discussing lost packet groupings in rough multiples of individual call volumes. In the latter case, one really wants to refuse or preempt calls. The discussion of what packets to drop when on alternate Tuesdays the moon skips a beat in its orbit seems a very secondary consideration to delivering a solid service all of the time. >[jpg] I further agree that, in any situation where "calls" are losing >packets, it is highly desirable to "do something" so that you have some >calls that remain up and intelligible, and so that other calls go away, >rather than using up bandwidth sending packets that are not "useful" from >the end user's perspective. And whatever that "something" is, I want it >to be able (assuming the appropriate business agreements are in place) to >slant the odds in favor of the ETS calls being the ones that stay up and >intelligible. I don't know if you heard about the demo we showed DISA and others in December. I don't think anybody is arguing that the ETS/MLPP/whatever calls need to be intelligible. The issue is that the calls you keep are paying for their bandwidth too, and are not getting the service you sold them if you're heaving their packets willy-nilly. At the end of the day, depending only on packet dropping (and yes, Mike, I heard you say in private email that you like CAC too, but I'm looking for the architectural document that says that and I'm having trouble finding it) doesn't deliver that. --=---===----=-=----=--==---=-========----=-=----- Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP 7.0.1 iQA/AwUBQCAw024xHWxyLJtDEQJJCgCeN9ugFjzOXqkjb3amSWPxaLkE4M0Ani7n E6C2pIJL5zQDRhhSiqdSoecz =vP/J -----END PGP MESSAGE----- --=---===----=-=----=--==---=-========----=-=------- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 4 02:05:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01093 for ; Wed, 4 Feb 2004 02:05:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoH5m-0004S9-UB for ieprep-archive@odin.ietf.org; Wed, 04 Feb 2004 02:04:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1474wea017098 for ieprep-archive@odin.ietf.org; Wed, 4 Feb 2004 02:04:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoH5l-0004RX-AH for ieprep-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:04:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00545 for ; Wed, 4 Feb 2004 02:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoH5h-0003wf-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 02:04:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoH4k-0003s5-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 02:03:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoH3u-0003ng-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 02:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoH3t-0003mW-Rr; Wed, 04 Feb 2004 02:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoH3o-0003lj-MK for ieprep@optimus.ietf.org; Wed, 04 Feb 2004 02:02:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28214 for ; Wed, 4 Feb 2004 02:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoH3l-0003n7-00 for ieprep@ietf.org; Wed, 04 Feb 2004 02:02:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoH2m-0003iC-00 for ieprep@ietf.org; Wed, 04 Feb 2004 02:01:53 -0500 Received: from acics.csce.kyushu-u.ac.jp ([133.5.22.128] helo=dontaku.csce.kyushu-u.ac.jp) by ietf-mx with esmtp (Exim 4.12) id 1AoH1m-0003ZG-00 for ieprep@ietf.org; Wed, 04 Feb 2004 02:00:50 -0500 Received: from localhost (IDENT:tomonaga@P061204094046.ppp.prin.ne.jp [61.204.94.46]) by dontaku.csce.kyushu-u.ac.jp (8.12.10/8.12.8) with SMTP id i1470MjO029545; Wed, 4 Feb 2004 16:00:23 +0900 (JST) (envelope-from tomonaga@ale.csce.kyushu-u.ac.jp) Date: Wed, 4 Feb 2004 16:11:43 +0900 From: =?ISO-2022-JP?B?GyRCRCtEORsoQiAbJEI5LzJwGyhC?= To: sob@harvard.edu (Scott Bradner) Cc: ieprep@ietf.org Subject: Re: [Ieprep] IEPREP in Korea Message-Id: <20040204161143.0662507b.tomonaga@ale.csce.kyushu-u.ac.jp> In-Reply-To: <20040115144625.5445FCF3F6@newdev.harvard.edu> References: <20040115144625.5445FCF3F6@newdev.harvard.edu> Organization: =?ISO-2022-JP?B?GyRCNmU9I0JnM1glNyU5JUYlYD5wSnMySjNYSVwbKEI=?= X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-vine-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Scott & Kimberly, I am writing a new internet-draft. And I want to present this draft in the next meeting in Korea. The abstract of the draft is written in below. Abstract This document presents a usage of anycast in support of Emergency Telecommunications Services (ETS) within the context of IP telephony. In the Public Switched Telephone Network (PSTN), 911 is reserved to call to the closest designated emergency agency. Instead of 911, this document presents using anycast addresses within IP architecture and service models for in support of ETS. Now I'm not sure if I will be able to submit this draft till next Monday. If possible, please add my presentation to time schedule of the next meeting. The presentation may take 10 minitus. Regards, Kosuke TOMONAGA On Thu, 15 Jan 2004 09:46:25 -0500 (EST) sob@harvard.edu (Scott Bradner) wrote: > > at this point we do not plan to have an ieprep meeting in Korea > > if feel very strongly that we should please let us know > > Scott & Kimberly > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 4 02:16:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08580 for ; Wed, 4 Feb 2004 02:16:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHGS-0008UK-Cp for ieprep-archive@odin.ietf.org; Wed, 04 Feb 2004 02:16:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147G0Lc032628 for ieprep-archive@odin.ietf.org; Wed, 4 Feb 2004 02:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHGS-0008UB-4a for ieprep-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08226 for ; Wed, 4 Feb 2004 02:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHGO-0004sy-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 02:15:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHFS-0004nr-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 02:14:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoHEV-0004j4-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 02:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHEX-0007v8-KC; Wed, 04 Feb 2004 02:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHEW-0007uO-5w for ieprep@optimus.ietf.org; Wed, 04 Feb 2004 02:14:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07359 for ; Wed, 4 Feb 2004 02:13:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHES-0004ih-00 for ieprep@ietf.org; Wed, 04 Feb 2004 02:13:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHDY-0004e7-00 for ieprep@ietf.org; Wed, 04 Feb 2004 02:13:01 -0500 Received: from acics.csce.kyushu-u.ac.jp ([133.5.22.128] helo=dontaku.csce.kyushu-u.ac.jp) by ietf-mx with esmtp (Exim 4.12) id 1AoHD9-0004Z6-00 for ieprep@ietf.org; Wed, 04 Feb 2004 02:12:35 -0500 Received: from localhost (IDENT:tomonaga@P061204094046.ppp.prin.ne.jp [61.204.94.46]) by dontaku.csce.kyushu-u.ac.jp (8.12.10/8.12.8) with SMTP id i147CUjO029854; Wed, 4 Feb 2004 16:12:31 +0900 (JST) (envelope-from tomonaga@ale.csce.kyushu-u.ac.jp) Date: Wed, 4 Feb 2004 16:23:53 +0900 From: Kosuke TOMONAGA To: sob@harvard.edu (Scott Bradner) Cc: ieprep@ietf.org Subject: Re: [Ieprep] IEPREP in Korea Message-Id: <20040204162353.65c56d1e.tomonaga@ale.csce.kyushu-u.ac.jp> In-Reply-To: <20040115144625.5445FCF3F6@newdev.harvard.edu> References: <20040115144625.5445FCF3F6@newdev.harvard.edu> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-vine-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry, I sended a wrong mail including japanese font. I submit again. Regards, Kosuke TOMONAGA --- Hi, Scott & Kimberly, I am writing a new internet-draft. And I want to present this draft in the next meeting in Korea. The abstract of the draft is written in below. Abstract This document presents a usage of anycast in support of Emergency Telecommunications Services (ETS) within the context of IP telephony. In the Public Switched Telephone Network (PSTN), 911 is reserved to call to the closest designated emergency agency. Instead of 911, this document presents using anycast addresses within IP architecture and service models for in support of ETS. Now I'm not sure if I will be able to submit this draft till next Monday. If possible, please add my presentation to time schedule of the next meeting. The presentation may take 10 minitus. Regards, Kosuke TOMONAGA On Thu, 15 Jan 2004 09:46:25 -0500 (EST) sob@harvard.edu (Scott Bradner) wrote: > > at this point we do not plan to have an ieprep meeting in Korea > > if feel very strongly that we should please let us know > > Scott & Kimberly > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 4 06:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01132 for ; Wed, 4 Feb 2004 06:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLEL-0004dW-EH for ieprep-archive@odin.ietf.org; Wed, 04 Feb 2004 06:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14BU5bs017821 for ieprep-archive@odin.ietf.org; Wed, 4 Feb 2004 06:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLEL-0004dM-8F for ieprep-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 06:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01060 for ; Wed, 4 Feb 2004 06:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLEH-0007Sp-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 06:30:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLDI-0007Nb-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 06:29:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLCJ-0007Fj-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 06:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLCL-0004Ss-7r; Wed, 04 Feb 2004 06:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLBV-0004RW-Jb for ieprep@optimus.ietf.org; Wed, 04 Feb 2004 06:27:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01006 for ; Wed, 4 Feb 2004 06:27:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLBR-0007EF-00 for ieprep@ietf.org; Wed, 04 Feb 2004 06:27:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLAY-00079L-00 for ieprep@ietf.org; Wed, 04 Feb 2004 06:26:11 -0500 Received: from acics.csce.kyushu-u.ac.jp ([133.5.22.128] helo=dontaku.csce.kyushu-u.ac.jp) by ietf-mx with esmtp (Exim 4.12) id 1AoL9n-00073w-00 for ieprep@ietf.org; Wed, 04 Feb 2004 06:25:24 -0500 Received: from localhost (IDENT:tomonaga@P061198143155.ppp.prin.ne.jp [61.198.143.155]) by dontaku.csce.kyushu-u.ac.jp (8.12.10/8.12.8) with SMTP id i14BPDjO032133; Wed, 4 Feb 2004 20:25:14 +0900 (JST) (envelope-from tomonaga@ale.csce.kyushu-u.ac.jp) Date: Wed, 4 Feb 2004 20:36:35 +0900 From: Kosuke TOMONAGA To: "King, Kimberly S." Cc: ieprep@ietf.org Subject: Re: [Ieprep] IEPREP in Korea Message-Id: <20040204203635.2b48e483.tomonaga@ale.csce.kyushu-u.ac.jp> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-vine-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Kimberly, > Please submit your draft but we won't have an IEPREP meeting in Korea. Thank you, I'll submit my draft. But I feel very strongly that we should hold the meeting. Because we did not have an IEPREP meeting in the previous IETF meeting. Regards, Kosuke TOMONAGA On Wed, 4 Feb 2004 04:19:20 -0500 "King, Kimberly S." wrote: > Hello, > > Please submit your draft but we won't have an IEPREP meeting in Korea. > > Kimberly > > -----Original Message----- > From: ieprep-admin@ietf.org > To: sob@harvard.edu > Cc: ieprep@ietf.org > Sent: 2/4/2004 2:23 AM > Subject: Re: [Ieprep] IEPREP in Korea > > Sorry, I sended a wrong mail including japanese font. > I submit again. > > Regards, > Kosuke TOMONAGA > > --- > Hi, Scott & Kimberly, > > I am writing a new internet-draft. And I want to present this draft > in the next meeting in Korea. The abstract of the draft is written in > below. > > Abstract > > This document presents a usage of anycast in support of Emergency > Telecommunications Services (ETS) within the context of IP telephony. > > In the Public Switched Telephone Network (PSTN), 911 is reserved to > call to the closest designated emergency agency. Instead of 911, > this document presents using anycast addresses within IP architecture > > and service models for in support of ETS. > > > Now I'm not sure if I will be able to submit this draft till next > Monday. > If possible, please add my presentation to time schedule of the next > meeting. > The presentation may take 10 minitus. > > Regards, > Kosuke TOMONAGA > > > On Thu, 15 Jan 2004 09:46:25 -0500 (EST) > sob@harvard.edu (Scott Bradner) wrote: > > > > > at this point we do not plan to have an ieprep meeting in Korea > > > > if feel very strongly that we should please let us know > > > > Scott & Kimberly > > > > _______________________________________________ > > Ieprep mailing list > > Ieprep@ietf.org > > https://www1.ietf.org/mailman/listinfo/ieprep > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 4 07:12:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02883 for ; Wed, 4 Feb 2004 07:12:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLt7-0007UE-9c for ieprep-archive@odin.ietf.org; Wed, 04 Feb 2004 07:12:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14CCDTL028771 for ieprep-archive@odin.ietf.org; Wed, 4 Feb 2004 07:12:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLt7-0007Ty-46 for ieprep-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:12:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02875 for ; Wed, 4 Feb 2004 07:12:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLt6-000461-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 07:12:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLs8-00040V-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 07:11:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLrv-0003v2-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 07:10:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLrx-0007Lh-K7; Wed, 04 Feb 2004 07:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLr7-0007JR-0K for ieprep@optimus.ietf.org; Wed, 04 Feb 2004 07:10:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02815 for ; Wed, 4 Feb 2004 07:10:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLr2-0003uD-00 for ieprep@ietf.org; Wed, 04 Feb 2004 07:10:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLqA-0003pk-00 for ieprep@ietf.org; Wed, 04 Feb 2004 07:09:11 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1AoLpQ-0003ea-00 for ieprep@ietf.org; Wed, 04 Feb 2004 07:08:24 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 048BC10246A; Wed, 4 Feb 2004 07:07:50 -0500 (EST) To: sob@harvard.edu, tomonaga@ale.csce.kyushu-u.ac.jp Subject: Re: [Ieprep] IEPREP in Korea Cc: ieprep@ietf.org In-Reply-To: <20040204161143.0662507b.tomonaga@ale.csce.kyushu-u.ac.jp> Message-Id: <20040204120750.048BC10246A@newdev.harvard.edu> Date: Wed, 4 Feb 2004 07:07:50 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 we do not plan to have an ieprep session during the meeting but even if we did we do not provide time to present internet drafts that have not had discussion on the list note that the pre meeting cutoff is 9am US eastern time on monday - any new ID submission received after that time will be rejected (the cutoff for revised IDs is teh following monday) Scott --- From tomonaga@ale.csce.kyushu-u.ac.jp Wed Feb 4 02:00:37 2004 X-Original-To: sob@newdev.harvard.edu Delivered-To: sob@newdev.harvard.edu Date: Wed, 4 Feb 2004 16:11:43 +0900 From: =?ISO-2022-JP?B?GyRCRCtEORsoQiAbJEI5LzJwGyhC?= To: sob@harvard.edu (Scott Bradner) Cc: ieprep@ietf.org Subject: Re: [Ieprep] IEPREP in Korea In-Reply-To: <20040115144625.5445FCF3F6@newdev.harvard.edu> References: <20040115144625.5445FCF3F6@newdev.harvard.edu> Organization: =?ISO-2022-JP?B?GyRCNmU9I0JnM1glNyU5JUYlYD5wSnMySjNYSVwbKEI=?= X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-vine-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Scott & Kimberly, I am writing a new internet-draft. And I want to present this draft in the next meeting in Korea. The abstract of the draft is written in below. Abstract This document presents a usage of anycast in support of Emergency Telecommunications Services (ETS) within the context of IP telephony. In the Public Switched Telephone Network (PSTN), 911 is reserved to call to the closest designated emergency agency. Instead of 911, this document presents using anycast addresses within IP architecture and service models for in support of ETS. Now I'm not sure if I will be able to submit this draft till next Monday. If possible, please add my presentation to time schedule of the next meeting. The presentation may take 10 minitus. Regards, Kosuke TOMONAGA On Thu, 15 Jan 2004 09:46:25 -0500 (EST) sob@harvard.edu (Scott Bradner) wrote: > > at this point we do not plan to have an ieprep meeting in Korea > > if feel very strongly that we should please let us know > > Scott & Kimberly > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 4 08:04:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04424 for ; Wed, 4 Feb 2004 08:04:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMhU-0002lc-8K for ieprep-archive@odin.ietf.org; Wed, 04 Feb 2004 08:04:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14D4GOu010635 for ieprep-archive@odin.ietf.org; Wed, 4 Feb 2004 08:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMhU-0002lS-3g for ieprep-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 08:04:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04400 for ; Wed, 4 Feb 2004 08:04:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMhS-00019D-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 08:04:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMgY-00013x-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 08:03:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMgH-0000y6-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 08:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMgH-0002W5-6X; Wed, 04 Feb 2004 08:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMfS-0002Ua-RW for ieprep@optimus.ietf.org; Wed, 04 Feb 2004 08:02:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04346 for ; Wed, 4 Feb 2004 08:02:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMfR-0000x1-00 for ieprep@ietf.org; Wed, 04 Feb 2004 08:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMeU-0000s9-00 for ieprep@ietf.org; Wed, 04 Feb 2004 08:01:11 -0500 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by ietf-mx with esmtp (Exim 4.12) id 1AoMe0-0000nA-00 for ieprep@ietf.org; Wed, 04 Feb 2004 08:00:40 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 08:00:10 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B638F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'?? ??'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] IEPREP in Korea Date: Wed, 4 Feb 2004 08:00:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I think this draft is not appropriate for IEPREP, at least as I interpret the draft. I believe the IEPREP charter deals with how the Internet can be used in disasters, where existing facilities may be needed by responders to organize relief. The normal call for help, for which 9-1-1 would be the phone number in North America, is out of scope. We are dealing with these issues in sipping, and there is a draft (currently expired, but expected to be reissued shortly) that covers the specific problem raised by this draft (9-1-1 is not an internationally recognized directory number for emergencies), although it proposes a different solution. Brian > -----Original Message----- > From: tomonaga@ale.csce.kyushu-u.ac.jp > [mailto:tomonaga@ale.csce.kyushu-u.ac.jp] > Sent: Wednesday, February 04, 2004 2:12 AM > To: sob@harvard.edu > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] IEPREP in Korea > > > Hi, Scott & Kimberly, > > I am writing a new internet-draft. And I want to present this draft > in the next meeting in Korea. The abstract of the draft is written in > below. > > Abstract > > This document presents a usage of anycast in support of Emergency > Telecommunications Services (ETS) within the context of IP > telephony. > In the Public Switched Telephone Network (PSTN), 911 is > reserved to > call to the closest designated emergency agency. Instead of 911, > this document presents using anycast addresses within IP > architecture > and service models for in support of ETS. > > > Now I'm not sure if I will be able to submit this draft till > next Monday. > If possible, please add my presentation to time schedule of > the next meeting. > The presentation may take 10 minitus. > > Regards, > Kosuke TOMONAGA > > > On Thu, 15 Jan 2004 09:46:25 -0500 (EST) > sob@harvard.edu (Scott Bradner) wrote: > > > > > at this point we do not plan to have an ieprep meeting in Korea > > > > if feel very strongly that we should please let us know > > > > Scott & Kimberly > > > > _______________________________________________ > > Ieprep mailing list > > Ieprep@ietf.org > > https://www1.ietf.org/mailman/listinfo/ieprep > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 4 08:16:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04715 for ; Wed, 4 Feb 2004 08:16:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMt2-0003ky-KQ for ieprep-archive@odin.ietf.org; Wed, 04 Feb 2004 08:16:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14DGCYU014433 for ieprep-archive@odin.ietf.org; Wed, 4 Feb 2004 08:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMt2-0003kh-D2 for ieprep-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 08:16:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04712 for ; Wed, 4 Feb 2004 08:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMt1-0002IE-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 08:16:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMs3-0002DU-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 08:15:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoMru-00028i-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 08:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMru-0003dr-4j; Wed, 04 Feb 2004 08:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoMr7-0003cc-KO for ieprep@optimus.ietf.org; Wed, 04 Feb 2004 08:14:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04671 for ; Wed, 4 Feb 2004 08:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoMr6-00027v-00 for ieprep@ietf.org; Wed, 04 Feb 2004 08:14:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoMqF-000230-00 for ieprep@ietf.org; Wed, 04 Feb 2004 08:13:19 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1AoMpr-0001w4-00 for ieprep@ietf.org; Wed, 04 Feb 2004 08:12:55 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id DE6C81026E7; Wed, 4 Feb 2004 08:12:19 -0500 (EST) To: Brian.Rosen@marconi.com, tomonaga@ale.csce.kyushu-u.ac.jp Subject: RE: [Ieprep] IEPREP in Korea Cc: ieprep@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B638F@whq-msgusr-02.pit.comms.marconi.com> Message-Id: <20040204131219.DE6C81026E7@newdev.harvard.edu> Date: Wed, 4 Feb 2004 08:12:19 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > The normal call for help, for which 9-1-1 would be the phone number > in North America, is out of scope. Brian is corect that citizen-to-authority emergency calling is out of scope for ieprep and is being addressed in sipping Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 4 16:22:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29676 for ; Wed, 4 Feb 2004 16:22:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoUTd-0008Mi-QU for ieprep-archive@odin.ietf.org; Wed, 04 Feb 2004 16:22:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14LMTth032155 for ieprep-archive@odin.ietf.org; Wed, 4 Feb 2004 16:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoUTd-0008MU-Ic for ieprep-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 16:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29535 for ; Wed, 4 Feb 2004 16:22:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoUTb-000095-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 16:22:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoUSM-0007eO-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 16:21:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoURL-0007Py-00 for ieprep-web-archive@ietf.org; Wed, 04 Feb 2004 16:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoURF-0008Cw-TS; Wed, 04 Feb 2004 16:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoURB-0008CO-6U for ieprep@optimus.ietf.org; Wed, 04 Feb 2004 16:19:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29114 for ; Wed, 4 Feb 2004 16:19:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoUR9-0007Ny-00 for ieprep@ietf.org; Wed, 04 Feb 2004 16:19:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoUPb-0006wx-00 for ieprep@ietf.org; Wed, 04 Feb 2004 16:18:20 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1AoUN1-0006Aj-00 for ieprep@ietf.org; Wed, 04 Feb 2004 16:15:39 -0500 Received: (qmail 24207 invoked from network); 4 Feb 2004 21:15:00 -0000 Received: from pool-141-157-19-111.balt.east.verizon.net (HELO albers) (141.157.19.111) by phobos.simply.net with SMTP; 4 Feb 2004 21:15:00 -0000 From: "Ken Carlberg" To: Cc: Subject: RE: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Wed, 4 Feb 2004 16:14:59 -0500 Message-ID: <000601c3eb63$f31fc0e0$7401a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <9D598A34672DF24F89FF4F851A416195085DC021@i2km08-ukbr.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Steve, Just a couple of comments for clarification to hopefully alleviate some of your concerns... > If a call/session is in progress between a non authorised ETS user and a > emergency service then this should never be subject to pre-emption by a > authorised ETS user, it could have fatal consequences. This by extension > could be applied to a call/session in progress between non authorised > ETS users, as this contact could be the only point of hope for someone > in trouble. In the soon-to-be-released RFC-3689, General Requirements for ETS, there are a couple of pertinent excerpts about "policy". Paraphrased, it says that a set of labels may exist and that they may have a stated relationship to each other. In the case of MLPP, this would include preemption. HOWEVER, that relationship is only for *that* set. This means that the characteristic of preemption does not automatically correlate to a different set of defined labels. Instead, that relationship is defined by local policy. Put another way, the fact that MLPP has precedence does not mean that the same characteristic automatically applies to other labels (ie, other ETS type labels) or non labeled traffic. Instead, you the operator (if you support ETS labels) decide the relationship between different sets of ETS type labels, as well as the relationship between ETS and non-ETS labeled traffic. If this is still not clear, contact me privately and I will expand. Note: In the case of BT, Oftel may make that decision for you based on laws/regulations, but that's outside the scope of the technology. In the case of the US PSTN, automated preemption is not allowed. -ken ps, the predominance of MLPP systems in use today are in private (non-PSTN) systems. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Feb 6 13:55:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09217 for ; Fri, 6 Feb 2004 13:55:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB7w-0002s5-U8 for ieprep-archive@odin.ietf.org; Fri, 06 Feb 2004 13:54:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16IsuAH011036 for ieprep-archive@odin.ietf.org; Fri, 6 Feb 2004 13:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB7w-0002rv-Po for ieprep-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 13:54:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09204 for ; Fri, 6 Feb 2004 13:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApB7u-0002lp-00 for ieprep-web-archive@ietf.org; Fri, 06 Feb 2004 13:54:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApB6x-0002it-00 for ieprep-web-archive@ietf.org; Fri, 06 Feb 2004 13:53:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApB65-0002fw-00 for ieprep-web-archive@ietf.org; Fri, 06 Feb 2004 13:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB65-0002j6-03; Fri, 06 Feb 2004 13:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB60-0002iU-J5 for ieprep@optimus.ietf.org; Fri, 06 Feb 2004 13:52:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09163 for ; Fri, 6 Feb 2004 13:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApB5y-0002f5-00 for ieprep@ietf.org; Fri, 06 Feb 2004 13:52:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApB55-0002cL-00 for ieprep@ietf.org; Fri, 06 Feb 2004 13:52:00 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1ApB4b-0002Z8-00; Fri, 06 Feb 2004 13:51:29 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i16IpTk24393; Fri, 6 Feb 2004 10:51:29 -0800 (PST) Message-Id: <200402061851.i16IpTk24393@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, ieprep@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Feb 2004 10:51:28 -0800 Subject: [Ieprep] RFC 3689 on General Requirements for Emergency Telecommunication Service (ETS) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Author(s): K. Carlberg, R. Atkinson Status: Informational Date: February 2004 Mailbox: k.carlberg@cs.ucl.ac.uk, rja@extremenetworks.com Pages: 10 Characters: 21680 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ieprep-ets-general-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3689.txt 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). This document is a product of the Internet Emergency Preparedness Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040206105011.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3689 --OtherAccess Content-Type: Message/External-body; name="rfc3689.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040206105011.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Feb 6 13:57:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09306 for ; Fri, 6 Feb 2004 13:57:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB9q-00034d-Aq for ieprep-archive@odin.ietf.org; Fri, 06 Feb 2004 13:56:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Iusop011809 for ieprep-archive@odin.ietf.org; Fri, 6 Feb 2004 13:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB9q-00034O-7Z for ieprep-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 13:56:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09288 for ; Fri, 6 Feb 2004 13:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApB9o-0002s0-00 for ieprep-web-archive@ietf.org; Fri, 06 Feb 2004 13:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApB8w-0002os-00 for ieprep-web-archive@ietf.org; Fri, 06 Feb 2004 13:55:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApB81-0002mO-00 for ieprep-web-archive@ietf.org; Fri, 06 Feb 2004 13:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB82-0002t4-V2; Fri, 06 Feb 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB7x-0002sD-EO for ieprep@optimus.ietf.org; Fri, 06 Feb 2004 13:54:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09207 for ; Fri, 6 Feb 2004 13:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApB7v-0002lu-00 for ieprep@ietf.org; Fri, 06 Feb 2004 13:54:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApB6y-0002j1-00 for ieprep@ietf.org; Fri, 06 Feb 2004 13:53:57 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1ApB68-0002fz-00; Fri, 06 Feb 2004 13:53:05 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i16Ir4k24893; Fri, 6 Feb 2004 10:53:04 -0800 (PST) Message-Id: <200402061853.i16Ir4k24893@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, ieprep@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Feb 2004 10:53:04 -0800 Subject: [Ieprep] RFC 3690 on IP Telephony Requirements for Emergency Telecommunication Service (ETS) Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Author(s): K. Carlberg, R. Atkinson Status: Informational Date: February 2004 Mailbox: k.carlberg@cs.ucl.ac.uk, rja@extremenetworks.com Pages: 7 Characters: 13919 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ieprep-ets-telephony-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3690.txt 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. This document is a product of the Internet Emergency Preparedness Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040206105150.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3690 --OtherAccess Content-Type: Message/External-body; name="rfc3690.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040206105150.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 9 16:26:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14634 for ; Mon, 9 Feb 2004 16:26:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIvF-0003fB-ES for ieprep-archive@odin.ietf.org; Mon, 09 Feb 2004 16:26:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LQT0f014080 for ieprep-archive@odin.ietf.org; Mon, 9 Feb 2004 16:26:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIvF-0003f1-9e for ieprep-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:26:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14526 for ; Mon, 9 Feb 2004 16:26:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIvD-0004P2-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 16:26:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIsr-0003sh-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 16:24:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIr0-0003Rx-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 16:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqw-0002p1-Is; Mon, 09 Feb 2004 16:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqI-0002l3-OM for ieprep@optimus.ietf.org; Mon, 09 Feb 2004 16:21:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13732; Mon, 9 Feb 2004 16:21:19 -0500 (EST) Message-Id: <200402092121.QAA13732@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 09 Feb 2004 16:21:19 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-08.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Framework for Supporting IEPS in IP Telephony Author(s) : K. Carlberg, I. Brown, C. Beard Filename : draft-ietf-ieprep-framework-08.txt Pages : 27 Date : 2004-2-9 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 PSTN, contribute to a constrained solution space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-framework-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ieprep-framework-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-framework-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-9162035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-framework-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-framework-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9162035.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 9 17:26:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23076 for ; Mon, 9 Feb 2004 17:26:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJqZ-0001Wg-Gr for ieprep-archive@odin.ietf.org; Mon, 09 Feb 2004 17:25:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MPhCR005866 for ieprep-archive@odin.ietf.org; Mon, 9 Feb 2004 17:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJqZ-0001WX-Cg for ieprep-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22999 for ; Mon, 9 Feb 2004 17:25:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJqW-0007SD-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 17:25:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJp8-00078c-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 17:24:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJo4-0006v7-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 17:23:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqJo3-0001yE-Uv for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 17:23:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJny-0001J9-Ik; Mon, 09 Feb 2004 17:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJni-0001GZ-Ig for ieprep@optimus.ietf.org; Mon, 09 Feb 2004 17:22:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22660 for ; Mon, 9 Feb 2004 17:22:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJng-0006qt-00 for ieprep@ietf.org; Mon, 09 Feb 2004 17:22:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJms-0006hD-00 for ieprep@ietf.org; Mon, 09 Feb 2004 17:21:54 -0500 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1AqJlc-0006Qi-00 for ieprep@ietf.org; Mon, 09 Feb 2004 17:20:36 -0500 Received: from skeeter.psp.pas.earthlink.net ([207.217.78.186]) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AqJlX-0003uK-00; Mon, 09 Feb 2004 14:20:31 -0800 Message-ID: <7184932.1076365231293.JavaMail.root@skeeter.psp.pas.earthlink.net> Date: Mon, 9 Feb 2004 14:20:06 -0800 (PST) From: Janet Gunn Reply-To: Janet Gunn To: Scott Bradner , jgunn6@csc.com, jmpolk@cisco.com Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: fred@cisco.com, ieprep@ietf.org, steves@shentel.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have finally had a chance to do some more reading, and I think I fianlly understand the source of my confusion (and probably some others). I had assumed that the term "Call Admission Control" was active only only at the START of a call- that once a call had been admitted in the first place, there was no further CAC involvement. However, reading between the lines in several posts, and relating that to some of the reference documents, it appears that the term CAC is being applied to a mechanism which remains involved throught the live of the call, and can "rescind" the admission during the course of the call, if necessary. Is this right, or am I just barking up a different wrong tree? Janet -----Original Message----- From: Scott Bradner Sent: Feb 3, 2004 5:31 AM To: jgunn6@csc.com, jmpolk@cisco.com Cc: fred@cisco.com, ieprep@ietf.org, steves@shentel.net Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt > [jpg] It is not clear to me how CAC says "sorry, but there was another call > with higher priority, and I have to shut your call down now" once the call > has been established. I was under the impression that, once the call was > established, the router did not distinguish between individual calls. I > would be glad to be enlightened on that point. note that the router is not involved in establishing the call - its all packets to the router but if the call QoS is maintained by RSVP (as Fred suggested) there is less of an issue - a router can reject RSVP sessions even after they have started Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 9 18:07:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27549 for ; Mon, 9 Feb 2004 18:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKUV-0006yF-Eu for ieprep-archive@odin.ietf.org; Mon, 09 Feb 2004 18:06:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19N6xec026794 for ieprep-archive@odin.ietf.org; Mon, 9 Feb 2004 18:06:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKUV-0006y5-BQ for ieprep-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 18:06:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27475 for ; Mon, 9 Feb 2004 18:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKUS-0005Vl-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 18:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKTT-0005MY-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 18:05:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqKSf-0005D0-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 18:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKSd-0006Ou-2K; Mon, 09 Feb 2004 18:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKSA-0006Fo-6X for ieprep@optimus.ietf.org; Mon, 09 Feb 2004 18:04:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27082 for ; Mon, 9 Feb 2004 18:04:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKS7-00059M-00 for ieprep@ietf.org; Mon, 09 Feb 2004 18:04:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKRE-00051z-00 for ieprep@ietf.org; Mon, 09 Feb 2004 18:03:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqKQO-0004mZ-00 for ieprep@ietf.org; Mon, 09 Feb 2004 18:02:44 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2004 15:10:09 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i19N2BGv019920; Mon, 9 Feb 2004 15:02:12 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA08322; Mon, 9 Feb 2004 15:02:11 -0800 (PST) Message-Id: <4.3.2.7.2.20040209165114.03e54cc0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 17:02:26 -0600 To: Janet Gunn , Scott Bradner , jgunn6@csc.com From: "James M. Polk" Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: fred@cisco.com, ieprep@ietf.org, steves@shentel.net In-Reply-To: <7184932.1076365231293.JavaMail.root@skeeter.psp.pas.earthl ink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 02:20 PM 2/9/2004 -0800, Janet Gunn wrote: >I have finally had a chance to do some more reading, and I think I fianlly >understand the source of my confusion (and probably some others). > >I had assumed that the term "Call Admission Control" was active only only >at the START of a call- that once a call had been admitted in the first >place, there was no further CAC involvement. > >However, reading between the lines in several posts, and relating that to >some of the reference documents, it appears that the term CAC is being >applied to a mechanism which remains involved throught the live of the >call, and can "rescind" the admission during the course of the call, if >necessary. What you were believing was the case is called "Locations based CAC" (done once at start-up, and not again). This is a hack, but kinda sorta works in very limited links between 2 locations (not daisy-chained mind you, the complexity and topology knowledge is just not really possible then). What you have realized about RSVP is that the CAC functionality is from call inception, makes sure there is enough resources to complete a call at a known bandwidth (errors the set-up if there isn't enough), and the routers in between remain in a "soft state" condition for all the RSVP "flows" that have been accepted through that interface for the duration of all the flows (or calls) until their end, which is either by a normal end of a call (user hang-up) or a preemption event at a congested router interface (to make room for another flow/call). >Is this right, or am I just barking up a different wrong tree? the crowd applauds!! >Janet > >-----Original Message----- >From: Scott Bradner >Sent: Feb 3, 2004 5:31 AM >To: jgunn6@csc.com, jmpolk@cisco.com >Cc: fred@cisco.com, ieprep@ietf.org, steves@shentel.net >Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt > > > [jpg] It is not clear to me how CAC says "sorry, but there was another call > > with higher priority, and I have to shut your call down now" once the call > > has been established. I was under the impression that, once the call was > > established, the router did not distinguish between individual calls. I > > would be glad to be enlightened on that point. > >note that the router is not involved in establishing the call - its all >packets to the router > >but if the call QoS is maintained by RSVP (as Fred suggested) there is >less of an issue - a router can reject RSVP sessions even after they >have started > >Scott > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 9 19:22:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04177 for ; Mon, 9 Feb 2004 19:22:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLeg-0006Rl-8x for ieprep-archive@odin.ietf.org; Mon, 09 Feb 2004 19:21:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0LYx2024775 for ieprep-archive@odin.ietf.org; Mon, 9 Feb 2004 19:21:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLeg-0006RW-3p for ieprep-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 19:21:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04168 for ; Mon, 9 Feb 2004 19:21:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLee-0007HM-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 19:21:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLdp-0007C1-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 19:20:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqLdD-00075Y-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 19:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLdD-0006No-Qc; Mon, 09 Feb 2004 19:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLcx-0006Ll-1u for ieprep@optimus.ietf.org; Mon, 09 Feb 2004 19:19:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03963 for ; Mon, 9 Feb 2004 19:19:43 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLcv-00072r-00 for ieprep@ietf.org; Mon, 09 Feb 2004 19:19:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLbw-0006qs-00 for ieprep@ietf.org; Mon, 09 Feb 2004 19:18:45 -0500 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 1AqLak-0006Va-00 for ieprep@ietf.org; Mon, 09 Feb 2004 19:17:30 -0500 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36_r4.12.) id u.11c.2b203b73 (3657); Mon, 9 Feb 2004 19:16:43 -0500 (EST) Message-ID: <11c.2b203b73.2d597ceb@aol.com> Date: Mon, 9 Feb 2004 19:16:43 EST Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: jgunn@ix.netcom.com, sob@harvard.edu, jgunn6@csc.com, jmpolk@cisco.com CC: fred@cisco.com, ieprep@ietf.org, steves@shentel.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_11c.2b203b73.2d597ceb_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_11c.2b203b73.2d597ceb_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/9/2004 5:23:37 PM Eastern Standard Time, jgunn@ix.netcom.com writes: > I had assumed that the term "Call Admission Control" was active only only > at the START of a call- that once a call had been admitted in the first place, > there was no further CAC involvement. > > However, reading between the lines in several posts, and relating that to > some of the reference documents, it appears that the term CAC is being applied > to a mechanism which remains involved throught the live of the call, and can > "rescind" the admission during the course of the call, if necessary. > This is a term which needs consistent definition before we continue. It's being used in different ways, including as you noted above. Since the term is "Admission", I believe it only makes sense to use "CAC" it to refer to the control that is placed on deciding whether or not to admit a new call (i.e., packet flow), not on anything that is done later to decide whether to preempt a call or terminate a packet flow. Mike --part1_11c.2b203b73.2d597ceb_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/9/2004 5:23:37 PM Eastern Standard Time, jgunn@ix.netcom.com writes:


I had assumed that the term= "Call Admission Control" was active only only at the START of a call- that=20= once a call had been admitted in the first place, there was no further CAC i= nvolvement.  

However, reading between the lines in several posts, and relating that t= o some of the reference documents, it appears that the term CAC is being app= lied to a mechanism which remains involved throught the live of the call, an= d can "rescind" the admission during the course of the call, if necessary.



This is a term which needs consistent definition before we continue. It'= s being used in different ways, including as you noted above.

Since the term is "Admission", I believe it only makes sense to use "CAC= " it to refer to the control that is placed on deciding whether or not to ad= mit a new call (i.e., packet flow), not on anything that is done later to de= cide whether to preempt a call or terminate a packet flow.

Mike
--part1_11c.2b203b73.2d597ceb_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 9 19:46:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06765 for ; Mon, 9 Feb 2004 19:46:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqM2Y-0007Kv-T1 for ieprep-archive@odin.ietf.org; Mon, 09 Feb 2004 19:46:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0kEbg028201 for ieprep-archive@odin.ietf.org; Mon, 9 Feb 2004 19:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqM2Y-0007Km-Q4 for ieprep-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 19:46:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06671 for ; Mon, 9 Feb 2004 19:46:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqM2X-0003Ed-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 19:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqM10-0002sd-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 19:44:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqLyV-0002QJ-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 19:42:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqLyW-0003uW-2D for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 19:42:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLyT-0007ER-7D; Mon, 09 Feb 2004 19:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLyA-0007E4-BT for ieprep@optimus.ietf.org; Mon, 09 Feb 2004 19:41:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06166 for ; Mon, 9 Feb 2004 19:41:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLy8-0002Mz-00 for ieprep@ietf.org; Mon, 09 Feb 2004 19:41:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLx5-0002Ab-00 for ieprep@ietf.org; Mon, 09 Feb 2004 19:40:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqLvx-0001p1-00 for ieprep@ietf.org; Mon, 09 Feb 2004 19:39:25 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2004 16:46:51 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1A0cqu5012798; Mon, 9 Feb 2004 16:38:52 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA11999; Mon, 9 Feb 2004 16:38:51 -0800 (PST) Message-Id: <4.3.2.7.2.20040209183201.03ed7c88@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 18:39:06 -0600 To: Mpierce1@aol.com, jgunn@ix.netcom.com, sob@harvard.edu, jgunn6@csc.com From: "James M. Polk" Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: fred@cisco.com, ieprep@ietf.org, steves@shentel.net In-Reply-To: <11c.2b203b73.2d597ceb@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I'm sorry Mike, but that is the functionality RSVP does and has done for many many years.... I'm not going to change it. Further, the maintenance CAC function (what you would call the part after initial admission) is what RSVP does. When referring to CAC and RSVP, this is the definition that is used in the IETF for voice and video flows. When in Rome, you do what the Roman's do.... At 07:16 PM 2/9/2004 -0500, Mpierce1@aol.com wrote: >In a message dated 2/9/2004 5:23:37 PM Eastern Standard Time, >jgunn@ix.netcom.com writes: > > >>I had assumed that the term "Call Admission Control" was active only only >>at the START of a call- that once a call had been admitted in the first >>place, there was no further CAC involvement. >> >>However, reading between the lines in several posts, and relating that to >>some of the reference documents, it appears that the term CAC is being >>applied to a mechanism which remains involved throught the live of the >>call, and can "rescind" the admission during the course of the call, if >>necessary. > > > >This is a term which needs consistent definition before we continue. It's >being used in different ways, including as you noted above. > >Since the term is "Admission", I believe it only makes sense to use "CAC" >it to refer to the control that is placed on deciding whether or not to >admit a new call (i.e., packet flow), not on anything that is done later >to decide whether to preempt a call or terminate a packet flow. > >Mike cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Feb 9 21:04:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10767 for ; Mon, 9 Feb 2004 21:04:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNFO-0003IF-Kg for ieprep-archive@odin.ietf.org; Mon, 09 Feb 2004 21:03:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A23YM1012658 for ieprep-archive@odin.ietf.org; Mon, 9 Feb 2004 21:03:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNFO-0003I5-Cg for ieprep-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 21:03:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10749 for ; Mon, 9 Feb 2004 21:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqNFL-0003gz-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 21:03:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqNES-0003bb-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 21:02:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqNDs-0003WJ-00 for ieprep-web-archive@ietf.org; Mon, 09 Feb 2004 21:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNDt-0003Dq-Ja; Mon, 09 Feb 2004 21:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqNDM-0003DG-L4 for ieprep@optimus.ietf.org; Mon, 09 Feb 2004 21:01:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10681 for ; Mon, 9 Feb 2004 21:01:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqNDK-0003Ub-00 for ieprep@ietf.org; Mon, 09 Feb 2004 21:01:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqNCN-0003Qq-00 for ieprep@ietf.org; Mon, 09 Feb 2004 21:00:28 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqNBo-0003J6-00 for ieprep@ietf.org; Mon, 09 Feb 2004 20:59:52 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1A1xKuA004606; Mon, 9 Feb 2004 17:59:20 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (dhcp-171-68-147-47.cisco.com [171.68.147.47]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQD20434; Mon, 9 Feb 2004 17:59:20 -0800 (PST) Message-Id: <6.0.1.1.2.20040209161948.05539628@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 09 Feb 2004 17:59:00 -0800 To: Mpierce1@aol.com From: Fred Baker Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: ieprep@ietf.org In-Reply-To: <11c.2b203b73.2d597ceb@aol.com> References: <11c.2b203b73.2d597ceb@aol.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="--==--==---=--=----=--===-=--=--=====---===-=--="; protocol="application/pgp-signature"; micalg=pgp-sha1 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.7 required=5.0 tests=FORGED_MUA_EUDORA, INVALID_MSGID autolearn=no version=2.60 ----==--==---=--=----=--===-=--=--=====---===-=--= Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:16 PM 2/9/2004, Mpierce1@aol.com wrote: >Since the term is "Admission", I believe it only makes sense to use "CAC" >it to refer to the control that is placed on deciding whether or not to >admit a new call (i.e., packet flow), not on anything that is done later >to decide whether to preempt a call or terminate a packet flow. perhaps. As James noted, there are a variety of procedures that are called CAC: these are generally call counters in SIP Proxies or H.323 Gatekeepers, and MOSAIC defines something based on Bandwidth Broker research. These, as you say, these procedures look at the call when it is being negotiated and never look at it again. RSVP, as defined in RFC 2205, is continuous. It maintains a continuous knowledge of what sessions are up and what sessions are going away, reinstalls them if the routing path changes, and is quite capable of preempting a call if need be. This is discussed in some detail in http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01.txt which will be posted later on this week. The -00 version touches on it, but not in as great detail. To assert that a bandwidth-and-routing aware protocol such as RSVP is not "call admission control" does some violence to the English language, IMHO. If it is not admitting calls, I'm not sure what it is doing. Yes, in addition is performs preemption; to RSVP, those are different outcomes of the same process. I have a list of the relevant IETF standards at ftp://ftpeng.cisco.com/fred/mlpp/rsvp.html if you're interested, you might want to review how preemption works in RSVP ftp://ftp.rfc-editor.org/in-notes/rfc3181.txt ----==--==---=--=----=--===-=--=--=====---===-=--= Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP 7.0.1 iQA/AwUBQCg6424xHWxyLJtDEQKlHwCg7hKDosnjxIg1i3sSgVMY7//ERJoAn0jn LAr00EFwfL+jup7HNYroJKmA =50q5 -----END PGP MESSAGE----- ----==--==---=--=----=--===-=--=--=====---===-=--=-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Feb 10 11:52:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27055 for ; Tue, 10 Feb 2004 11:52:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb78-0005qp-Ik for ieprep-archive@odin.ietf.org; Tue, 10 Feb 2004 11:51:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AGpwSX022487 for ieprep-archive@odin.ietf.org; Tue, 10 Feb 2004 11:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb78-0005qb-EM for ieprep-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27046 for ; Tue, 10 Feb 2004 11:51:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb77-0004AV-00 for ieprep-web-archive@ietf.org; Tue, 10 Feb 2004 11:51:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqb6D-00043p-00 for ieprep-web-archive@ietf.org; Tue, 10 Feb 2004 11:51:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb5L-0003wu-00 for ieprep-web-archive@ietf.org; Tue, 10 Feb 2004 11:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb5G-0005kB-3J; Tue, 10 Feb 2004 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb5D-0005jp-Vu for ieprep@optimus.ietf.org; Tue, 10 Feb 2004 11:50:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27010 for ; Tue, 10 Feb 2004 11:49:57 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb5C-0003vO-00 for ieprep@ietf.org; Tue, 10 Feb 2004 11:49:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqb4G-0003nT-00 for ieprep@ietf.org; Tue, 10 Feb 2004 11:49:02 -0500 Received: from imo-r06.mx.aol.com ([152.163.225.102]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb3J-0003Zj-00 for ieprep@ietf.org; Tue, 10 Feb 2004 11:48:01 -0500 Received: from Mpierce1@aol.com by imo-r06.mx.aol.com (mail_out_v36_r4.12.) id c.29.50d40cf0 (3940); Tue, 10 Feb 2004 11:47:16 -0500 (EST) Message-ID: <29.50d40cf0.2d5a6514@aol.com> Date: Tue, 10 Feb 2004 11:47:16 EST To: fred@cisco.com CC: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_29.50d40cf0.2d5a6514_boundary" X-Mailer: 6.0 for Windows XP sub 51 Subject: [Ieprep] Re: CAC definition Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_29.50d40cf0.2d5a6514_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/9/2004 8:59:41 PM Eastern Standard Time, fred@cisco.com writes: > As James noted, there are a variety of procedures that are called CAC: > these are generally call counters in SIP Proxies or H.323 Gatekeepers, and > MOSAIC defines something based on Bandwidth Broker research. These, as you > say, these procedures look at the call when it is being negotiated and > never look at it again. > > RSVP, as defined in RFC 2205, is continuous. It maintains a continuous > knowledge of what sessions are up and what sessions are going away, > reinstalls them if the routing path changes, and is quite capable of > preempting a call if need be. This is discussed in some detail in > > http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01.txt > > which will be posted later on this week. The -00 version touches on it, but > not in as great detail. > > To assert that a bandwidth-and-routing aware protocol such as RSVP is not > "call admission control" does some violence to the English language, IMHO. > If it is not admitting calls, I'm not sure what it is doing. Yes, in > addition is performs preemption; to RSVP, those are different outcomes of > the same process. > To all, The issue that Janet raised and that I responded to had nothing to do with the functionality of RSVP. I am well aware that RSVP includes the notion of preempting existing flows, and I think we can make good use of that. I did not assert that RSVP is not "call admisison control". I said nothing about RSVP. The issue raised by Janet is simply the definition of the term "Call Admission Control" or "CAC" and whether or not the term includes "preemption". Since you're mentioned RSVP, looking through existing RSVP RFCs, there are references to "Admission Control" and RFC3181 mentions "Capacity Admission Control (CAC)". (Of course, RSVP does not refer to "Call Admission Control".) RFC 2205 defines: o Traffic control The entire set of machinery in the node that supplies requested QoS to data streams. Traffic control includes packet classifier, packet scheduler, and admission control functions. o Admission control A traffic control function that decides whether the packet scheduler in the node can supply the requested QoS while continuing to provide the QoS requested by previously-admitted requests. See also "policy control" and "traffic control". I would claim that the above definition of "Admission Control" does not include the function of preemption, although RSVP does include preemption. I would suggest that as we talk more about preemption (of calls or packet flows), we need better definitions. It seems that "Traffic Control" should be extended to include a fourth component: preemption of packet flows. The definition of "Admisison Control" would remain as it is above in RFC 2205. As noted, CAC may cause preemption to occur, but I think it's better to define them as separate functions (and terms). Mike Pierce --part1_29.50d40cf0.2d5a6514_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/9/2004 8:59:41 PM Eastern Standard Time, fred@cisco.com writes:


As James noted, there are a= variety of procedures that are called CAC:=20
these are generally call counters in SIP Proxies or H.323 Gatekeepers, a= nd=20
MOSAIC defines something based on Bandwidth Broker research. These, as y= ou=20
say, these procedures look at the call when it is being negotiated and=20
never look at it again.

RSVP, as defined in RFC 2205, is continuous. It maintains a continuous=20
knowledge of what sessions are up and what sessions are going away,=20
reinstalls them if the routing path changes, and is quite capable of=20
preempting a call if need be. This is discussed in some detail in
    http://www.ietf.org/internet-drafts/draft-baker= -tsvwg-mlpp-that-works-01.txt

which will be posted later on this week. The -00 version touches on it,=20= but=20
not in as great detail.

To assert that a bandwidth-and-routing aware protocol such as RSVP is no= t=20
"call admission control" does some violence to the English language, IMH= O.=20
If it is not admitting calls, I'm not sure what it is doing. Yes, in=20
addition is performs preemption; to RSVP, those are different outcomes o= f=20
the same process.




To all,

The issue that Janet raised and that I responded to had nothing to do wi= th the functionality of RSVP. I am well aware that RSVP includes the notion=20= of preempting existing flows, and I think we can make good use of that. I di= d not assert that RSVP is not "call admisison control". I said nothing about= RSVP.

The issue raised by Janet is simply the definition of the term "Call Adm= ission Control" or "CAC" and whether or not the term includes "preemption".

Since you're mentioned RSVP, looking through existing RSVP RFCs, there a= re references to "Admission Control" and RFC3181 mentions "Capacity Admissio= n Control (CAC)". (Of course, RSVP does not refer to "Call Admission Control= ".)

RFC 2205 defines:

  o    Traffic control

       The entire set of machinery i= n the node that supplies requested
       QoS to data streams.  Tr= affic control includes packet
       classifier, packet scheduler,= and admission control functions.

  o    Admission control

       A traffic control function th= at decides whether the packet
       scheduler in the node can sup= ply the requested QoS while
       continuing to provide the QoS= requested by previously-admitted
       requests.  See also "pol= icy control" and "traffic control".

I would claim that the above definition of "Admission Control" does not=20= include the function of preemption, although RSVP does include preemption.

I would suggest that as we talk more about preemption (of calls or packe= t flows), we need better definitions. It seems that "Traffic Control" should= be extended to include a fourth component: preemption of packet flows. The=20= definition of "Admisison Control" would remain as it is above in RFC 2205. A= s noted, CAC may cause preemption to occur, but I think it's better to defin= e them as separate functions (and terms).

Mike Pierce
--part1_29.50d40cf0.2d5a6514_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Feb 11 11:29:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07930 for ; Wed, 11 Feb 2004 11:29:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxE4-00050I-Kw for ieprep-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGSaYd019233 for ieprep-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxE4-000508-Fi for ieprep-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:28:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07785 for ; Wed, 11 Feb 2004 11:28:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxE3-0006Zq-00 for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:28:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxBr-00067s-00 for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:26:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqxAa-0005vs-02 for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:25:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqx4r-0002dm-PB for ieprep-web-archive@ietf.org; Wed, 11 Feb 2004 11:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx4m-0004Ce-GU; Wed, 11 Feb 2004 11:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx41-00049x-8X for ieprep@optimus.ietf.org; Wed, 11 Feb 2004 11:18:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07158 for ; Wed, 11 Feb 2004 11:18:11 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx40-00054z-00 for ieprep@ietf.org; Wed, 11 Feb 2004 11:18:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqx2p-0004vI-00 for ieprep@ietf.org; Wed, 11 Feb 2004 11:17:00 -0500 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx2P-0004nL-00 for ieprep@ietf.org; Wed, 11 Feb 2004 11:16:33 -0500 Received: from Mpierce1@aol.com by imo-m23.mx.aol.com (mail_out_v36_r4.12.) id t.2b.50aab1b2 (4196); Wed, 11 Feb 2004 11:15:58 -0500 (EST) Message-ID: <2b.50aab1b2.2d5baf3e@aol.com> Date: Wed, 11 Feb 2004 11:15:58 EST Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: jgunn6@csc.com, ieprep@ietf.org CC: jmpolk@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_2b.50aab1b2.2d5baf3e_boundary" X-Mailer: 6.0 for Windows XP sub 51 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --part1_2b.50aab1b2.2d5baf3e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/10/2004 11:56:45 AM Eastern Standard Time, jgunn6@csc.com writes: > Yes, I think it would be worthwhile to have a "definition" of CAC as a > stand-alone posting on the list. But I don't think we need to have a > "discussion" about it. > Well, it's hard to have a "definition" without some discussion, since it should be something that is agreed. I think our "discussion" and the need is for a definition of "Call Admission Control", which I had used in my draft on preferential treatement examples, with the belief that there was a uniform understanding of what it meant. I believe it is an old term from the telephony environment, and what we are talking about here is "telephony". The application layer functions (call setup) haven't changed. We should clearly separate the transport layer (e.g., RSVP, packet flows) from the application layer (call setup, preemption, release) with our terms. Unfortunately, RFC3181 uses the term "Capacity Admission Control (CAC)" in referring to packet transport. Fred and James' comments related to RSVP, but RSVP never talked about "calls". As RSVP defines "Admission Control", I don't see the term including "preemption", although RSVP clearly does. In a message dated 2/10/2004 3:28:34 PM Eastern Standard Time, jmpolk@cisco.com writes: > define CAC in IP as: > > - set-up of the call at the endpoints (SIP does this), and > > - the ongoing monitoring process to keep the flow "functional" > > this second bullet deals with packet admission, per packet to meet an > agreed upon bandwidth guarantee promised to all other nodes for that flow. > Yes, I think this is fine, except that the first bullet is the application layer (call) and the second is the packet transport layer. So "CAC" would then be "Call/Capacity Admission Control". CAC affects the initial setup of the call as well as the continuation of the call (packet flow). That's fine. I just think that the specific function of preemption of one call (packet flow) by another should be called something else for sake of clarity in descriptions, etc. Mike Pierce --part1_2b.50aab1b2.2d5baf3e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 2/10/2004 11:56:45 AM Eastern Standard Time, jgunn6@csc.com writes:


Yes, I think it would be wo= rthwhile to have a "definition" of CAC as a
stand-alone posting on the list.   But I don't think we need t= o have a
"discussion" about it.


Well, it's hard to have a "definition" without some discussion, since it= should be something that is agreed.

I think our "discussion" and the need is for a definition of "Call Admis= sion Control", which I had used in my draft on preferential treatement examp= les, with the belief that there was a uniform understanding of what it meant= . I believe it is an old term from the telephony environment, and what we ar= e talking about here is "telephony". The application layer functions (call s= etup) haven't changed.

We should clearly separate the transport layer (e.g., RSVP, packet flows= ) from the application layer (call setup, preemption, release) with our term= s. Unfortunately, RFC3181 uses the term "Capacity Admission Control (CAC)" i= n referring to packet transport.

Fred and James' comments related to RSVP, but RSVP never talked about "c= alls". As RSVP defines "Admission Control", I don't see the term
including "preemption", although RSVP clearly does.

In a message dated 2/10/2004 3:28:34 PM Eastern Standard Time, jmpolk@ci= sco.com writes:


define CAC in IP as:

        - set-up of the call at= the endpoints (SIP does this), and

        - the ongoing monitorin= g process to keep the flow "functional"

this second bullet deals with packet admission, per packet to meet an=20
agreed upon bandwidth guarantee promised to all other nodes for that flo= w.


Yes, I think this is fine, except that the first bullet is the applicati= on layer (call) and the second is the packet transport layer. So "CAC" would= then be "Call/Capacity Admission Control".

CAC affects the initial setup of the call as well as the continuation of= the call (packet flow). That's fine. I just think that the specific functio= n of preemption of one call (packet flow) by another should be called someth= ing else for sake of clarity in descriptions, etc.

Mike Pierce
--part1_2b.50aab1b2.2d5baf3e_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Feb 13 08:19:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08249 for ; Fri, 13 Feb 2004 08:19:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdDd-0004Cw-Mo for ieprep-archive@odin.ietf.org; Fri, 13 Feb 2004 08:18:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDIvMQ016168 for ieprep-archive@odin.ietf.org; Fri, 13 Feb 2004 08:18:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdDd-0004Ch-Ir for ieprep-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:18:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08246 for ; Fri, 13 Feb 2004 08:18:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdDc-0007AR-00 for ieprep-web-archive@ietf.org; Fri, 13 Feb 2004 08:18:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdCi-00076Y-00 for ieprep-web-archive@ietf.org; Fri, 13 Feb 2004 08:18:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArdBo-00072p-00 for ieprep-web-archive@ietf.org; Fri, 13 Feb 2004 08:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdBk-00043n-S3; Fri, 13 Feb 2004 08:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArdAv-00042T-BL for ieprep@optimus.ietf.org; Fri, 13 Feb 2004 08:16:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08188 for ; Fri, 13 Feb 2004 08:16:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArdAu-0006xp-00 for ieprep@ietf.org; Fri, 13 Feb 2004 08:16:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdA4-0006sz-00 for ieprep@ietf.org; Fri, 13 Feb 2004 08:15:16 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1Ard9b-0006mY-00 for ieprep@ietf.org; Fri, 13 Feb 2004 08:14:47 -0500 Received: (qmail 8834 invoked from network); 13 Feb 2004 13:14:11 -0000 Received: from tow18dhcp83.towson01.md.comcast.net (HELO albers) (68.33.18.83) by phobos.simply.net with SMTP; 13 Feb 2004 13:14:11 -0000 From: "Ken Carlberg" To: Date: Fri, 13 Feb 2004 08:13:58 -0500 Message-ID: <001901c3f233$3e6bc550$7301a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Ieprep] draft-ietf-ieprep-framework-08.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 09 Feb 2004 16:21:19 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-08.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This latest version includes changes based on private comments from Ran Atkinson (primarily in the area of security), and Yakov Shafranovich. My understanding is that ieprep chairs will soon announce a working group last call on the draft with the hope of putting this puppy to rest. Cheers, -ken ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Framework for Supporting IEPS in IP Telephony Author(s) : K. Carlberg, I. Brown, C. Beard Filename : Pages : 27 Date : 2004-2-9 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 PSTN, contribute to a constrained solution space. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep