Internet Engineering Task Force Internet Draft Schulzrinne Columbia U. draft-schulzrinne-ieprep-resource-req-00.txt April 21, 2002 Expires: October 2002 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document summarizes requirements for prioritizing access to PSTN and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). 1 Introduction For voice-over-IP or, more generally, multimedia calls placed by authorized users during emergencies, there are four cases where certain calls may need to be treated with priority: 1. If PSTN gateway resources are scarce, authorized calls should be able to queue for resources and acquire outbound trunks with priority or, if local policy permits, preempt Schulzrinne [Page 1] Internet Draft RP Requirements April 21, 2002 an existing call. 2. If a call originates from a circuit-switched network with multiple priority levels and traverses a VoIP network using SIP signaling on its way to another circuit-switched network with multiple priority levels, it is desirable that the priority information is not lost during transit. Similarly, calls originating on a VoIP terminal and terminating in the PSTN also need to be able to invoke the appropriate priority mechanism. 3. Resources in networks may be managed based on SIP calls. (This is not always desirable or feasible due to the divergence of media and signaling paths and the limited ability of session setup messages to express traffic characteristics, but it may be the only available mechanism absent a resource reservation protocol.) In such cases, policy may grant emergency preparedness or MLPP calls prioritized access. 4. In some circumstances, it may be appropriate to prioritize access to signaling resources (e.g., CPU cycles) in SIP proxies. Thus, SIP signaling requires a mechanism that allows the caller to indicate such priority. In the PSTN and certain private networks, such as those run by military organizations, calls are marked in various ways to indicate priorities. Below are some requirements for such a mechanism: Not specific to one domain: The mechanism should not be specific to one country or particular priority mechanism. For example, there are currently at least four priority schemes in widespread use: Q.735, with five levels, the U.S. defense network and NATO with five levels, the United States GETS (Government Emergency Telecommunications Systems) scheme with implied higher priority and the British GTPS system ???. Usage of existing namespaces: Since there are a number of existing resource priority schemes for both the PSTN and private networks, it is likely that hybrid or VoIP networks will inherit these naming schemes. Extensibility: New naming schemes may need to be defined as Schulzrinne [Page 2] Internet Draft RP Requirements April 21, 2002 resource priority mechanism are applied in additional private networks, or if a VoIP-specific priority scheme is being defined. Separation of indication and policy: The indication should not request a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Default behavior: Network terminals configured to use priority scheme A may occasionally end up making calls in a network that does not support such a scheme or the terminal may have an older list of priorities in a namespace. Multiple simultaneous schemes: Some user agents will need to support multiple different priority schemes, as several will remain in use in networks run by different agencies and operators. (Not all user agents will have the means of authorizing callers using different schemes, and thus may be configured at run-time to only recognize certain namespaces.) Discovery: A terminal should be able to discover which priority name spaces are supported by a particular proxy or user agent (gateway). Priority mechanisms can be roughly categorized by whether they use a priority queue for resource attempts or whether they preempt existing resource uses (e.g., calls). The choice between these mechanisms depends on the operational needs and characteristics of the network, e.g., on the number of active requests in the system and the fraction of prioritized calls. Generally, if the number of prioritized calls is small compared to the system capacity and the system capacity is large, it is likely that another call will naturally terminate in short order when a higher-priority call arrives. Thus, it is conceivable that the system indication can sometimes cause preemption, while otherwise it just Some namespaces may inherently imply a preemption policy, while others may be silent on whether preemption is to be used or not, leaving this to local entity policy. Similarly, the precise relationships between labels, e.g., what fraction of capacity is set aside for each priority level, is also a matter of local policy. This is similar to how differentiated services labels are handled. 2 Relationship to Emergency Call Services Schulzrinne [Page 3] Internet Draft RP Requirements April 21, 2002 The resource priority mechanisms are used to have selected individuals place calls with elevated priority during times when the network is suffering from an emergency-induced shortage of resources. Generally, calls for emergency help placed by non-officials (e.g., "911" and "112" calls) don't need resource priority under normal circumstances. If such emergency calls are placed during emergency- induced network resource shortages, the call identifier itself is sufficient to identify the emergency nature of the call. Adding an indication of resource priority may be less appropriate, as this would require that all such calls carry this indicator. Also, it opens another attack mechanism, where non-emergency calls are marked as emergency calls. (If the entity can recognize the request URI as an emergency call, it would not need the resource priority mechanism.) 3 Security Requirements Any resource priority mechanism can be abused to obtain resources and thus deny service to other users. While the indication itself does not have to provide separate authentication, any SIP request carrying such information has higher authentication requirements than regular requests. 4 Acknowledgements James Polk provided helpful comments. 5 Authors' Addresses Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu Schulzrinne [Page 4]