idnits 2.17.1 draft-beard-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: ---------------------------------------------------------------------------- == 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 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 (May 2002) is 8017 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 101 looks like a reference -- Missing reference section? '2' on line 452 looks like a reference -- Missing reference section? '3' on line 153 looks like a reference -- Missing reference section? '4' on line 327 looks like a reference -- Missing reference section? '5' on line 522 looks like a reference -- Missing reference section? '6' on line 366 looks like a reference -- Missing reference section? '7' on line 393 looks like a reference -- Missing reference section? '8' on line 420 looks like a reference -- Missing reference section? '9' on line 426 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Cory Beard 3 INTERNET DRAFT Univ. of Missouri-Kansas City 4 Expires: November 2002 May 2002 6 Network Requirements for Internet Emergency Preparedness Services 7 draft-beard-ieprep-requirements-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document outlines requirements that need to be met in IP-based 33 networks to enable and support communications for National 34 Security/Emergency Preparedness (NS/EP) operations. It provides a 35 template from which an emergency service can be negotiated and 36 provides a set of requirements that should be met for acceptable 37 emergency communication services. The focus here is on network 38 requirements, rather than requirements for particular applications. 39 The requirements are general and are intended to provide wide 40 latitude in implementation options for service providers. 42 Table of Contents 44 1. Introduction...................................................2 45 1.1 Current PSTN Capabilities..................................3 46 1.2 Purpose and Scope of this Document.........................3 47 1.3 Fundamental Approaches.....................................4 48 2. General Requirements...........................................4 49 2.1 Availability...............................................5 50 2.2 Dependability..............................................5 51 2.3 Authorized Access..........................................6 52 2.4 Privacy....................................................6 53 3. Technical Requirements.........................................6 54 3.1 Identification of Priority Traffic.........................7 55 3.2 Signalling for Resource Requests...........................7 56 3.3 Better Then Best Effort Service............................7 57 4. Special Requirements...........................................7 58 4.1 Traffic Types..............................................8 59 4.2 Network Areas..............................................8 60 4.3 Application-Specific Support...............................9 61 5. Policy Decisions..............................................10 62 5.1 Services Always Available or Only Enabled Upon Emergency 63 Declaration...................................................10 64 5.2 Restoration Procedures....................................10 65 5.3 Preemption................................................10 66 5.4 Cooperation Between Service Providers.....................10 67 6. Security Considerations.......................................11 68 References.......................................................11 69 Author's Address.................................................12 71 1. Introduction 73 This document outlines requirements that need to be met in public 74 and private IP-based networks to enable communications for National 75 Security/Emergency Preparedness (NS/EP) operations. These 76 activities seek to return the population to normal living conditions 77 after serious disasters and events, such as floods, earthquakes, 78 hurricanes, and terrorist attacks. Communication activities can 79 involve person-to-person communications, group coordination, 80 disaster assessment application execution, remote information 81 retrieval, etc. 83 Disaster situations can occur unexpectedly at any time and at any 84 place. These events often cause significant damage to the community 85 infrastructure, including network infrastructure, and severely 86 disrupt daily living. Recovery requires rapid response by local 87 authorities, immediate reaction from utility service providers, and 88 support from medical, construction, fire, and police resources. 89 Effective communications are essential to facilitate the 90 coordination of lifesaving activities concurrent with reestablishing 91 control in the disaster area. Following a disaster, immediate 92 response operations focus on saving lives, protecting property, and 93 meeting basic human needs. 95 From a network perspective, communications can be particularly 96 difficult even if the network infrastructure has not been the target 97 of a terrorist or affected by a natural disaster. This is because 98 there can be a drastic surge in the network load in response to a 99 disaster. In recent years the Public Switched Telephone Network 100 (PSTN) has experienced load levels three to five times normal 101 immediately after an event [1], and the same is expected for the 102 Internet, especially as IP telephony becomes more prevalent. 104 1.1 Current PSTN Capabilities 106 One model to consider for emergency communication services is the 107 existing service in the United States PSTN, the Government 108 Emergency Telecommunications Service (GETS). Some other countries 109 have equivalent services. 111 The purpose of GETS is to increase the probability that phone 112 service will be available to selected government agency personnel in 113 times of emergencies. It does not guarantee that service will be 114 available, but it does implement a series of functions that increase 115 the likelihood of finding an available circuit. 117 The key aspects of GETS are as follows: 119 o Personnel gain access to GETS by calling a specified telephone 120 number and presenting a credit-card type of authentication. 122 o Having authenticated themselves, the call is completed on a 123 preferential basis. If calls are initially blocked, they can 124 be queued and can use alternate carriers. 126 o If fundamental telephone services are compromised, services 127 contracted under GETS are restored first. 129 These features enhance the capability of NS/EP calls to be completed 130 in congested networks. GETS will not preempt public telephone 131 calls, nor are there levels of precedence within GETS. 133 The approach of GETS is based on a preferential treatment model. 134 This model may also be used by providers of Internet network 135 services. Other models could also be used and are introduced in a 136 later section. 138 1.2 Purpose and Scope of this Document 140 The purpose of this document is to provide a template from which an 141 emergency service can be specified and negotiated between network 142 service providers and customers. It provides a set of requirements 143 that would need to be met for a service to acceptably support 144 emergency communications. The focus here is on network 145 requirements, rather than requirements for particular applications. 146 For particular requirements related to IP Telephony, see [2]. 148 More importantly, however, the requirements given here are quite 149 general and it is intended that wide latitude be available to 150 service providers to implement services as they consider 151 appropriate. In [3], recommendations are provided as to how best to 152 implement these services, but in this document requirements are 153 stated so that service providers need not necessarily follow [3]. 155 Section 2 provides general requirements that give high-level service 156 capabilities that must be provided. Section 3 then provides a 157 minimal set of specific technical requirements for meeting the 158 general requirements. Section 4 gives special considerations that 159 may optionally be addressed in an agreement for emergency services. 160 And finally, Section 5 provides a list of policy decisions that need 161 to be made and explained to customers by a service provider, but no 162 specific requirements are given for policy issues. 164 1.3 Fundamental Approaches 166 Before the requirements are discussed, it is first useful, however, 167 to briefly outline the basic approaches that could be used by a 168 provider in offering emergency services. These are as follows. 170 o Best Effort Provisioning - Service providers may wish to 171 provide emergency services by using sufficient capacity such 172 that emergency services are provided acceptable quality without 173 using additional mechanisms beyond best effort traffic handling 174 [4]. One way this could be implemented would be to size links 175 such that no congestion would be experienced, even if all 176 traffic that would traverse a link would be multiplexed 177 together. Another approach could be to use a VPN-based 178 approach to partition the capacity to at least keep emergency 179 traffic from experiencing congestion. In either approach, a 180 service provider must be able to provide sufficient confidence 181 that congestion would not be seen by emergency traffic even in 182 the heavily overloaded conditions following disasters. 184 o Service Guarantees - Service providers may wish to provide 185 emergency services that give some measure of service 186 guarantees. For example, they may provide specified upper 187 bounds on delay for audio or video traffic. They would agree 188 to meet such requirements for a certain percentage of packets 189 regardless of network conditions. 191 o Preferential Treatment - In contrast to service guarantees, 192 however, service providers may wish to only provide services 193 that in some way provide preferential treatment for emergency 194 traffic without explicit guarantees. If network congestion 195 increases dramatically, the performance for emergency traffic 196 might degrade right along with normal traffic, but would still 197 receive some form of preference. Although the traffic would 198 not be immune to the effects of overloads, GETS has used this 199 approach and it has proven to be acceptable. 201 2. General Requirements 203 This section outlines four requirements for services that aim to 204 provide emergency communications for the Internet (or any 205 communication medium for that manner). They pertain to the ability 206 to begin communications, complete communications successfully, and 207 conduct them in an authorized and private manner. 209 2.1 Availability 211 The most fundamental requirement for emergency communication 212 services is that emergency-related users must have a high likelihood 213 of network resources being available to them when they need them. 214 Priority users must have a high probability of being able to 215 initiate a communication session. 217 Two interpretations of the concept of "high availability" could be 218 applied, either in a relative sense or an absolute sense. Such 219 options on interpretation give latitude in implementation 220 possibilities for emergency services. The first interprets "high 221 availability" in a preferential or relative sense. Priority users 222 would have preferred access to resources over normal users. A 223 service provider would implement mechanisms to identify and treat 224 priority traffic in special ways. Such an approach would allow a 225 service provider to avoid having to meet specific availability 226 targets (e.g., 95% availability) through an assurance that is given 227 to priority customers that their traffic is being treated 228 preferentially. If the network is stressed, availability for 229 priority users may decrease, but it would still be relatively higher 230 (even much higher) than for normal users. 232 In the second interpretation, high availability would mean absolute 233 availability levels that would be provided regardless of the network 234 operating conditions. Service providers may choose to provide high 235 availability levels through best effort provisioning even when the 236 network is stressed. They could choose to avoid using any 237 mechanisms to identify or preferentially treat priority traffic, 238 because priority traffic requirements would be met by the default 239 operation of their network. 241 2.2 Dependability 243 Priority users must not only be able to initiate communication 244 sessions; they must also be able to successfully complete their 245 intended activities. While PSTN communications provide such 246 dependability by default, Internet communications might be affected 247 by a variety of network operating conditions, such as congestion or 248 link failures. An emergency communication service must protect 249 priority communications from being affected by those conditions, at 250 least to the extent that the communication session can still be 251 conducted acceptably. Definitions of acceptable performance will 252 vary depending on the application. 254 2.3 Authorized Access 256 Mechanisms must be implemented so that only authorized users have 257 access to priority communications services. Such authorization 258 could be PIN-based or based on assignment of cryptographic keys [5]. 259 Authorization protects network resources from excessive use and 260 abuse. The two purposes for this requirement are to restrict usage 261 of network resources only to those who are allowed to use them and 262 to enable proper billing. Even when using a best effort 263 provisioning approach where emergency users are not provided special 264 services, proper billing necessitates authorized access. 266 Such authorization mechanisms should be flexible enough to provide 267 various levels of restriction and authorization depending on the 268 expectations of a particular service or customer. For example, it 269 might be desirable to provide access to emergency communications 270 differently after a hurricane where the emergency was caused by a 271 natural disaster as compared to after a terrorist attack that was 272 caused by humans. In the hurricane scenario, members of the general 273 public might be given access (e.g., at a lower priority level than 274 emergency response organizations) where after a terrorist attack 275 security concerns might necessitate highly restrictive access to 276 emergency services. 278 In the case of 911-type services, authorization is also applicable. 279 In such cases, users self-authorize themselves by deciding that they 280 have an urgent need that warrants special attention. If they abuse 281 the service, they also understand that they could be held 282 accountable for such abuse. 284 Further requirements and recommended procedures are given in [5]. 286 2.4 Privacy 288 Emergency communications will frequently have a requirement that 289 they not be susceptible to viewing or modification by others, due to 290 the sensitive and urgent nature of emergency response activities. 291 An emergency communications service should be able to protect the 292 integrity of user communication with options to encrypt user 293 traffic. 295 3. Technical Requirements 297 The following technical requirements represent the mechanisms that 298 must be in operation to enable the general requirements listed above 299 to be realized. For several of the requirements below, it is 300 assumed that networks will experience temporary scarcity of 301 resources, especially because of damaged infrastructure and high 302 demand immediately following a disaster. If a service provider 303 employs a best effort provisioning approach to provide emergency 304 services so that resources are never scarce, some of the following 305 requirements will not be necessary. 307 3.1 Identification of Priority Traffic 309 Priority traffic must be recognized in the forwarding plane. An 310 emergency communication service must have procedures by which 311 emergency traffic is marked so that it can be identified throughout 312 the network. The decisions about who does such marking (i.e., end 313 users or the network), where it occurs, who recognizes such marking, 314 whether re-marking might occur, and at what layer or layers marking 315 is implemented are left to the discretion of the service provider. 317 3.2 Signalling for Resource Requests 319 Priority traffic must be recognized in the control plane. For 320 applications where sessions need to be established or network 321 resources reserved, signalling mechanisms must be used that support 322 the differentiation of priority signalling messages. 324 3.3 Better Then Best Effort Service 326 The default best-effort forwarding behavior available in existing 327 routers as standardized in [4] does not provide performance 328 assurances. This is especially true for emergency services where 329 severe congestion that accompanies disasters can cause the 330 performance of best-effort delivery to degrade well below acceptable 331 levels. 333 Quality of service for emergency communication services does not 334 necessarily mean better quality of voice/video as compared to what 335 is available to normal users. The same QoS classes, which are 336 already defined for normal traffic, can be utilized for emergency 337 traffic as well. 339 The fundamental quality of service requirement for priority traffic 340 is this - better than best effort service. Service providers have 341 the freedom to implement special quality of service mechanisms to 342 meet this requirement, but other approaches may be effective as 343 well. 345 Better than best effort service is provided to emergency traffic so 346 that it will receive guaranteed performance levels that are at or 347 above a minimum performance level. Without such a requirement, the 348 dependability requirement outlined above could not be met. 350 4. Special Requirements 352 In addition to the general and technical requirements given above, 353 this section provides additional requirements that may optionally be 354 requested for particular service agreements. They primarily involve 355 the specification of the particular approach that is being used by 356 service providers for particular networks, applications, and types 357 of traffic. 359 4.1 Traffic Types 361 A service provider may choose to provide an emergency service that 362 supports different traffic types in different ways with customized 363 levels of availability and dependability. The three types of 364 traffic that may be treated in distinctive ways are as follows. 366 o Inelastic traffic - As defined in [6], inelastic traffic is 367 traffic which has a firm delay bound. If packets arrive after 368 a maximum acceptable delay, the packets are essentially 369 worthless to the receiver. Real-time audio and video are 370 examples of inelastic traffic. 372 o Interactive elastic traffic - Elastic applications are 373 generally those which wait for data to arrive and do not 374 discard it if it is late. This does not mean that applications 375 are insensitive to delay, however, because such delays could 376 hurt application performance significantly. In particular, 377 interactive elastic traffic requires reasonable delays because 378 of the user interaction that is involved. Examples of 379 interactive elastic traffic include HTTP and instant messaging 380 traffic. 382 o Bulk transfer elastic traffic - Some elastic applications, 383 however, do not involve direct user interaction. In such 384 cases, delay is not so much a concern as average throughput. 385 Bulk transfers can have large variations in delay as long as an 386 expected average throughput is obtained. For example, if a 387 file can be downloaded in 100 seconds, it does not matter if 388 for part of the transfer the throughput was virtually zero. 389 Examples of bulk transfer traffic are FTP and SMTP. 391 As an example of how service providers may wish to support the above 392 types of traffic, they may wish to provide service guarantees for 393 inelastic traffic using Diffserv [7] but use best effort 394 provisioning for both types of elastic traffic. 396 4.2 Network Areas 398 It is not expected that service providers use the same approach to 399 supporting emergency traffic in all parts of their network. They 400 are free to provide services differently based on whether traffic is 401 traversing core, distribution, or access layers of the service 402 provider's network. Specifications may also differ depending on the 403 type of access technology that is being used (e.g., LAN, wireless, 404 or DSL). 406 For example, a service provider may wish to identify and provide 407 specialized treatment of emergency traffic in access networks and 408 use best effort treatment in core networks. 410 4.3 Application-Specific Support 412 In addition to the above requirements for network layer mechanisms 413 to support priority services, specific applications may have 414 additional requirements to be acceptable for emergency users. Such 415 requirements might include additional signalling or mechanisms to 416 provide preferential performance or dependability to priority users. 417 Examples of applications include the following. 419 o Voice on IP, using such signaling architectures as H.323 or SIP 420 [8]. 422 o Shared real-time whiteboard. 424 o Instant messaging and presence. 426 o Databases such as the Japanese "I am Alive" [9] service, for 427 communication with persons not involved in the crisis. 429 o Database services for managing the crisis, including 430 calendaring, contact management, order and trouble report 431 management, legal services, medical services, etc. 433 o Electronic mail. 435 o Damage assessment applications. 437 o File transfer. 439 o World Wide Web. 441 However, this document does not address requirements for 442 applications. The focus of this document is to provide requirements 443 for network service providers. Requirements for the applications 444 should be met by content providers and end users. However, network 445 service providers may wish to provide network-based services which 446 could improve the performance of particular applications, for 447 example by providing web caching. 449 Of specific interest to current emergency management organizations 450 are IP Telephony and Voice on IP. Further requirements and 451 recommended procedures for these applications in particular are 452 given in [2]. 454 5. Policy Decisions 456 The above general and technical requirements provide wide latitude 457 for creativity on the part of service providers to implement 458 emergency services. In addition to meeting the requirements above, 459 a series of policy decisions should be made in the implementation of 460 emergency services. No particular approach is prescribed regarding 461 these policies. However, the policies used by a service provider to 462 addressing the following issues should be clearly defined and 463 communicated. 465 5.1 Services Always Available or Only Enabled Upon Emergency 466 Declaration 468 Providers of an emergency service should specify whether emergency 469 treatment is always available within the network or whether the 470 service is only activated upon declaration of emergency conditions 471 by an appropriate authority. Service providers may also choose to 472 provide a minimal service that is available at all times, but which 473 could be expanded once an emergency declaration was made. 475 5.2 Restoration Procedures 477 Service providers should describe the restoration procedures they 478 will use when substantial damage is experienced in their network. 479 They should provide plans and estimates in advance of how damaged 480 facilities will affect the availability of emergency services and, 481 if a critical relationship exists, how prioritized restoration of 482 those vital facilities will be accomplished. Service providers may, 483 of course, choose to rely upon rerouting mechanisms that would make 484 the restoration procedures they use irrelevant to the continued 485 dependability of emergency services. The only concern in that case 486 is when damage could be so extensive that rerouting mechanisms would 487 be ineffective. 489 5.3 Preemption 491 Service providers may wish to provide resources for emergency 492 communications by interrupting particular non-emergency traffic 493 flows. If such an approach is used, this should be explicitly 494 stated and details should be given on how preemption is carried out. 495 Regulatory guidelines in some jurisdictions may prohibit the use of 496 preemption to support emergency traffic. 498 5.4 Cooperation Between Service Providers 500 Emergency users will only be concerned with the quality of the end- 501 to-end communications they are provided. However, it is possible 502 that no one particular service provider will be able to support that 503 service end-to-end. Emergency services could be carried over a 504 combination of service providers, some of which would provide 505 emergency capabilities and some of which may not. 507 Service providers which do provide emergency services may choose to 508 provide services that are only operative within their networks and 509 are independent of other service providers. Alternatively, service 510 providers may employ mechanisms to cooperate with other service 511 providers to provide emergency services. This would result in a 512 considerable portion of the end-to-end path being administered in a 513 cooperative fashion. If so, service providers should specify the 514 mechanisms they would use and the extent to which they would 515 cooperate with other service providers to support emergency 516 services. 518 6. Security Considerations 520 Authorized access and privacy are presented here as general security 521 requirements for emergency services in Section 2. Further 522 requirements are given in [5]. 524 References 526 1 B. Brewin, "Nation's Networks See Large Volume Spikes After 527 Attacks,", Computerworld, September 17, 2001. 529 2 Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP 530 Telephony," draft-ietf-ieprep-framework-00 (work in progress), 531 February 2002. 533 3 Work-in-progress. 535 4 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 536 June 1995. 538 5 Brown, I., "Securing prioritised emergency traffic", draft-brown- 539 ieprep-sec-00 (work in progress), February 2002. 541 6 Braden, R, Clark, D., and Shenkar, S., "Integrated Services in 542 the Internet Architecture: an Overview", RFC 1633, June 1994. 544 7 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. 545 Weiss, "An Architecture for Differentiated Services", RFC 2475, 546 December 1998. 548 8 Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 549 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 551 9 , "IAA System (I Am Alive): The Experiences of the Internet 552 Disaster Drills", INET 2000, June 2000. 554 Author's Address 556 Cory Beard 557 School of Interdisciplinary Computing and Engineering 558 University of Missouri-Kansas City 559 5100 Rockhill Road 560 Kansas City, MO 64110 562 Phone: 1-816-235-1550 563 Email: beardc@umkc.edu