Ieprep
   Internet Engineering Task Force                              Hal Draft                                              H. Folts
INTERNET DRAFT                          National Communications System
   Document: draft-ietf-ieprep-requirements-01.txt                  NCS
   Expires: December December 2002                             Cory April 2003                                         C. Beard
                                         Univ. of Missouri-Kansas City
                                                             June
                                                                   UMKC
                                                            K. Carlberg
                                                                    UCL
                                                           October 2002

               Requirements for Emergency Telecommunication
                       Capabilities in the Internet

                <draft-ietf-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. 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 that need to be met in for IP-based networks to
   enable and support communications for National
   Security/Emergency Preparedness (NS/EP) 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 an emergency telecommunications service ETS can
   be negotiated and provides a set of requirements that should be met for
   acceptable emergency telecommunication capabilities for disaster
   recovery operations. The focus here is on network requirements,
   rather than requirements for particular applications. to provide user-acceptable communications.  The
   requirements in this document relate to user expectation and are
   general, functional, and are intended to provide wide latitude in
   implementation options options.  This document also provides in-depth
   background on the state of emergency telecommunication capabilities
   as they exist today and the motivation for service providers. 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

   1. Introduction...................................................2
      1.1 Current PSTN Capabilities..................................4
      1.2 Network Technology Transition..............................5
      1.3 Purpose and Scope of this Document.........................5 Document.........................6
   2. General Requirements...........................................6
      2.2 Dependability..............................................6
      2.3 Authorized Access..........................................7
      2.4 Security Protection........................................7
      2.5 Privacy....................................................8 User Requirements..............................................6
   3. Technical Requirements.........................................8
      3.1 Identification of Emergency Traffic........................8 Service Applications.................................7
      3.1 Inelastic applications.....................................8
      3.2 Signaling for Resource Requests............................8
      3.3 Better Then Best Effort Service............................9 Elastic applications.......................................8
   4. Special Requirements...........................................9
      4.1 Application-Specific Support...............................9
      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 Issues..................................................8
   5.  Security Considerations.......................................9
   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  References....................................................9
   7. Conclusions...................................................14  Acknowledgments...............................................9
   8. Security Considerations.......................................14
   References.......................................................14  Author's Addresses............................................9
   9.  Copyright....................................................10

