idnits 2.17.1 draft-ietf-ieprep-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 17 looks like a reference -- Missing reference section? '2' on line 261 looks like a reference -- Missing reference section? '3' on line 56 looks like a reference -- Missing reference section? '4' on line 179 looks like a reference -- Missing reference section? '5' on line 201 looks like a reference -- Missing reference section? '6' on line 228 looks like a reference -- Missing reference section? '7' on line 262 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Ieprep 2 Internet Draft H. Folts 3 Document: draft-ietf-ieprep-requirements-01.txt NCS 4 Expires: April 2003 C. Beard 5 UMKC 6 K. Carlberg 7 UCL 8 October 2002 10 Requirements for Emergency Telecommunication 11 Capabilities in the Internet 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 For potential updates to the above required-text see: 34 http://www.ietf.org/ietf/1id-guidelines.txt 36 Abstract 38 This document outlines user requirements for IP-based networks to 39 enable and support an authorized emergency telecommunications service 40 (ETS)for use by authorities to organize and coordinate emergency and 41 disaster relief operations. It provides a basis from which ETS can 42 be negotiated to provide user-acceptable communications. The 43 requirements in this document relate to user expectation and are 44 general, functional, and intended to provide wide latitude in 45 implementation options. This document also provides in-depth 46 background on the state of emergency telecommunication capabilities 47 as they exist today and the motivation for supporting these in IP 48 networks. Specific system requirements involving end-to-end and 49 network issues are presented in [2]. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [3]. 57 Table of Contents 59 1. Introduction...................................................2 60 1.1 Current PSTN Capabilities..................................4 61 1.2 Network Technology Transition..............................5 62 1.3 Purpose and Scope of this Document.........................6 63 2. User Requirements..............................................6 64 3. Emergency Service Applications.................................7 65 3.1 Inelastic applications.....................................8 66 3.2 Elastic applications.......................................8 67 4. Policy Issues..................................................8 68 5. Security Considerations.......................................9 69 6. References....................................................9 70 7. Acknowledgments...............................................9 71 8. Author's Addresses............................................9 72 9. Copyright....................................................10 74 1. Introduction 76 Natural and man-made disasters can occur anywhere, anytime. These 77 include, for example, earthquakes, floods, airplane crashes, and 78 terrorist attacks. While some advance planning is possible for 79 expected disaster events, most disasters happen unexpectedly. 80 Readily available telecommunication capabilities are essential for 81 emergency and disaster relief operations to quickly start saving 82 lives and restoring the community infrastructure. A number of 83 telecommunication facilities can be involved in disaster operations. 84 These include local mobile radio, dedicated satellite systems, 85 transportable capabilities, and the public telecommunications 86 infrastructure. Some of these facilities need to be deployed to the 87 disaster site and very likely may not be immediately available. The 88 public telecommunication services, however, are generally at hand 89 except in the most remote areas. The publicly available capabilities 90 include the traditional telephone network and the Internet, which can 91 both be accessed via wire line, wireless, and various broadband 92 facilities. Disaster recovery operations can significantly benefit 93 from a variety of modes for interchange of critical information to 94 organize and coordinate the emergency activities. Emergency voice 95 communications are supported today by a preferential service through 96 public telephone networks in some countries. The Definition of the 97 International Preference Scheme (ieps) for circuit-switched telephone 98 networks is provided in ITU-T Recommendation E.106 [4]. 100 Now, however, an evolution is taking place in traditional public 101 telecommunication networks toward integrating circuit-switched and 102 packet-based technologies. This promises to provide a rich menu of 103 fully integrated capabilities for handling voice, message, data, and 104 video traffic to greatly enhance disaster recovery operations. These 105 capabilities are being considered in the development of a 106 comprehensive emergency telecommunication service (ETS) to be 107 deployed in the new generation of packet-based public networks. ETS 108 is now the globally recognized term that identifies the new 109 generation of emergency communications capabilities in public 110 telecommunication networks for authorized users to use during 111 emergency and disaster relief operations. 113 The bulk of conventional telephony is accomplished over relatively 114 narrow band wire line or wireless facilities of the public switched 115 telephone network (PSTN). These constrained links are also used for 116 various other applications like instant messaging, email, and 117 telemedicine telemetry. In addition, wideband capabilities for video 118 broadcast, conferencing, and telemedicine will continue to flourish 119 and greatly enhance emergency recovery operations. 121 During serious disaster events, public networking facilities can 122 experience severe stress due to damaged infrastructure and heavy 123 traffic loads. As bandwidth gets severely constrained, it becomes 124 difficult to establish and maintain effective communication sessions. 125 It is essential that disaster recovery operations be able to readily 126 communicate to organize and coordinate essential activities. 127 Authorized emergency communication sessions need to have ready access 128 to available network resources and be given an enhanced probability 129 of successful completion of these critical communications to help 130 save lives and restore community infrastructure. 132 Only people authorized by the appropriate authority are permitted to 133 establish enhanced emergency communication sessions through public 134 networking facilities for facilitating immediate disaster recovery 135 operations. We use the term �enhanced� to refer to additional 136 measures taken to achieve and sustain communications by selected 137 authorized personnel. Those typically authorized are local police, 138 fire, and medical personnel as well as designated government 139 officials from local, regional, and national levels who are 140 responsible for various aspects of disaster recovery operations. 142 All emergency communication sessions should be processed as normal 143 traffic along with all non-emergency traffic when sufficient network 144 bandwidth and resources are available. ONLY when networks reach 145 traffic saturation is there a need for giving emergency communication 146 sessions a higher probability of completion over non-emergency 147 communications. While this occurrence may never happen in the 148 typical Internet-based environment, capabilities for accommodating 149 emergency traffic need to be established in preparation for a serious 150 catastrophe. These provisions should be in place before a potential 151 disaster, even for highly over-provisioned networks. It is better to 152 be prepared ahead of time and not wait for the worst to happen first. 154 The ETS capabilities for handling authorized emergency traffic should 155 be accomplished using existing applications, Internet features, and 156 standards whenever possible. Establishment of new and different 157 standards would be both costly and unlikely to ever be implemented. 158 The desired approach is to adopt existing standards and where needed 159 adapt new standards with any necessary adjustments needed to support 160 preferential treatment of emergency traffic during severe periods of 161 congestion. 163 This document outlines user requirements that need to be met in 164 public and private IP-based networks to enable communications for 165 ETS. These requirements would include support for existing systems 166 that address National Security/Emergency Preparedness (NS/EP) 167 requirements and capabilities. Recovery activities can involve 168 person-to-person communications, group coordination, disaster 169 assessment application execution, remote information retrieval, 170 continuity of government, etc. 172 1.1 Current PSTN Capabilities 174 As a starting point, the model to consider for emergency 175 communication services is the existing service capability in the 176 United States PSTN, the Government Emergency Telecommunications 177 Service (GETS). Some other countries have similar services. GETS is 178 based upon the requirements presented in ITU-T Recommendations E.106 179 [4]. 181 The purpose of GETS is to increase the probability of completion of a 182 telephone call for authorized operations personnel in times of 183 emergencies. It does not guarantee that service will be available, 184 but it does implement a set of functions that increase the likelihood 185 of finding an available circuit to complete a call in the PSTN. 187 The key aspects of GETS are as follows: 189 o Personnel gain access to GETS by calling a specified 190 telephone number and presenting a credit-card type of 191 authentication. 193 o Once being authenticated, the call is completed on a 194 preferential high probability of call completion basis. If 195 calls are initially blocked, they can be queued and 196 switched to alternate carriers. 198 o If fundamental telephone services are compromised, services 199 contracted under GETS are restored first. This is under 200 the provisions of TSP (Telecommunication Service Priority 201 [5]), which is independent of GETS. 203 These features enhance the capability of NS/EP calls to be completed 204 with a high probability in congested networks. GETS will not preempt 205 public telephone calls, nor are there multiple levels of precedence 206 within GETS. 208 1.2 Network Technology Transition 210 The public telecommunication infrastructure is in the process of 211 evolving from the traditional circuit-switched technology to 212 Internet-based packet technology. In developing new ETS capabilities 213 for the future, consideration needs to be given during the period of 214 transitions, which is often referred to as "convergence". 216 During convergence, IP packet-based technology is being integrated 217 into the public telecommunications infrastructure. It is important 218 that the existing basic capability for preferential handling of 219 emergency traffic in current telephone networks is preserved during 220 the transition period. There are four basic configurations that come 221 into play during convergence. These include: 223 o PSTN-to-PSTN via IP backbone 224 o IP telephony to PSTN via gateway 225 o PSTN to IP Telephony via gateway 226 o Pure IP telephony, with no link to the PSTN 228 These are described in ETSI Technical Report [6]. 230 As the IP packet-technology becomes the dominant part of the public 231 telecommunications infrastructure, the prospect of many enhanced 232 capabilities and services comes forth. These could include expanded 233 features in IP-telephony to support an enhanced probability of call 234 completion and additional call processing features. The provision of 235 additional communication services such as Email, instant messaging, 236 telemedicine, white board, and telemetry can provide emergency 237 recovery operations with a rich menu of capabilities. Some time in 238 the future, it is envisioned that the multimedia services will become 239 the dominate mode for emergency communications. 241 1.3 Purpose and Scope of this Document 243 The purpose of this document is to articulate user requirements 244 concerning support for emergency related communications. It provides 245 a set of requirements that need to be met by service(s) to acceptably 246 support emergency communications. The requirements given here are 247 quite general and it is intended that wide latitude be available to 248 service providers and/or vendors to implement emergency services as 249 they consider appropriate. 251 Section 2 provides a summary of the user requirements that identify 252 high-level service capabilities that should be provided. Section 3 253 provides a list of possible emergency communication applications that 254 could be used by emergency personnel. And finally, Section 4 255 identifies policy issues that need to be considered in the deployment 256 and operation of an ETS. 258 System requirements that focus on how user requirements (taken as a 259 whole) are to be satisfied with respect to the network & gateways 260 (i.e., network layer to application layer) are specified in other 261 documents. [2] specifies a set of general system requirements and 262 [7] articulates a set of more specific set of system requirements for 263 IP telephony. 265 2. User Requirements 267 The basic user requirements that need to be considered in providing 268 emergency telecommunication capabilities to support recovery 269 operations from serious disaster situations are summarized as 270 follows. Note that we assume the presence of Service Level 271 Agreements in cases where user requirements cover expectations of 272 service providers: 274 o Users should be able to use public telecommunication 275 resources for supporting emergency communications to help 276 organize and coordinate immediate disaster recovery 277 operations. 279 o Users that access emergency telecommunications service must 280 be authenticated. This should be accomplished in a timely 281 manner. 283 o When networks reach traffic saturation emergency 284 communication sessions should be provided with with a 285 higher probability of completion over non-emergency 286 communications. We assume the presence of a service level 287 agreement to accomplish this latter case. (Note: Sessions 288 identified as emergency communication could be processed as 289 normal traffic along with all non-emergency traffic when 290 sufficient network bandwidth and resources are available.) 292 o Once an emergency communications session is established, 293 the user should be able to complete the session without 294 being interrupted or having the quality of the 295 communications be degraded excessively. 297 o There must exist a mapping association between labels 298 defined by various standards bodies. This mapping will 299 help facilitate inter-working of services in cases where 300 gateways and networks support emergency telecommunications 301 services. 303 o Emergency traffic should be able to transit multiple 304 service providers. The existence of service level 305 agreements determines the extent by which this can be 306 accomplished. 308 o Networks should be able to support a variety of user 309 applications including telephony, video, database access, 310 messaging, telemetry, and web browsing to support emergency 311 operations. 313 o Authorized emergency communications should be protected 314 from intrusion or interference, such as, spoofing, change 315 of content, and denial of service. If the protection 316 cannot be accomplished, then users must be able to detect 317 this failure. 319 o Users should have the option protecting certain sensitive 320 traffic from eavesdropping and the source/destination of 321 some traffic. 323 o Users should have the option of requesting degraded quality 324 of service when normal or expected QoS cannot be achieved. 326 It may not be possible to fulfill all of these requirements 327 immediately and within existing standards, Internet features, and 328 applications. However, provision of the best probability of 329 successful completion of critical emergency communications will 330 significantly enhance the ability of disaster recovery operations to 331 save lives and restore community infrastructure. 333 3. Emergency Service Applications 335 A variety of IP based applications are expected to be used to support 336 disaster recovery and response operations in the future as future 337 services become available to the user. They include not only the 338 basic IP telephony services but expand to include a selection of 339 multimedia services to enhance the ability for saving lives and 340 restoring community infrastructure impacted by serious disaster 341 events. This implies that various upper layer characteristics will 342 be operating over IP. 344 The following list is not exhaustive, but is illustrative of the 345 types of capabilities that could prove to be beneficial: 347 3.1 Inelastic applications 349 o Real time interactive voice (telephony) 350 o Real time interactive video conference 351 o Real time interactive video telemedicine 352 o Real time interactive white board 353 o Streaming audio and video 354 o Telemedicine telemetry for vital sign monitoring 355 o Virtual reality imaging for disaster scene surveillance 357 3.2 Elastic applications 359 o Interactive victim database (e.g. I Am Alive - IAA) 360 o Interactive database services for crisis management 361 o Interactive Web access 362 o Electronic Mail 363 o Instant messaging and presence 364 o File transfer 366 The application of immediate interest to current emergency management 367 organizations is tends to center on IP telephony. In the future, 368 however, it is anticipated that voice communications will be 369 overshadowed by a number of emerging multimedia modes of 370 communication that will significantly benefit emergency recovery 371 operations. 373 4. Policy Issues 375 In the development and deployment of ETS capabilities, a number of 376 policy decisions are required that will define how the services are 377 to be applied, configured, and used. The user policies will be 378 conveyed to the service provider in the service level agreement (SLA) 379 established for the provision of the ETS capabilities. Service 380 providers will have the freedom to determine its own internal 381 policies in how the service is actually implemented in fulfillment of 382 the SLA. 384 5. Security Considerations 386 Discussion on security is addressed in Section 2. 388 6. References 390 1 Bradner, S., Internet Standards Process � Revision 3, BCP 9, RFC 391 2026, October 1996. 393 2 Carlberg, K., Atkinson, R., "General Requirements for Emergency 394 Telecommunications Service", Internet Draft, Work in Progress, 395 September, 2002. 397 3 Bradner, S., �Key Words for Use in RFCs to Indicate Requirement 398 Levels�, BCP 14, RFC 2119, March 1997. 400 4 ITU-T, "Description of an International Emergency Preference 401 Scheme", ITU-T Recommendation E.106, March 2000. 403 5 �Information Interchange Representation of National Security 404 Emergency Preparedness � Telecommunications Service Priority�, 405 American National Standard T1.211-1989 (R1999). 407 6 ETSI TR 101 300, V2.1.1, "Telecommunications and Internet Protocol 408 Harmonization Over Networks (TIPHON); Description of Technical 409 Issues", October 1999 411 7 Carlberg, K., Atkinson, R., "IP Telephony Requirements for 412 Emergency Telecommunications Service", Internet Draft, Work in 413 Progress, September, 2002 415 7. Acknowledgments 417 Many thanks to Fred Baker, Scott Bradner, Ian Brown, and Ran Atkinson 418 for their comments on this draft. 420 8. Author's Addresses 422 Hal Folts 423 National Communications System 424 701 South Courthouse Road 425 Arlington, VA 22204-2198 USA 426 Phone: +1 703 607-6186 427 Email: foltsh@ncs.gov 428 Cory Beard 429 School of Interdisciplinary Computing and Engineering 430 University of Missouri-Kansas City 431 5100 Rockhill Road 432 Kansas City, MO 64110 433 Phone: 1-816-235-1550 434 Email: beardc@umkc.edu 436 Ken Carlberg 437 University College London 438 Department of Computer Science 439 London, WC1E 6BT 440 United Kingdom 441 k.carlberg@cs.ucl.ac.uk 443 9. Copyright 445 "Copyright (C) The Internet Society (date). All Rights 446 Reserved. This document and translations of it may be copied and 447 furnished to others, and derivative works that comment on or 448 otherwise 449 explain it or assist in its implementation may be prepared, copied, 450 published and distributed, in whole or in part, without restriction 451 of 452 any kind, provided that the above copyright notice and this paragraph 453 are included on all such copies and derivative works. However, this 454 document itself may not be modified in any way, such as by removing 455 the copyright notice or references to the Internet Society or other 456 Internet organizations, except as needed for the purpose of 457 developing 458 Internet standards in which case the procedures for copyrights 459 defined 460 in the Internet Standards process must be followed, or as required to 461 translate it into languages other than English. 463 The limited permissions granted above are perpetual and will not be 464 revoked by the Internet Society or its successors or assigns. This 465 document and the information contained herein is provided as an "AS 466 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 467 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 468 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 469 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MERCHANTABILITY 470 OR FITNESS FOR A PARTICULAR PURPOSE.