[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-folts-ieprep-requirements) 00 01

   Ieprep
   Internet Draft                                              H. Folts
   Document: draft-ietf-ieprep-requirements-01.txt                  NCS
   Expires: April 2003                                         C. Beard
                                                                   UMKC
                                                            K. Carlberg
                                                                    UCL
                                                           October 2002


               Requirements for Emergency Telecommunication
                       Capabilities in the Internet


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

   For potential updates to the above required-text see:
   http://www.ietf.org/ietf/1id-guidelines.txt


Abstract

   This document outlines user requirements for IP-based networks to
   enable and support an authorized emergency telecommunications service
   (ETS)for use by authorities to organize and coordinate emergency and
   disaster relief operations.  It provides a basis from which ETS can
   be negotiated to provide user-acceptable communications.  The
   requirements in this document relate to user expectation and are
   general, functional, and intended to provide wide latitude in
   implementation options.  This document also provides in-depth
   background on the state of emergency telecommunication capabilities
   as they exist today and the motivation for supporting these in IP








         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002


   networks.  Specific system requirements involving end-to-end and
   network issues are presented in [2].


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [3].

Table of Contents

   1. Introduction...................................................2
      1.1 Current PSTN Capabilities..................................4
      1.2 Network Technology Transition..............................5
      1.3 Purpose and Scope of this Document.........................6
   2. User Requirements..............................................6
   3. Emergency Service Applications.................................7
      3.1 Inelastic applications.....................................8
      3.2 Elastic applications.......................................8
   4. Policy Issues..................................................8
   5.  Security Considerations.......................................9
   6.  References....................................................9
   7.  Acknowledgments...............................................9
   8.  Author's Addresses............................................9
   9.  Copyright....................................................10


1.   Introduction

   Natural and man-made disasters can occur anywhere, anytime.  These
   include, for example, earthquakes, floods, airplane crashes, and
   terrorist attacks.  While some advance planning is possible for
   expected disaster events, most disasters happen unexpectedly.
   Readily available telecommunication capabilities are essential for
   emergency and disaster relief operations to quickly start saving
   lives and restoring the community infrastructure.  A number of
   telecommunication facilities can be involved in disaster operations.
   These include local mobile radio, dedicated satellite systems,
   transportable capabilities, and the public telecommunications
   infrastructure.  Some of these facilities need to be deployed to the
   disaster site and very likely may not be immediately available.  The
   public telecommunication services, however, are generally at hand
   except in the most remote areas.  The publicly available capabilities
   include the traditional telephone network and the Internet, which can
   both be accessed via wire line, wireless, and various broadband
   facilities.  Disaster recovery operations can significantly benefit
   from a variety of modes for interchange of critical information to
   organize and coordinate the emergency activities.  Emergency voice


Folts                    Expires - April 2003                 [Page 2]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002


   communications are supported today by a preferential service through
   public telephone networks in some countries.  The Definition of the
   International Preference Scheme (ieps) for circuit-switched telephone
   networks is provided in ITU-T Recommendation E.106 [4].

   Now, however, an evolution is taking place in traditional public
   telecommunication networks toward integrating circuit-switched and
   packet-based technologies.  This promises to provide a rich menu of
   fully integrated capabilities for handling voice, message, data, and
   video traffic to greatly enhance disaster recovery operations.  These
   capabilities are being considered in the development of a
   comprehensive emergency telecommunication service (ETS) to be
   deployed in the new generation of packet-based public networks.  ETS
   is now the globally recognized term that identifies the new
   generation of emergency communications capabilities in public
   telecommunication networks for authorized users to use during
   emergency and disaster relief operations.

   The bulk of conventional telephony is accomplished over relatively
   narrow band wire line or wireless facilities of the public switched
   telephone network (PSTN).  These constrained links are also used for
   various other applications like instant messaging, email, and
   telemedicine telemetry.  In addition, wideband capabilities for video
   broadcast, conferencing, and telemedicine will continue to flourish
   and greatly enhance emergency recovery operations.

   During serious disaster events, public networking facilities can
   experience severe stress due to damaged infrastructure and heavy
   traffic loads.  As bandwidth gets severely constrained, it becomes
   difficult to establish and maintain effective communication sessions.
   It is essential that disaster recovery operations be able to readily
   communicate to organize and coordinate essential activities.
   Authorized emergency communication sessions need to have ready access
   to available network resources and be given an enhanced probability
   of successful completion of these critical communications to help
   save lives and restore community infrastructure.

   Only people authorized by the appropriate authority are permitted to
   establish enhanced emergency communication sessions through public
   networking facilities for facilitating immediate disaster recovery
   operations.  We use the term ôenhancedö to refer to additional
   measures taken to achieve and sustain communications by selected
   authorized personnel.  Those typically authorized are local police,
   fire, and medical personnel as well as designated government
   officials from local, regional, and national levels who are
   responsible for various aspects of disaster recovery operations.

   All emergency communication sessions should be processed as normal
   traffic along with all non-emergency traffic when sufficient network


