Re: [Ieprep] re-charter
Richard F Kaczmarek <rkaczmarek@csc.com> Wed, 13 July 2005 21:21 UTC
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15051 for <ieprep-archive@ietf.org>; Wed, 13 Jul 2005 17:21:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsp8O-0002xO-16 for ieprep-archive@ietf.org; Wed, 13 Jul 2005 17:51:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoeL-0007LC-P0; Wed, 13 Jul 2005 17:20:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsoeK-0007L2-5j for ieprep@megatron.ietf.org; Wed, 13 Jul 2005 17:20:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14925 for <ieprep@ietf.org>; Wed, 13 Jul 2005 17:20:09 -0400 (EDT)
Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsp6n-0002tE-Ux for ieprep@ietf.org; Wed, 13 Jul 2005 17:49:38 -0400
Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j6DLK8S3012985 for <ieprep@ietf.org>; Wed, 13 Jul 2005 17:20:08 -0400 (EDT)
In-Reply-To: <e37f9f9146639f675fc1321110a55d4e@cisco.com>
Subject: Re: [Ieprep] re-charter
To: ieprep@ietf.org
X-Mailer: Lotus Notes 652HF83 November 04, 2004
Message-ID: <OFDD23781C.4DCC3A71-ON8525703D.0074F6E3-8525703D.00752F77@csc.com>
From: Richard F Kaczmarek <rkaczmarek@csc.com>
Date: Wed, 13 Jul 2005 17:19:58 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/13/2005 05:19:56 PM
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
I think rechartering the ieprep wg is a good idea. In rechartering, I would like the group to consider the following. Based upon testing of IP/GSTN interoperability under conditions of congestion, there are a number of IP network requirements and mechanisms needed to ensure a GETS-like service works across a congested IP network. For example, fidelity of DTMF tones for PIN authentication is an issue at high utilizations. The requirements associated with emergency communications (e.g., a GETS-like service) fall into four broad categories: 1. Signaling. Signaling requirements can be divided into two types: (a) Signaling a request for emergency communications to an authentication / authorization entity for approval, and (b) Signaling an authorized / authenicated request from the source to destination. Within the IP network, SIP was found to be resilient in the face of congestion, so no distinction may be required between the two signaling types. However, the delays associated with SIP under heavy congestion impacted its successful interoperation with SS7 signaling in the PSTN. 2. Resource Provisioning. Providing the necessary resources for authenticated emergency communications. With G711 codecs, VoIP was found to be intelligible up to an offered load of 150% of the bottleneck link capacity. Thus a Call Admission Control mechanism that allows for "oversubscription" for emergency communications may be appropriate (e.g., CAC set to 80% of link capacity, with emergency communications allowed an additional 10% of link capacity). If oversubscription is not acceptable, guaranteed bandwith is also possible. With the Cisco routers we were using, we could allocate bandwidth in the EF queue for emergency communications and for normal traffic. In this latter case, some sort of marker (e.g., DSCP) may be needed for emergency traffic, but a unique per hop behavior may not be needed. 3. Security. Issues include authentication within the IP network and across network boundaries. In particular, if a GETS-like service is authenticated in the GSTN through DTMF tones transmitted across the IP network (as is currently done), there are issues of PIN intercept and PIN transmission errors associated with delayed and dropped packets at high utilizations. RFC 2833 and the KeyPad Markup Language (KPML) may provide solutions. A second issue concerns inter-domain trust to allow "prioritization" of emergency communications end-to-end, both between IP domains, and between IP and GSTN domains. 4. Network engineering and provisioning "best practices." For example, for IP/GSTN interoperation, the number of SIP retries should be set to "x." While the documents already produced by the ieprep wg address, at varying levels, many of these areas, there are additional "GETS-like" service-unique requirements that are not documented. It is likely that a majority of these additional requirements can be satisfied by using the mechanisms (being) developed by the other working groups. As such, I believe the charter should allow for the creation of additional "to be specified" I-D documents by the working group. If this is allowed and the working group is rechartered, then I am willing to work in the group to define and create the appropriate documents discussing the "GETS-like" requirements, mechanisms and best practices. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] re-charter? Ken Carlberg
- Re: [Ieprep] re-charter? Fred Baker
- Re: [Ieprep] re-charter? Rex Buddenberg
- RE: [Ieprep] re-charter? Ken Carlberg
- Re: [Ieprep] re-charter Richard F Kaczmarek