Internet Engineering Task Force Janet P. Gunn Internet Draft CSC Expiration: Dec 21st, 2003 File: draft-gunn-ieprep-ip-telephony-bcp-00.txt Best Current Practices for Internet Emergency Preparedness Use of IP Telephony June 21st, 2003 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document proposes best current practices for Internet Emergency Preparedness in the context of IP telephony in private IP networks designed, engineered and managed with telephony as the dominant application. It takes a top-down approach, and is intended to stimulate discussion and further revision and enhancement. Gunn Page 1 Internet Draft BCP IEPREP IP Tel June 21st, 2003 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 High Probability of Call Completion. . . . . . . . . . . . . . . 4 2.2 No Loss of Signaling Information . . . . . . . . . . . . . . . . 4 2.3 Distinction of Data Traffic . . . . . . . . . . . . . . . . . . 5 2.4 Non Pre-emptive . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 Functional in a Non-ubiquitous Environment . . . . . . . . . . . 6 2.6 Authenticated Service . . . . . . . . . . . . . . . . . . . . . 6 2.7 Alternate Path Routing . . . . . . . . . . . . . . . . . . . . . 6 2.8 End to End Fault Tolerance . . . . . . . . . . . . . . . . . . . 6 3.0 Key Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Single IP Administrative Domain . . . . . . . . . . . . . . . . 7 3.1.1 Solutions for Providing Signaling of EP Calls . . . . . . . . . 7 3.1.2 Solutions for Providing Priority for the Data Stream . . . . . . 9 3.2 Multiple (but Predefined) Administrative Domains . . . . . . . . 10 3.2.1 Solutions for Providing Signaling of EP Calls . . . . . . . . . 11 3.2.2 Solutions for Providing Priority for the Data Stream . . . . . . 14 4.0 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.0 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 6.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 7.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 8.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.0 Author Information . . . . . . . . . . . . . . . . . . . . . . . 16 1.0 Introduction The Charter for the Internet Emergency Preparedness (IEPREP) working group [2] calls for the development of a Best Current Practices document. The scope of the IEPREP working group is quite broad. It covers support for both emergency personnel use of IP telephony, and of other applications. It covers emergency personnel use of isolated private networks that happen to run the IP protocol suite, public Internet Service Providers (ISPs), and the "Big I" Internet interconnection of networks. From the telephony perspective, it includes dedicated telephony networks, and general purpose networks which include telephony with many other applications. It includes "IP Bridging", "IP at the Start", "IP at the End", "End-to-End IP". These topologies are described in RFC 3523 [3]. The "best practices" will vary significantly in each of these environments. Any attempt to address them all in a single Best Practices document would probably be futile. Therefore we take the approach of drastically limiting the scope of this initial document. In the future, as best practices are documented for other environments, it may make sense to consolidate them into a single document, or it may make sense to keep them distinct. Gunn Page 2 Internet Draft BCP IEPREP IP Tel June 21st, 2003 This document addresses best practices from a high level. It is hoped that this will generate discussion which will lead to a "top-down" development of more detailed best practices. We do not attempt to identify "Best Practices" for Voice over IP (VoIP) in general, only incremental "Best Practices" for Emergency Preparedness. The scope of this document is thus limited to - Voice Telephony - Private (isolated from the "Big I" Internet) IP networks that are designed, engineered, and managed with Telephony as the dominant application. This means that the issues associated with Quality of Service (QoS) for basic telephony service (e.g. assuring that you do not have 10 simultaneous "calls" across a single 128K link) have already been addressed, in either a standards- based, or a proprietary manner. We can then focus on any needed enhancements to support Emergency Preparedness. The scope includes all four topologies described in RFC 3523 [3]: "IP Bridging", "IP at the Start", "IP at the End", "End-to-End IP". The "class 4" IP networks being deployed by several of the (historically CSN based) telephony carriers are examples of networks encompassed by this scope. [Note: a universally acceptable term for the incremental services needed to support Emergency Personnel has not yet been established. Emergency Preparedness (EP), Emergency Telecommunications Service (ETS), and International Emergency Preference Scheme (IEPS) have all been used, but each has connotations or legal implications which make them inappropriate in some contexts. In this document we use "EP" or "emergency preparedness", recognizing that this will be replaced when a more universally acceptable term is selected.] 2.0 Objectives "Framework for Supporting ETS in IP Telephony"[4] describes six "objectives": - High Probability of Call Completion - No Loss of Signaling Information - Distinction of Signaling and Data - Non Pre-emptive Action - Functional in a Non-ubiquitous Environment - Authenticated Service And 2 "value added objectives": - Alternate Path Routing - End to End Fault Tolerance These objectives are based on the "General Requirements for Emergency Telecommunications Service" [5], and "IP Telephony Requirements for Emergency Telecommunications Service" [6]. Gunn Page 3 Internet Draft BCP IEPREP IP Tel June 21st, 2003 This document will attempt to address best practices for meeting these objectives in the limited scope of private, telephony focused, IP networks. 2.1 High Probability of Call Completion In the context of an IP network that is already configured to provide "carrier grade voice over IP", then the "high probability of call completion" objective is focused on the call admission process at each point in the path. The need for high probability of delivery for the data packets is largely taken care of by the network's QoS mechanism. EP personnel do need a "higher than others" probability of call admission during congestion. But, if normal calls have an acceptable QoS, they do not necessarily need a "higher than others" QoS for established calls. In some circumstances, emergency preparedness personnel may actually find it acceptable to accept a "lower than others" QoS (as long as it is still above a basic intelligibility threshold) as a tradeoff for a higher probability of call admission. Within the context of a private IP network that is designed, engineered, and managed with Telephony as the dominant application, we can assume that there is already a call admission policy of some sort in place. This policy determines what to do when the system cannot provide the "standard" QoS. It may be desirable for the policy to distinguish between "normal" calls and EP-related calls. Examples of the kinds of actions associated with the policy are: - Reject the call - Establish a queue for some or all calls that cannot be established - Retry the attempt to establish the call after a (fixed or variable) time interval - Attempt to establish the call with a different (for instance less stringent) QoS level - Establish the call anyway, recognizing that this may result in violations of the QoS expectations/commitments for this and/or other, calls. All except the first are actions which will increase the probability of completion for the calls they are applied to. 2.2 No Loss of Signaling Information This objective addresses the need for the IP network to transmit Circuit Switched Network (CSN) related signaling information (e.g., Signaling System No. 7 (SS7) information) about Emergency Preparedness status to the CSN network, so that the CSN can provide priority treatment on the CSN. This signaling information is currently contained in two particular parameters that are part of the SS7 ISDN User Part (ISUP) Initial Address Message (IAM) [7] which is used to set up the call path: the Calling Party Category Parameter and the Precedence Parameter. Gunn Page 4 Internet Draft BCP IEPREP IP Tel June 21st, 2003 The first parameter used to signal Emergency Preparedness status is the NS/EP Calling Party Category (CPC) code point, often referred to as the "High Probability of Completion" (HPC) code point [8]. The HPC code point is used in public portions of the USA telephony CSN. The second parameter used to signal Emergency Preparedness status is the Precedence parameter. The most common use of this parameter is to signal the priority level in MLPP (Multi Level Precedence and Priority) systems[9]. MLPP systems allow higher priority calls to pre-empt lower priority calls, when the higher priority call would otherwise be blocked. Such MLPP systems exist only in isolated, privately controlled CSN, such as those controlled by the military. The Precedence parameter can also be used to signal the priority level for enhanced Multi Level Precedence and Priority (eMLPP) systems [10], [11], [12]. eMLPP systems are specified for Global System for Mobile Communications (GSM) telephone systems, but currently exist only in private mobile networks, such as those run by railway companies. Depending on how related parameters are set in the GSM switches, a higher priority call may preempt a lower priority call when it would otherwise be blocked, or otherwise blocked calls may queue (in priority order) until the call can be completed. A third use of the Precedence parameter is to signal the priority for the Wireless Priority Service (WPS). The WPS operates in selected carriers in the public mobile network in the US. It is expected that the Emergency Preparedness information (which will be translated into either the CPC or Precedence Parameter in the CSN) will be carried in IP networks in a label such as the proposed SIP Resource Priority Header [13} and [14]. Therefore translation will be needed (both ways) between the IP label and the CPC (HPC) and/or Precedence parameters. 2.3 Distinction of Data Traffic This objective addresses the need to distinguish data packets associated with Emergency Preparedness from other types of Voice over IP data packets. This is typically discussed in terms of providing different treatment (such as lower drop rate, lower delay) for the distinguished packets. 2.4 Non Pre-emptive This objective indicates that the means used to provide priority treatment for Emergency Preparedness calls shall not result in the pre-emption (disconnection) of an existing call (whether Emergency Preparedness related or not) in either the CSN or IP network. However, the priority treatment for Emergency Preparedness calls may result in future non-EP calls being blocked. It may also result in a limited level (specified by Service Level Agreement (SLA)) of degradation of QoS, for both EP and non-EP calls. Gunn Page 5 Internet Draft BCP IEPREP IP Tel June 21st, 2003 2.5 Functional in a Non-ubiquitous Environment The objective of functioning in a non-ubiquitous environment is less important within the constraints/scope of Private IP networks that are designed, engineered, and managed with Telephony as the dominant application, than in a "general purpose" or "public" IP network. None the less, even private, telephony focused networks may have a variety of equipment and interfaces. An approach will not be rejected just because it does not work well for every piece of equipment in the network, or because it cannot be supported end0to-end for all calls. 2.6 Authenticated Service Authentication/authorization is likely to be somewhat different, depending on whether the call originates in the CSN (IP in the middle, or IP at the end), or in the IP network (IP end to end or IP at the start. If the call originates in the CSN, the authentication/authorization will probably also take place in the CSN. It is then important that the IP network can trust the authentication/authorization passed to it by the CSN. If the call originates in the IP network, a different method for authentication/authorization will need to be adopted, and, in the case of IP at the start, the CSN must trust the authentication/authorization passed to it by the IP network. It is anticipated that this will be based on authentication/authorization approaches implemented for SIP and non-EP IP telephony [15], [16]. 2.7 Alternate Path Routing There are two quite different levels at which alternate path routing can apply. - When the end destination is not in the IP network (IP bridging or IP at the start) there may be a choice of exit gateways to reach the final destination. If the call can not be established through the first choice of an exit gateway, the source can attempt to establish a connection via the second choice exit gateway. - When the end destination is in the IP network (or the exit gateway is fixed), it may be possible to establish an alternate path through the IP network. How feasible this is depends on what mechanism is already being used to provide QoS for VoIP traffic. 2.8 End to End Fault Tolerance Any VoIP system needs to have a mechanism to compensate for lossy networks providing best effort services. The issue here is whether the system can provide a different level of fault tolerance for calls that have been defined as EP related. As noted above, there are circumstances in which EP related calls can accept a lower QoS connection than normal voice over IP calls. There may be other circumstances in which they require a higher QoS connection. Gunn Page 6 Internet Draft BCP IEPREP IP Tel June 21st, 2003 3.0 Key Scenarios There are two key scenarios within the scope of this document (there are many more scenarios within the larger scope of general purpose IP networks). The first, and simplest scenario, is a single administrative domain. The second scenario is multiple administrative domains which have already resolved the relevant technical and business issues associated with supporting normal VoIP. 3.1 Single IP Administrative Domain A single administrative domain (especially in the current context of private IP networks that are designed, engineered, and managed with Telephony as the dominant application) is the simplest scenario for supporting the Emergency Preparedness objectives. - QoS issues to support IP telephony in general are easiest to address in a single administrative domain, and additional QoS consideration for Emergency Preparedness are also simplest- protocols like MPLS and DiffServe are applicable in the single administrative domain. - Authorization/authentication are simplified in a single domain. There is no need to establish trust in transferring the EP label (whatever it is) between domains. There are a number of policies that can be implemented at various points in the path based on the identification of the call as EP-related. - Queue - Retry - Attempt with different QoS - Establish in spite of lack of capacity. 3.1.1 Solutions for Providing Signaling of EP Calls In this scenario we address each of the topologies discussed in RFC 3523 [3]: "IP Bridging" "IP at the Start". "IP at the End" "End-to-End IP" identifying possible solutions for each scenario "IP bridging"- - Do nothing new (now) - Pros û Easy to implement, no security holes - Cons û Not only no new benefit, but will lose existing CSN functionality in the terminating CSN network when an IP "island" is inserted in the CSN. Gunn Page 7 Internet Draft BCP IEPREP IP Tel June 21st, 2003 - Encapsulation (now) - - Pros - It works (or is close to working) now, not dependant on implementation of new services by the IP carrier - Cons û It has no visibility in the IP part, and may fail if the start and end are using different "flavors" of ISUP - Translation (e.g., from ISUP to SIP to ISUP)(future) - Pros û It will provide visibility within the IP part, and can address translation to different "flavors" of ISUP - Cons - Not there yet, and will require implementation by the IP carrier "IP at the start" - Do nothing new (now) - Pros û Easy to implement, no security holes - Cons û No benefit in either the CSN or IP network - Apply CSN methods independent of IP telephony (e.g. recognize a dialed 2prefix, or a special dialed number combined with a pin) - Pros - Easy to implement, only requires IP carrier to recognize and appropriately route the dialed number or prefix - Cons - Very inefficient. Authorization/authentication scheme which is adequate for the CSN may not be sufficiently secure for IP networks. - Translation (e.g., from SIP to ISUP) and IP based authorization /authentication(future) - Pros - Visibility within IP network, More efficient (don't need to send PIN signaling back and forth). More flexible (easier to apply to multiple CSN systems), less dependant on CSN model for authentication/authorization, better security model, potentially expandable to IP end-to-end - Cons û Not there yet. Will require implementation by IP carrier. Will require development /implementation of IP based authentication/authorization scheme. "IP at the End" - Do nothing (still use the CSN based method to signal EP in the "start" CSN) (now) - Pros û Easy to implement, no security holes - Cons û No benefit in the IP network (still have benefit in the "start" CSN) - Translation (e.g., from ISUP to SIP) (future) - Pros - Visibility within IP network. Flexible (easy to apply to various different CSN variants), better security model possible, potentially expandable to IP end-to-end - Cons û Not there yet. Will require implementation by IP carrier. Will require additional agreement between CSN and IP network providers, and requires the IP carrier to trust the CSN authentication. Gunn Page 8 Internet Draft BCP IEPREP IP Tel June 21st, 2003 "End-to-End IP" - Do nothing (now) - Pros û Easy to implement, no security holes - Cons û no benefit in the IP network - "EP" signaling within SIP - Pros û visibility within the IP network (only valuable if something is also implemented for the data side) - Cons - not there yet. Will require implementation by IP carrier. Will require development /implementation of IP based authentication/authorization scheme. Not much benefit if there is no congestion within the IP network. 3.1.2 Solutions for Providing Priority for the Data Stream In this context, we assume that the network already has provisions to assure basic "QoS" for voice traffic. We consider alternatives to for providing a different treatment for EP-Voice related data packets, in comparison to non-EP- Voice related data packets. The particular alternatives would depend on the techniques already in place to support VoIP (e.g., RSVP, DiffServe, MPLS). Therefore we only list generic alternatives here. In some cases, the basic VoIP service may rely on over provisioning, with no active policing of call admission to prevent congestion related problems. In these cases, it may be difficult to provide priority for the EP-Voice related data stream without major enhancement. In general, we are referring to the data stream containing the "voice packets". But some of these approaches might also be relevant for the data stream containing the signaling packets. In general, we expect a more stringent QoS for EP-Voice related data packets, but under some circumstances, a less stringent QoS for EP-Voice related data packets may be desirable, as the "tradeoff" for establishing the call at all. The alternatives, and the basic "pros and cons" are the same for all four topologies. The major difference is whether or not the access links are likely to be congestion points. For instance, the access links are less likely to be a congestion point in "IP bridging" (where the access link may have been traffic engineered to correspond to the capacity of the CSN at that point) than in "End- to-End IP" (where the access links may connect to single enterprise locations, and may have been engineered with a greater emphasis on reducing link costs). - Do nothing new - Pros û Easy, Cheap - Cons - no benefit- but may not need a benefit if the entire network has excess capacity Gunn Page 9 Internet Draft BCP IEPREP IP Tel June 21st, 2003 - Provide different QoS only on the ingress access link - Pros û can be based on signaling information at the ingress gateway, does not require transmitting packet level information across the IP network, provides benefit on the ingress access link - Cons û provides no benefit at the egress access link, which may be a congestion point - Provide different QoS on the ingress and egress access links - Pros û provides benefits at the two most likely congestion points - Cons û requires signaling to the egress gateway, and/or packet level labeling, transmitted across the IP network, with possible impact on processing speed. - Provide different QoS only on the egress access links - Pros û provides benefit on the egress access link - Cons û requires signaling to the egress gateway, and/or packet level labeling, transmitted across the IP network, with possible impact on processing speed. Provides no benefit in ingress access link, which may be a congestion point. - Provide different QoS on all links - Pros û provides maximum benefit - Cons - but also maximum potential for Denial of Service (DoS), maximum impact on processing a at all intermediate nodes etc. 3.2 Multiple (but Predefined) Administrative Domains In this section we consider multiple Private (isolated from the "Big I" Internet) IP networks that are designed, engineered, and managed with Telephony as the dominant application. We will discuss it in the context of just two independent domains, but most of the considerations can be extrapolated to multiple domains. We assume that all technical issues, and all relevant SLAs, contractual, and authorization issues related to carrying normal IP Telephony traffic across the multiple domains have already been addressed. In this section we focus on the connection between the domains. The four different topologies are not particularly important in this context. Rather, there are several other high level considerations that affect the best practices (this is not a complete list of considerations): - No service-Neither domain recognizes any special services for Emergency Preparedness traffic - Service in One Domain-One domain provides special services for Emergency Preparedness traffic and the other does not. - Untrusted Domains-Each domain provides special services for Emergency Preparedness traffic, but they do not trust each other, nor share the same set of authorized users (e.g. a US based domain and a North Korea based domain) Gunn Page 10 Internet Draft BCP IEPREP IP Tel June 21st, 2003 - Trusted, Different Services-Each domain provides special services for Emergency Preparedness traffic, they do trust each other, they share the same set (or at least a subset) of authorized users, but the nature of the special services they provide are different (e.g., a private military domain and a private civilian domain). - Trusted, Same Services-Each domain provides special services for Emergency Preparedness traffic, they do trust each other, they share the same set of authorized users, and the nature of the special services they provide are essentially the same (e.g., two private civilian domains). The two private domains may be directly connected, or they may be connected by another network. In the latter case we assume that provisions (such as tunneling) have already been implemented to serve normal IP telephony traffic between the two domains. We do not make specific assumptions about the interfaces between the domains (firewalls, media gateways, proxy servers, NATs, etc.)beyond the fact that they are supporting normal IP Telephony traffic. There are a number of policies that can be implemented at the interfaces and connections between the domains, based on the identification of the call as EP- related. - Queue - Retry - Attempt with different QoS - Establish in spite of lack of capacity. 3.2.1 Solutions for Providing Signaling of EP Calls The potential signaling solutions for the first three cases (No Service, Service in One Domain, and Untrusted Domains) are essentially the same: - Strip any EP related information out of the signaling messages - Pros û avoids any potential DoS attack, or unauthorized use - Cons û lose any possibility to pass the signaling information, which might be acted on by subsequent domains (IP based or CSN) if appropriate. - Ignore any EP related information in the signaling messages, but do not remove it. - Pros - Any EP indication in the signaling messages(e.g., resource priority header, calling party category, encapsulated ISUP parameters) may be passed transparently, to be acted on by subsequent domains (IP based or CSN) if appropriate. - Cons û Provides an additional burden on any subsequent domain which might act on the signaling information, in terms of authorization/authentication, and detecting and preventing DoS attempts. Provides potential unauthorized use and DoS attacks. Gunn Page 11 Internet Draft BCP IEPREP IP Tel June 21st, 2003 Trusted, Different Services- - Strip any EP related information out of the signaling messages - Pros û avoids any potential DoS attack, or unauthorized use - Cons û Lose any benefit - Ignore any EP related information in the signaling messages, but do not remove it. - Pros - Any EP indication in the signaling messages(e.g., resource priority header, calling party category, encapsulated ISUP parameters) may be passed transparently, to be acted on by subsequent domains (IP based or CSN) if appropriate. Because there is already a trust relationship between the domains, there is less chance of DoS or unauthorized use. - Cons û Does not provide the possible benefit in the second domain. Provides small potential for unauthorized use and DoS attacks in subsequent domains. - Translate signaling information appropriate for the first domain into signaling information appropriate for the second domain (e.g., between CPC and Precedence parameters in encapsulated ISUP message, or change the value of the resource priority header in SIP message) (for users authorized in both domains) - Pros - Provides potential for benefit in both domains - Cons - More workload/processing on interfaces both in determining which users are authorized in both domains (and thus which signaling messages should be translated) and I doing the translations Trusted, Same Services - Strip any EP related information out of the signaling messages - Pros û avoids any potential DoS attack, or unauthorized use - Cons û Lose any benefit here, or in subsequent domains. - Ignore any EP related information in the signaling messages, but do not remove it. - Pros - Provides potential benefit in subsequent domains - Cons û Does not provide the possible benefit in the second domain. Can provide potential for DoS in subsequent domains. - Act on the signaling information, and pass it on. - Pros - Provides potential for benefit in both domains (and subsequent domains) - Cons - Dependant on the trust relationship (and the strength of the authorization/authentication process in the first domain). Gunn Page 12 Internet Draft BCP IEPREP IP Tel June 21st, 2003 3.2.2 Solutions for Providing Priority for the Data Stream In this context we refer to providing priority in the interfaces and connections between the two domains, not within the domains themselves. Where EP related signaling information is stripped or ignored, there is only one option. - Do nothing new - Pros û Easy, Cheap - Cons- no benefit- but may not need a benefit if the connections and interfaces between domains have excess capacity Where EP related signaling information is translated, or acted on directly, there are two options. - Do nothing new - Pros û Easy, Cheap - Cons- no benefit- but may not need a benefit if the connections and interfaces between domains have excess capacity - Provide different QoS on the interfaces and connections between the domains - Pros û provides maximum benefit - Cons - but also maximum potential for DoS, maximum impact on processing at interfaces, etc. May not be viable if the interfaces and/or connections are under the control of a third domain. 4.0 Recommendations There are a number of criteria to use in choosing among the various possible alternatives. Meeting the stated objectives is certainly one criterion, but there are a number of others: - Impact on other users ("fairness") (both other VoIP users and other IP users in general) - Use of communications capacity - Potential for abuse (e.g. DoS and DDoS) - Delay - Robustness - Cost to users - Impact on service provider (ISP) - Ease of development/implementation - Ease of maintenance/management (including SLAs) - Network availability, MTBF, MTTR - Cost vs. revenue opportunities - Impact on equipment vendors - Ease of development - Market possibilities - Cost vs. Revenue possibilities Gunn Page 13 Internet Draft BCP IEPREP IP Tel June 21st, 2003 - Impact on application level functionality - Transparency - Security - "Unintended side effects" 4.1 Signaling The recommended solution is to use SIP signaling (e.g., the proposed resource priority header), and translation between this and CSN signaling(e.g., ISUP) when available. When and where SIP signaling is not available, the recommended solution is to encapsulate the CSN signaling (e.g., ISUP). 4.2 Data The recommended solution is to provide special treatment for the EP Voice related data stream only where there is not a large level of excess capacity. This depends on the engineered capacity vs traffic level of the individual networks and domains. 5.0 Security Considerations Security considerations are addressed throughout the document. There are two primary concerns: - Authorization/authentication of traffic which is entitled to EP- Voice special treatment. The approaches currently used within the CSN (PIN based authorization and/or dialing prefix-caller device based authorization) do not always translate well to IP Domains. This document recognizes the issue, but does not propose specific solutions - Potential for unauthorized use of EP-Voice special treatment, and of DoS or DDoS attacks. This potential is addressed in the pros and cons of each alternative considered. 6.0 IANA Considerations There are no IANA considerations addressed in this document 7.0 Acknowledgements The author would like to acknowledge the helpful comments, opinions, and clarifications of Pat McGregor, Dennis Berg, and Richard Kaczmarek, as well as those comments received from the IEPS and IEPREP mailing lists. Gunn Page 14 Internet Draft BCP IEPREP IP Tel June 21st, 2003 8.0 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Internet Emergency Preparedness (IEPREP) Working Group Charter [3] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology", RFC 3523, April 2003. [4] Carlberg, K., Brown I., Beard, C. "Framework for Supporting ETS in IP Telephony", draft-ietf-ieprep-framework-04.txt, Internet Draft, March, 2003 [5] Carlberg, K., Atkinson, R., "General Requirements for Emergency Telecommunications Service", draft-ietf-ieprep-ets-general-03.txt, Internet Draft, January, 2003 [6] Carlberg, K., Atkinson, R., "IP Telephony Requirements for Emergency Telecommunications Service", draft-ietf-ieprep-ets-telephony-05.txt,Internet Draft, January, 2003 [7] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 2000 [8] ANSI, "Signalling System No. 7 (SS7) û High Probability of Completion (HPC) Network Capability." ANSI T1.631-1993, 1993 [9] ITU-T Recommendation I.255.3 (1990), "Multilevel Precedence and Preemption Service (MLPP)", 1990 [10] 3GPP TS 22.067 version 3.0.1 (1999-10), "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; enhanced Multi-Level Precedence and Pre-emption (eMLPP) û Stage 1 (Release 1999)" [11] 3GPP TS 23.067 version 3.3.0 (2001-06), "3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Pre-emption (eMLPP) û Stage 2 (Release 1999)" [12] 3GPP TS 24.067 version 3.2.0 (2001-06), "3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Pre-emption (eMLPP) û Stage 3 (Release 1999)" [13] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February, 2003. Gunn Page 15 Internet Draft BCP IEPREP IP Tel June 21st, 2003 [14] Schulzrinne, H., Polk, J., "SIP Communications Resource Priority Header", draft-polk-sip-resource-02.txt, Internet Draft, March 2003 [15] Loughney, J., Camarillo, G., "Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol", draft-ietf-sipping-aaa-req-03.txt, Internet Draft, May 2003 [16] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-01.txt, Internet Draft, February 2003 9.0 Author Information Janet P Gunn CSC 15000 Conference Center Dr. Chantilly, VA, 20151-3808 USA Email: janet.gunn@dyncorp.com Phone: 703 818 4725 "Copyright (C) The Internet Society (May 21st, 2003). 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 Gunn Page 16 Internet Draft BCP IEPREP IP Tel June 21st, 2003 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." The Expiration date for this Internet Draft is: December 21st, 2003 Gunn Page 17