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 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]