draft-ietf-ieprep-requirements-00.txt   draft-ietf-ieprep-requirements-01.txt 
Internet Engineering Task Force Hal Folts Ieprep
INTERNET DRAFT National Communications System Internet Draft H. Folts
Expires: December December 2002 Cory Beard Document: draft-ietf-ieprep-requirements-01.txt NCS
Univ. of Missouri-Kansas City Expires: April 2003 C. Beard
June 2002 UMKC
K. Carlberg
UCL
October 2002
Requirements for Emergency Telecommunication Requirements for Emergency Telecommunication
Capabilities in the Internet Capabilities in the Internet
<draft-ietf-ieprep-requirements-00.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract Abstract
This document outlines requirements that need to be met in IP-based This document outlines user requirements for IP-based networks to
networks to enable and support communications for National enable and support an authorized emergency telecommunications service
Security/Emergency Preparedness (NS/EP) operations. It provides a (ETS)for use by authorities to organize and coordinate emergency and
basis from which an emergency telecommunications service can be disaster relief operations. It provides a basis from which ETS can
negotiated and provides a set of requirements that should be met for be negotiated to provide user-acceptable communications. The
acceptable emergency telecommunication capabilities for disaster requirements in this document relate to user expectation and are
recovery operations. The focus here is on network requirements, general, functional, and intended to provide wide latitude in
rather than requirements for particular applications. The implementation options. This document also provides in-depth
requirements are general, functional, and are intended to provide background on the state of emergency telecommunication capabilities
wide latitude in implementation options for service providers. as they exist today and the motivation for supporting these in IP
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 Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1 Current PSTN Capabilities..................................4 1.1 Current PSTN Capabilities..................................4
1.2 Purpose and Scope of this Document.........................5 1.2 Network Technology Transition..............................5
2. General Requirements...........................................6 1.3 Purpose and Scope of this Document.........................6
2.2 Dependability..............................................6 2. User Requirements..............................................6
2.3 Authorized Access..........................................7 3. Emergency Service Applications.................................7
2.4 Security Protection........................................7 3.1 Inelastic applications.....................................8
2.5 Privacy....................................................8 3.2 Elastic applications.......................................8
3. Technical Requirements.........................................8 4. Policy Issues..................................................8
3.1 Identification of Emergency Traffic........................8 5. Security Considerations.......................................9
3.2 Signaling for Resource Requests............................8 6. References....................................................9
3.3 Better Then Best Effort Service............................9 7. Acknowledgments...............................................9
4. Special Requirements...........................................9 8. Author's Addresses............................................9
4.1 Application-Specific Support...............................9 9. Copyright....................................................10
4.2 Traffic Types.............................................11
5. Policy Decisions..............................................11
5.1 Emergency Service Activation..............................12
5.2 Restoration Procedures....................................12
5.3 Preemption................................................12
5.4 Cooperation Between Service Providers.....................12
6. Example Emergency Scenarios...................................13
6.1 Local recovery operations.................................13
6.2 Medical operations........................................13
6.3 Regional operations.......................................13
6.4 National operations.......................................14
7. Conclusions...................................................14
8. Security Considerations.......................................14
References.......................................................14
1. Introduction 1. Introduction
Natural and man-made disasters can happen anywhere, anytime. These Natural and man-made disasters can occur anywhere, anytime. These
include, for example, earthquakes, floods, airplane crashes, and include, for example, earthquakes, floods, airplane crashes, and
terrorist attacks. While some advance planning is possible for terrorist attacks. While some advance planning is possible for
expected disaster events, most disasters happen unexpectedly. expected disaster events, most disasters happen unexpectedly.
Readily available telecommunication capabilities are essential for Readily available telecommunication capabilities are essential for
emergency recovery operations to quickly start saving lives and emergency and disaster relief operations to quickly start saving
restoring the community infrastructure. A number of lives and restoring the community infrastructure. A number of
telecommunication facilities can be involved in disaster recovery telecommunication facilities can be involved in disaster operations.
operations. These include local mobile radio, dedicated satellite These include local mobile radio, dedicated satellite systems,
systems, transportable capabilities, and the public transportable capabilities, and the public telecommunications
telecommunications infrastructure. Some of these facilities need to infrastructure. Some of these facilities need to be deployed to the
be deployed to the disaster site and very likely may not be disaster site and very likely may not be immediately available. The
immediately available. The public telecommunication services, public telecommunication services, however, are generally at hand
however, are generally at hand except in the most remote areas. The except in the most remote areas. The publicly available capabilities
publicly available capabilities include the traditional telephone include the traditional telephone network and the Internet, which can
network and the Internet, which can both be accessed via wire line, both be accessed via wire line, wireless, and various broadband
wireless, and various broadband facilities. Disaster recovery facilities. Disaster recovery operations can significantly benefit
operations can significantly benefit from a variety of modes for from a variety of modes for interchange of critical information to
interchange of critical information to organize and coordinate the organize and coordinate the emergency activities. Emergency voice
emergency activities. Emergency voice communications are supported communications are supported today by a preferential service through
today by a preferential service through public telephone networks in public telephone networks in some countries. The Definition of the
some countries. Now, however, an evolution is taking place in International Preference Scheme (ieps) for circuit-switched telephone
traditional public telecommunication networks toward integrating networks is provided in ITU-T Recommendation E.106 [4].
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.
Mostly voice traffic using either VoIP or conventional telephony is Now, however, an evolution is taking place in traditional public
used today for emergency communications over wireline and wireless telecommunication networks toward integrating circuit-switched and
facilities. However, narrowband modes can also be effectively packet-based technologies. This promises to provide a rich menu of
applied, including instant messaging, email, and telemedicine fully integrated capabilities for handling voice, message, data, and
telemetry. In addition, wideband capabilities for video broadcast, video traffic to greatly enhance disaster recovery operations. These
conferencing, and telemedicine will also greatly enhance emergency capabilities are being considered in the development of a
recovery operations. 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 During serious disaster events, public networking facilities can
experience severe stress due to damaged infrastructure and heavy experience severe stress due to damaged infrastructure and heavy
traffic loads. As bandwidth gets severely constrained, it becomes traffic loads. As bandwidth gets severely constrained, it becomes
difficult to establish and maintain effective communication difficult to establish and maintain effective communication sessions.
sessions. It is essential that disaster recovery operations be able It is essential that disaster recovery operations be able to readily
to readily communicate to organize and coordinate essential communicate to organize and coordinate essential activities.
activities. Authorized emergency communication sessions need to have Authorized emergency communication sessions need to have ready access
immediate access to available network resources and be given a high to available network resources and be given an enhanced probability
probability of successful completion of these critical of successful completion of these critical communications to help
communications to help save lives and restore community save lives and restore community infrastructure.
infrastructure.
Only people authorized by the appropriate authority are permitted to Only people authorized by the appropriate authority are permitted to
establish emergency communication sessions through public networking establish enhanced emergency communication sessions through public
facilities for facilitating immediate disaster recovery operations. networking facilities for facilitating immediate disaster recovery
Those typically authorized are local police, fire, and medical operations. We use the term ˘enhanced÷ to refer to additional
personnel as well as designated government officials from local, measures taken to achieve and sustain communications by selected
regional, and national levels who are responsible for various authorized personnel. Those typically authorized are local police,
aspects of disaster recovery operations. 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 All emergency communication sessions should be processed as normal
traffic along with all non-emergency traffic when sufficient network traffic along with all non-emergency traffic when sufficient network
bandwidth and resources are available. ONLY when networks reach bandwidth and resources are available. ONLY when networks reach
traffic saturation is there a need for giving emergency traffic saturation is there a need for giving emergency communication
communication sessions a higher probability of completion over non- sessions a higher probability of completion over non-emergency
emergency communications. While this occurrence may never happen in communications. While this occurrence may never happen in the
the typical Internet-based environment, capabilities for typical Internet-based environment, capabilities for accommodating
preferential handling of emergency traffic need to be established in emergency traffic need to be established in preparation for a serious
preparation for a serious catastrophe. These provisions should be in catastrophe. These provisions should be in place before a potential
place before a potential doomsday disaster, even for highly over- disaster, even for highly over-provisioned networks. It is better to
provisioned networks. It is better to be prepared ahead of time and be prepared ahead of time and not wait for the worst to happen first.
not wait for the worst to happen first.
The telecommunication capabilities for handling authorized emergency The ETS capabilities for handling authorized emergency traffic should
traffic should be accomplished using existing applications and be accomplished using existing applications, Internet features, and
standards whenever possible. Establishment of new and different standards whenever possible. Establishment of new and different
standards would be both costly and unlikely to ever be implemented. standards would be both costly and unlikely to ever be implemented.
The desired approach is to adopt existing standards and where needed The desired approach is to adopt existing standards and where needed
adapt new standards with any necessary adjustments needed to support adapt new standards with any necessary adjustments needed to support
preferential treatment of emergency traffic during severe periods of preferential treatment of emergency traffic during severe periods of
congestion. congestion.
This document outlines requirements that need to be met in public This document outlines user requirements that need to be met in
and private IP-based networks to enable communications for National public and private IP-based networks to enable communications for
Security/Emergency Preparedness (NS/EP) operations. Recovery ETS. These requirements would include support for existing systems
activities can involve person-to-person communications, group that address National Security/Emergency Preparedness (NS/EP)
coordination, disaster assessment application execution, remote requirements and capabilities. Recovery activities can involve
information retrieval, continuity of government, etc. person-to-person communications, group coordination, disaster
assessment application execution, remote information retrieval,
From a network perspective, processing communications can be continuity of government, etc.
particularly difficult even if the network infrastructure has not
been the target of a terrorist or affected by a natural disaster.
This is because there can be a drastic surge in the network load in
response to a disaster. In recent years the Public Switched
Telephone Network (PSTN) has experienced load levels three to five
times normal immediately after an event [1], and the same is
expected for the Internet, especially as IP telephony becomes more
prevalent.
1.1 Current PSTN Capabilities 1.1 Current PSTN Capabilities
As a starting point, the model to consider for emergency As a starting point, the model to consider for emergency
communication services is the existing service capability in the communication services is the existing service capability in the
United States PSTN, the Government Emergency Telecommunications United States PSTN, the Government Emergency Telecommunications
Service (GETS). Some other countries have similar services. 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 The purpose of GETS is to increase the probability of completion of a
a telephone call for authorized operations personnel in times of telephone call for authorized operations personnel in times of
emergencies. It does not guarantee that service will be available, emergencies. It does not guarantee that service will be available,
but it does implement a set of functions that increase the but it does implement a set of functions that increase the likelihood
likelihood of finding an available circuit to complete a call in the of finding an available circuit to complete a call in the PSTN.
PSTN.
The key aspects of GETS are as follows: The key aspects of GETS are as follows:
o Personnel gain access to GETS by calling a specified telephone o Personnel gain access to GETS by calling a specified
number and presenting a credit-card type of authentication. telephone number and presenting a credit-card type of
authentication.
o Having authenticated themselves, the call is completed on a o Once being authenticated, the call is completed on a
preferential high probability of completion basis. If calls preferential high probability of call completion basis. If
are initially blocked, they can be queued and switched to calls are initially blocked, they can be queued and
alternate carriers. switched to alternate carriers.
o If fundamental telephone services are compromised, services o If fundamental telephone services are compromised, services
contracted under GETS are restored first. This is under the contracted under GETS are restored first. This is under
provisions of TSP (Telecommunication Service Priority [2]), the provisions of TSP (Telecommunication Service Priority
which is independent of GETS. [5]), which is independent of GETS.
These features enhance the capability of NS/EP calls to be completed These features enhance the capability of NS/EP calls to be completed
with a high probability in congested networks. GETS will not with a high probability in congested networks. GETS will not preempt
preempt public telephone calls, nor are there multiple levels of public telephone calls, nor are there multiple levels of precedence
precedence within GETS. within GETS.
The approach of GETS is based on a preferential, high probability of
completion, treatment model. This model may also be used by
providers of Internet-based network services.
1.2 Purpose and Scope of this Document
The purpose of this document is to provide a basis from which
emergency service capabilities can be specified and negotiated
between network service providers and customers. It provides a set
of requirements that would need to be met for a service to
acceptably support emergency communications. The focus here is on
network requirements, rather than requirements for particular
applications. For particular requirements related to IP Telephony,
see [3].
More importantly, however, the requirements given here are quite
general and it is intended that wide latitude be available to
service providers to implement emergency services as they consider
appropriate. In [4], recommendations are provided as to how best to
implement these services, but in this document requirements are
stated so that service providers need not necessarily follow [4].
Section 2 provides general requirements that give high-level service
capabilities that should be provided. Section 3 then provides a
minimal set of specific technical requirements for meeting the
general requirements. Section 4 gives special considerations that
may optionally be addressed in an agreement for emergency services.
And finally, Section 5 provides a list of policy decisions that need
to be made and explained to customers by a service provider, but no
specific requirements are given for policy issues.
2. General Requirements
This section outlines five requirements for services that aim to
provide emergency communications for the Internet-based
infrastructure (or any telecommunication medium for that manner).
They pertain to the ability to begin communications, complete
communications successfully, and conduct them in an authorized and
private manner.
2.1 Availability
The most fundamental requirement for emergency telecommunication
services is that emergency-related users must have a high likelihood
of network resources being available to them when they need them.
Authorized users must have a high probability of being able to
initiate and complete a communication session.
Two interpretations of the concept of "high availability" could be
applied, either in a relative sense or an absolute sense. Such
options on interpretation give latitude in implementation
possibilities for emergency services. The first interprets "high
availability" in a preferential or relative sense. Authorized users
would have preferred access to resources over normal users. A
service provider would implement mechanisms to identify and treat
emergency traffic in special ways. Such an approach would allow a
service provider to avoid having to meet specific availability
targets (e.g., 95% availability) through an assurance that is given
to emergency customers that their traffic is being treated
preferentially. If the network is stressed, availability for
emergency users may decrease, but it would still be relatively
higher (even much higher) than for normal users.
In the second interpretation, high availability would mean absolute
availability levels that would be provided regardless of the network
operating conditions. Service providers may choose to provide high
availability levels through overprovisioning even when the network
is stressed. They could choose to avoid using any mechanisms to
identify or preferentially treat emergency traffic, because
emergency traffic requirements would be met by the default operation
of their network.
2.2 Dependability
Authorized users must not only be able to initiate communication
sessions; they must also be able to successfully complete their
intended activities. While PSTN services basically provide such
dependability by default, communications through the Internet might
be affected by a variety of network operating conditions, such as
congestion or link failures. An emergency telecommunication service
needs to protect authorized communications from being affected by
those conditions, at least to the extent that an emergency
communication session can still be conducted acceptably.
Definitions of acceptable performance will vary depending on the
application.
2.3 Authorized Access
Mechanisms must be implemented so that only authorized users have
access to emergency telecommunications services. Such authorization
could be PIN-based or based on assignment of cryptographic keys [5].
Authorization protects network resources from excessive use and
abuse. The two purposes for this requirement are to restrict usage
of network resources only to those who are allowed to use them and
to enable proper billing. Even when using an overprovisioning
approach where emergency users are not provided special services,
proper billing necessitates authorized access.
In today's public telephone networks a credit-card process is used.
This means entry of 32 digits of information to complete
establishment of a communication session. This is cumbersome and
time-consuming. With future technology in an Internet-based
infrastructure there is a need for a more time-responsive and
streamlined mechanism for rapid authentication.
Such authorization mechanisms should be flexible enough to provide
various levels of restriction and authorization depending on the
expectations of a particular service or customer. For example, it
might be desirable to provide access to emergency telecommunication
services differently after a hurricane where the emergency was
caused by a natural disaster as compared to after a terrorist attack
that was caused by humans. In the hurricane scenario, members of
the general public might be given access (e.g., at a lower
precedence level than emergency response organizations) where after
a terrorist attack security concerns might necessitate highly
restrictive access to emergency services.
Further requirements and recommended procedures are given in [5].
2.4 Security Protection
The overall problem of Internet security is being pursued by
appropriate and expert resources in the IETF and elsewhere. However,
specific problems of emergency traffic need to be considered.
Emergency traffic needs to be protected against intrusion, spoofing,
and specifically, denial of service. If overall security measures
that are established do not satisfy these specific requirements,
additional consideration should be given to protection specifically
focused on emergency traffic. This is discussed further in [5].
2.5 Privacy
Some emergency communications will have a requirement that they not
be susceptible to viewing or modification by others, due to the
sensitive and urgent nature of emergency response activities. An
emergency telecommunications service should be able to protect the
integrity of all emergency user communications and have options to
encrypt certain user traffic. However, due to urgency and short-term
meaningfulness of the content at initial stages of disaster
response, encryption will have limited application.
3. Technical Requirements
The following technical requirements represent the functions that
need to be fulfilled to enable the general requirements listed above
to be realized. For several of the requirements below, it is
assumed that networks will experience temporary scarcity of
resources, especially because of damaged infrastructure and high
demand immediately following a disaster. If a service provider
employs an over provisioning approach to provide emergency services
so that resources are never scarce, some of the following
requirements might not be necessary.
3.1 Identification of Emergency Traffic
Emergency traffic should be recognized in the forwarding plane. An
emergency telecommunication service should have procedures by which
emergency traffic is marked so that it can be identified throughout
the network. The decisions about who does such marking (i.e., end
users or the network), where it occurs, who recognizes such marking,
whether re-marking might occur, and at what layer or layers marking
is implemented are left to the discretion of the policy makers and
specified in service level agreements. Standardized mechanisms,
however, should be utilized.
3.2 Signaling for Resource Requests
Emergency traffic should be recognized in the control plane. For
applications where sessions need to be established or network
resources reserved, signaling mechanisms can be used to support the
differentiation of emergency signaling messages.
3.3 Better Then Best Effort Service
The default best-effort forwarding behavior available in existing
routers as standardized in [6] does not provide performance
assurances. This is especially true for emergency services where
severe congestion that accompanies disasters can cause the
performance of best-effort delivery to degrade well below acceptable
levels.
Quality of service for emergency telecommunication services does not
necessarily mean better quality of voice/video as compared to what
is available to normal users. The same QoS classes, which are
already defined for normal traffic, can be utilized for emergency
traffic as well.
The fundamental quality of service requirement for emergency traffic
is this - better than best effort service. Service providers have
the freedom to implement special quality of service mechanisms to
meet this requirement, but other approaches may be effective as
well.
Better than best effort service is provided to emergency traffic so
that it will receive assured performance levels that are at or above
a minimum performance level. Without such a requirement, the
dependability requirement outlined above could not be met.
Emergency traffic that suffers degraded QoS, however, should not be
terminated but should be allowed to continue. Disaster response
operations must be given the best chance to communicate, even if
with difficulty.
4. Special Requirements
In addition to the general and technical requirements given above,
this section provides additional requirements that may optionally be
requested for particular service agreements. They primarily involve
the specification of the particular approach that is being used by
service providers for particular networks, applications, and types
of traffic.
4.1 Application-Specific Support
The requirements in this document are for network layer mechanisms
to support emergency services. In general, these network layer
mechanisms will provide support to the rich array of applications
that could be used for emergency response operations. Specific
applications, however, may have additional requirements to be
acceptable for emergency users.
Such requirements might include additional signalling or mechanisms
to provide preferential performance or dependability to authorized
users. Examples of applications include the following.
o Voice on IP, using such signaling architectures as H.323 or SIP
[7].
o Shared real-time whiteboard.
o Instant messaging and presence.
o Databases such as the Japanese "I am Alive" [8] service, for
communication with persons not involved in the crisis.
o Database services for managing the crisis, including
calendaring, contact management, order and trouble report
management, legal services, medical services, etc.
o Electronic mail.
o Telemedicine, victim observation video, and vital-sign 1.2 Network Technology Transition
telemetry
o Damage assessment applications. 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".
o File transfer. 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 World Wide Web. 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
This document does not address specific requirements for these These are described in ETSI Technical Report [6].
applications. The focus of this document is to provide requirements
for network service providers. Requirements for the applications
should be met by content providers and end users. However, network
service providers may wish to provide network-based services that
could improve the performance of particular applications, for
example by providing web caching.
Of specific interest to current emergency management organizations As the IP packet-technology becomes the dominant part of the public
are IP Telephony and Voice on IP. Further requirements and telecommunications infrastructure, the prospect of many enhanced
recommended procedures for these applications, in particular, are capabilities and services comes forth. These could include expanded
given in [3]. In the future, however, it is anticipated that voice features in IP-telephony to support an enhanced probability of call
communications will be overshadowed by a number of other multimedia completion and additional call processing features. The provision of
modes of communication that will significantly benefit emergency additional communication services such as Email, instant messaging,
recovery operations. 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.
4.2 Traffic Types 1.3 Purpose and Scope of this Document
Consideration should be given to the different traffic types in The purpose of this document is to articulate user requirements
supporting the different multimedia applications for emergency concerning support for emergency related communications. It provides
telecommunication services. The three types of traffic that may be a set of requirements that need to be met by service(s) to acceptably
treated in distinctive ways are as follows. 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.
o Inelastic traffic - As defined in [9], inelastic traffic is Section 2 provides a summary of the user requirements that identify
traffic which has a firm delay bound. If packets arrive after high-level service capabilities that should be provided. Section 3
a maximum acceptable delay, the packets are essentially provides a list of possible emergency communication applications that
worthless to the receiver. Real-time audio and video are could be used by emergency personnel. And finally, Section 4
examples of inelastic traffic. identifies policy issues that need to be considered in the deployment
and operation of an ETS.
o Interactive elastic traffic - Elastic applications are System requirements that focus on how user requirements (taken as a
generally those which wait for data to arrive and do not whole) are to be satisfied with respect to the network & gateways
discard it if it is late. This does not mean that applications (i.e., network layer to application layer) are specified in other
are insensitive to delay, however, because such delays could documents. [2] specifies a set of general system requirements and
hurt application performance significantly. In particular, [7] articulates a set of more specific set of system requirements for
interactive elastic traffic requires reasonable delays because IP telephony.
of the user interaction that is involved. Examples of
interactive elastic traffic include HTTP and instant messaging
traffic.
o Bulk transfer elastic traffic - Some elastic applications, 2. User Requirements
however, do not involve direct user interaction. In such
cases, delay is not so much a concern as average throughput.
Bulk transfers can have large variations in delay as long as an
expected average throughput is obtained. For example, if a
file can be downloaded in 100 seconds, it does not matter if
for part of the transfer the throughput was virtually zero.
Examples of bulk transfer traffic are FTP and SMTP.
As an example, service providers may wish to provide service The basic user requirements that need to be considered in providing
assurances for inelastic traffic using Diffserv [10] but use emergency telecommunication capabilities to support recovery
overprovisioning for both types of elastic traffic. 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:
5. Policy Decisions o Users should be able to use public telecommunication
resources for supporting emergency communications to help
organize and coordinate immediate disaster recovery
operations.
The above general and technical requirements provide wide latitude o Users that access emergency telecommunications service must
for creativity on the part of service providers to implement be authenticated. This should be accomplished in a timely
emergency services. In addition to meeting the requirements above, manner.
a series of policy decisions should be made in the implementation of
emergency services. No particular approach is prescribed regarding
these policies. However, the policies used by a service provider to
address the following issues should be clearly defined and
communicated.
The user needs to determine specific policies for the emergency o When networks reach traffic saturation emergency
telecommunications service, and these should be specified and agreed communication sessions should be provided with with a
upon in the service level agreement. 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
normal traffic along with all non-emergency traffic when
sufficient network bandwidth and resources are available.)
5.1 Emergency Service Activation 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.
Providers of an emergency service should specify whether emergency o There must exist a mapping association between labels
treatment is always available within the network or whether the defined by various standards bodies. This mapping will
service is only activated upon declaration of emergency conditions help facilitate inter-working of services in cases where
by an appropriate authority. Service providers may also choose to gateways and networks support emergency telecommunications
provide a minimal service that is available at all times, but which services.
could be expanded once an emergency declaration was made.
5.2 Restoration Procedures 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.
Service providers should describe the restoration procedures they o Networks should be able to support a variety of user
will use when substantial damage is experienced in their network. applications including telephony, video, database access,
They should provide plans and estimates in advance of how damaged messaging, telemetry, and web browsing to support emergency
facilities will affect the availability of emergency services and, operations.
if a critical relationship exists, how prioritized restoration of
those vital facilities will be accomplished. Service providers may,
of course, choose to rely upon rerouting mechanisms that would make
the restoration procedures they use irrelevant to the continued
dependability of emergency services. The only concern in that case
is when damage could be so extensive that rerouting mechanisms would
be ineffective. Also see [2].
5.3 Preemption 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.
Service providers may wish to provide resources for emergency o Users should have the option protecting certain sensitive
communications by interrupting particular non-emergency traffic traffic from eavesdropping and the source/destination of
flows. If such an approach is used, this should be explicitly some traffic.
stated and details should be given on how preemption is carried out.
Regulatory guidelines in some jurisdictions may prohibit the use of
preemption to support emergency traffic.
5.4 Cooperation Between Service Providers o Users should have the option of requesting degraded quality
of service when normal or expected QoS cannot be achieved.
Emergency users will only be concerned with the quality of the end- It may not be possible to fulfill all of these requirements
to-end communications they are provided. However, it is possible immediately and within existing standards, Internet features, and
that no one particular service provider will be able to support that applications. However, provision of the best probability of
service end-to-end. Emergency services could be carried over a successful completion of critical emergency communications will
combination of service providers, some of which would provide significantly enhance the ability of disaster recovery operations to
emergency capabilities and some of which may not. save lives and restore community infrastructure.
Service providers that do provide emergency services may choose to 3. Emergency Service Applications
provide services that are only operative within their networks and
are independent of other service providers. Alternatively, service
providers may employ mechanisms to cooperate with other service
providers to provide emergency services. This would result in a
considerable portion of the end-to-end path being administered in a
cooperative fashion. If so, service providers should specify the
mechanisms they would use and the extent to which they would
cooperate with other service providers to support emergency
services.
6. Example Emergency Scenarios A variety of IP based applications are expected to be used to support
disaster recovery and response operations in the future as future
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.
Some example instances for emergency communications are described The following list is not exhaustive, but is illustrative of the
below. These show some different levels of emergency communication types of capabilities that could prove to be beneficial:
requirements that need to be supported.
6.1 Local recovery operations 3.1 Inelastic applications
While mobile radio is the primary mode of communication for police o Real time interactive voice (telephony)
and fire brigade operations, there is often a need to supplement o Real time interactive video conference
these capabilities with access to the public telecommunication o Real time interactive video telemedicine
networks. This is particularly needed during the initial stages and o Real time interactive white board
immediately following a disaster event. These emergency o Streaming audio and video
communications can be accomplished through use of wireless access o Telemedicine telemetry for vital sign monitoring
(cellular phone or PDA) where priority service may be necessary due o Virtual reality imaging for disaster scene surveillance
to congestion. Some mobile radio systems interface with public
networks, but their use is often discouraged or avoided because of
limited bandwidth availability in the frequency allocation.
Communications outside the immediate local radio coverage area are
often required to request additional resources from other areas and
to notify and coordinate operations with regional (e.g. county and
state) and national authorities. Public telecommunications services
provide at-hand capability to immediately support these critical
emergency communications
6.2 Medical operations 3.2 Elastic applications
The process of saving lives and providing medical treatment to o Interactive victim database (e.g. I Am Alive - IAA)
victims is greatly enhanced through the use of data telemetry to o Interactive database services for crisis management
remotely provide victim vital signs to a central medical center. In o Interactive Web access
addition, treatment of victims at the disaster site can be o Electronic Mail
significantly accelerated through the use of video telemedicine o Instant messaging and presence
transmissions to remote medical staff. These vital life-saving o File transfer
communications can be very effectively supported by an Internet-
based infrastructure.
6.3 Regional operations 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.
The magnitude of the event may require recovery support from 4. Policy Issues
resources outside of the immediate area of impact. Critical
information is provided for authorities to proclaim a disaster
crisis and activate vital support resources.
Regional emergency operations centers would need immediate and
effective telecommunication capabilities to rapidly organize and
coordinate support from elsewhere regionally, nationally, or
internationally. Public telecommunication resources are essential to
support these emergency activities.
6.4 National operations 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.
The most serious disaster events can impact national security of a 5. Security Considerations
country. Therefore, immediate action is required by government
officials to organize and coordinate the highest level of emergency
support resources. With a serious threat to national security,
actions to ensure continuity of government must be initiated. These
types of activities need to not only have priority treatment for
emergency communications in the public telecommunications domain,
but they also require protection against eavesdropping of
confidential/sensitive information. In addition, locations of source
and destination of some critical national security traffic needs
protection. While these communications can often be supported
directly by dedicated government networks, public telecommunication
facilities provide an essential alternate capability.
7. Conclusions Discussion on security is addressed in Section 2.
There are many critical requirements for emergency 6. References
telecommunications that need to be addressed as outlined above.
These are important ingredients to the total solution required for
effective and comprehensive emergency telecommunication capabilities
in a public Internet-based telecommunication service infrastructure.
Technical solutions are neither proposed nor suggested, so that full
consideration and innovation will be used in seeking effective
solutions. There are many other procedural, operational, policy,
regulatory, and full systems considerations that also need to be
addressed to ensure that the technical capabilities of Internet-
based infrastructures are established and sound.
8. Security Considerations 1 Bradner, S., Internet Standards Process ű Revision 3, BCP 9, RFC
2026, October 1996.
Detailed requirements are given in [5]. Authorized access, security 2 Carlberg, K., Atkinson, R., "General Requirements for Emergency
protection, and privacy are presented here as general security Telecommunications Service", Internet Draft, Work in Progress,
requirements for emergency services in Section 2. September, 2002.
References 3 Bradner, S., ˘Key Words for Use in RFCs to Indicate Requirement
Levels÷, BCP 14, RFC 2119, March 1997.
1 B. Brewin, "Nation's Networks See Large Volume Spikes After 4 ITU-T, "Description of an International Emergency Preference
Attacks,", Computerworld, September 17, 2001. Scheme", ITU-T Recommendation E.106, March 2000.
2 Information Interchange Representation of National Security 5 ˘Information Interchange Representation of National Security
Emergency Preparedness ű Telecommunications Service Priority, Emergency Preparedness ű Telecommunications Service Priority÷,
American National Standard T1.211-1989 (R1999). American National Standard T1.211-1989 (R1999).
3 Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP 6 ETSI TR 101 300, V2.1.1, "Telecommunications and Internet Protocol
Telephony," draft-ietf-ieprep-framework-00 (work in progress), Harmonization Over Networks (TIPHON); Description of Technical
February 2002. Issues", October 1999
4 Work-in-progress.
5 Brown, I., "Securing prioritised emergency traffic", draft-brown-
ieprep-sec-00 (work in progress), February 2002.
6 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
7 Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
8 "IAA System (I Am Alive): The Experiences of the Internet 7 Carlberg, K., Atkinson, R., "IP Telephony Requirements for
Disaster Drills", INET 2000, June 2000. Emergency Telecommunications Service", Internet Draft, Work in
Progress, September, 2002
9 Braden, R., Clark, D., and Shenkar, S., "Integrated Services in 7. Acknowledgments
the Internet Architecture: an Overview", RFC 1633, June 1994.
10 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Many thanks to Fred Baker, Scott Bradner, Ian Brown, and Ran Atkinson
Weiss, "An Architecture for Differentiated Services", RFC 2475, for their comments on this draft.
December 1998.
Author Addresses 8. Author's Addresses
Hal Folts, Senior Systems Engineer Hal Folts
Priority Services - Internet Team, Technology and Programs
National Communications System National Communications System
1-703-607-6186 701 South Courthouse Road
foltsh@ncs.gov Arlington, VA 22204-2198 USA
Phone: +1 703 607-6186
Email: foltsh@ncs.gov
Cory Beard Cory Beard
School of Interdisciplinary Computing and Engineering School of Interdisciplinary Computing and Engineering
University of Missouri-Kansas City University of Missouri-Kansas City
5100 Rockhill Road 5100 Rockhill Road
Kansas City, MO 64110 Kansas City, MO 64110
1-816-235-1550 Phone: 1-816-235-1550
beardc@umkc.edu 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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/