idnits 2.17.1 draft-ietf-ieprep-requirements-00.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 is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (June 2002) is 7985 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 172 looks like a reference -- Missing reference section? '2' on line 549 looks like a reference -- Missing reference section? '3' on line 472 looks like a reference -- Missing reference section? '4' on line 230 looks like a reference -- Missing reference section? '5' on line 660 looks like a reference -- Missing reference section? '6' on line 386 looks like a reference -- Missing reference section? '7' on line 437 looks like a reference -- Missing reference section? '8' on line 443 looks like a reference -- Missing reference section? '9' on line 484 looks like a reference -- Missing reference section? '10' on line 510 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Hal Folts 3 INTERNET DRAFT National Communications System 4 Expires: December December 2002 Cory Beard 5 Univ. of Missouri-Kansas City 6 June 2002 8 Requirements for Emergency Telecommunication 9 Capabilities in the Internet 11 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. 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 24 months and may be updated, replaced, or obsoleted by other documents 25 at any 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 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document outlines requirements that need to be met in IP-based 37 networks to enable and support communications for National 38 Security/Emergency Preparedness (NS/EP) operations. It provides a 39 basis from which an emergency telecommunications service can be 40 negotiated and provides a set of requirements that should be met for 41 acceptable emergency telecommunication capabilities for disaster 42 recovery operations. The focus here is on network requirements, 43 rather than requirements for particular applications. The 44 requirements are general, functional, and are intended to provide 45 wide latitude in implementation options for service providers. 47 Table of Contents 49 1. Introduction...................................................2 50 1.1 Current PSTN Capabilities..................................4 51 1.2 Purpose and Scope of this Document.........................5 52 2. General Requirements...........................................6 53 2.2 Dependability..............................................6 54 2.3 Authorized Access..........................................7 55 2.4 Security Protection........................................7 56 2.5 Privacy....................................................8 57 3. Technical Requirements.........................................8 58 3.1 Identification of Emergency Traffic........................8 59 3.2 Signaling for Resource Requests............................8 60 3.3 Better Then Best Effort Service............................9 61 4. Special Requirements...........................................9 62 4.1 Application-Specific Support...............................9 63 4.2 Traffic Types.............................................11 64 5. Policy Decisions..............................................11 65 5.1 Emergency Service Activation..............................12 66 5.2 Restoration Procedures....................................12 67 5.3 Preemption................................................12 68 5.4 Cooperation Between Service Providers.....................12 69 6. Example Emergency Scenarios...................................13 70 6.1 Local recovery operations.................................13 71 6.2 Medical operations........................................13 72 6.3 Regional operations.......................................13 73 6.4 National operations.......................................14 74 7. Conclusions...................................................14 75 8. Security Considerations.......................................14 76 References.......................................................14 78 1. Introduction 80 Natural and man-made disasters can happen anywhere, anytime. These 81 include, for example, earthquakes, floods, airplane crashes, and 82 terrorist attacks. While some advance planning is possible for 83 expected disaster events, most disasters happen unexpectedly. 85 Readily available telecommunication capabilities are essential for 86 emergency recovery operations to quickly start saving lives and 87 restoring the community infrastructure. A number of 88 telecommunication facilities can be involved in disaster recovery 89 operations. These include local mobile radio, dedicated satellite 90 systems, transportable capabilities, and the public 91 telecommunications infrastructure. Some of these facilities need to 92 be deployed to the disaster site and very likely may not be 93 immediately available. The public telecommunication services, 94 however, are generally at hand except in the most remote areas. The 95 publicly available capabilities include the traditional telephone 96 network and the Internet, which can both be accessed via wire line, 97 wireless, and various broadband facilities. Disaster recovery 98 operations can significantly benefit from a variety of modes for 99 interchange of critical information to organize and coordinate the 100 emergency activities. Emergency voice communications are supported 101 today by a preferential service through public telephone networks in 102 some countries. Now, however, an evolution is taking place in 103 traditional public telecommunication networks toward integrating 104 circuit-switched and packet-based technologies. This promises to 105 provide a rich menu of fully integrated capabilities for handling 106 voice, message, data, and video traffic to greatly enhance disaster 107 recovery operations. 109 Mostly voice traffic using either VoIP or conventional telephony is 110 used today for emergency communications over wireline and wireless 111 facilities. However, narrowband modes can also be effectively 112 applied, including instant messaging, email, and telemedicine 113 telemetry. In addition, wideband capabilities for video broadcast, 114 conferencing, and telemedicine will also greatly enhance emergency 115 recovery operations. 117 During serious disaster events, public networking facilities can 118 experience severe stress due to damaged infrastructure and heavy 119 traffic loads. As bandwidth gets severely constrained, it becomes 120 difficult to establish and maintain effective communication 121 sessions. It is essential that disaster recovery operations be able 122 to readily communicate to organize and coordinate essential 123 activities. Authorized emergency communication sessions need to have 124 immediate access to available network resources and be given a high 125 probability of successful completion of these critical 126 communications to help save lives and restore community 127 infrastructure. 129 Only people authorized by the appropriate authority are permitted to 130 establish emergency communication sessions through public networking 131 facilities for facilitating immediate disaster recovery operations. 132 Those typically authorized are local police, fire, and medical 133 personnel as well as designated government officials from local, 134 regional, and national levels who are responsible for various 135 aspects of disaster recovery operations. 137 All emergency communication sessions should be processed as normal 138 traffic along with all non-emergency traffic when sufficient network 139 bandwidth and resources are available. ONLY when networks reach 140 traffic saturation is there a need for giving emergency 141 communication sessions a higher probability of completion over non- 142 emergency communications. While this occurrence may never happen in 143 the typical Internet-based environment, capabilities for 144 preferential handling of emergency traffic need to be established in 145 preparation for a serious catastrophe. These provisions should be in 146 place before a potential doomsday disaster, even for highly over- 147 provisioned networks. It is better to be prepared ahead of time and 148 not wait for the worst to happen first. 150 The telecommunication capabilities for handling authorized emergency 151 traffic should be accomplished using existing applications and 152 standards whenever possible. Establishment of new and different 153 standards would be both costly and unlikely to ever be implemented. 154 The desired approach is to adopt existing standards and where needed 155 adapt new standards with any necessary adjustments needed to support 156 preferential treatment of emergency traffic during severe periods of 157 congestion. 159 This document outlines requirements that need to be met in public 160 and private IP-based networks to enable communications for National 161 Security/Emergency Preparedness (NS/EP) operations. Recovery 162 activities can involve person-to-person communications, group 163 coordination, disaster assessment application execution, remote 164 information retrieval, continuity of government, etc. 166 From a network perspective, processing communications can be 167 particularly difficult even if the network infrastructure has not 168 been the target of a terrorist or affected by a natural disaster. 169 This is because there can be a drastic surge in the network load in 170 response to a disaster. In recent years the Public Switched 171 Telephone Network (PSTN) has experienced load levels three to five 172 times normal immediately after an event [1], and the same is 173 expected for the Internet, especially as IP telephony becomes more 174 prevalent. 176 1.1 Current PSTN Capabilities 178 As a starting point, the model to consider for emergency 179 communication services is the existing service capability in the 180 United States PSTN, the Government Emergency Telecommunications 181 Service (GETS). Some other countries have similar services. 183 The purpose of GETS is to increase the probability of completion of 184 a telephone call for authorized operations personnel in times of 185 emergencies. It does not guarantee that service will be available, 186 but it does implement a set of functions that increase the 187 likelihood of finding an available circuit to complete a call in the 188 PSTN. 190 The key aspects of GETS are as follows: 192 o Personnel gain access to GETS by calling a specified telephone 193 number and presenting a credit-card type of authentication. 195 o Having authenticated themselves, the call is completed on a 196 preferential high probability of completion basis. If calls 197 are initially blocked, they can be queued and switched to 198 alternate carriers. 200 o If fundamental telephone services are compromised, services 201 contracted under GETS are restored first. This is under the 202 provisions of TSP (Telecommunication Service Priority [2]), 203 which is independent of GETS. 205 These features enhance the capability of NS/EP calls to be completed 206 with a high probability in congested networks. GETS will not 207 preempt public telephone calls, nor are there multiple levels of 208 precedence within GETS. 210 The approach of GETS is based on a preferential, high probability of 211 completion, treatment model. This model may also be used by 212 providers of Internet-based network services. 214 1.2 Purpose and Scope of this Document 216 The purpose of this document is to provide a basis from which 217 emergency service capabilities can be specified and negotiated 218 between network service providers and customers. It provides a set 219 of requirements that would need to be met for a service to 220 acceptably support emergency communications. The focus here is on 221 network requirements, rather than requirements for particular 222 applications. For particular requirements related to IP Telephony, 223 see [3]. 225 More importantly, however, the requirements given here are quite 226 general and it is intended that wide latitude be available to 227 service providers to implement emergency services as they consider 228 appropriate. In [4], recommendations are provided as to how best to 229 implement these services, but in this document requirements are 230 stated so that service providers need not necessarily follow [4]. 232 Section 2 provides general requirements that give high-level service 233 capabilities that should be provided. Section 3 then provides a 234 minimal set of specific technical requirements for meeting the 235 general requirements. Section 4 gives special considerations that 236 may optionally be addressed in an agreement for emergency services. 237 And finally, Section 5 provides a list of policy decisions that need 238 to be made and explained to customers by a service provider, but no 239 specific requirements are given for policy issues. 241 2. General Requirements 243 This section outlines five requirements for services that aim to 244 provide emergency communications for the Internet-based 245 infrastructure (or any telecommunication medium for that manner). 246 They pertain to the ability to begin communications, complete 247 communications successfully, and conduct them in an authorized and 248 private manner. 250 2.1 Availability 252 The most fundamental requirement for emergency telecommunication 253 services is that emergency-related users must have a high likelihood 254 of network resources being available to them when they need them. 255 Authorized users must have a high probability of being able to 256 initiate and complete a communication session. 258 Two interpretations of the concept of "high availability" could be 259 applied, either in a relative sense or an absolute sense. Such 260 options on interpretation give latitude in implementation 261 possibilities for emergency services. The first interprets "high 262 availability" in a preferential or relative sense. Authorized users 263 would have preferred access to resources over normal users. A 264 service provider would implement mechanisms to identify and treat 265 emergency traffic in special ways. Such an approach would allow a 266 service provider to avoid having to meet specific availability 267 targets (e.g., 95% availability) through an assurance that is given 268 to emergency customers that their traffic is being treated 269 preferentially. If the network is stressed, availability for 270 emergency users may decrease, but it would still be relatively 271 higher (even much higher) than for normal users. 273 In the second interpretation, high availability would mean absolute 274 availability levels that would be provided regardless of the network 275 operating conditions. Service providers may choose to provide high 276 availability levels through overprovisioning even when the network 277 is stressed. They could choose to avoid using any mechanisms to 278 identify or preferentially treat emergency traffic, because 279 emergency traffic requirements would be met by the default operation 280 of their network. 282 2.2 Dependability 284 Authorized users must not only be able to initiate communication 285 sessions; they must also be able to successfully complete their 286 intended activities. While PSTN services basically provide such 287 dependability by default, communications through the Internet might 288 be affected by a variety of network operating conditions, such as 289 congestion or link failures. An emergency telecommunication service 290 needs to protect authorized communications from being affected by 291 those conditions, at least to the extent that an emergency 292 communication session can still be conducted acceptably. 293 Definitions of acceptable performance will vary depending on the 294 application. 296 2.3 Authorized Access 298 Mechanisms must be implemented so that only authorized users have 299 access to emergency telecommunications services. Such authorization 300 could be PIN-based or based on assignment of cryptographic keys [5]. 301 Authorization protects network resources from excessive use and 302 abuse. The two purposes for this requirement are to restrict usage 303 of network resources only to those who are allowed to use them and 304 to enable proper billing. Even when using an overprovisioning 305 approach where emergency users are not provided special services, 306 proper billing necessitates authorized access. 308 In today's public telephone networks a credit-card process is used. 309 This means entry of 32 digits of information to complete 310 establishment of a communication session. This is cumbersome and 311 time-consuming. With future technology in an Internet-based 312 infrastructure there is a need for a more time-responsive and 313 streamlined mechanism for rapid authentication. 315 Such authorization mechanisms should be flexible enough to provide 316 various levels of restriction and authorization depending on the 317 expectations of a particular service or customer. For example, it 318 might be desirable to provide access to emergency telecommunication 319 services differently after a hurricane where the emergency was 320 caused by a natural disaster as compared to after a terrorist attack 321 that was caused by humans. In the hurricane scenario, members of 322 the general public might be given access (e.g., at a lower 323 precedence level than emergency response organizations) where after 324 a terrorist attack security concerns might necessitate highly 325 restrictive access to emergency services. 327 Further requirements and recommended procedures are given in [5]. 329 2.4 Security Protection 331 The overall problem of Internet security is being pursued by 332 appropriate and expert resources in the IETF and elsewhere. However, 333 specific problems of emergency traffic need to be considered. 335 Emergency traffic needs to be protected against intrusion, spoofing, 336 and specifically, denial of service. If overall security measures 337 that are established do not satisfy these specific requirements, 338 additional consideration should be given to protection specifically 339 focused on emergency traffic. This is discussed further in [5]. 341 2.5 Privacy 343 Some emergency communications will have a requirement that they not 344 be susceptible to viewing or modification by others, due to the 345 sensitive and urgent nature of emergency response activities. An 346 emergency telecommunications service should be able to protect the 347 integrity of all emergency user communications and have options to 348 encrypt certain user traffic. However, due to urgency and short-term 349 meaningfulness of the content at initial stages of disaster 350 response, encryption will have limited application. 352 3. Technical Requirements 354 The following technical requirements represent the functions that 355 need to be fulfilled to enable the general requirements listed above 356 to be realized. For several of the requirements below, it is 357 assumed that networks will experience temporary scarcity of 358 resources, especially because of damaged infrastructure and high 359 demand immediately following a disaster. If a service provider 360 employs an over provisioning approach to provide emergency services 361 so that resources are never scarce, some of the following 362 requirements might not be necessary. 364 3.1 Identification of Emergency Traffic 366 Emergency traffic should be recognized in the forwarding plane. An 367 emergency telecommunication service should have procedures by which 368 emergency traffic is marked so that it can be identified throughout 369 the network. The decisions about who does such marking (i.e., end 370 users or the network), where it occurs, who recognizes such marking, 371 whether re-marking might occur, and at what layer or layers marking 372 is implemented are left to the discretion of the policy makers and 373 specified in service level agreements. Standardized mechanisms, 374 however, should be utilized. 376 3.2 Signaling for Resource Requests 378 Emergency traffic should be recognized in the control plane. For 379 applications where sessions need to be established or network 380 resources reserved, signaling mechanisms can be used to support the 381 differentiation of emergency signaling messages. 383 3.3 Better Then Best Effort Service 385 The default best-effort forwarding behavior available in existing 386 routers as standardized in [6] does not provide performance 387 assurances. This is especially true for emergency services where 388 severe congestion that accompanies disasters can cause the 389 performance of best-effort delivery to degrade well below acceptable 390 levels. 392 Quality of service for emergency telecommunication services does not 393 necessarily mean better quality of voice/video as compared to what 394 is available to normal users. The same QoS classes, which are 395 already defined for normal traffic, can be utilized for emergency 396 traffic as well. 398 The fundamental quality of service requirement for emergency traffic 399 is this - better than best effort service. Service providers have 400 the freedom to implement special quality of service mechanisms to 401 meet this requirement, but other approaches may be effective as 402 well. 404 Better than best effort service is provided to emergency traffic so 405 that it will receive assured performance levels that are at or above 406 a minimum performance level. Without such a requirement, the 407 dependability requirement outlined above could not be met. 409 Emergency traffic that suffers degraded QoS, however, should not be 410 terminated but should be allowed to continue. Disaster response 411 operations must be given the best chance to communicate, even if 412 with difficulty. 414 4. Special Requirements 416 In addition to the general and technical requirements given above, 417 this section provides additional requirements that may optionally be 418 requested for particular service agreements. They primarily involve 419 the specification of the particular approach that is being used by 420 service providers for particular networks, applications, and types 421 of traffic. 423 4.1 Application-Specific Support 425 The requirements in this document are for network layer mechanisms 426 to support emergency services. In general, these network layer 427 mechanisms will provide support to the rich array of applications 428 that could be used for emergency response operations. Specific 429 applications, however, may have additional requirements to be 430 acceptable for emergency users. 432 Such requirements might include additional signalling or mechanisms 433 to provide preferential performance or dependability to authorized 434 users. Examples of applications include the following. 436 o Voice on IP, using such signaling architectures as H.323 or SIP 437 [7]. 439 o Shared real-time whiteboard. 441 o Instant messaging and presence. 443 o Databases such as the Japanese "I am Alive" [8] service, for 444 communication with persons not involved in the crisis. 446 o Database services for managing the crisis, including 447 calendaring, contact management, order and trouble report 448 management, legal services, medical services, etc. 450 o Electronic mail. 452 o Telemedicine, victim observation video, and vital-sign 453 telemetry 455 o Damage assessment applications. 457 o File transfer. 459 o World Wide Web. 461 This document does not address specific requirements for these 462 applications. The focus of this document is to provide requirements 463 for network service providers. Requirements for the applications 464 should be met by content providers and end users. However, network 465 service providers may wish to provide network-based services that 466 could improve the performance of particular applications, for 467 example by providing web caching. 469 Of specific interest to current emergency management organizations 470 are IP Telephony and Voice on IP. Further requirements and 471 recommended procedures for these applications, in particular, are 472 given in [3]. In the future, however, it is anticipated that voice 473 communications will be overshadowed by a number of other multimedia 474 modes of communication that will significantly benefit emergency 475 recovery operations. 477 4.2 Traffic Types 479 Consideration should be given to the different traffic types in 480 supporting the different multimedia applications for emergency 481 telecommunication services. The three types of traffic that may be 482 treated in distinctive ways are as follows. 484 o Inelastic traffic - As defined in [9], inelastic traffic is 485 traffic which has a firm delay bound. If packets arrive after 486 a maximum acceptable delay, the packets are essentially 487 worthless to the receiver. Real-time audio and video are 488 examples of inelastic traffic. 490 o Interactive elastic traffic - Elastic applications are 491 generally those which wait for data to arrive and do not 492 discard it if it is late. This does not mean that applications 493 are insensitive to delay, however, because such delays could 494 hurt application performance significantly. In particular, 495 interactive elastic traffic requires reasonable delays because 496 of the user interaction that is involved. Examples of 497 interactive elastic traffic include HTTP and instant messaging 498 traffic. 500 o Bulk transfer elastic traffic - Some elastic applications, 501 however, do not involve direct user interaction. In such 502 cases, delay is not so much a concern as average throughput. 503 Bulk transfers can have large variations in delay as long as an 504 expected average throughput is obtained. For example, if a 505 file can be downloaded in 100 seconds, it does not matter if 506 for part of the transfer the throughput was virtually zero. 507 Examples of bulk transfer traffic are FTP and SMTP. 509 As an example, service providers may wish to provide service 510 assurances for inelastic traffic using Diffserv [10] but use 511 overprovisioning for both types of elastic traffic. 513 5. Policy Decisions 515 The above general and technical requirements provide wide latitude 516 for creativity on the part of service providers to implement 517 emergency services. In addition to meeting the requirements above, 518 a series of policy decisions should be made in the implementation of 519 emergency services. No particular approach is prescribed regarding 520 these policies. However, the policies used by a service provider to 521 address the following issues should be clearly defined and 522 communicated. 524 The user needs to determine specific policies for the emergency 525 telecommunications service, and these should be specified and agreed 526 upon in the service level agreement. 528 5.1 Emergency Service Activation 530 Providers of an emergency service should specify whether emergency 531 treatment is always available within the network or whether the 532 service is only activated upon declaration of emergency conditions 533 by an appropriate authority. Service providers may also choose to 534 provide a minimal service that is available at all times, but which 535 could be expanded once an emergency declaration was made. 537 5.2 Restoration Procedures 539 Service providers should describe the restoration procedures they 540 will use when substantial damage is experienced in their network. 541 They should provide plans and estimates in advance of how damaged 542 facilities will affect the availability of emergency services and, 543 if a critical relationship exists, how prioritized restoration of 544 those vital facilities will be accomplished. Service providers may, 545 of course, choose to rely upon rerouting mechanisms that would make 546 the restoration procedures they use irrelevant to the continued 547 dependability of emergency services. The only concern in that case 548 is when damage could be so extensive that rerouting mechanisms would 549 be ineffective. Also see [2]. 551 5.3 Preemption 553 Service providers may wish to provide resources for emergency 554 communications by interrupting particular non-emergency traffic 555 flows. If such an approach is used, this should be explicitly 556 stated and details should be given on how preemption is carried out. 557 Regulatory guidelines in some jurisdictions may prohibit the use of 558 preemption to support emergency traffic. 560 5.4 Cooperation Between Service Providers 562 Emergency users will only be concerned with the quality of the end- 563 to-end communications they are provided. However, it is possible 564 that no one particular service provider will be able to support that 565 service end-to-end. Emergency services could be carried over a 566 combination of service providers, some of which would provide 567 emergency capabilities and some of which may not. 569 Service providers that do provide emergency services may choose to 570 provide services that are only operative within their networks and 571 are independent of other service providers. Alternatively, service 572 providers may employ mechanisms to cooperate with other service 573 providers to provide emergency services. This would result in a 574 considerable portion of the end-to-end path being administered in a 575 cooperative fashion. If so, service providers should specify the 576 mechanisms they would use and the extent to which they would 577 cooperate with other service providers to support emergency 578 services. 580 6. Example Emergency Scenarios 582 Some example instances for emergency communications are described 583 below. These show some different levels of emergency communication 584 requirements that need to be supported. 586 6.1 Local recovery operations 588 While mobile radio is the primary mode of communication for police 589 and fire brigade operations, there is often a need to supplement 590 these capabilities with access to the public telecommunication 591 networks. This is particularly needed during the initial stages and 592 immediately following a disaster event. These emergency 593 communications can be accomplished through use of wireless access 594 (cellular phone or PDA) where priority service may be necessary due 595 to congestion. Some mobile radio systems interface with public 596 networks, but their use is often discouraged or avoided because of 597 limited bandwidth availability in the frequency allocation. 598 Communications outside the immediate local radio coverage area are 599 often required to request additional resources from other areas and 600 to notify and coordinate operations with regional (e.g. county and 601 state) and national authorities. Public telecommunications services 602 provide at-hand capability to immediately support these critical 603 emergency communications 605 6.2 Medical operations 607 The process of saving lives and providing medical treatment to 608 victims is greatly enhanced through the use of data telemetry to 609 remotely provide victim vital signs to a central medical center. In 610 addition, treatment of victims at the disaster site can be 611 significantly accelerated through the use of video telemedicine 612 transmissions to remote medical staff. These vital life-saving 613 communications can be very effectively supported by an Internet- 614 based infrastructure. 616 6.3 Regional operations 618 The magnitude of the event may require recovery support from 619 resources outside of the immediate area of impact. Critical 620 information is provided for authorities to proclaim a disaster 621 crisis and activate vital support resources. 622 Regional emergency operations centers would need immediate and 623 effective telecommunication capabilities to rapidly organize and 624 coordinate support from elsewhere regionally, nationally, or 625 internationally. Public telecommunication resources are essential to 626 support these emergency activities. 628 6.4 National operations 630 The most serious disaster events can impact national security of a 631 country. Therefore, immediate action is required by government 632 officials to organize and coordinate the highest level of emergency 633 support resources. With a serious threat to national security, 634 actions to ensure continuity of government must be initiated. These 635 types of activities need to not only have priority treatment for 636 emergency communications in the public telecommunications domain, 637 but they also require protection against eavesdropping of 638 confidential/sensitive information. In addition, locations of source 639 and destination of some critical national security traffic needs 640 protection. While these communications can often be supported 641 directly by dedicated government networks, public telecommunication 642 facilities provide an essential alternate capability. 644 7. Conclusions 646 There are many critical requirements for emergency 647 telecommunications that need to be addressed as outlined above. 648 These are important ingredients to the total solution required for 649 effective and comprehensive emergency telecommunication capabilities 650 in a public Internet-based telecommunication service infrastructure. 651 Technical solutions are neither proposed nor suggested, so that full 652 consideration and innovation will be used in seeking effective 653 solutions. There are many other procedural, operational, policy, 654 regulatory, and full systems considerations that also need to be 655 addressed to ensure that the technical capabilities of Internet- 656 based infrastructures are established and sound. 658 8. Security Considerations 660 Detailed requirements are given in [5]. Authorized access, security 661 protection, and privacy are presented here as general security 662 requirements for emergency services in Section 2. 664 References 666 1 B. Brewin, "Nation's Networks See Large Volume Spikes After 667 Attacks,", Computerworld, September 17, 2001. 669 2 Information Interchange Representation of National Security 670 Emergency Preparedness � Telecommunications Service Priority, 671 American National Standard T1.211-1989 (R1999). 673 3 Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP 674 Telephony," draft-ietf-ieprep-framework-00 (work in progress), 675 February 2002. 677 4 Work-in-progress. 679 5 Brown, I., "Securing prioritised emergency traffic", draft-brown- 680 ieprep-sec-00 (work in progress), February 2002. 682 6 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 683 June 1995. 685 7 Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 686 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 688 8 "IAA System (I Am Alive): The Experiences of the Internet 689 Disaster Drills", INET 2000, June 2000. 691 9 Braden, R., Clark, D., and Shenkar, S., "Integrated Services in 692 the Internet Architecture: an Overview", RFC 1633, June 1994. 694 10 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. 695 Weiss, "An Architecture for Differentiated Services", RFC 2475, 696 December 1998. 698 Author Addresses 700 Hal Folts, Senior Systems Engineer 701 Priority Services - Internet Team, Technology and Programs 702 National Communications System 703 1-703-607-6186 704 foltsh@ncs.gov 706 Cory Beard 707 School of Interdisciplinary Computing and Engineering 708 University of Missouri-Kansas City 709 5100 Rockhill Road 710 Kansas City, MO 64110 711 1-816-235-1550 712 beardc@umkc.edu