Folts                    Expires - April 2003                 [Page 3]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002


   bandwidth and resources are available.  ONLY when networks reach
   traffic saturation is there a need for giving emergency communication
   sessions a higher probability of completion over non-emergency
   communications.  While this occurrence may never happen in the
   typical Internet-based environment, capabilities for accommodating
   emergency traffic need to be established in preparation for a serious
   catastrophe.  These provisions should be in place before a potential
   disaster, even for highly over-provisioned networks.  It is better to
   be prepared ahead of time and not wait for the worst to happen first.

   The ETS capabilities for handling authorized emergency traffic should
   be accomplished using existing applications, Internet features, and
   standards whenever possible.  Establishment of new and different
   standards would be both costly and unlikely to ever be implemented.
   The desired approach is to adopt existing standards and where needed
   adapt new standards with any necessary adjustments needed to support
   preferential treatment of emergency traffic during severe periods of
   congestion.

   This document outlines user requirements that need to be met in
   public and private IP-based networks to enable communications for
   ETS.  These requirements would include support for existing systems
   that address National Security/Emergency Preparedness (NS/EP)
   requirements and capabilities.  Recovery activities can involve
   person-to-person communications, group coordination, disaster
   assessment application execution, remote information retrieval,
   continuity of government, etc.


1.1     Current PSTN Capabilities

   As a starting point, the model to consider for emergency
   communication services is the existing service capability in the
   United States PSTN, the Government Emergency Telecommunications
   Service (GETS).  Some other countries have similar services.  GETS is
   based upon the requirements presented in ITU-T Recommendations E.106
   [4].

   The purpose of GETS is to increase the probability of completion of a
   telephone call for authorized operations personnel in times of
   emergencies.  It does not guarantee that service will be available,
   but it does implement a set of functions that increase the likelihood
   of finding an available circuit to complete a call in the PSTN.

   The key aspects of GETS are as follows:

          o Personnel gain access to GETS by calling a specified
            telephone number and presenting a credit-card type of
            authentication.


Folts                    Expires - April 2003                 [Page 4]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002



          o Once being authenticated, the call is completed on a
            preferential high probability of call completion basis.  If
            calls are initially blocked, they can be queued and
            switched to alternate carriers.

          o If fundamental telephone services are compromised, services
            contracted under GETS are restored first.  This is under
            the provisions of TSP (Telecommunication Service Priority
            [5]), which is independent of GETS.

   These features enhance the capability of NS/EP calls to be completed
   with a high probability in congested networks.  GETS will not preempt
   public telephone calls, nor are there multiple levels of precedence
   within GETS.

