[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                              Hal Folts
INTERNET DRAFT                          National Communications System
Expires: December December 2002                             Cory Beard
                                         Univ. of Missouri-Kansas City
                                                             June 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.

   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
   basis from which an emergency telecommunications service 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. The
   requirements are general, functional, and are intended to provide
   wide latitude in implementation options for service providers.







Folts & Beard             Expires - December 2002              [Page 1]


Internet-Draft          Emergency Requirements                 June 2002


   Table of Contents

   1. Introduction...................................................2
      1.1 Current PSTN Capabilities..................................4
      1.2 Purpose and Scope of this Document.........................5
   2. General Requirements...........................................6
      2.2 Dependability..............................................6
      2.3 Authorized Access..........................................7
      2.4 Security Protection........................................7
      2.5 Privacy....................................................8
   3. Technical Requirements.........................................8
      3.1 Identification of Emergency Traffic........................8
      3.2 Signaling for Resource Requests............................8
      3.3 Better Then Best Effort Service............................9
   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
   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

   Natural and man-made disasters can happen 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 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


Folts & Beard             Expires - December 2002               [Page 2]


Internet-Draft          Emergency Requirements                 June 2002


   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. 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 is
   used today for 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 for video broadcast,
   conferencing, and telemedicine will also 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 access to available network resources and be given a high
   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 emergency communication sessions through public networking
   facilities for facilitating immediate disaster recovery operations.
   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 communications. While this occurrence may never happen in


Folts & Beard             Expires - December 2002               [Page 3]


Internet-Draft          Emergency Requirements                 June 2002


   the typical Internet-based environment, capabilities for
   preferential handling of 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 networks. It is better to be prepared ahead of time and
   not wait for the worst to happen first.

   The telecommunication capabilities for handling authorized emergency
   traffic should be accomplished using existing applications 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 requirements that need to be met in public
   and private IP-based networks to enable communications for National
   Security/Emergency Preparedness (NS/EP) operations.  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.

   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:


Folts & Beard             Expires - December 2002               [Page 4]


Internet-Draft          Emergency Requirements                 June 2002



      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 high probability of 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]),
        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.

   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



Folts & Beard             Expires - December 2002               [Page 5]


Internet-Draft          Emergency Requirements                 June 2002


   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

Folts & Beard             Expires - December 2002               [Page 6]


Internet-Draft          Emergency Requirements                 June 2002


   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.


Folts & Beard             Expires - December 2002               [Page 7]


Internet-Draft          Emergency Requirements                 June 2002


   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.



Folts & Beard             Expires - December 2002               [Page 8]


Internet-Draft          Emergency Requirements                 June 2002


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.


Folts & Beard             Expires - December 2002               [Page 9]


Internet-Draft          Emergency Requirements                 June 2002



   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.





Folts & Beard             Expires - December 2002              [Page 10]


Internet-Draft          Emergency Requirements                 June 2002


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.




Folts & Beard             Expires - December 2002              [Page 11]


Internet-Draft          Emergency Requirements                 June 2002


   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


Folts & Beard             Expires - December 2002              [Page 12]


Internet-Draft          Emergency Requirements                 June 2002


   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

Folts & Beard             Expires - December 2002              [Page 13]


Internet-Draft          Emergency Requirements                 June 2002


   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 to ensure that the technical capabilities of Internet-
   based infrastructures are established and sound.

8. Security Considerations

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

References

   1  B. Brewin, "Nation's Networks See Large Volume Spikes After
      Attacks,", Computerworld, September 17, 2001.

Folts & Beard             Expires - December 2002              [Page 14]


Internet-Draft          Emergency Requirements                 June 2002




   2  Information Interchange Representation of National Security
      Emergency Preparedness รป Telecommunications Service Priority,
      American National Standard T1.211-1989 (R1999).

   3  Carlberg, K. and I. Brown, "Framework 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 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
      Disaster Drills", INET 2000, June 2000.

   9  Braden, R., Clark, D., 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 for Differentiated Services", RFC 2475,
      December 1998.

   Author Addresses

      Hal Folts, Senior Systems Engineer
      Priority Services - Internet Team, Technology and Programs
      National Communications System
      1-703-607-6186
      foltsh@ncs.gov

      Cory Beard
      School of Interdisciplinary Computing and Engineering
      University of Missouri-Kansas City
      5100 Rockhill Road
      Kansas City, MO  64110
      1-816-235-1550
      beardc@umkc.edu



Folts & Beard             Expires - December 2002              [Page 15]