Engineering Task Force HalDraft H. Folts INTERNET DRAFT National Communications SystemDocument: draft-ietf-ieprep-requirements-01.txt NCS Expires: December December 2002 CoryApril 2003 C. Beard Univ. of Missouri-Kansas City JuneUMKC K. Carlberg UCL October 2002 Requirements for Emergency Telecommunication Capabilities in the Internet <draft-ietf-ieprep-requirements-00.txt>Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document outlines user requirements that need to be met infor IP-based networks to enable and support communications for National Security/Emergency Preparedness (NS/EP)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 an emergency telecommunications serviceETS 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.to provide user-acceptable communications. The requirements in this document relate to user expectation and are general, functional, and areintended to provide wide latitude in implementation optionsoptions. This document also provides in-depth background on the state of emergency telecommunication capabilities as they exist today and the motivation for service providers.supporting these in IP networks. Specific system requirements involving end-to-end and network issues are presented in . 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 . 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.........................5Document.........................6 2. General Requirements...........................................6 2.2 Dependability..............................................6 2.3 Authorized Access..........................................7 2.4 Security Protection........................................7 2.5 Privacy....................................................8User Requirements..............................................6 3. Technical Requirements.........................................8 3.1 Identification ofEmergency Traffic........................8Service Applications.................................7 3.1 Inelastic applications.....................................8 3.2 Signaling for Resource Requests............................8 3.3 Better Then Best Effort Service............................9Elastic applications.......................................8 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.....................12Issues..................................................8 5. Security Considerations.......................................9 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.......................................14References....................................................9 7. Conclusions...................................................14Acknowledgments...............................................9 8. Security Considerations.......................................14 References.......................................................14Author's Addresses............................................9 9. Copyright....................................................10 1. Introduction Natural and man-made disasters can happenoccur 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 recoveryand disaster relief operations to quickly start saving lives and restoring the community infrastructure. A number of telecommunication facilities can be involved in disaster recoveryoperations. 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 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 . 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 telephonyThese 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 used today fornow the globally recognized term that identifies the new generation of emergency communications over wireline and wireless facilities. However, narrowband modes can also be effectively applied, including instant messaging, email, and telemedicine telemetry. In addition, widebandcapabilities in public telecommunication networks for video broadcast, conferencing, and telemedicine will also greatly enhanceauthorized users to use during emergency recoveryand disaster relief operations. DuringThe 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 immediateready access to available network resources and be given a highan 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 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- emergencynon-emergency communications. While this occurrence may never happen in the typical Internet-based environment, capabilities for preferential handling ofaccommodating emergency traffic need to be established in preparation for a serious catastrophe. These provisions should be in place before a potential doomsdaydisaster, even for highly over- provisionedover-provisioned networks. It is better to be prepared ahead of time and not wait for the worst to happen first. The telecommunicationETS capabilities for handling authorized emergency traffic should be accomplished using existing applicationsapplications, 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) operations.requirements and capabilities. 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 , 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. GETS is based upon the requirements presented in ITU-T Recommendations E.106 . 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. o Having authenticated themselves,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 ),), 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 approach of GETSpublic telecommunication infrastructure is based on a preferential, high probability of completion, treatment model. This model may also be used by providersin the process of evolving from the traditional circuit-switched technology to Internet-based network services. 1.2 Purpose and Scope of this Document The purposepacket technology. In developing new ETS capabilities for the future, consideration needs to be given during the period of this documenttransitions, which is often referred to provide a basis from which emergency service capabilities can be specified and negotiated between network service providers and customers.as "convergence". During convergence, IP packet-based technology is being integrated into the public telecommunications infrastructure. It provides a set of requirementsis important that would need to be metthe existing basic capability for a servicepreferential 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 . 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 acceptablysupport 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. 1.3 Purpose and Scope of this Document The focus herepurpose of this document is on network requirements, rather thanto articulate user requirements concerning support for particular applications. For particular requirementsemergency related communications. It provides a set of requirements that need to IP Telephony, see . More importantly, however, thebe 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. In , 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 .Section 2 provides generala summary of the user requirements that giveidentify high-level service capabilities that should be provided. Section 3 thenprovides a minimal setlist of specific technical requirements for meeting the general requirements. Section 4 gives special considerationspossible emergency communication applications that may optionallycould be addressed in an agreement forused by emergency services.personnel. And finally, Section 5 provides a list of4 identifies policy decisionsissues that need to be madeconsidered in the deployment and explained to customers by a service provider, but no specific requirements are given for policy issues. 2. General Requirements This section outlines fiveoperation of an ETS. System requirements for servicesthat aim to provide emergency communications for the Internet-based infrastructure (or any telecommunication medium for that manner). They pertainfocus on how user requirements (taken as a whole) are to be satisfied with respect to the abilitynetwork & gateways (i.e., network layer to begin communications, complete communications successfully, and conduct themapplication layer) are specified in an authorizedother documents.  specifies a set of general system requirements and private manner. 2.1 Availability The most fundamental requirement 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 services iscapabilities to support recovery operations from serious disaster situations are summarized as follows. Note that emergency-related users must have a high likelihoodwe assume the presence of network resources being available to them when they need them. Authorized users must have a high probabilityService Level Agreements in cases where user requirements cover expectations of beingservice providers: o Users should be able to initiateuse public telecommunication resources for supporting emergency communications to help organize and complete a communication session. Two interpretations of the concept of "high availability" couldcoordinate immediate disaster recovery operations. o Users that access emergency telecommunications service must be applied, eitherauthenticated. This should be accomplished in a relative sense or an absolute sense. Such options on interpretation give latitude in implementation possibilities fortimely manner. o When networks reach traffic saturation emergency services. The first interprets "high availability" incommunication sessions should be provided with with a preferential or relative sense. Authorized users would have preferred access to resourceshigher probability of completion over normal users. Anon-emergency communications. We assume the presence of a service provider would implement mechanismslevel agreement to identify and treataccomplish this latter case. (Note: Sessions identified as emergency communication could be processed as normal traffic in special ways. Such an approach would allow a service provider to avoid having to meet specific availability targets (e.g., 95% availability) throughalong with all non-emergency traffic when sufficient network bandwidth and resources are available.) o Once an assurance that is given toemergency customers that their trafficcommunications session is being treated preferentially. Ifestablished, the network is stressed, availability for emergency users may decrease, but it would stilluser should 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 chooseable to provide high availability levels through overprovisioning even whencomplete the network is stressed. They could choose to avoid using any mechanisms to identifysession without being interrupted or preferentially treat emergency traffic, because emergency traffic requirements would be met byhaving the default operationquality of their network. 2.2 Dependability Authorized users must not onlythe communications be able to initiate communication sessions; theydegraded excessively. o There must alsoexist 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 successfully complete their intended activities. While PSTN services basically provide such dependability by default, communications through the Internet might be affected by a varietytransit multiple service providers. The existence of network operating conditions, such as congestion or link failures. An emergency telecommunicationservice needs to protect authorized communications from being affected by those conditions, at least tolevel agreements determines the extent that an emergency communication sessionby which this can stillbe conducted acceptably. Definitions of acceptable performance will vary depending on the application. 2.3 Authorized Access Mechanisms mustaccomplished. o Networks should be implemented so that only authorized users have accessable to support a variety of user applications including telephony, video, database access, messaging, telemetry, and web browsing to support emergency telecommunications services. Such authorization couldoperations. o Authorized emergency communications should be PIN-basedprotected from intrusion or based on assignmentinterference, such as, spoofing, change of cryptographic keys . Authorization protects network resources from excessive usecontent, and abuse. The two purposes for this requirement are to restrict usagedenial of network resources only to those who are allowedservice. If the protection cannot be accomplished, then users must be able to use themdetect this failure. o Users should have the option protecting certain sensitive traffic from eavesdropping 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 digitsthe source/destination of information to complete establishmentsome traffic. o Users should have the option 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 expectationsrequesting degraded quality of a particularservice when normal or customer. For example, it mightexpected QoS cannot 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 mightachieved. It may not 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 accesspossible to emergency services. Furtherfulfill all of these requirements immediately and recommended procedures are given in . 2.4 Security Protection The overall problem ofwithin existing standards, Internet security is being pursued by appropriate and expert resources in the IETFfeatures, and elsewhere.applications. However, specific problemsprovision of the best probability of successful completion of critical emergency traffic need to be considered. Emergency traffic needscommunications will significantly enhance the ability of disaster recovery operations to be protected against intrusion, spoofing,save lives and specifically, denialrestore community infrastructure. 3. Emergency Service Applications A variety of service. If overall security measures thatIP based applications are established do not satisfy these specific requirements, additional consideration should be givenexpected to protection specifically focused on emergency traffic. This is discussed further in . 2.5 Privacy Some emergency communications will have a requirement that they notbe susceptible to viewing or modification by others, dueused to the sensitivesupport disaster recovery and urgent nature of emergencyresponse activities. An emergency telecommunications service should be able to protectoperations in the integrity of all emergency user communications and have optionsfuture as future services become available to encrypt certain user traffic. However, duethe user. They include not only the basic IP telephony services but expand to urgency and short-term meaningfulnessinclude a selection of multimedia services to enhance the content at initial stages ofability for saving lives and restoring community infrastructure impacted by serious disaster response, encryptionevents. This implies that various upper layer characteristics will have limited application. 3. Technical Requirementsbe operating over IP. The following technical requirements representlist is not exhaustive, but is illustrative of the functionstypes of capabilities that needcould prove to be fulfilledbeneficial: 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 enable the general requirements listed abovecurrent emergency management organizations is tends to be realized. For several ofcenter on IP telephony. In the requirements below,future, however, it is assumedanticipated that networksvoice communications will experience temporary scarcity of resources, especially because of damaged infrastructure and high demand immediately following a disaster. Ifbe overshadowed by a service provider employs an over provisioning approach to provide emergency services so that resources are never scarce, somenumber of the following requirements might not be necessary. 3.1 Identificationemerging multimedia modes 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 socommunication that it can be identified throughoutwill significantly benefit emergency recovery operations. 4. Policy Issues In the network. Thedevelopment and deployment of ETS capabilities, a number of policy decisions about who does such marking (i.e., end users orare required that will define how the network), where it occurs, who recognizes such marking, whether re-marking might occur, and at what layer or layers marking is implementedservices are leftto the discretion of the policy makersbe applied, configured, and specifiedused. The user policies will be conveyed to the service provider in the service level agreements. Standardized mechanisms, however, should be utilized. 3.2 Signalingagreement (SLA) established for Resource Requests Emergency traffic should be recognized inthe control plane. For applications where sessions need to be established or network resources reserved, signaling mechanisms can be used to support the differentiationprovision of emergency signaling messages. 3.3 Better Then Best Effort Service The default best-effort forwarding behavior available in existing routers as standardized in  does not provide performance assurances. This is especially true for emergency services where severe congestion that accompanies disasters can causethe 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.ETS capabilities. 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 mechanismswill provide support to the rich array of applications that could be used for emergency response operations. Specific applications, however, mayhave additional requirements to be acceptable for emergency users. 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 . o Shared real-time whiteboard. o Instant messaging and presence. o Databases such as the Japanese "I am Alive"  service, for communication with persons not involved in the crisis. o Database services for managingthe 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 . 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. 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 , 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  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. 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 . 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 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 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 addressedfreedom to ensure thatdetermine its own internal policies in how the technical capabilitiesservice is actually implemented in fulfillment of Internet- based infrastructures are established and sound. 8.the SLA. 5. Security Considerations Detailed requirements are given in . Authorized access, security protection, and privacy are presented here as generalDiscussion on security requirements for emergency servicesis addressed in Section 2. 6. References 1 B. Brewin, "Nation's Networks See Large Volume Spikes After Attacks,", Computerworld, September 17, 2001.Bradner, S., Internet Standards Process ű Revision 3, BCP 9, RFC 2026, October 1996. 2 InformationCarlberg, 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,Priority÷, American National Standard T1.211-1989 (R1999). 3 Carlberg, K.6 ETSI TR 101 300, V2.1.1, "Telecommunications and I. Brown, "FrameworkInternet Protocol Harmonization Over Networks (TIPHON); Description of Technical Issues", October 1999 7 Carlberg, K., Atkinson, R., "IP Telephony Requirements 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 (workEmergency Telecommunications Service", Internet Draft, Work in progress), February 2002. 6Progress, September, 2002 7. Acknowledgments Many thanks to Fred 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.,Scott Bradner, Ian Brown, 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 ArchitectureRan Atkinson for Differentiated Services", RFC 2475, December 1998. Authortheir comments on this draft. 8. Author's Addresses Hal Folts, Senior Systems Engineer Priority Services - Internet Team, Technology and ProgramsFolts National Communications System 1-703-607-6186701 South Courthouse Road Arlington, VA 22204-2198 USA Phone: +1 703 607-6186 Email: firstname.lastname@example.org 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: email@example.com Ken Carlberg University College London Department of Computer Science London, WC1E 6BT United Kingdom firstname.lastname@example.org 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.