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]