idnits 2.17.1 draft-baker-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 59 has weird spacing: '...calling a spe...' -- 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 (February 15, 2002) is 8100 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) == Unused Reference: '8' is defined on line 569, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 581, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 584, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 587, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 590, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 593, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 596, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 599, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 603, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 606, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 617, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 640, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 649, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 653, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 655, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 670, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 674, but no explicit reference was found in the text == Unused Reference: '40' is defined on line 677, but no explicit reference was found in the text == Unused Reference: '41' is defined on line 679, but no explicit reference was found in the text == Unused Reference: '43' is defined on line 686, but no explicit reference was found in the text == Unused Reference: '44' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '45' is defined on line 693, but no explicit reference was found in the text == Unused Reference: '46' is defined on line 697, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-02) exists of draft-polk-sip-resource-00 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 793 (ref. '4') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1771 (ref. '7') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '12') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '16') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '17') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '18') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '19') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '22') ** Obsolete normative reference: RFC 2543 (ref. '24') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2581 (ref. '25') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2582 (ref. '26') (Obsoleted by RFC 3782) ** Obsolete normative reference: RFC 2598 (ref. '28') (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 2616 (ref. '29') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2705 (ref. '30') (Obsoleted by RFC 3435) ** Downref: Normative reference to an Informational RFC: RFC 2760 (ref. '31') ** Obsolete normative reference: RFC 2885 (ref. '32') (Obsoleted by RFC 3015) ** Obsolete normative reference: RFC 2886 (ref. '33') (Obsoleted by RFC 3015) ** Downref: Normative reference to an Informational RFC: RFC 2897 (ref. '34') ** Obsolete normative reference: RFC 2960 (ref. '36') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. '37') ** Obsolete normative reference: RFC 3015 (ref. '38') (Obsoleted by RFC 3525) ** Downref: Normative reference to an Informational RFC: RFC 3054 (ref. '39') ** Downref: Normative reference to an Informational RFC: RFC 3064 (ref. '40') ** Downref: Normative reference to an Informational RFC: RFC 3149 (ref. '41') -- Possible downref: Normative reference to a draft: ref. '43' -- Unexpected draft version: The latest known version of draft-carlberg-ieprep-framework is -00, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '44' -- Possible downref: Normative reference to a draft: ref. '45' -- Possible downref: Normative reference to a draft: ref. '46' Summary: 30 errors (**), 0 flaws (~~), 27 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Expires: August 15, 2002 February 15, 2002 6 IEPS Requirement Statement 7 draft-baker-ieprep-requirements-00 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 months 20 and may be updated, replaced, or obsoleted by other documents at any 21 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 This Internet-Draft will expire on May 15, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 The requirements for an Internet Emergency Preference Scheme 39 comparable to the US Government Emergency Telecommunications Service 40 are explored. 42 1. Introduction 44 Some countries have deployed a telecommunications access service to 45 expedite emergency services and government functionality in times of 46 crisis. With the increased utility of the Internet, there is 47 interest in creating a similar service in the Internet. This paper 48 attempts to capture the technical problems related to that. 50 1.1 GETS - Government Emergency Telecommunications Service 52 In the United States, the existing service is GETS, the Government 53 Emergency Telecommunications Service; some other countries have 54 equivalent services. In essence, GETS is a program that specifies a 55 uniform set of services that government agencies may refer to in 56 contracting emergency use of a telephone system. The key aspects of 57 this service are that: 59 o Personnel gain access to GETS by calling a specified telephone 60 number and presenting a credit-card type of authentication. 62 o Having authenticated themselves, the call is completed on 63 preferential basis; if the system must choose between placing a 64 GETS call and another call to the same destination, it will choose 65 the GETS call. 67 o If fundamental telephone services are compromised, services 68 contracted under GETS are restored first. 70 The telephone circuits (which is to say, the medium for the content 71 of a telephone connection) given to GETS users are no different from 72 other telephone circuits. The key consideration is that, under GETS, 73 some people have a higher probability of placing a telephone call 74 when common people cannot or are delayed. GETS calls receive 75 priority treatment over normal calls through: 77 o Controls such as trunk queuing, trunk subgrouping, or trunk 78 reservation. 80 o Exemption from restrictive network management controls that are 81 used to reduce network congestion. 83 o High Probability of Completion Standard (ANSI T1.631-1993) 84 application to provide: 86 * National Security and Emergency Preparedness (NS/EP) 87 identification 89 * Priority signaling. 91 * Alternate carrier routing 93 These features enhance the capability of NS/EP calls to be completed 94 in congested networks. GETS will not preempt public telephone calls, 95 nor are there levels of precedence within GETS. 97 1.2 Internet Emergency Preference Scheme (IEPS) 99 Emergency management agencies in many countries are contemplating an 100 Internet Emergency Preference Scheme [2] similar to GETS. The IEPS 101 is envisaged as a program that specifies a uniform set of network 102 services that government agencies may refer to in contracting 103 emergency use of the Internet. The key aspects of this service are 104 that: 106 o Personnel granted access to the IEPS carry identification in a 107 secure form, which allows them to authenticate with an Internet 108 Service Provider. 110 o Having authenticated themselves, they may enjoy preferred access 111 to Voice on IP and data services at times when others are being 112 denied service. 114 o If fundamental Internet access is compromised, services contracted 115 under IEPS are restored first. 117 o Internet routers, switches, and computers deployed by emergency 118 services personnel have a standard configuration which may be used 119 with any IEPS network. 121 Just as the telephone circuits provided under GETS does not differ 122 from standard telephone circuits, the fundamental Internet access 123 service provided under IEPS is not necessarily different from other 124 Internet access service. The key consideration is that, during times 125 of emergency, the contracted services are available to IEPS- 126 authenticated personnel if they are available to anyone, and that the 127 ISP treats provision of those services as of greater immediate 128 importance than provision of those services to other customers. 129 Where signaling is required or limitations are imposed to limit 130 congestion, IEPS access is intended to circumvent those limits. 132 In the GETS system, a standard configuration is unnecessary, as by 133 tariff telephones use one of a small set of standard interfaces to 134 the telephone network. This is by no means true of the Internet, 135 however, and configuration issues are legendary causes of delay in 136 deployment of IP services. For this reason, a standard configuration 137 which may be used with any IEPS-contracted ISP, to which the 138 equipment is configured before deployment, is contemplated. 140 The services contemplated in the IEPS are in no sense limited, but 141 potentially include the following applications: 143 o Voice on IP, using such signaling architectures as H.323 or SIP 144 [24]. 146 o Video on IP, using the same services. 148 o Shared real-time whiteboard. 150 o Instant messaging and presence 152 o Databases such as the Japanese "I am Alive" [1] service, for 153 communication with persons not involved in the crisis. 155 o Database services for managing the crisis, including calendaring, 156 contact management, order and trouble report management, legal 157 services, medical services, etc. 159 o Electronic mail. 161 o File transfer. 163 o World Wide Web. 165 1.3 Issues in the IEPS 167 These services have obviously different requirements, and may have 168 different plans for provisioning them. For example, the "I am Alive" 169 [1] service would appear to be a good candidate for outsourcing 170 lookup engines to web hosting providers, while crisis management 171 services may have strong security requirements that call for 172 positioning in a closely managed data center. Similarly, voice 173 traffic has specific delay requirements, database access has total- 174 system-delay requirements, and file transfer tends to call for high 175 throughput rates. 177 Preliminary discussion of the IEPS has suffered from mismatched 178 language and concepts between the Internet Engineering community and 179 the emergency preparedness community, which is used to the GETS 180 telephone service. 182 A key point of confusion has been the issue of "priority". The 183 telephone system may be viewed as a control plane and a data plane, 184 with no concept of priority in the data plane, but a potential for 185 choice in the placement and routing of calls. The control plane in 186 the Internet is more difficult to discern; it exists, along with a 187 data plane, but apart from telephone-system-emulation has no concept 188 of a call or of routing of a call. For most Internet applications, 189 the closest analogs are in middleware such as the Domain Name System, 190 application proxies that enable firewall traversal, or in servers for 191 address management. 193 Another key point has been the deployment of services. In GETS, it 194 is sufficient for an individual to find a standard telephone and 195 place a call to the GETS number. The closest analogs in the Internet 196 may be the use of an Internet Cafe, a commandeered ISP access link 197 (home or corporate), or the rapid deployment of an office-in-a-box 198 requiring the deployment of a standard internet service to a new 199 service location. 201 A last point of confusion has been the perception that all 202 requirements to support IEPS are targeted for deployment over the 203 Internet and ISPs. It is conceivable that recommendations to augment 204 IP-based protocols will only be deployed in closed networks (e.g., IP 205 backbone networks connecting signaling gateways at the edges, which 206 in turn peer only with the PSTN). In this case, the IP network is 207 private and isolated from the rest of the Internet. 209 In short, from an end-user perspective, while there are strong 210 similarities when viewed at a very high level, there are large 211 operational differences, which require careful thought in specifying. 213 2. Key problem areas to consider 215 We turn to a quick review of the issues involved in an IEPS service 216 deployment. 218 One scenario is the interaction of IP telephony with the existing 219 PSTN. As mentioned above, some parts of PSTN provide additional 220 support for emergency-related calls. In the case of systems like 221 GETS, a code point exists for use by the PSTN, which at a minimum 222 distinguishes an emergency call from others. The problem that arises 223 with respect to the IEPS is how to bridge this service to the PSTN. 225 Another scenario is two variants of a common setting, the deployment 226 of a crisis-related service center. Before an emergency occurs, 227 someone decides that an emergency might come into existence, such as 228 a war, a natural disaster, or other contingency. They determine that 229 meeting that disaster is going to require a specified set of 230 electronically connected services. Portions of the projected 231 services use permanent computing sites, perhaps in a redundant 232 configuration, running specific applications. Other portions may be 233 mobile, may require emergency deployment, or may be accessible from 234 other locations 236 One example of such a service is deployed by the US Federal Emergency 237 Management Agency (FEMA). FEMA has central computing equipment 238 running specific applications in various locations. On demand, it 239 can deploy what one might think of as an office in a box, consisting 240 of a small-aperture satellite earth station, a router, and some 241 number of VoIP telephones and computers, plus lightweight office 242 infrastructure. Such rapid-deployment offices enable FEMA to quickly 243 set up offices to serve victims of a disaster. 245 The most important part of setting up such electronic crisis 246 management services is, of course, the preparatory planning and 247 application design that permits the service to be useful on short 248 notice. However, with respect to the rapidly-deployable offices, 249 there are a list of additional issues which must be addressed: 250 security, service quality, and commonality of configuration. 252 2.1 Security 254 The first issue is the security of the facilities themselves. Some 255 issues are non-technical in nature but may have technical solutions: 256 When a link is commandeered or an ISP is asked to deploy service 257 under an IEPS contract, how does it know that the request is valid? 258 Some of the issues are common to any Internet access point: in what 259 way is a computer or computing facility protected from electronic 260 warfare, garden variety viruses, denial of service attacks, and so 261 on? How does one know that users of an IEPS service are authorized to 262 do so? 264 The Security Architecture for the Internet Protocol [11] addresses a 265 subset of these issues; other issues will require application layer 266 security approaches, and some will require legal solutions. 268 2.1.1 Deployment and authentication of IEPS personnel and sites 270 The deployment of an IEPS site may be part of a long-term plan, or 271 may be set up under emergency conditions. To obtain ISP services 272 pursuant to an IEPS contract, the deploying agency will need to 273 present credentials of type specified by law and contract. Three 274 fundamental scenarios exist: 276 o In the normal case, one would expect that an IEPS site would 277 either be a permanent site, or (like the FEMA example) will 278 provide its own bandwidth on a temporary basis. In such cases, 279 normal contract procedures apply. 281 o In dealing with a major issue, an office-in-a-box may be converted 282 over time to a more permanent facility. The administration may 283 find it appropriate to contract bandwidth from a local ISP to 284 support the site. In such cases, again, normal contract 285 procedures apply. 287 o During the early hours of an emergency, however, IEPS-authorized 288 officials may find a need to commandeer Internet access, and 289 identify themselves to the supporting ISP as requiring IEPS- 290 contracted services. The initial emergency recovery support 291 requires readily available public telecommunication services to 292 start organizing and coordinating. There is no time to deploy 293 special facilities. In such cases, immediately available 294 capabilities must be use, such as cell phones, PDAs, IP phones, 295 computer terminals on Internet, etc. The ISP will need to be 296 advised of the emergency condition, and may need to modify its 297 configurations appropriately to support the site. In this case, 298 electronic identification such as a one-time password or 299 cryptographic identification may be appropriate. 301 Internet access sites, like telephone equipment installation, are 302 generally fairly permanent. Unlike telephone calls, however, the use 303 of an Internet site also has aspects of permanence; even a site 304 deployed in a park must have supporting infrastructure prepared in 305 advance, and that infrastructure has long-term contractual aspects. 306 Security issues in this matter therefore are primarily those related 307 to the the access to and deployment of any Internet access facility. 308 Where electronic identification is appropriate, it would likely be of 309 a type commonly used for strong Internet authentication. 311 2.1.2 Defense of an IEPS site against common attacks 313 IEPS sites are vulnerable to attacks common to the Internet. Such 314 attacks include: 316 o Attacks from within, including: 318 * disruption, 320 * unauthorized disclosure of, access to, or alteration of 321 information, or 323 * unauthorized issuance of instructions, 325 o Attacks from without, such as denial of service attacks on the 326 IEPS equipment or the routing infrastructure supporting it, 328 o Attacks that transcend boundaries, such as viruses and worms. 330 While some of the ramifications of such attacks may transcend normal 331 consequences (the fire department may fail to be dispatched or may be 332 sent to the wrong part of town, or the "I Am Alive" database service 333 may find itself the vehicle for distribution of the nimda virus), 334 these are not fundamentally different kinds of attacks than those 335 experienced by other Internet sites. 337 One must therefore assume that the prevention and management of such 338 attacks is similarly common to the Internet. 340 2.1.3 Potentials for abuse of IEPS sites 342 There are also a number of ways that IEPS sites may be abused. For 343 example, if a wireless LAN is used to implement a site in a park, any 344 person with a compatible wireless LAN card can, at least 345 theoretically, obtain an IP Address and use the LAN for non-IEPS 346 purposes. If one assumes that the device will not be configured to 347 use IEPS DSCP values or applications, then it may be acceptable to 348 limit the case to a small percentage of available bandwidth and for 349 get it. Part of the requirement is to assess such risks, and in some 350 cases address them. 352 2.2 Call prioritization 354 The GETS service specifies that its telephone calls should be placed 355 in preference to other calls, should a situation arise in which some 356 calls are not being placed. In SS7, it does this by specifying that 357 the call is an "authorized emergency" call in the ISUP IAM message. 358 There are two possible approaches to translating this into H.323 or 359 SIP: we can include the policy, in a call priority, or we can label 360 the call expecting external policy to have the necessary result. SIP 361 [24] has a priority field which is used for user to user 362 communication of call importance, but is not generally used by the 363 network. H.323 lacks both capabilities. In a situation where a 364 large number of people are attempting to place calls simultaneously, 365 the ability to select authenticated call requestors seems important. 367 An alternative approach is to label calls. For example, if the SS7 368 tag "authorized emergency" is to be translated to a corresponding SIP 369 or H.323 tag, that tag can be interpreted as implying a call 370 preference. Proposals are in place to label calls "authorized 371 emergency" in both H.323 and SIP [3], using priority (a policy) as a 372 label. 374 2.3 Routing Algorithms 376 IP Routing is generally performed on the basis of the destination 377 address prefix. In edge networks, and in backbones of ISPs, this is 378 often performed using "best path" protocols like OSPF [10]IS-IS [6]. 379 Between ISPs, and between ISPs and their more sophisticated 380 customers, routing is performed using the policy-based Border Gateway 381 Protocol [7]. 383 Routing paths will be chosen by the ISPs en route based on their 384 inter-carrier contracts and other parameters to meet their service 385 commitments. Generally speaking, ISPs are able to provide service 386 level agreements, which may include rate and delay characteristics, 387 within their networks; multi-provider routes offer less guarantees. 389 2.4 Quality of Service Algorithms and Configurations 391 The IEPS community is interested in tagging their information and 392 having it dealt with appropriately. The architecture for doing this 393 is a combination of the Differentiated Services Architecture [22] and 394 the Framework for Integrated Services Operation over Differentiated 395 Services Networks [37]. 397 Such a configuration might, for example, provide seven classes of 398 traffic with specific support: 400 o EF [28] service for voice, with signaling of bandwidth [9][37], 402 o AF4 [27] service for video, with signaling of bandwidth [9][37], 403 o AF3 [27] service for voice/video signaling, 405 o AF2 [27] service for transaction/ERP traffic, 407 o AF1 [27] service for traffic that will potentially move large 408 volumes, 410 o Class selector '110000' [21] for IP Routing traffic, 412 o Class selector '000000' [21] for everything else (interloper, DNS, 413 and anything we haven't thought of). 415 Such a definition, if it is to work well, must take into account the 416 various application's requirements, and meet them directly. These 417 requirements may be in the form of delay or jitter limits, rate 418 enforcement (whether as an upper or a lower bound), or enforcement of 419 access controls. 421 2.4.1 Voice and video services 423 If Voice on IP is in view, the key issues are loss, one-way delay and 424 variation in that delay. One-way delay is the sum of the 425 serialization and propagation delays of the various links en route, 426 plus the variable queuing delays. Data is generated in small voice 427 samples, which are either generated at a constant rate or are 428 suppressed when they contain silence. If the one-way delay is within 429 acceptable bounds, and variation in delay end to end is sufficiently 430 small, voice on IP is an effective application. Making that happen 431 can be hard; it requires either a sufficient over-supply of bandwidth 432 that all applications are served with essentially no jitter, or 433 separation of voice traffic into a queue that gives it essentially no 434 jitter. 436 Video on IP is a related application. As with voice, the key issues 437 are loss, one-way delay and variation in that delay. Video, however, 438 occupies a much higher data rate, one to three orders of magnitude 439 faster, and consists of fixed or variable data bursts in application 440 frame windows. Video is acceptable when all of the messages in a 441 frame arrive during either that frame window or the subsequent frame 442 window, which is a looser requirement than that of voice. Making 443 that happen can be hard none-the-less; it requires either a 444 sufficient over-supply of bandwidth that all applications are served 445 with no more jitter or loss than a video session can accept. 447 Accomplishing these goals in an environment which is not 448 significantly overprovisioned, or in which the degree of 449 overprovisioning is not known, requires ensuring proper behavior 450 becomes the responsibility of the bottleneck device. Accomplishing 451 the goal requires the application of appropriate bandwidth admission 452 and queuing algorithms, such as Assured Forwarding [27], Expedited 453 Forwarding [28], RSVP [9], and the Integration of the Integrated and 454 Differentiated Services Architectures [37]. 456 It is important to note that the action of assuring resources and 457 admission control for voice/video service to the general public may 458 in turn contribute to congestion. This may prevent new call from 459 being accepted, as opposed to all flows experiencing the same measure 460 of packet loss (and corresponding degraded service). The is the 461 fundamental reason to increase the probability that a call would pass 462 admission control. 464 2.4.2 Signaling information 466 The example configuration above calls for separate classes for voice 467 signaling (H.323 or SIP [24]). and for IP Routing. These have the 468 same basic requirements: while they are low volume overhead traffic, 469 their loss at critical junctures can be very unfortunate. They 470 should therefore not be unduly delayed, and they should not be 471 dropped. 473 Whether they should be classified separately is debated. One line of 474 reasoning suggests that they are both signaling with essentially the 475 same requirement, and so belong in the same class. Another line of 476 reason suggests that if IP Routing fails, everything fails, while if 477 voice signaling fails, a single Voice/Video on IP Call fails. The 478 separation in class proposed is due to the latter line of reasoning. 480 2.4.3 TCP- and SCTP-based applications 482 Most internet applications, however, are unlike voice or video in 483 their requirements. They are said to be "elastic", meaning that they 484 adapt themselves somewhat to available bandwidth, even if that 485 bandwidth fluctuates over time due to competing traffic demands. 486 These applications generally use TCP [4] or SCTP [36] as their 487 transport, but may use other transports. For convenience, 488 applications may be broken down by their dominant traffic 489 characteristics: some tend to have short exchanges during which 490 humans await the outcome, which we generically call "transaction" or 491 "interactive applications", and some move volumes of information in a 492 background mode, which we refer to as "file transfer" applications. 493 Examples of transaction applications include most database protocols, 494 but the most familiar is the World Wide Web [29]. An example of a 495 file transfer application is the File Transfer Protocol [5]. 497 In general, transaction applications generate relatively low traffic 498 rates. The exchanges are sensitive to loss, in that a single packet 499 loss may significantly extend the duration of an exchange. File 500 transfers, however, may consume the entire bandwidth of a link if 501 left unchecked, and especially on lower speed links can disrupt voice 502 and video applications, or may dramatically increase the delay 503 experienced by transaction applications. 505 At this point, the recommendation of the internet community is that 506 any TCP should implement TCP Congestion Avoidance [25], along with 507 the New Reno Modifications [26]. Regardless of transport (although 508 this is normally implemented by the transport), applications should 509 comply with the IETF Congestion Control Principles [35]. The 510 combined effects of these recommendations are to maximize the 511 throughput rates of TCP sessions while also making them very adaptive 512 to loss in the network. While not widely deployed at this writing, 513 there is also significant reason to believe that Explicit Congestion 514 Notification [42] has the effect of making TCP adapt well to 515 congestion without requiring loss to detect it. 517 Routers used in supporting bottleneck points in an IEPS service 518 should therefore also support Assured Forwarding [27], which combines 519 the concepts of giving a class of traffic a rate using a queue, using 520 active queue management to manage throughput, and potentially 521 metering arriving traffic when the rate is appropriate. If Explicit 522 Congestion Notification [42] is configurable in the routers, AQM's 523 random marking should be accomplished using that rather than 524 dropping. 526 In the FEMA example, satellites were used to provide rapidly 527 deployable mobile bandwidth. Satellites are an example of high 528 delay*bandwidth product links; the specifications developed for them 529 are applicable to any link having a high delay*bandwidth product, 530 such as transoceanic cable. Applications using such facilities 531 should review and apply Enhancing TCP Over Satellite Channels using 532 Standard Mechanisms [23]Ongoing TCP Research Related to Satellites 533 [31] 535 3. Security Considerations 537 This document contains a section which addresses security 538 considerations. 540 4. Acknowledgements 542 Scott Bradner, Hal Folts, Ken Carlberg, and Rei Atarashi reviewed 543 this draft. 545 References 547 [1] , "IAA System (I Am Alive): The Experiences of the Internet 548 Disaster Drills", INET 2000, June 2000. 550 [2] "International Emergency Preparedness Scheme", ITU E.106, March 551 2000. 553 [3] Polk, J. and H. Schulzrinne, "SIP Communications Resource 554 Priority Header", draft-polk-sip-resource-00 (work in 555 progress), November 2001. 557 [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 558 September 1981. 560 [5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 561 RFC 959, October 1985. 563 [6] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 564 environments", RFC 1195, December 1990. 566 [7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 567 RFC 1771, March 1995. 569 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 570 Levels", BCP 14, RFC 2119, March 1997. 572 [9] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource 573 ReSerVation Protocol (RSVP) -- Version 1 Functional 574 Specification", RFC 2205, September 1997. 576 [10] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 578 [11] Kent, S. and R. Atkinson, "Security Architecture for the 579 Internet Protocol", RFC 2401, November 1998. 581 [12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 582 November 1998. 584 [13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and 585 AH", RFC 2403, November 1998. 587 [14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 588 and AH", RFC 2404, November 1998. 590 [15] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 591 With Explicit IV", RFC 2405, November 1998. 593 [16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 594 (ESP)", RFC 2406, November 1998. 596 [17] Piper, D., "The Internet IP Security Domain of Interpretation 597 for ISAKMP", RFC 2407, November 1998. 599 [18] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 600 Association and Key Management Protocol (ISAKMP)", RFC 2408, 601 November 1998. 603 [19] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 604 RFC 2409, November 1998. 606 [20] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its 607 Use With IPsec", RFC 2410, November 1998. 609 [21] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of 610 the Differentiated Services Field (DS Field) in the IPv4 and 611 IPv6 Headers", RFC 2474, December 1998. 613 [22] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. 614 Weiss, "An Architecture for Differentiated Services", RFC 2475, 615 December 1998. 617 [23] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over 618 Satellite Channels using Standard Mechanisms", BCP 28, RFC 619 2488, January 1999. 621 [24] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 622 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 624 [25] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 625 Control", RFC 2581, April 1999. 627 [26] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's 628 Fast Recovery Algorithm", RFC 2582, April 1999. 630 [27] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured 631 Forwarding PHB Group", RFC 2597, June 1999. 633 [28] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited 634 Forwarding PHB", RFC 2598, June 1999. 636 [29] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 637 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 638 HTTP/1.1", RFC 2616, June 1999. 640 [30] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, 641 "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, 642 October 1999. 644 [31] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., 645 Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, 646 S., Scott, K. and J. Semke, "Ongoing TCP Research Related to 647 Satellites", RFC 2760, February 2000. 649 [32] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B. and 650 J. Segers, "Megaco Protocol version 0.8", RFC 2885, August 651 2000. 653 [33] Taylor, T., "Megaco Errata", RFC 2886, August 2000. 655 [34] Cromwell, D., "Proposal for an MGCP Advanced Audio Package", 656 RFC 2897, August 2000. 658 [35] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, 659 September 2000. 661 [36] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 662 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 663 "Stream Control Transmission Protocol", RFC 2960, October 2000. 665 [37] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 666 Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. 667 Felstaine, "A Framework for Integrated Services Operation over 668 Diffserv Networks", RFC 2998, November 2000. 670 [38] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and 671 J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 672 2000. 674 [39] Blatherwick, P., Bell, R. and P. Holland, "Megaco IP Phone 675 Media Gateway Application Profile", RFC 3054, January 2001. 677 [40] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001. 679 [41] Srinath, A., Levendel, G., Fritz, K. and R. Kalyanaram, "MGCP 680 Business Phone Packages", RFC 3149, September 2001. 682 [42] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 683 Explicit Congestion Notification (ECN) to IP", RFC 3168, 684 September 2001. 686 [43] Brown, I., "Securing prioritised emergency traffic", draft- 687 brown-ieprep-sec-00 (work in progress), July 2001. 689 [44] Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP 690 Telephony", draft-carlberg-ieprep-framework-02 (work in 691 progress), October 2001. 693 [45] Carlberg, K., "The Classifier Extension Header for RTP", draft- 694 carlberg-rtp-classifier-extension-00 (work in progress), 695 October 2001. 697 [46] Folts, H., "Emergency Telecommunications Service in Next- 698 Generation Networks", draft-folts-ieprep-white-paper-00 (work in 699 progress), October 2001. 701 Author's Address 703 Fred Baker 704 Cisco Systems 705 1121 Via Del Rey 706 Santa Barbara, CA 93117 707 US 709 Phone: +1-408-526-4257 710 Fax: +1-413-473-2403 711 EMail: fred.baker@cisco.com 713 Full Copyright Statement 715 Copyright (C) The Internet Society (2001). All Rights Reserved. 717 This document and translations of it may be copied and furnished to 718 others, and derivative works that comment on or otherwise explain it 719 or assist in its implementation may be prepared, copied, published 720 and distributed, in whole or in part, without restriction of any 721 kind, provided that the above copyright notice and this paragraph are 722 included on all such copies and derivative works. However, this 723 document itself may not be modified in any way, such as by removing 724 the copyright notice or references to the Internet Society or other 725 Internet organizations, except as needed for the purpose of 726 developing Internet standards in which case the procedures for 727 copyrights defined in the Internet Standards process must be 728 followed, or as required to translate it into languages other than 729 English. 731 The limited permissions granted above are perpetual and will not be 732 revoked by the Internet Society or its successors or assigns. 734 This document and the information contained herein is provided on an 735 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 736 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 737 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 738 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 739 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 741 Acknowledgement 743 Funding for the RFC Editor function is currently provided by the 744 Internet Society.