1.2    Network Technology Transition

   The public telecommunication infrastructure is in the process of
   evolving from the traditional circuit-switched technology to
   Internet-based packet technology.  In developing new ETS capabilities
   for the future, consideration needs to be given during the period of
   transitions, which is often referred to as "convergence".

   During convergence, IP packet-based technology is being integrated
   into the public telecommunications infrastructure.  It is important
   that the existing basic capability for preferential handling of
   emergency traffic in current telephone networks is preserved during
   the transition period.  There are four basic configurations that come
   into play during convergence.  These include:

          o  PSTN-to-PSTN via IP backbone
          o  IP telephony to PSTN via gateway
          o  PSTN to IP Telephony via gateway
          o  Pure IP telephony, with no link to the PSTN

   These are described in ETSI Technical Report [6].

   As the IP packet-technology becomes the dominant part of the public
   telecommunications infrastructure, the prospect of many enhanced
   capabilities and services comes forth.  These could include expanded
   features in IP-telephony to support an enhanced probability of call
   completion and additional call processing features.  The provision of
   additional communication services such as Email, instant messaging,
   telemedicine, white board, and telemetry can provide emergency
   recovery operations with a rich menu of capabilities.  Some time in
   the future, it is envisioned that the multimedia services will become
   the dominate mode for emergency communications.



Folts                    Expires - April 2003                 [Page 5]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002


1.3     Purpose and Scope of this Document

   The purpose of this document is to articulate user requirements
   concerning support for emergency related communications.  It provides
   a set of requirements that need to be met by service(s) to acceptably
   support emergency communications.  The requirements given here are
   quite general and it is intended that wide latitude be available to
   service providers and/or vendors to implement emergency services as
   they consider appropriate.

   Section 2 provides a summary of the user requirements that identify
   high-level service capabilities that should be provided.  Section 3
   provides a list of possible emergency communication applications that
   could be used by emergency personnel.  And finally, Section 4
   identifies policy issues that need to be considered in the deployment
   and operation of an ETS.

   System requirements that focus on how user requirements (taken as a
   whole) are to be satisfied with respect to the network & gateways
   (i.e., network layer to application layer) are specified in other
   documents.  [2] specifies a set of general system requirements and
   [7] articulates a set of more specific set of system requirements for
   IP telephony.

2.   User Requirements

   The basic user requirements that need to be considered in providing
   emergency telecommunication capabilities to support recovery
   operations from serious disaster situations are summarized as
   follows.  Note that we assume the presence of Service Level
   Agreements in cases where user requirements cover expectations of
   service providers:

          o Users should be able to use public telecommunication
            resources for supporting emergency communications to help
            organize and coordinate immediate disaster recovery
            operations.

          o Users that access emergency telecommunications service must
            be authenticated.  This should be accomplished in a timely
            manner.

          o When networks reach traffic saturation emergency
            communication sessions should be provided with with a
            higher probability of completion over non-emergency
            communications.  We assume the presence of a service level
            agreement to accomplish this latter case. (Note: Sessions
            identified as emergency communication could be processed as



Folts                    Expires - April 2003                 [Page 6]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002


            normal traffic along with all non-emergency traffic when
            sufficient network bandwidth and resources are available.)

          o Once an emergency communications session is established,
            the user should be able to complete the session without
            being interrupted or having the quality of the
            communications be degraded excessively.

          o There must exist a mapping association between labels
            defined by various standards bodies.  This mapping will
            help facilitate inter-working of services in cases where
            gateways and networks support emergency telecommunications
            services.

          o Emergency traffic should be able to transit multiple
            service providers.  The existence of service level
            agreements determines the extent by which this can be
            accomplished.

          o Networks should be able to support a variety of user
            applications including telephony, video, database access,
            messaging, telemetry, and web browsing to support emergency
            operations.

          o Authorized emergency communications should be protected
            from intrusion or interference, such as, spoofing, change
            of content, and denial of service.  If the protection
            cannot be accomplished, then users must be able to detect
            this failure.

          o Users should have the option protecting certain sensitive
            traffic from eavesdropping and the source/destination of
            some traffic.

          o Users should have the option of requesting degraded quality
            of service when normal or expected QoS cannot be achieved.

   It may not be possible to fulfill all of these requirements
   immediately and within existing standards, Internet features, and
   applications.  However, provision of the best probability of
   successful completion of critical emergency communications will
   significantly enhance the ability of disaster recovery operations to
   save lives and restore community infrastructure.