1.   Introduction

   Natural and man-made disasters can happen 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 recovery and disaster relief operations to quickly start saving
   lives and restoring the community infrastructure.  A number of
   telecommunication facilities can be involved in disaster recovery 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
   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.

   Mostly voice traffic using either VoIP or conventional telephony  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
   used today for now the globally recognized term that identifies the new
   generation of emergency communications over wireline and wireless
   facilities. However, narrowband modes can also be effectively
   applied, including instant messaging, email, and telemedicine
   telemetry. In addition, wideband capabilities in public
   telecommunication networks for video broadcast,
   conferencing, and telemedicine will also greatly enhance authorized users to use during
   emergency
   recovery and disaster relief operations.

   During

   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
   immediate ready access
   to available network resources and be given a high 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
   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 non-emergency
   communications.  While this occurrence may never happen in the
   typical Internet-based environment, capabilities for
   preferential handling of accommodating
   emergency traffic need to be established in preparation for a serious
   catastrophe.  These provisions should be in place before a potential doomsday
   disaster, even for highly over-
   provisioned over-provisioned networks.  It is better to
   be prepared ahead of time and not wait for the worst to happen first.

   The telecommunication ETS capabilities for handling authorized emergency traffic should
   be accomplished using existing applications 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) operations.
   requirements and capabilities.  Recovery activities can involve
   person-to-person communications, group coordination, disaster
   assessment application execution, remote information retrieval,
   continuity of government, etc.

   From a network perspective, processing 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.

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.

          o Having authenticated themselves, 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 [2]),
            [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 approach of GETS public telecommunication infrastructure is based on a preferential, high probability of
   completion, treatment model. This model may also be used by
   providers in the process of
   evolving from the traditional circuit-switched technology to
   Internet-based network services.

1.2 Purpose and Scope of this Document

   The purpose packet technology.  In developing new ETS capabilities
   for the future, consideration needs to be given during the period of this document
   transitions, which is often referred to provide a basis from which
   emergency service capabilities can be specified and negotiated
   between network service providers and customers. as "convergence".

   During convergence, IP packet-based technology is being integrated
   into the public telecommunications infrastructure.  It provides a set
   of requirements is important
   that would need to be met the existing basic capability for a service 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
   acceptably 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.

1.3     Purpose and Scope of this Document

   The focus here purpose of this document is on
   network requirements, rather than to articulate user requirements
   concerning support for particular
   applications. For particular requirements emergency related communications.  It provides
   a set of requirements that need to IP Telephony,
   see [3].

   More importantly, however, the 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.  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 a summary of the user requirements that give identify
   high-level service capabilities that should be provided.  Section 3 then
   provides a
   minimal set list of specific technical requirements for meeting the
   general requirements.  Section 4 gives special considerations possible emergency communication applications that
   may optionally
   could be addressed in an agreement for used by emergency services. personnel.  And finally, Section 5 provides a list of 4
   identifies policy decisions issues that need to be made considered in the deployment
   and explained to customers by a service provider, but no
   specific requirements are given for policy issues.

2. General Requirements

   This section outlines five operation of an ETS.

   System requirements for services that aim to
   provide emergency communications for the Internet-based
   infrastructure (or any telecommunication medium for that manner).
   They pertain focus on how user requirements (taken as a
   whole) are to be satisfied with respect to the ability network & gateways
   (i.e., network layer to begin communications, complete
   communications successfully, and conduct them application layer) are specified in an authorized other
   documents.  [2] specifies a set of general system requirements and
   private manner.

2.1 Availability

   The most fundamental requirement
   [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
   services is capabilities to support recovery
   operations from serious disaster situations are summarized as
   follows.  Note that emergency-related users must have a high likelihood we assume the presence of network resources being available to them when they need them.
   Authorized users must have a high probability Service Level
   Agreements in cases where user requirements cover expectations of being
   service providers:

          o Users should be able to
   initiate use public telecommunication
            resources for supporting emergency communications to help
            organize and complete a communication session.

   Two interpretations of the concept of "high availability" could coordinate immediate disaster recovery
            operations.

          o Users that access emergency telecommunications service must
            be
   applied, either authenticated.  This should be accomplished in a relative sense or an absolute sense.  Such
   options on interpretation give latitude in implementation
   possibilities for timely
            manner.

          o When networks reach traffic saturation emergency services.  The first interprets "high
   availability" in
            communication sessions should be provided with with a preferential or relative sense.  Authorized users
   would have preferred access to resources
            higher probability of completion over normal users.  A non-emergency
            communications.  We assume the presence of a service provider would implement mechanisms level
            agreement to identify and treat accomplish this latter case. (Note: Sessions
            identified as emergency communication could be processed as
            normal 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 along with all non-emergency traffic when
            sufficient network bandwidth and resources are available.)

          o Once an assurance that is given
   to emergency customers that their traffic communications session is being treated
   preferentially.  If established,
            the network is stressed, availability for
   emergency users may decrease, but it would still user should 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 able to provide high
   availability levels through overprovisioning even when complete the network
   is stressed.  They could choose to avoid using any mechanisms to
   identify session without
            being interrupted or preferentially treat emergency traffic, because
   emergency traffic requirements would be met by having the default operation quality of their network.

2.2 Dependability

   Authorized users must not only the
            communications be able to initiate communication
   sessions; they degraded excessively.

          o There must also 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 successfully complete their
   intended activities.  While PSTN services basically provide such
   dependability by default, communications through the Internet might
   be affected by a variety transit multiple
            service providers.  The existence 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 level
            agreements determines the extent that an emergency
   communication session by which this can still be conducted acceptably.
   Definitions of acceptable performance will vary depending on the
   application.

2.3 Authorized Access

   Mechanisms must
            accomplished.

          o Networks should be implemented so that only authorized users have
   access able to support a variety of user
            applications including telephony, video, database access,
            messaging, telemetry, and web browsing to support emergency telecommunications services.  Such authorization
   could
            operations.

          o Authorized emergency communications should be PIN-based protected
            from intrusion or based on assignment interference, such as, spoofing, change
            of cryptographic keys [5].
   Authorization protects network resources from excessive use content, and
   abuse.  The two purposes for this requirement are to restrict usage denial of network resources only to those who are allowed service.  If the protection
            cannot be accomplished, then users must be able to use them detect
            this failure.

          o Users should have the option protecting certain sensitive
            traffic from eavesdropping 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 the source/destination of information to complete
   establishment
            some traffic.

          o Users should have the option 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 requesting degraded quality
            of a particular service when normal or customer.  For example, it
   might expected QoS cannot 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 achieved.

   It may not 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 possible to emergency services.

   Further fulfill all of these requirements
   immediately and recommended procedures are given in [5].

2.4 Security Protection

   The overall problem of within existing standards, Internet security is being pursued by
   appropriate and expert resources in the IETF features, and elsewhere.
   applications.  However,
   specific problems provision of the best probability of
   successful completion of critical emergency traffic need to be considered.

   Emergency traffic needs communications will
   significantly enhance the ability of disaster recovery operations to be protected against intrusion, spoofing,
   save lives and specifically, denial restore community infrastructure.

3.   Emergency Service Applications

   A variety of service. If overall security measures
   that IP based applications are established do not satisfy these specific requirements,
   additional consideration should be given expected 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 used to the
   sensitive support
   disaster recovery and urgent nature of emergency response activities. An
   emergency telecommunications service should be able to protect operations in the
   integrity of all emergency user communications and have options future as future
   services become available to
   encrypt certain user traffic. However, due the user.  They include not only the
   basic IP telephony services but expand to urgency and short-term
   meaningfulness include a selection of
   multimedia services to enhance the content at initial stages of ability for saving lives and
   restoring community infrastructure impacted by serious disaster
   response, encryption
   events.  This implies that various upper layer characteristics will have limited application.

3. Technical Requirements
   be operating over IP.

   The following technical requirements represent list is not exhaustive, but is illustrative of the functions
   types of capabilities that
   need could prove to be fulfilled 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 enable the general requirements listed above current emergency management
   organizations is tends to be realized.  For several of center on IP telephony.  In the requirements below, future,
   however, it is
   assumed anticipated that networks voice communications will experience temporary scarcity of
   resources, especially because of damaged infrastructure and high
   demand immediately following a disaster.  If be
   overshadowed by a service provider
   employs an over provisioning approach to provide emergency services
   so that resources are never scarce, some number of the following
   requirements might not be necessary.

3.1 Identification emerging multimedia modes 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
   communication that it can be identified throughout will significantly benefit emergency recovery
   operations.

4.   Policy Issues

   In the network.  The development and deployment of ETS capabilities, a number of
   policy decisions about who does such marking (i.e., end
   users or are required that will define how the network), where it occurs, who recognizes such marking,
   whether re-marking might occur, and at what layer or layers marking
   is implemented services are left
   to the discretion of the policy makers be applied, configured, and
   specified used.  The user policies will be
   conveyed to the service provider in the service level agreements. Standardized mechanisms,
   however, should be utilized.

3.2 Signaling agreement (SLA)
   established 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 provision 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. ETS capabilities.  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
        telemetry

     o  Damage assessment applications.

     o  File transfer.

     o  World Wide Web.

   This document does not address specific requirements for these
   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
   are IP Telephony and Voice on IP.  Further requirements and
   recommended procedures for these applications, in particular, are
   given in [3]. In the future, however, it is anticipated that voice
   communications will be overshadowed by a number of other multimedia
   modes of communication that will significantly benefit emergency
   recovery operations.

4.2 Traffic Types

   Consideration should be given to the different traffic types in
   supporting the different multimedia applications for emergency
   telecommunication services.  The three types of traffic that may be
   treated in distinctive ways are as follows.

     o  Inelastic traffic - As defined in [9], 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, service providers may wish to provide service
   assurances for inelastic traffic using Diffserv [10] but use
   overprovisioning for both types of elastic traffic.

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
   address the following issues should be clearly defined and
   communicated.

   The user needs to determine specific policies for the emergency
   telecommunications service, and these should be specified and agreed
   upon in the service level agreement.

5.1 Emergency Service Activation

   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. Also see [2].

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
   combination of service providers, some of which would provide
   emergency capabilities and some of which may not.

   Service providers that 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. Example Emergency Scenarios

   Some example instances for emergency communications are described
   below. These show some different levels of emergency communication
   requirements that need to be supported.

6.1 Local recovery operations

   While mobile radio is the primary mode of communication for police
   and fire brigade operations, there is often a need to supplement
   these capabilities with access to the public telecommunication
   networks. This is particularly needed during the initial stages and
   immediately following a disaster event. These emergency
   communications can be accomplished through use of wireless access
   (cellular phone or PDA) where priority service may be necessary due
   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

   The process of saving lives and providing medical treatment to
   victims is greatly enhanced through the use of data telemetry to
   remotely provide victim vital signs to a central medical center. In
   addition, treatment of victims at the disaster site can be
   significantly accelerated through the use of video telemedicine
   transmissions to remote medical staff. These vital life-saving
   communications can be very effectively supported by an Internet-
   based infrastructure.

6.3 Regional operations

   The magnitude of the event may require recovery support from
   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

   The most serious disaster events can impact national security of a
   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

   There are many critical requirements for emergency
   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 freedom to ensure that determine its own internal
   policies in how the technical capabilities service is actually implemented in fulfillment of Internet-
   based infrastructures are established and sound.

8.
   the SLA.

5.  Security Considerations

   Detailed requirements are given in [5]. Authorized access, security
   protection, and privacy are presented here as general

   Discussion on security
   requirements for emergency services is addressed in Section 2.

6.  References

   1  B. Brewin, "Nation's Networks See Large Volume Spikes After
      Attacks,", Computerworld, September 17, 2001.  Bradner, S., Internet Standards Process ű Revision 3, BCP 9, RFC
   2026, October 1996.

   2  Information  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, Priority÷,
      American National Standard T1.211-1989 (R1999).

   3  Carlberg, K.

   6  ETSI TR 101 300, V2.1.1, "Telecommunications and I. Brown, "Framework Internet Protocol
      Harmonization Over Networks (TIPHON); Description of Technical
      Issues", October 1999

   7  Carlberg, K., Atkinson, R., "IP Telephony Requirements for Supporting IEPS in IP
      Telephony," draft-ietf-ieprep-framework-00 (work in progress),
      February 2002.

   4  Work-in-progress.

   5  Brown, I., "Securing prioritised emergency traffic", draft-brown-
      ieprep-sec-00 (work
      Emergency Telecommunications Service", Internet Draft, Work in progress), February 2002.

   6
      Progress, September, 2002

7.  Acknowledgments

   Many thanks to Fred 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
      Disaster Drills", INET 2000, June 2000.

   9  Braden, R., Clark, D., Scott Bradner, Ian Brown, and Shenkar, S., "Integrated Services in
      the Internet Architecture: an Overview", RFC 1633, June 1994.

   10 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
      Weiss, "An Architecture Ran Atkinson
   for Differentiated Services", RFC 2475,
      December 1998.

   Author their comments on this draft.

8.  Author's Addresses

   Hal Folts, Senior Systems Engineer
      Priority Services - Internet Team, Technology and Programs Folts
   National Communications System
      1-703-607-6186
   701 South Courthouse Road
   Arlington, VA 22204-2198 USA
   Phone: +1 703 607-6186
   Email: foltsh@ncs.gov
   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.