Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT UCL
April 28, 2003 Ran Atkinson
Extreme Networks
IP Telephony Requirements for
Emergency Telecommunication Service
<draft-ietf-ieprep-ets-telephony-04.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
This document presents a list of requirements in support of Emergency
Telecommunications Service (ETS) within the context of IP telephony.
It is an extension to the general requirements presented in [2].
Solutions to these requirements are not presented in this document.
1. Introduction
Effective telecommunications capabilities can be imperative to
facilitate immediate recovery operations for serious disaster events,
such as, hurricanes, floods, earthquakes, and terrorist attacks.
Disasters can happen any time, any place, unexpectedly. Quick
response for recovery operations requires immediate access to any
public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet
access via online terminals, IP telephones, and wireless Personal
Carlberg & Atkinson Expires October 28, 2003 [Page 1]
^L
Internet Draft ETS Telephony Requirements April 28, 2003
Digital Assistants (PDAs). The commercial telecommunications
infrastructure is rapidly evolving to Internet-based technology.
Therefore, the Internet community needs to consider how it can best
support emergency management and recovery operations.
1.1 Problem
Standards have been developed by other standards bodies concerning
emergency communications. As discussed in [2], some of these
standards, such as T1.631 [4], define specific indicators or labels
for emergency communications in Signaling System 7 (SS7) networks.
Certain requirements must be defined in order to achieve peering
across hybrid networks (networks that communicate between IP and
other types of networks such as that realized by the Public Switched
Telephone Network) in order to achieve an interworking of services.
2. Scope
[2] has defined a set of general system requirements to support
Emergency Telecommunications Service (ETS). This document defines an
additional set of system requirements to achieve support for ETS
within the specific context of IP telephony (note that this document
views IP telephony within the context of an end-to-end application
layer service). Solutions to requirements are not defined. The
document does not specify protocol enhancements or specifications.
Note that [3], Requirements for Resource Priority Mechanisms for the
Session Initiation Protocol (SIP), is an RFC that shares some overlap
with this document. However, [3] only applies to SIP and is not
meant to be applied to a more general perspective of IP telephony as
it relates to ETS.
2.1 Out of Scope
An item that is not in scope of this document is mandating acceptance
and support of the requirements presented in this document. The IETF
does not mandate requirements or capabilities to independent networks
that comprise the Internet. As an example, Internet Service
Providers (ISP) may choose not to operate any telephony-related
gateways or services. The IETF cannot and does not mandate that an
ISP deploy either telephony-related gateways or telephony-related
services. There is an expectation that business contracts, for
example Service Level Agreements (SLA), will be used to satisfy those
following requirements that apply to service providers. Absence of
an SLA implies best effort service is provided.
It is assumed that some ISPs will choose to offer ETS services and
that other carriers will choose not to offer ETS services. These
Carlberg & Atkinson Expires October 28, 2003 [Page 2]
^L
Internet Draft ETS Telephony Requirements April 28, 2003
requirements do not apply to ISPs that have chosen not to offer ETS
services.
3. IP Telephony Requirements
The requirements in this section relate only to Telephony Signaling
as used in Internet-based telephony services. They are an extension
to the general requirements specified in [2]. The following
requirements explicitly do not relate to IP-layer mechanisms, such as
Differentiated Services or Integrated Services.
1) Telephony signaling applications used with Internet-based
telephony MUST be able to carry labels.
2) The ability to carry labels MUST be extensible to support
various types and numbers of labels. A single binary value will
not be sufficient given the various labeling standards in existence
today.
3) Telephony signaling labels SHOULD have a mapping with the
various emergency related labels/markings used in other telephony
based networks, such as the Public Switched Telephone Network
(PSTN). This ensures that a telephone call placed over a hybrid
infrastructure (traditional PSTN over some portion(s) of the path,
Internet telephony over some other portion(s) of the path) can
carry the labels end-to-end with appropriate translation at
PSTN/Internet boundaries. Absence of a mapping means that the
signaling reverts to a default service (presumably one attributed
to the general public).
4) Application layer IP telephony capabilities MUST NOT preclude
the ability to do application layer accounting.
5) With respect to application layer signaling, application layer
mechanisms specifically targeted to recognize ETS type labels MUST
be ABLE to support "best available" service (this will probably
be realized as better than best effort). This support SHOULD
focus on probability of forwarding packets used for call
completion. Probability MAY reach 100% depending on the local
policy associated with the label. Local policy MUST also be used
to determine IF better than best effort is to be applied to a
specific label (or related set of labels).
The above paragraph MUST be taken in its entirety. The ability to
support best available service does not mean that the application
layer mechanism is expected to be activated. Further, we do not
define the means by which best available service is or should be
realized. Application layer mechanisms that do not recognize ETS
Carlberg & Atkinson Expires October 28, 2003 [Page 3]
^L
Internet Draft ETS Telephony Requirements April 28, 2003
type labels are not subject to this requirement.
4. Issues
This section presents issues that arise in considering solutions for
the telephony requirements that have been defined for ETS. This
section does not specify solutions nor is it to be confused with
requirements. Subsequent documents that articulate a more specific
set of requirements for a particular service may make a statement
about the following issues.
1) Alternate paths
Experience with The Government Emergency Telecommunications
Service (GETS) over the PSTN has shown the utility of
alternate paths to a destination to help facilitate
emergency-related communications. From the perspective of the
Internet, this utility may be difficult to achieve and have a
more limited benefit. Unlike the PSTN, which creates a fixed
path during call setup phase, the Internet uses dynamic routing
for IP packets. This dynamic routing capability automatically
causes IP packets to travel the best current path. The Internet
network infrastructure does not have the concept of a "call" or
the concept of "call setup", though IP telephony applications
might have application layer awareness of calls or the call
setup concept.
5. Security
Only authorized users or operators SHOULD be able to create non-
ordinary Labels (i.e., labels that may alter the default best effort
service. Labels SHOULD be associated with mechanisms to provide
strong end-to-end integrity during their transmission through the
telephony systems. Finally, in cases where labels are expected to be
acted upon by operators, these operators SHOULD have the capability
of authenticating the label on a received message or transmission in
order to prevent theft of service and reduce risk of denial of
service (e.g. by unauthorized users consuming any limited resources).
Security is also discussed in the general requirements of [2], which
applies to section 3 above.
6. References
Carlberg & Atkinson Expires October 28, 2003 [Page 4]
^L
Internet Draft ETS Telephony Requirements April 28, 2003
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Carlberg, K., Atkinson, R., "General System Requirements for
Emergency Telecommunications Service", Internet Draft,
Work In Progress, September, 2002
3 Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, February,
2003.
4 ANSI, "Signaling System No. 7(SS7): High Probability of
Completion (HPC) Network Capability", ANSI T1.631, 1993.
7. Author's Addresses
Ken Carlberg Ran Atkinson
University College London Extreme Networks
Department of Computer Science 3585 Monroe Street
Gower Street Santa Clara, CA
London, WC1E 6BT 95051 USA
United Kingdom
k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Carlberg & Atkinson Expires October 28, 2003 [Page 5]
^L
Internet Draft ETS Telephony Requirements April 28, 2003
This document and the information contained herein is provided as an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.
Carlberg & Atkinson Expires October 28, 2003 [Page 6]