3.   Emergency Service Applications

   A variety of IP based applications are expected to be used to support
   disaster recovery and response operations in the future as future


Folts                    Expires - April 2003                 [Page 7]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002


   services become available to the user.  They include not only the
   basic IP telephony services but expand to include a selection of
   multimedia services to enhance the ability for saving lives and
   restoring community infrastructure impacted by serious disaster
   events.  This implies that various upper layer characteristics will
   be operating over IP.

   The following list is not exhaustive, but is illustrative of the
   types of capabilities that could prove to be beneficial:

3.1     Inelastic applications

          o Real time interactive voice (telephony)
          o Real time interactive video conference
          o Real time interactive video telemedicine
          o Real time interactive white board
          o Streaming audio and video
          o Telemedicine telemetry for vital sign monitoring
          o Virtual reality imaging for disaster scene surveillance

3.2     Elastic applications

          o Interactive victim database (e.g.  I Am Alive - IAA)
          o Interactive database services for crisis management
          o Interactive Web access
          o Electronic Mail
          o Instant messaging and presence
          o File transfer

   The application of immediate interest to current emergency management
   organizations is tends to center on IP telephony.  In the future,
   however, it is anticipated that voice communications will be
   overshadowed by a number of emerging multimedia modes of
   communication that will significantly benefit emergency recovery
   operations.


4.   Policy Issues

   In the development and deployment of ETS capabilities, a number of
   policy decisions are required that will define how the services are
   to be applied, configured, and used.  The user policies will be
   conveyed to the service provider in the service level agreement (SLA)
   established for the provision of the ETS capabilities.  Service
   providers will have the freedom to determine its own internal
   policies in how the service is actually implemented in fulfillment of
   the SLA.




Folts                    Expires - April 2003                 [Page 8]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002



5.  Security Considerations

   Discussion on security is addressed in Section 2.


6.  References

   1  Bradner, S., Internet Standards Process û Revision 3, BCP 9, RFC
   2026, October 1996.

   2  Carlberg, K., Atkinson, R., "General Requirements for Emergency
      Telecommunications Service", Internet Draft, Work in Progress,
      September, 2002.

   3  Bradner, S., ôKey Words for Use in RFCs to Indicate Requirement
      Levelsö, BCP 14, RFC 2119, March 1997.

   4  ITU-T, "Description of an International Emergency Preference
      Scheme", ITU-T Recommendation E.106, March 2000.

   5  ôInformation Interchange Representation of National Security
      Emergency Preparedness û Telecommunications Service Priorityö,
      American National Standard T1.211-1989 (R1999).

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

   7  Carlberg, K., Atkinson, R., "IP Telephony Requirements for
      Emergency Telecommunications Service", Internet Draft, Work in
      Progress, September, 2002


7.  Acknowledgments

   Many thanks to Fred Baker, Scott Bradner, Ian Brown, and Ran Atkinson
   for their comments on this draft.


8.  Author's Addresses

   Hal Folts
   National Communications System
   701 South Courthouse Road
   Arlington, VA 22204-2198 USA
   Phone: +1 703 607-6186
   Email: foltsh@ncs.gov



Folts                    Expires - April 2003                 [Page 9]


         Rqmts for Emergency Telecom Capabilities In Internet Oct. 2002


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

   Ken Carlberg
   University College London
   Department of Computer Science
   London, WC1E 6BT
   United Kingdom
   k.carlberg@cs.ucl.ac.uk



9.  Copyright

   "Copyright (C) The Internet Society (date).  All Rights
   Reserved.  This document and translations of it may be copied and
   furnished to others, and derivative works that comment on or
   otherwise
   explain it or assist in its implementation may be prepared, copied,
   published and distributed, in whole or in part, without restriction
   of
   any kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing
   Internet standards in which case the procedures for copyrights
   defined
   in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.  This
   document and the information contained herein is provided as an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.






Folts                    Expires - April 2003                [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/