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]
