Internet Engineering Task Force Cory Beard INTERNET DRAFT Univ. of Missouri-Kansas City Expires: November 2002 May 2002 Network Requirements for Internet Emergency Preparedness Services draft-beard-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 template from which an emergency service can be negotiated and provides a set of requirements that should be met for acceptable emergency communication services. The focus here is on network requirements, rather than requirements for particular applications. The requirements are general and are intended to provide wide latitude in implementation options for service providers. Table of Contents 1. Introduction...................................................2 1.1 Current PSTN Capabilities..................................3 1.2 Purpose and Scope of this Document.........................3 1.3 Fundamental Approaches.....................................4 2. General Requirements...........................................4 2.1 Availability...............................................5 2.2 Dependability..............................................5 2.3 Authorized Access..........................................6 2.4 Privacy....................................................6 3. Technical Requirements.........................................6 3.1 Identification of Priority Traffic.........................7 Beard Expires - November 2002 [Page 1] Internet-Draft Emergency Requirements May 2002 3.2 Signalling for Resource Requests...........................7 3.3 Better Then Best Effort Service............................7 4. Special Requirements...........................................7 4.1 Traffic Types..............................................8 4.2 Network Areas..............................................8 4.3 Application-Specific Support...............................9 5. Policy Decisions..............................................10 5.1 Services Always Available or Only Enabled Upon Emergency Declaration...................................................10 5.2 Restoration Procedures....................................10 5.3 Preemption................................................10 5.4 Cooperation Between Service Providers.....................10 6. Security Considerations.......................................11 References.......................................................11 Author's Address.................................................12 1. Introduction 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. These activities seek to return the population to normal living conditions after serious disasters and events, such as floods, earthquakes, hurricanes, and terrorist attacks. Communication activities can involve person-to-person communications, group coordination, disaster assessment application execution, remote information retrieval, etc. Disaster situations can occur unexpectedly at any time and at any place. These events often cause significant damage to the community infrastructure, including network infrastructure, and severely disrupt daily living. Recovery requires rapid response by local authorities, immediate reaction from utility service providers, and support from medical, construction, fire, and police resources. Effective communications are essential to facilitate the coordination of lifesaving activities concurrent with reestablishing control in the disaster area. Following a disaster, immediate response operations focus on saving lives, protecting property, and meeting basic human needs. From a network perspective, 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. Beard Expires - November 2002 [Page 2] Internet-Draft Emergency Requirements May 2002 1.1 Current PSTN Capabilities One model to consider for emergency communication services is the existing service in the United States PSTN, the Government Emergency Telecommunications Service (GETS). Some other countries have equivalent services. The purpose of GETS is to increase the probability that phone service will be available to selected government agency personnel in times of emergencies. It does not guarantee that service will be available, but it does implement a series of functions that increase the likelihood of finding an available circuit. The key aspects of GETS are as follows: o Personnel gain access to GETS by calling a specified telephone number and presenting a credit-card type of authentication. o Having authenticated themselves, the call is completed on a preferential basis. If calls are initially blocked, they can be queued and can use alternate carriers. o If fundamental telephone services are compromised, services contracted under GETS are restored first. These features enhance the capability of NS/EP calls to be completed in congested networks. GETS will not preempt public telephone calls, nor are there levels of precedence within GETS. The approach of GETS is based on a preferential treatment model. This model may also be used by providers of Internet network services. Other models could also be used and are introduced in a later section. 1.2 Purpose and Scope of this Document The purpose of this document is to provide a template from which an emergency service 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 [2]. More importantly, however, the requirements given here are quite general and it is intended that wide latitude be available to service providers to implement services as they consider appropriate. In [3], 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 [3]. Beard Expires - November 2002 [Page 3] Internet-Draft Emergency Requirements May 2002 Section 2 provides general requirements that give high-level service capabilities that must 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 to be made and explained to customers by a service provider, but no specific requirements are given for policy issues. 1.3 Fundamental Approaches Before the requirements are discussed, it is first useful, however, to briefly outline the basic approaches that could be used by a provider in offering emergency services. These are as follows. o Best Effort Provisioning - Service providers may wish to provide emergency services by using sufficient capacity such that emergency services are provided acceptable quality without using additional mechanisms beyond best effort traffic handling [4]. One way this could be implemented would be to size links such that no congestion would be experienced, even if all traffic that would traverse a link would be multiplexed together. Another approach could be to use a VPN-based approach to partition the capacity to at least keep emergency traffic from experiencing congestion. In either approach, a service provider must be able to provide sufficient confidence that congestion would not be seen by emergency traffic even in the heavily overloaded conditions following disasters. o Service Guarantees - Service providers may wish to provide emergency services that give some measure of service guarantees. For example, they may provide specified upper bounds on delay for audio or video traffic. They would agree to meet such requirements for a certain percentage of packets regardless of network conditions. o Preferential Treatment - In contrast to service guarantees, however, service providers may wish to only provide services that in some way provide preferential treatment for emergency traffic without explicit guarantees. If network congestion increases dramatically, the performance for emergency traffic might degrade right along with normal traffic, but would still receive some form of preference. Although the traffic would not be immune to the effects of overloads, GETS has used this approach and it has proven to be acceptable. 2. General Requirements This section outlines four requirements for services that aim to provide emergency communications for the Internet (or any communication medium for that manner). They pertain to the ability Beard Expires - November 2002 [Page 4] Internet-Draft Emergency Requirements May 2002 to begin communications, complete communications successfully, and conduct them in an authorized and private manner. 2.1 Availability The most fundamental requirement for emergency communication services is that emergency-related users must have a high likelihood of network resources being available to them when they need them. Priority users must have a high probability of being able to initiate 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. Priority users would have preferred access to resources over normal users. A service provider would implement mechanisms to identify and treat priority 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 priority customers that their traffic is being treated preferentially. If the network is stressed, availability for priority 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 best effort provisioning even when the network is stressed. They could choose to avoid using any mechanisms to identify or preferentially treat priority traffic, because priority traffic requirements would be met by the default operation of their network. 2.2 Dependability Priority users must not only be able to initiate communication sessions; they must also be able to successfully complete their intended activities. While PSTN communications provide such dependability by default, Internet communications might be affected by a variety of network operating conditions, such as congestion or link failures. An emergency communication service must protect priority communications from being affected by those conditions, at least to the extent that the communication session can still be conducted acceptably. Definitions of acceptable performance will vary depending on the application. Beard Expires - November 2002 [Page 5] Internet-Draft Emergency Requirements May 2002 2.3 Authorized Access Mechanisms must be implemented so that only authorized users have access to priority communications 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 a best effort provisioning approach where emergency users are not provided special services, proper billing necessitates authorized access. 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 communications 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 priority level than emergency response organizations) where after a terrorist attack security concerns might necessitate highly restrictive access to emergency services. In the case of 911-type services, authorization is also applicable. In such cases, users self-authorize themselves by deciding that they have an urgent need that warrants special attention. If they abuse the service, they also understand that they could be held accountable for such abuse. Further requirements and recommended procedures are given in [5]. 2.4 Privacy Emergency communications will frequently 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 communications service should be able to protect the integrity of user communication with options to encrypt user traffic. 3. Technical Requirements The following technical requirements represent the mechanisms that must be in operation 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 a best effort provisioning approach to provide emergency Beard Expires - November 2002 [Page 6] Internet-Draft Emergency Requirements May 2002 services so that resources are never scarce, some of the following requirements will not be necessary. 3.1 Identification of Priority Traffic Priority traffic must be recognized in the forwarding plane. An emergency communication service must 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 service provider. 3.2 Signalling for Resource Requests Priority traffic must be recognized in the control plane. For applications where sessions need to be established or network resources reserved, signalling mechanisms must be used that support the differentiation of priority signalling messages. 3.3 Better Then Best Effort Service The default best-effort forwarding behavior available in existing routers as standardized in [4] 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 communication 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 priority 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 guaranteed performance levels that are at or above a minimum performance level. Without such a requirement, the dependability requirement outlined above could not be met. 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 Beard Expires - November 2002 [Page 7] Internet-Draft Emergency Requirements May 2002 the specification of the particular approach that is being used by service providers for particular networks, applications, and types of traffic. 4.1 Traffic Types A service provider may choose to provide an emergency service that supports different traffic types in different ways with customized levels of availability and dependability. The three types of traffic that may be treated in distinctive ways are as follows. o Inelastic traffic - As defined in [6], 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 of how service providers may wish to support the above types of traffic, they may wish to provide service guarantees for inelastic traffic using Diffserv [7] but use best effort provisioning for both types of elastic traffic. 4.2 Network Areas It is not expected that service providers use the same approach to supporting emergency traffic in all parts of their network. They are free to provide services differently based on whether traffic is traversing core, distribution, or access layers of the service provider's network. Specifications may also differ depending on the type of access technology that is being used (e.g., LAN, wireless, or DSL). Beard Expires - November 2002 [Page 8] Internet-Draft Emergency Requirements May 2002 For example, a service provider may wish to identify and provide specialized treatment of emergency traffic in access networks and use best effort treatment in core networks. 4.3 Application-Specific Support In addition to the above requirements for network layer mechanisms to support priority services, specific applications may have additional requirements to be acceptable for emergency users. Such requirements might include additional signalling or mechanisms to provide preferential performance or dependability to priority users. Examples of applications include the following. o Voice on IP, using such signaling architectures as H.323 or SIP [8]. o Shared real-time whiteboard. o Instant messaging and presence. o Databases such as the Japanese "I am Alive" [9] 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 Damage assessment applications. o File transfer. o World Wide Web. However, this document does not address requirements for 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 which 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 [2]. Beard Expires - November 2002 [Page 9] Internet-Draft Emergency Requirements May 2002 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 addressing the following issues should be clearly defined and communicated. 5.1 Services Always Available or Only Enabled Upon Emergency Declaration 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. 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 Beard Expires - November 2002 [Page 10] Internet-Draft Emergency Requirements May 2002 combination of service providers, some of which would provide emergency capabilities and some of which may not. Service providers which do provide emergency services may choose to provide services that are only operative within their networks and are independent of other service providers. Alternatively, service providers may employ mechanisms to cooperate with other service providers to provide emergency services. This would result in a considerable portion of the end-to-end path being administered in a cooperative fashion. If so, service providers should specify the mechanisms they would use and the extent to which they would cooperate with other service providers to support emergency services. 6. Security Considerations Authorized access and privacy are presented here as general security requirements for emergency services in Section 2. Further requirements are given in [5]. References 1 B. Brewin, "Nation's Networks See Large Volume Spikes After Attacks,", Computerworld, September 17, 2001. 2 Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP Telephony," draft-ietf-ieprep-framework-00 (work in progress), February 2002. 3 Work-in-progress. 4 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. 5 Brown, I., "Securing prioritised emergency traffic", draft-brown- ieprep-sec-00 (work in progress), February 2002. 6 Braden, R, Clark, D., and Shenkar, S., "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. 7 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. 8 Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 9 , "IAA System (I Am Alive): The Experiences of the Internet Disaster Drills", INET 2000, June 2000. Beard Expires - November 2002 [Page 11] Internet-Draft Emergency Requirements May 2002 Author's Address 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 Beard Expires - November 2002 [Page 12]