Network Working Group F. Baker Internet-Draft Cisco Systems Expires: May 15, 2002 November 14, 2001 IEPS Requirement Statement draft-baker-ieps-requirements-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The requirements for an Internet Emergency Preference Scheme comparable to the US Government Emergency Telecommunications Service are explored. Baker Expires May 15, 2002 [Page 1] Internet-Draft Document November 2001 1. Introduction Some countries have deployed a telecommunications access service to expedite emergency services and government functionality in times of crisis. With the increased utility of the Internet, there is interest in creating a similar service in the Internet. This paper attempts to capture the technical problems related to that. 1.1 GETS - Government Emergency Telecommunications Service In the United States, the existing service is GETS, the Government Emergency Telecommunications Service; some other countries have equivalent services. In essence, GETS is a program that specifies a uniform set of services that government agencies may refer to in contracting emergency use of a telephone system. The key aspects of this service are that: o Personnel gain access to GETS by calling a specified telephone number and presenting a credit-card type of authentication. o Having authenticated themselves, the call is completed on preferential basis; if the system must choose between placing a GETS call and another call to the same destination, it will choose the GETS call. o If fundamental telephone services are compromised, services contracted under GETS are restored first. The telephone circuits (which is to say, the medium for the content of a telephone connection) given to GETS users are no different from other telephone circuits. The key consideration is that, under GETS, some people have a higher probability of placing a telephone call when common people cannot or are delayed. GETS calls receive priority treatment over normal calls through: o Controls such as trunk queuing, trunk subgrouping, or trunk reservation. o Exemption from restrictive network management controls that are used to reduce network congestion. o High Probability of Completion Standard (ANSI T1.631-1993) application to provide: * National Security and Emergency Preparedness (NS/EP) identification * Priority signaling. Baker Expires May 15, 2002 [Page 2] Internet-Draft Document November 2001 * Alternate carrier routing These features enhance the capability of NS/EP calls to be completed in congested networks. GETS will not preempt public telephone calls, nor are there levels of precedence within GETS. 1.2 Internet Emergency Preference Scheme (IEPS) Emergency management agencies in many countries are contemplating an Internet Emergency Preference Scheme [2] similar to GETS. The IEPS is envisaged as a program that specifies a uniform set of network services that government agencies may refer to in contracting emergency use of the Internet. The key aspects of this service are that: o Personnel granted access to the IEPS carry identification in a secure form, which allows them to authenticate with an Internet Service Provider. o Having authenticated themselves, they may enjoy preferred access to Voice on IP and data services at times when others are being denied service. o If fundamental Internet access is compromised, services contracted under IEPS are restored first. o Internet routers, switches, and computers deployed by emergency services personnel have a standard configuration which may be used with any IEPS network. Just as the telephone circuits provided under GETS does not differ from standard telephone circuits, the fundamental Internet access service provided under IEPS is not necessarily different from other Internet access service. The key consideration is that, during times of emergency, the contracted services are available to IEPS- authenticated personnel if they are available to anyone, and that the ISP treats provision of those services as of greater immediate importance than provision of those services to other customers. Where signaling is required or limitations are imposed to limit congestion, IEPS access is intended to circumvent those limits. In the GETS system, a standard configuration is unnecessary, as by tariff telephones use one of a small set of standard interfaces to the telephone network. This is by no means true of the Internet, however, and configuration issues are legendary causes of delay in deployment of IP services. For this reason, a standard configuration which may be used with any IEPS-contracted ISP, to which the equipment is configured before deployment, is contemplated. Baker Expires May 15, 2002 [Page 3] Internet-Draft Document November 2001 The services contemplated in the IEPS are in no sense limited, but potentially include the following applications: o Voice on IP, using such signaling architectures as H.323 or SIP [24]. o Video on IP, using the same services. o Shared real-time whiteboard. o Instant messaging and presence o Databases such as the Japanese "I am Alive" [1] service, for communication with persons not involved in the crisis. o Database services for managing the crisis, including calendaring, contact management, order and trouble report management, legal services, medical services, etc. o Electronic mail. o File transfer. o World Wide Web. 1.3 Issues in the IEPS These services have obviously different requirements, and may have different plans for provisioning them. For example, the "I am Alive" [1] service would appear to be a good candidate for outsourcing lookup engines to web hosting providers, while crisis management services may have strong security requirements that call for positioning in a closely managed data center. Similarly, voice traffic has specific delay requirements, database access has total- system-delay requirements, and file transfer tends to call for high throughput rates. Preliminary discussion of the IEPS has suffered from mismatched language and concepts between the Internet Engineering community and the emergency preparedness community, which is used to the GETS telephone service. A key point of confusion has been the issue of "priority". The telephone system may be viewed as a control plane and a data plane, with no concept of priority in the data plane, but a potential for choice in the placement and routing of calls. The control plane in the Internet is more difficult to discern; it exists, along with a Baker Expires May 15, 2002 [Page 4] Internet-Draft Document November 2001 data plane, but apart from telephone-system-emulation has no concept of a call or of routing of a call. For most Internet applications, the closest analogs are in middleware such as the Domain Name System, application proxies that enable firewall traversal, or in servers for address management. Another key point has been the deployment of services. In GETS, it is sufficient for an individual to find a standard telephone and place a call to the GETS number. The closest analogs in the Internet may be the use of an Internet Cafe, a commandeered ISP access link (home or corporate), or the rapid deployment of an office-in-a-box requiring the deployment of a standard internet service to a new service location. A last point of confusion has been the perception that all requirements to support IEPS are targeted for deployment over the Internet and ISPs. It is conceivable that recommendations to augment IP-based protocols will only be deployed in closed networks (e.g., IP backbone networks connecting signaling gateways at the edges, which in turn peer only with the PSTN). In this case, the IP network is private and isolated from the rest of the Internet. In short, from an end-user perspective, while there are strong similarities when viewed at a very high level, there are large operational differences, which require careful thought in specifying. Baker Expires May 15, 2002 [Page 5] Internet-Draft Document November 2001 2. Key problem areas to consider We turn to a quick review of the issues involved in an IEPS service deployment. One scenario is the interaction of IP telephony with the existing PSTN. As mentioned above, some parts of PSTN provide additional support for emergency-related calls. In the case of systems like GETS, a code point exists for use by the PSTN, which at a minimum distinguishes an emergency call from others. The problem that arises with respect to the IEPS is how to bridge this service to the PSTN. Another scenario is two variants of a common setting, the deployment of a crisis-related service center. Before an emergency occurs, someone decides that an emergency might come into existence, such as a war, a natural disaster, or other contingency. They determine that meeting that disaster is going to require a specified set of electronically connected services. Portions of the projected services use permanent computing sites, perhaps in a redundant configuration, running specific applications. Other portions may be mobile, may require emergency deployment, or may be accessible from other locations One example of such a service is deployed by the US Federal Emergency Management Agency (FEMA). FEMA has central computing equipment running specific applications in various locations. On demand, it can deploy what one might think of as an office in a box, consisting of a small-aperture satellite earth station, a router, and some number of VoIP telephones and computers, plus lightweight office infrastructure. Such rapid-deployment offices enable FEMA to quickly set up offices to serve victims of a disaster. The most important part of setting up such electronic crisis management services is, of course, the preparatory planning and application design that permits the service to be useful on short notice. However, with respect to the rapidly-deployable offices, there are a list of additional issues which must be addressed: security, service quality, and commonality of configuration. 2.1 Security The first issue is the security of the facilities themselves. Some issues are non-technical in nature but may have technical solutions: When a link is commandeered or an ISP is asked to deploy service under an IEPS contract, how does it know that the request is valid? Some of the issues are common to any Internet access point: in what way is a computer or computing facility protected from electronic warfare, garden variety viruses, denial of service attacks, and so Baker Expires May 15, 2002 [Page 6] Internet-Draft Document November 2001 on? How does one know that users of an IEPS service are authorized to do so? The Security Architecture for the Internet Protocol [11] addresses a subset of these issues; other issues will require application layer security approaches, and some will require legal solutions. 2.1.1 Deployment and authentication of IEPS personnel and sites The deployment of an IEPS site may be part of a long-term plan, or may be set up under emergency conditions. To obtain ISP services pursuant to an IEPS contract, the deploying agency will need to present credentials of type specified by law and contract. Three fundamental scenarios exist: o In the normal case, one would expect that an IEPS site would either be a permanent site, or (like the FEMA example) will provide its own bandwidth on a temporary basis. In such cases, normal contract procedures apply. o In dealing with a major issue, an office-in-a-box may be converted over time to a more permanent facility. The administration may find it appropriate to contract bandwidth from a local ISP to support the site. In such cases, again, normal contract procedures apply. o During the early hours of an emergency, however, IEPS-authorized officials may find a need to commandeer Internet access, and identify themselves to the supporting ISP as requiring IEPS- contracted services. The initial emergency recovery support requires readily available public telecommunication services to start organizing and coordinating. There is no time to deploy special facilities. In such cases, immediately available capabilities must be use, such as cell phones, PDAs, IP phones, computer terminals on Internet, etc. The ISP will need to be advised of the emergency condition, and may need to modify its configurations appropriately to support the site. In this case, electronic identification such as a one-time password or cryptographic identification may be appropriate. Internet access sites, like telephone equipment installation, are generally fairly permanent. Unlike telephone calls, however, the use of an Internet site also has aspects of permanence; even a site deployed in a park must have supporting infrastructure prepared in advance, and that infrastructure has long-term contractual aspects. Security issues in this matter therefore are primarily those related to the the access to and deployment of any Internet access facility. Where electronic identification is appropriate, it would likely be of Baker Expires May 15, 2002 [Page 7] Internet-Draft Document November 2001 a type commonly used for strong Internet authentication. 2.1.2 Defense of an IEPS site against common attacks IEPS sites are vulnerable to attacks common to the Internet. Such attacks include: o Attacks from within, including: * disruption, * unauthorized disclosure of, access to, or alteration of information, or * unauthorized issuance of instructions, o Attacks from without, such as denial of service attacks on the IEPS equipment or the routing infrastructure supporting it, o Attacks that transcend boundaries, such as viruses and worms. While some of the ramifications of such attacks may transcend normal consequences (the fire department may fail to be dispatched or may be sent to the wrong part of town, or the "I Am Alive" database service may find itself the vehicle for distribution of the nimda virus), these are not fundamentally different kinds of attacks than those experienced by other Internet sites. One must therefore assume that the prevention and management of such attacks is similarly common to the Internet. 2.1.3 Potentials for abuse of IEPS sites There are also a number of ways that IEPS sites may be abused. For example, if a wireless LAN is used to implement a site in a park, any person with a compatible wireless LAN card can, at least theoretically, obtain an IP Address and use the LAN for non-IEPS purposes. If one assumes that the device will not be configured to use IEPS DSCP values or applications, then it may be acceptable to limit the case to a small percentage of available bandwidth and for get it. Part of the requirement is to assess such risks, and in some cases address them. 2.2 Call prioritization The GETS service specifies that its telephone calls should be placed in preference to other calls, should a situation arise in which some Baker Expires May 15, 2002 [Page 8] Internet-Draft Document November 2001 calls are not being placed. In SS7, it does this by specifying that the call is an "authorized emergency" call in the ISUP IAM message. There are two possible approaches to translating this into H.323 or SIP: we can include the policy, in a call priority, or we can label the call expecting external policy to have the necessary result. SIP [24] has a priority field which is used for user to user communication of call importance, but is not generally used by the network. H.323 lacks both capabilities. In a situation where a large number of people are attempting to place calls simultaneously, the ability to select authenticated call requestors seems important. An alternative approach is to label calls. For example, if the SS7 tag "authorized emergency" is to be translated to a corresponding SIP or H.323 tag, that tag can be interpreted as implying a call preference. Proposals are in place to label calls "authorized emergency" in both H.323 and SIP [3], using priority (a policy) as a label. 2.3 Routing Algorithms IP Routing is generally performed on the basis of the destination address prefix. In edge networks, and in backbones of ISPs, this is often performed using "best path" protocols like OSPF [10]IS-IS [6]. Between ISPs, and between ISPs and their more sophisticated customers, routing is performed using the policy-based Border Gateway Protocol [7]. Routing paths will be chosen by the ISPs en route based on their inter-carrier contracts and other parameters to meet their service commitments. Generally speaking, ISPs are able to provide service level agreements, which may include rate and delay characteristics, within their networks; multi-provider routes offer less guarantees. 2.4 Quality of Service Algorithms and Configurations The IEPS community is interested in tagging their information and having it dealt with appropriately. The architecture for doing this is a combination of the Differentiated Services Architecture [22] and the Framework for Integrated Services Operation over Differentiated Services Networks [37]. Such a configuration might, for example, provide seven classes of traffic with specific support: o EF [28] service for voice, with signaling of bandwidth [9][37], o AF4 [27] service for video, with signaling of bandwidth [9][37], Baker Expires May 15, 2002 [Page 9] Internet-Draft Document November 2001 o AF3 [27] service for voice/video signaling, o AF2 [27] service for transaction/ERP traffic, o AF1 [27] service for traffic that will potentially move large volumes, o Class selector '110000' [21] for IP Routing traffic, o Class selector '000000' [21] for everything else (interloper, DNS, and anything we haven't thought of). Such a definition, if it is to work well, must take into account the various application's requirements, and meet them directly. These requirements may be in the form of delay or jitter limits, rate enforcement (whether as an upper or a lower bound), or enforcement of access controls. 2.4.1 Voice and video services If Voice on IP is in view, the key issues are loss, one-way delay and variation in that delay. One-way delay is the sum of the serialization and propagation delays of the various links en route, plus the variable queuing delays. Data is generated in small voice samples, which are either generated at a constant rate or are suppressed when they contain silence. If the one-way delay is within acceptable bounds, and variation in delay end to end is sufficiently small, voice on IP is an effective application. Making that happen can be hard; it requires either a sufficient over-supply of bandwidth that all applications are served with essentially no jitter, or separation of voice traffic into a queue that gives it essentially no jitter. Video on IP is a related application. As with voice, the key issues are loss, one-way delay and variation in that delay. Video, however, occupies a much higher data rate, one to three orders of magnitude faster, and consists of fixed or variable data bursts in application frame windows. Video is acceptable when all of the messages in a frame arrive during either that frame window or the subsequent frame window, which is a looser requirement than that of voice. Making that happen can be hard none-the-less; it requires either a sufficient over-supply of bandwidth that all applications are served with no more jitter or loss than a video session can accept. Accomplishing these goals in an environment which is not significantly overprovisioned, or in which the degree of overprovisioning is not known, requires ensuring proper behavior becomes the responsibility of the bottleneck device. Accomplishing Baker Expires May 15, 2002 [Page 10] Internet-Draft Document November 2001 the goal requires the application of appropriate bandwidth admission and queuing algorithms, such as Assured Forwarding [27], Expedited Forwarding [28], RSVP [9], and the Integration of the Integrated and Differentiated Services Architectures [37]. It is important to note that the action of assuring resources and admission control for voice/video service to the general public may in turn contribute to congestion. This may prevent new call from being accepted, as opposed to all flows experiencing the same measure of packet loss (and corresponding degraded service). The is the fundamental reason to increase the probability that a call would pass admission control. 2.4.2 Signaling information The example configuration above calls for separate classes for voice signaling (H.323 or SIP [24]). and for IP Routing. These have the same basic requirements: while they are low volume overhead traffic, their loss at critical junctures can be very unfortunate. They should therefore not be unduly delayed, and they should not be dropped. Whether they should be classified separately is debated. One line of reasoning suggests that they are both signaling with essentially the same requirement, and so belong in the same class. Another line of reason suggests that if IP Routing fails, everything fails, while if voice signaling fails, a single Voice/Video on IP Call fails. The separation in class proposed is due to the latter line of reasoning. 2.4.3 TCP- and SCTP-based applications Most internet applications, however, are unlike voice or video in their requirements. They are said to be "elastic", meaning that they adapt themselves somewhat to available bandwidth, even if that bandwidth fluctuates over time due to competing traffic demands. These applications generally use TCP [4] or SCTP [36] as their transport, but may use other transports. For convenience, applications may be broken down by their dominant traffic characteristics: some tend to have short exchanges during which humans await the outcome, which we generically call "transaction" or "interactive applications", and some move volumes of information in a background mode, which we refer to as "file transfer" applications. Examples of transaction applications include most database protocols, but the most familiar is the World Wide Web [29]. An example of a file transfer application is the File Transfer Protocol [5]. In general, transaction applications generate relatively low traffic rates. The exchanges are sensitive to loss, in that a single packet Baker Expires May 15, 2002 [Page 11] Internet-Draft Document November 2001 loss may significantly extend the duration of an exchange. File transfers, however, may consume the entire bandwidth of a link if left unchecked, and especially on lower speed links can disrupt voice and video applications, or may dramatically increase the delay experienced by transaction applications. At this point, the recommendation of the internet community is that any TCP should implement TCP Congestion Avoidance [25], along with the New Reno Modifications [26]. Regardless of transport (although this is normally implemented by the transport), applications should comply with the IETF Congestion Control Principles [35]. The combined effects of these recommendations are to maximize the throughput rates of TCP sessions while also making them very adaptive to loss in the network. While not widely deployed at this writing, there is also significant reason to believe that Explicit Congestion Notification [42] has the effect of making TCP adapt well to congestion without requiring loss to detect it. Routers used in supporting bottleneck points in an IEPS service should therefore also support Assured Forwarding [27], which combines the concepts of giving a class of traffic a rate using a queue, using active queue management to manage throughput, and potentially metering arriving traffic when the rate is appropriate. If Explicit Congestion Notification [42] is configurable in the routers, AQM's random marking should be accomplished using that rather than dropping. In the FEMA example, satellites were used to provide rapidly deployable mobile bandwidth. Satellites are an example of high delay*bandwidth product links; the specifications developed for them are applicable to any link having a high delay*bandwidth product, such as transoceanic cable. Applications using such facilities should review and apply Enhancing TCP Over Satellite Channels using Standard Mechanisms [23]Ongoing TCP Research Related to Satellites [31] Baker Expires May 15, 2002 [Page 12] Internet-Draft Document November 2001 3. Security Considerations This document contains a section which addresses security considerations. Baker Expires May 15, 2002 [Page 13] Internet-Draft Document November 2001 4. Acknowledgements Scott Bradner, Hal Folts, Ken Carlberg, and Rei Atarashi reviewed this draft. Baker Expires May 15, 2002 [Page 14] Internet-Draft Document November 2001 References [1] , "IAA System (I Am Alive): The Experiences of the Internet Disaster Drills", INET 2000, June 2000. [2] "International Emergency Preparedness Scheme", ITU E.106, March 2000. [3] Polk, J. and H. Schulzrinne, "SIP Communications Resource Priority Header", draft-polk-sip-resource-00 (work in progress), November 2001. [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [6] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [10] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [11] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [15] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. Baker Expires May 15, 2002 [Page 15] Internet-Draft Document November 2001 [16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [17] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [18] Maughan, D., Schneider, M. and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [19] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [20] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [21] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [22] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [23] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999. [24] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [25] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [26] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999. [27] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [28] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. [29] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [30] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, Baker Expires May 15, 2002 [Page 16] Internet-Draft Document November 2001 "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999. [31] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K. and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000. [32] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B. and J. Segers, "Megaco Protocol version 0.8", RFC 2885, August 2000. [33] Taylor, T., "Megaco Errata", RFC 2886, August 2000. [34] Cromwell, D., "Proposal for an MGCP Advanced Audio Package", RFC 2897, August 2000. [35] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [36] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [37] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [38] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. [39] Blatherwick, P., Bell, R. and P. Holland, "Megaco IP Phone Media Gateway Application Profile", RFC 3054, January 2001. [40] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001. [41] Srinath, A., Levendel, G., Fritz, K. and R. Kalyanaram, "MGCP Business Phone Packages", RFC 3149, September 2001. [42] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [43] Brown, I., "Securing prioritised emergency traffic", draft- brown-ieps-sec-00 (work in progress), July 2001. Baker Expires May 15, 2002 [Page 17] Internet-Draft Document November 2001 [44] Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP Telephony", draft-carlberg-ieps-framework-02 (work in progress), October 2001. [45] Carlberg, K., "The Classifier Extension Header for RTP", draft- carlberg-rtp-classifier-extension-00 (work in progress), October 2001. [46] Folts, H., "Emergency Telecommunications Service in Next- Generation Networks", draft-folts-ieps-white-paper-00 (work in progress), October 2001. Author's Address Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred.baker@cisco.com Baker Expires May 15, 2002 [Page 18] Internet-Draft Document November 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Baker Expires May 15, 2002 [Page 19]