Ieprep
Internet Draft H. Folts
Document: draft-ietf-ieprep-requirements-01.txt NCS
Expires: April 2003 C. Beard
UMKC
K. Carlberg
UCL
October 2002
Requirements for Emergency Telecommunication
Capabilities in the Internet
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 outlines user requirements for IP-based networks to
enable and support an authorized emergency telecommunications service
(ETS)for use by authorities to organize and coordinate emergency and
disaster relief operations. It provides a basis from which ETS can
be negotiated to provide user-acceptable communications. The
requirements in this document relate to user expectation and are
general, functional, and intended to provide wide latitude in
implementation options. This document also provides in-depth
background on the state of emergency telecommunication capabilities
as they exist today and the motivation for supporting these in IP
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
networks. Specific system requirements involving end-to-end and
network issues are presented in [2].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3].
Table of Contents
1. Introduction...................................................2
1.1 Current PSTN Capabilities..................................4
1.2 Network Technology Transition..............................5
1.3 Purpose and Scope of this Document.........................6
2. User Requirements..............................................6
3. Emergency Service Applications.................................7
3.1 Inelastic applications.....................................8
3.2 Elastic applications.......................................8
4. Policy Issues..................................................8
5. Security Considerations.......................................9
6. References....................................................9
7. Acknowledgments...............................................9
8. Author's Addresses............................................9
9. Copyright....................................................10
1. Introduction
Natural and man-made disasters can occur anywhere, anytime. These
include, for example, earthquakes, floods, airplane crashes, and
terrorist attacks. While some advance planning is possible for
expected disaster events, most disasters happen unexpectedly.
Readily available telecommunication capabilities are essential for
emergency and disaster relief operations to quickly start saving
lives and restoring the community infrastructure. A number of
telecommunication facilities can be involved in disaster operations.
These include local mobile radio, dedicated satellite systems,
transportable capabilities, and the public telecommunications
infrastructure. Some of these facilities need to be deployed to the
disaster site and very likely may not be immediately available. The
public telecommunication services, however, are generally at hand
except in the most remote areas. The publicly available capabilities
include the traditional telephone network and the Internet, which can
both be accessed via wire line, wireless, and various broadband
facilities. Disaster recovery operations can significantly benefit
from a variety of modes for interchange of critical information to
organize and coordinate the emergency activities. Emergency voice
Folts Expires - April 2003 [Page 2]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
communications are supported today by a preferential service through
public telephone networks in some countries. The Definition of the
International Preference Scheme (ieps) for circuit-switched telephone
networks is provided in ITU-T Recommendation E.106 [4].
Now, however, an evolution is taking place in traditional public
telecommunication networks toward integrating circuit-switched and
packet-based technologies. This promises to provide a rich menu of
fully integrated capabilities for handling voice, message, data, and
video traffic to greatly enhance disaster recovery operations. These
capabilities are being considered in the development of a
comprehensive emergency telecommunication service (ETS) to be
deployed in the new generation of packet-based public networks. ETS
is now the globally recognized term that identifies the new
generation of emergency communications capabilities in public
telecommunication networks for authorized users to use during
emergency and disaster relief operations.
The bulk of conventional telephony is accomplished over relatively
narrow band wire line or wireless facilities of the public switched
telephone network (PSTN). These constrained links are also used for
various other applications like instant messaging, email, and
telemedicine telemetry. In addition, wideband capabilities for video
broadcast, conferencing, and telemedicine will continue to flourish
and greatly enhance emergency recovery operations.
During serious disaster events, public networking facilities can
experience severe stress due to damaged infrastructure and heavy
traffic loads. As bandwidth gets severely constrained, it becomes
difficult to establish and maintain effective communication sessions.
It is essential that disaster recovery operations be able to readily
communicate to organize and coordinate essential activities.
Authorized emergency communication sessions need to have ready access
to available network resources and be given an enhanced probability
of successful completion of these critical communications to help
save lives and restore community infrastructure.
Only people authorized by the appropriate authority are permitted to
establish enhanced emergency communication sessions through public
networking facilities for facilitating immediate disaster recovery
operations. We use the term ôenhancedö to refer to additional
measures taken to achieve and sustain communications by selected
authorized personnel. Those typically authorized are local police,
fire, and medical personnel as well as designated government
officials from local, regional, and national levels who are
responsible for various aspects of disaster recovery operations.
All emergency communication sessions should be processed as normal
traffic along with all non-emergency traffic when sufficient network
Folts Expires - April 2003 [Page 3]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
bandwidth and resources are available. ONLY when networks reach
traffic saturation is there a need for giving emergency communication
sessions a higher probability of completion over non-emergency
communications. While this occurrence may never happen in the
typical Internet-based environment, capabilities for accommodating
emergency traffic need to be established in preparation for a serious
catastrophe. These provisions should be in place before a potential
disaster, even for highly over-provisioned networks. It is better to
be prepared ahead of time and not wait for the worst to happen first.
The ETS capabilities for handling authorized emergency traffic should
be accomplished using existing applications, Internet features, and
standards whenever possible. Establishment of new and different
standards would be both costly and unlikely to ever be implemented.
The desired approach is to adopt existing standards and where needed
adapt new standards with any necessary adjustments needed to support
preferential treatment of emergency traffic during severe periods of
congestion.
This document outlines user requirements that need to be met in
public and private IP-based networks to enable communications for
ETS. These requirements would include support for existing systems
that address National Security/Emergency Preparedness (NS/EP)
requirements and capabilities. Recovery activities can involve
person-to-person communications, group coordination, disaster
assessment application execution, remote information retrieval,
continuity of government, etc.
1.1 Current PSTN Capabilities
As a starting point, the model to consider for emergency
communication services is the existing service capability in the
United States PSTN, the Government Emergency Telecommunications
Service (GETS). Some other countries have similar services. GETS is
based upon the requirements presented in ITU-T Recommendations E.106
[4].
The purpose of GETS is to increase the probability of completion of a
telephone call for authorized operations personnel in times of
emergencies. It does not guarantee that service will be available,
but it does implement a set of functions that increase the likelihood
of finding an available circuit to complete a call in the PSTN.
The key aspects of GETS are as follows:
o Personnel gain access to GETS by calling a specified
telephone number and presenting a credit-card type of
authentication.
Folts Expires - April 2003 [Page 4]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
o Once being authenticated, the call is completed on a
preferential high probability of call completion basis. If
calls are initially blocked, they can be queued and
switched to alternate carriers.
o If fundamental telephone services are compromised, services
contracted under GETS are restored first. This is under
the provisions of TSP (Telecommunication Service Priority
[5]), which is independent of GETS.
These features enhance the capability of NS/EP calls to be completed
with a high probability in congested networks. GETS will not preempt
public telephone calls, nor are there multiple levels of precedence
within GETS.
1.2 Network Technology Transition
The public telecommunication infrastructure is in the process of
evolving from the traditional circuit-switched technology to
Internet-based packet technology. In developing new ETS capabilities
for the future, consideration needs to be given during the period of
transitions, which is often referred to as "convergence".
During convergence, IP packet-based technology is being integrated
into the public telecommunications infrastructure. It is important
that the existing basic capability for preferential handling of
emergency traffic in current telephone networks is preserved during
the transition period. There are four basic configurations that come
into play during convergence. These include:
o PSTN-to-PSTN via IP backbone
o IP telephony to PSTN via gateway
o PSTN to IP Telephony via gateway
o Pure IP telephony, with no link to the PSTN
These are described in ETSI Technical Report [6].
As the IP packet-technology becomes the dominant part of the public
telecommunications infrastructure, the prospect of many enhanced
capabilities and services comes forth. These could include expanded
features in IP-telephony to support an enhanced probability of call
completion and additional call processing features. The provision of
additional communication services such as Email, instant messaging,
telemedicine, white board, and telemetry can provide emergency
recovery operations with a rich menu of capabilities. Some time in
the future, it is envisioned that the multimedia services will become
the dominate mode for emergency communications.
Folts Expires - April 2003 [Page 5]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
1.3 Purpose and Scope of this Document
The purpose of this document is to articulate user requirements
concerning support for emergency related communications. It provides
a set of requirements that need to be met by service(s) to acceptably
support emergency communications. The requirements given here are
quite general and it is intended that wide latitude be available to
service providers and/or vendors to implement emergency services as
they consider appropriate.
Section 2 provides a summary of the user requirements that identify
high-level service capabilities that should be provided. Section 3
provides a list of possible emergency communication applications that
could be used by emergency personnel. And finally, Section 4
identifies policy issues that need to be considered in the deployment
and operation of an ETS.
System requirements that focus on how user requirements (taken as a
whole) are to be satisfied with respect to the network & gateways
(i.e., network layer to application layer) are specified in other
documents. [2] specifies a set of general system requirements and
[7] articulates a set of more specific set of system requirements for
IP telephony.
2. User Requirements
The basic user requirements that need to be considered in providing
emergency telecommunication capabilities to support recovery
operations from serious disaster situations are summarized as
follows. Note that we assume the presence of Service Level
Agreements in cases where user requirements cover expectations of
service providers:
o Users should be able to use public telecommunication
resources for supporting emergency communications to help
organize and coordinate immediate disaster recovery
operations.
o Users that access emergency telecommunications service must
be authenticated. This should be accomplished in a timely
manner.
o When networks reach traffic saturation emergency
communication sessions should be provided with with a
higher probability of completion over non-emergency
communications. We assume the presence of a service level
agreement to accomplish this latter case. (Note: Sessions
identified as emergency communication could be processed as
Folts Expires - April 2003 [Page 6]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
normal traffic along with all non-emergency traffic when
sufficient network bandwidth and resources are available.)
o Once an emergency communications session is established,
the user should be able to complete the session without
being interrupted or having the quality of the
communications be degraded excessively.
o There must exist a mapping association between labels
defined by various standards bodies. This mapping will
help facilitate inter-working of services in cases where
gateways and networks support emergency telecommunications
services.
o Emergency traffic should be able to transit multiple
service providers. The existence of service level
agreements determines the extent by which this can be
accomplished.
o Networks should be able to support a variety of user
applications including telephony, video, database access,
messaging, telemetry, and web browsing to support emergency
operations.
o Authorized emergency communications should be protected
from intrusion or interference, such as, spoofing, change
of content, and denial of service. If the protection
cannot be accomplished, then users must be able to detect
this failure.
o Users should have the option protecting certain sensitive
traffic from eavesdropping and the source/destination of
some traffic.
o Users should have the option of requesting degraded quality
of service when normal or expected QoS cannot be achieved.
It may not be possible to fulfill all of these requirements
immediately and within existing standards, Internet features, and
applications. However, provision of the best probability of
successful completion of critical emergency communications will
significantly enhance the ability of disaster recovery operations to
save lives and restore community infrastructure.
3. Emergency Service Applications
A variety of IP based applications are expected to be used to support
disaster recovery and response operations in the future as future
Folts Expires - April 2003 [Page 7]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
services become available to the user. They include not only the
basic IP telephony services but expand to include a selection of
multimedia services to enhance the ability for saving lives and
restoring community infrastructure impacted by serious disaster
events. This implies that various upper layer characteristics will
be operating over IP.
The following list is not exhaustive, but is illustrative of the
types of capabilities that could prove to be beneficial:
3.1 Inelastic applications
o Real time interactive voice (telephony)
o Real time interactive video conference
o Real time interactive video telemedicine
o Real time interactive white board
o Streaming audio and video
o Telemedicine telemetry for vital sign monitoring
o Virtual reality imaging for disaster scene surveillance
3.2 Elastic applications
o Interactive victim database (e.g. I Am Alive - IAA)
o Interactive database services for crisis management
o Interactive Web access
o Electronic Mail
o Instant messaging and presence
o File transfer
The application of immediate interest to current emergency management
organizations is tends to center on IP telephony. In the future,
however, it is anticipated that voice communications will be
overshadowed by a number of emerging multimedia modes of
communication that will significantly benefit emergency recovery
operations.
4. Policy Issues
In the development and deployment of ETS capabilities, a number of
policy decisions are required that will define how the services are
to be applied, configured, and used. The user policies will be
conveyed to the service provider in the service level agreement (SLA)
established for the provision of the ETS capabilities. Service
providers will have the freedom to determine its own internal
policies in how the service is actually implemented in fulfillment of
the SLA.
Folts Expires - April 2003 [Page 8]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
5. Security Considerations
Discussion on security is addressed in Section 2.
6. References
1 Bradner, S., Internet Standards Process û Revision 3, BCP 9, RFC
2026, October 1996.
2 Carlberg, K., Atkinson, R., "General Requirements for Emergency
Telecommunications Service", Internet Draft, Work in Progress,
September, 2002.
3 Bradner, S., ôKey Words for Use in RFCs to Indicate Requirement
Levelsö, BCP 14, RFC 2119, March 1997.
4 ITU-T, "Description of an International Emergency Preference
Scheme", ITU-T Recommendation E.106, March 2000.
5 ôInformation Interchange Representation of National Security
Emergency Preparedness û Telecommunications Service Priorityö,
American National Standard T1.211-1989 (R1999).
6 ETSI TR 101 300, V2.1.1, "Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON); Description of Technical
Issues", October 1999
7 Carlberg, K., Atkinson, R., "IP Telephony Requirements for
Emergency Telecommunications Service", Internet Draft, Work in
Progress, September, 2002
7. Acknowledgments
Many thanks to Fred Baker, Scott Bradner, Ian Brown, and Ran Atkinson
for their comments on this draft.
8. Author's Addresses
Hal Folts
National Communications System
701 South Courthouse Road
Arlington, VA 22204-2198 USA
Phone: +1 703 607-6186
Email: foltsh@ncs.gov
Folts Expires - April 2003 [Page 9]
Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002
Cory Beard
School of Interdisciplinary Computing and Engineering
University of Missouri-Kansas City
5100 Rockhill Road
Kansas City, MO 64110
Phone: 1-816-235-1550
Email: beardc@umkc.edu
Ken Carlberg
University College London
Department of Computer Science
London, WC1E 6BT
United Kingdom
k.carlberg@cs.ucl.ac.uk
9. Copyright
"Copyright (C) The Internet Society (date). 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. 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 PURPOSE.
Folts Expires - April 2003 [Page 10]