Internet Engineering Task Force Cory Beard
INTERNET DRAFT Univ. of Missouri-Kansas City
Expires: November 2002 May 2002
Network Requirements for Internet Emergency Preparedness Services
draft-beard-ieprep-requirements-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document outlines requirements that need to be met in IP-based
networks to enable and support communications for National
Security/Emergency Preparedness (NS/EP) operations. It provides a
template from which an emergency service can be negotiated and
provides a set of requirements that should be met for acceptable
emergency communication services. The focus here is on network
requirements, rather than requirements for particular applications.
The requirements are general and are intended to provide wide
latitude in implementation options for service providers.
Table of Contents
1. Introduction...................................................2
1.1 Current PSTN Capabilities..................................3
1.2 Purpose and Scope of this Document.........................3
1.3 Fundamental Approaches.....................................4
2. General Requirements...........................................4
2.1 Availability...............................................5
2.2 Dependability..............................................5
2.3 Authorized Access..........................................6
2.4 Privacy....................................................6
3. Technical Requirements.........................................6
3.1 Identification of Priority Traffic.........................7
Beard Expires - November 2002 [Page 1]
Internet-Draft Emergency Requirements May 2002
3.2 Signalling for Resource Requests...........................7
3.3 Better Then Best Effort Service............................7
4. Special Requirements...........................................7
4.1 Traffic Types..............................................8
4.2 Network Areas..............................................8
4.3 Application-Specific Support...............................9
5. Policy Decisions..............................................10
5.1 Services Always Available or Only Enabled Upon Emergency
Declaration...................................................10
5.2 Restoration Procedures....................................10
5.3 Preemption................................................10
5.4 Cooperation Between Service Providers.....................10
6. Security Considerations.......................................11
References.......................................................11
Author's Address.................................................12
1. Introduction
This document outlines requirements that need to be met in public
and private IP-based networks to enable communications for National
Security/Emergency Preparedness (NS/EP) operations. These
activities seek to return the population to normal living conditions
after serious disasters and events, such as floods, earthquakes,
hurricanes, and terrorist attacks. Communication activities can
involve person-to-person communications, group coordination,
disaster assessment application execution, remote information
retrieval, etc.
Disaster situations can occur unexpectedly at any time and at any
place. These events often cause significant damage to the community
infrastructure, including network infrastructure, and severely
disrupt daily living. Recovery requires rapid response by local
authorities, immediate reaction from utility service providers, and
support from medical, construction, fire, and police resources.
Effective communications are essential to facilitate the
coordination of lifesaving activities concurrent with reestablishing
control in the disaster area. Following a disaster, immediate
response operations focus on saving lives, protecting property, and
meeting basic human needs.
From a network perspective, communications can be 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.
Beard Expires - November 2002 [Page 2]
Internet-Draft Emergency Requirements May 2002
1.1 Current PSTN Capabilities
One model to consider for emergency communication services is the
existing service in the United States PSTN, the Government
Emergency Telecommunications Service (GETS). Some other countries
have equivalent services.
The purpose of GETS is to increase the probability that phone
service will be available to selected government agency personnel in
times of emergencies. It does not guarantee that service will be
available, but it does implement a series of functions that increase
the likelihood of finding an available circuit.
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.
o Having authenticated themselves, the call is completed on a
preferential basis. If calls are initially blocked, they can
be queued and can use alternate carriers.
o If fundamental telephone services are compromised, services
contracted under GETS are restored first.
These features enhance the capability of NS/EP calls to be completed
in congested networks. GETS will not preempt public telephone
calls, nor are there levels of precedence within GETS.
The approach of GETS is based on a preferential treatment model.
This model may also be used by providers of Internet network
services. Other models could also be used and are introduced in a
later section.
1.2 Purpose and Scope of this Document
The purpose of this document is to provide a template from which an
emergency service 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 [2].
More importantly, however, the requirements given here are quite
general and it is intended that wide latitude be available to
service providers to implement services as they consider
appropriate. In [3], 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 [3].
Beard Expires - November 2002 [Page 3]
Internet-Draft Emergency Requirements May 2002
Section 2 provides general requirements that give high-level service
capabilities that must 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.
1.3 Fundamental Approaches
Before the requirements are discussed, it is first useful, however,
to briefly outline the basic approaches that could be used by a
provider in offering emergency services. These are as follows.
o Best Effort Provisioning - Service providers may wish to
provide emergency services by using sufficient capacity such
that emergency services are provided acceptable quality without
using additional mechanisms beyond best effort traffic handling
[4]. One way this could be implemented would be to size links
such that no congestion would be experienced, even if all
traffic that would traverse a link would be multiplexed
together. Another approach could be to use a VPN-based
approach to partition the capacity to at least keep emergency
traffic from experiencing congestion. In either approach, a
service provider must be able to provide sufficient confidence
that congestion would not be seen by emergency traffic even in
the heavily overloaded conditions following disasters.
o Service Guarantees - Service providers may wish to provide
emergency services that give some measure of service
guarantees. For example, they may provide specified upper
bounds on delay for audio or video traffic. They would agree
to meet such requirements for a certain percentage of packets
regardless of network conditions.
o Preferential Treatment - In contrast to service guarantees,
however, service providers may wish to only provide services
that in some way provide preferential treatment for emergency
traffic without explicit guarantees. If network congestion
increases dramatically, the performance for emergency traffic
might degrade right along with normal traffic, but would still
receive some form of preference. Although the traffic would
not be immune to the effects of overloads, GETS has used this
approach and it has proven to be acceptable.
2. General Requirements
This section outlines four requirements for services that aim to
provide emergency communications for the Internet (or any
communication medium for that manner). They pertain to the ability
Beard Expires - November 2002 [Page 4]
Internet-Draft Emergency Requirements May 2002
to begin communications, complete communications successfully, and
conduct them in an authorized and private manner.
2.1 Availability
The most fundamental requirement for emergency communication
services is that emergency-related users must have a high likelihood
of network resources being available to them when they need them.
Priority users must have a high probability of being able to
initiate 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. Priority users
would have preferred access to resources over normal users. A
service provider would implement mechanisms to identify and treat
priority 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 priority customers that their traffic is being treated
preferentially. If the network is stressed, availability for
priority 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 best effort provisioning even when the
network is stressed. They could choose to avoid using any
mechanisms to identify or preferentially treat priority traffic,
because priority traffic requirements would be met by the default
operation of their network.
2.2 Dependability
Priority users must not only be able to initiate communication
sessions; they must also be able to successfully complete their
intended activities. While PSTN communications provide such
dependability by default, Internet communications might be affected
by a variety of network operating conditions, such as congestion or
link failures. An emergency communication service must protect
priority communications from being affected by those conditions, at
least to the extent that the communication session can still be
conducted acceptably. Definitions of acceptable performance will
vary depending on the application.
Beard Expires - November 2002 [Page 5]
Internet-Draft Emergency Requirements May 2002
2.3 Authorized Access
Mechanisms must be implemented so that only authorized users have
access to priority communications 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 a best effort
provisioning approach where emergency users are not provided special
services, proper billing necessitates authorized access.
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 communications
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 priority level than
emergency response organizations) where after a terrorist attack
security concerns might necessitate highly restrictive access to
emergency services.
In the case of 911-type services, authorization is also applicable.
In such cases, users self-authorize themselves by deciding that they
have an urgent need that warrants special attention. If they abuse
the service, they also understand that they could be held
accountable for such abuse.
Further requirements and recommended procedures are given in [5].
2.4 Privacy
Emergency communications will frequently 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 communications service should be able to protect the
integrity of user communication with options to encrypt user
traffic.
3. Technical Requirements
The following technical requirements represent the mechanisms that
must be in operation 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 a best effort provisioning approach to provide emergency
Beard Expires - November 2002 [Page 6]
Internet-Draft Emergency Requirements May 2002
services so that resources are never scarce, some of the following
requirements will not be necessary.
3.1 Identification of Priority Traffic
Priority traffic must be recognized in the forwarding plane. An
emergency communication service must 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 service provider.
3.2 Signalling for Resource Requests
Priority traffic must be recognized in the control plane. For
applications where sessions need to be established or network
resources reserved, signalling mechanisms must be used that support
the differentiation of priority signalling messages.
3.3 Better Then Best Effort Service
The default best-effort forwarding behavior available in existing
routers as standardized in [4] 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 communication 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 priority 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 guaranteed performance levels that are at or
above a minimum performance level. Without such a requirement, the
dependability requirement outlined above could not be met.
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
Beard Expires - November 2002 [Page 7]
Internet-Draft Emergency Requirements May 2002
the specification of the particular approach that is being used by
service providers for particular networks, applications, and types
of traffic.
4.1 Traffic Types
A service provider may choose to provide an emergency service that
supports different traffic types in different ways with customized
levels of availability and dependability. The three types of
traffic that may be treated in distinctive ways are as follows.
o Inelastic traffic - As defined in [6], inelastic traffic is
traffic which has a firm delay bound. If packets arrive after
a maximum acceptable delay, the packets are essentially
worthless to the receiver. Real-time audio and video are
examples of inelastic traffic.
o Interactive elastic traffic - Elastic applications are
generally those which wait for data to arrive and do not
discard it if it is late. This does not mean that applications
are insensitive to delay, however, because such delays could
hurt application performance significantly. In particular,
interactive elastic traffic requires reasonable delays because
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,
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 of how service providers may wish to support the above
types of traffic, they may wish to provide service guarantees for
inelastic traffic using Diffserv [7] but use best effort
provisioning for both types of elastic traffic.
4.2 Network Areas
It is not expected that service providers use the same approach to
supporting emergency traffic in all parts of their network. They
are free to provide services differently based on whether traffic is
traversing core, distribution, or access layers of the service
provider's network. Specifications may also differ depending on the
type of access technology that is being used (e.g., LAN, wireless,
or DSL).
Beard Expires - November 2002 [Page 8]
Internet-Draft Emergency Requirements May 2002
For example, a service provider may wish to identify and provide
specialized treatment of emergency traffic in access networks and
use best effort treatment in core networks.
4.3 Application-Specific Support
In addition to the above requirements for network layer mechanisms
to support priority services, specific applications 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 priority users.
Examples of applications include the following.
o Voice on IP, using such signaling architectures as H.323 or SIP
[8].
o Shared real-time whiteboard.
o Instant messaging and presence.
o Databases such as the Japanese "I am Alive" [9] 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 Damage assessment applications.
o File transfer.
o World Wide Web.
However, this document does not address requirements for
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 which
could improve the performance of particular applications, for
example by providing web caching.
Of specific interest to current emergency management organizations
are IP Telephony and Voice on IP. Further requirements and
recommended procedures for these applications in particular are
given in [2].
Beard Expires - November 2002 [Page 9]
Internet-Draft Emergency Requirements May 2002
5. Policy Decisions
The above general and technical requirements provide wide latitude
for creativity on the part of service providers to implement
emergency services. In addition to meeting the requirements above,
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
addressing the following issues should be clearly defined and
communicated.
5.1 Services Always Available or Only Enabled Upon Emergency
Declaration
Providers of an emergency service should specify whether emergency
treatment is always available within the network or whether the
service is only activated upon declaration of emergency conditions
by an appropriate authority. Service providers may also choose to
provide a minimal service that is available at all times, but which
could be expanded once an emergency declaration was made.
5.2 Restoration Procedures
Service providers should describe the restoration procedures they
will use when substantial damage is experienced in their network.
They should provide plans and estimates in advance of how damaged
facilities will affect the availability of emergency services and,
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.
5.3 Preemption
Service providers may wish to provide resources for emergency
communications by interrupting particular non-emergency traffic
flows. If such an approach is used, this should be explicitly
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
Emergency users will only be concerned with the quality of the end-
to-end communications they are provided. However, it is possible
that no one particular service provider will be able to support that
service end-to-end. Emergency services could be carried over a
Beard Expires - November 2002 [Page 10]
Internet-Draft Emergency Requirements May 2002
combination of service providers, some of which would provide
emergency capabilities and some of which may not.
Service providers which do provide emergency services may choose to
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. Security Considerations
Authorized access and privacy are presented here as general security
requirements for emergency services in Section 2. Further
requirements are given in [5].
References
1 B. Brewin, "Nation's Networks See Large Volume Spikes After
Attacks,", Computerworld, September 17, 2001.
2 Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP
Telephony," draft-ietf-ieprep-framework-00 (work in progress),
February 2002.
3 Work-in-progress.
4 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
5 Brown, I., "Securing prioritised emergency traffic", draft-brown-
ieprep-sec-00 (work in progress), February 2002.
6 Braden, R, Clark, D., and Shenkar, S., "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
7 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
8 Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
9 , "IAA System (I Am Alive): The Experiences of the Internet
Disaster Drills", INET 2000, June 2000.
Beard Expires - November 2002 [Page 11]
Internet-Draft Emergency Requirements May 2002
Author's Address
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
Beard Expires - November 2002 [Page 12]