Request for Comments: 4412 Columbia U.
Category: Standards Track J. Polk
Cisco Systems
February 2006
Communications Resource Priority for
the Session Initiation Protocol (SIP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines two new Session Initiation Protocol (SIP)
header fields for communicating resource priority, namely,
"Resource-Priority" and "Accept-Resource-Priority". The
"Resource-Priority" header field can influence the behavior of SIP
user agents (such as telephone gateways and IP telephones) and SIP
proxies. It does not directly influence the forwarding behavior of
IP routers.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................6
3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields ...................................................6
3.1. The ’Resource-Priority’ Header Field .......................6
3.2. The ’Accept-Resource-Priority’ Header Field ................8
3.3. Usage of the ’Resource-Priority’ and
’Accept-Resource-Priority’ .................................8
3.4. The ’resource-priority’ Option Tag .........................9
4. Behavior of SIP Elements That Receive Prioritized Requests ......9
4.1. Introduction ...............................................9
4.2. General Rules ..............................................9
4.3. Usage of Require Header with Resource-Priority ............10
4.4. OPTIONS Request with Resource-Priority ....................10
4.5. Approaches for Preferential Treatment of Requests .........11
4.5.1. Preemption .........................................11
4.5.2. Priority Queueing ..................................12
4.6. Error Conditions ..........................................12
4.6.1. Introduction .......................................12
4.6.2. No Known Namespace or Priority Value ...............13
4.6.3. Authentication Failure .............................13
4.6.4. Authorization Failure ..............................14
4.6.5. Insufficient Resources .............................14
4.6.6. Busy ...............................................14
4.7. Element-Specific Behaviors ................................15
4.7.1. User Agent Client Behavior .........................15
4.7.2. User Agent Server Behavior .........................15
4.7.3. Proxy Behavior .....................................16
5. Third-Party Authentication .....................................17
6. Backwards Compatibility ........................................17
7. Examples .......................................................17
7.1. Simple Call ...............................................18
7.2. Receiver Does Not Understand Namespace ....................19
8. Handling Multiple Concurrent Namespaces ........................21
8.1. General Rules .............................................21
8.2. Examples of Valid Orderings ...............................21
8.3. Examples of Invalid Orderings .............................22
9. Registering Namespaces .........................................23
10. Namespace Definitions .........................................24
10.1. Introduction .............................................24
10.2. The "DSN" Namespace ......................................24
10.3. The "DRSN" Namespace .....................................25
10.4. The "Q735" Namespace .....................................25
10.5. The "ETS" Namespace ......................................26
10.6. The "WPS" Namespace ......................................26
11. Security Considerations .......................................27
11.1. General Remarks ..........................................27
11.2. Authentication and Authorization .........................27
11.3. Confidentiality and Integrity ............................28
11.4. Anonymity ................................................29
11.5. Denial-of-Service Attacks ................................29
12. IANA Considerations ...........................................30
12.1. Introduction .............................................30
12.2. IANA Registration of ’Resource-Priority’ and
’Accept-Resource-Priority’ Header Fields .................30
12.3. IANA Registration for Option Tag resource-priority .......31
12.4. IANA Registration for Response Code 417 ..................31
12.5. IANA Resource-Priority Namespace Registration ............31
12.6. IANA Priority-Value Registrations ........................32
13. Acknowledgements ..............................................32
14. References ....................................................33
1. Introduction
During emergencies, communications resources (including telephone
circuits, IP bandwidth, and gateways between the circuit-switched and
IP networks) may become congested. Congestion can occur due to heavy
usage, loss of resources caused by the natural or man-made disaster,
and attacks on the network during man-made emergencies. This
congestion may make it difficult for persons charged with emergency
assistance, recovery, or law enforcement to coordinate their efforts.
As IP networks become part of converged or hybrid networks, along
with public and private circuit-switched (telephone) networks, it
becomes necessary to ensure that these networks can assist during
such emergencies.
Also, users may want to interrupt their lower-priority communications
activities and dedicate their end-system resources to the high-
priority communications attempt if a high-priority communications
request arrives at their end system.
There are many IP-based services that can assist during emergencies.
This memo only covers real-time communications applications involving
the Session Initiation Protocol (SIP) [RFC3261], including voice-
over-IP, multimedia conferencing, instant messaging, and presence.
SIP applications may involve at least five different resources that
may become scarce and congested during emergencies. These resources
include gateway resources, circuit-switched network resources, IP
network resources, receiving end-system resources, and SIP proxy
resources. IP network resources are beyond the scope of SIP
signaling and are therefore not considered here.
Even if the resources at the SIP element itself are not scarce, a SIP
gateway may mark outgoing calls with an indication of priority, e.g.,
on an ISUP (ISDN User Part) IAM (Initial Address Message) originated
by a SIP gateway with the Public Switched Telephone Network (PSTN).
In order to improve emergency response, it may become necessary to
prioritize access to SIP-signaled resources during periods of
emergency-induced resource scarcity. We call this "resource
prioritization". The mechanism itself may well be in place at all
times, but may only materially affect call handling during times of
resource scarcity.
Currently, SIP does not include a mechanism that allows a request
originator to indicate to a SIP element that it wishes the request to
invoke such resource prioritization. To address this need, this
document adds a SIP protocol element that labels certain SIP
requests.
This document defines (Section 3) two new SIP header fields for
communications resource priority, called ’Resource-Priority’ and
’Accept-Resource-Priority’. The ’Resource-Priority’ header field MAY
be used by SIP user agents, including Public Switched Telephone
Network (PSTN) gateways and terminals, and SIP proxy servers to
influence their treatment of SIP requests, including the priority
afforded to PSTN calls. For PSTN gateways, the behavior translates
into analogous schemes in the PSTN, for example, the ITU
Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both
the PSTN-to-IP and IP-to-PSTN directions. ITU Recommendation I.255.3
[I.255.3] is another example.
A SIP request with a ’Resource-Priority’ indication can be treated
differently in these situations:
1. The request can be given elevated priority for access to PSTN
gateway resources, such as trunk circuits.
2. The request can interrupt lower-priority requests at a user
terminal, such as an IP phone.
3. The request can carry information from one multi-level priority
domain in the telephone network (e.g., using the facilities of
Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves
inspecting or modifying the header field.
4. In SIP proxies and back-to-back user agents, requests of higher
priorities may displace existing signaling requests or bypass
PSTN gateway capacity limits in effect for lower priorities.
This header field is related to, but differs in semantics from, the
’Priority’ header field ([RFC3261], Section 20.26). The ’Priority’
header field describes the importance that the SIP request should
have for the receiving human or its agent. For example, that header
may be factored into decisions about call routing to mobile devices
and assistants and about call acceptance when the call destination is
busy. The ’Priority’ header field does not affect the usage of PSTN
gateway or proxy resources, for example. In addition, any User Agent
Client (UAC) can assert any ’Priority’ value, and usage of ’Resource-
Priority’ header field values is subject to authorization.
While the ’Resource-Priority’ header field does not directly
influence the forwarding behavior of IP routers or the use of
communications resources such as packet forwarding priority,
procedures for using this header field to cause such influence may be
defined in other documents.
Existing implementations of RFC 3261 that do not participate in the
resource priority mechanism follow the normal rules of RFC 3261,
Section 8.2.2: "If a UAS does not understand a header field in a
request (that is, the header field is not defined in this
specification or in any supported extension), the server MUST ignore
that header field and continue processing the message". Thus, the
use of this mechanism is wholly invisible to existing implementations
unless the request includes the Require header field with the
resource-priority option tag.
The mechanism described here can be used for emergency preparedness
in emergency telecommunications systems, but is only a small part of
an emergency preparedness network and is not restricted to such use.
The mechanism aims to satisfy the requirements in [RFC3487]. It is
structured so that it works in all SIP and Real-Time Transport
Protocol (RTP) [RFC3550] transparent networks, defined in [RFC3487].
In such networks, all network elements and SIP proxies let valid SIP
requests pass through unchanged. This is important since it is
likely that this mechanism will often be deployed in networks where
the edge networks are unaware of the resource priority mechanism and
provide no special privileges to such requests. The request then
reaches a PSTN gateway or set of SIP elements that are aware of the
mechanism.
For conciseness, we refer to SIP proxies and user agents (UAs) that
act on the ’Resource-Priority’ header field as RP actors.
It is likely to be common that the same SIP element will handle
requests that bear the ’Resource-Priority’ header fields and those
that do not.
Government entities and standardization bodies have developed several
different priority schemes for their networks. Users would like to
be able to obtain authorized priority handling in several of these
networks, without changing SIP clients. Also, a single call may
traverse SIP elements that are run by different administrations and
subject to different priority mechanisms. Since there is no global
ordering among those priorities, we allow each request to contain
more than one priority value drawn from these different priority
lists, called a namespace in this document. Typically, each SIP
element only supports one such namespace, but we discuss what happens
if an element needs to support multiple namespaces in Section 8.
Since gaining prioritized access to resources offers opportunities to
deny service to others, it is expected that all such prioritized
calls are subject to authentication and authorization, using standard
SIP security (Section 11) or other appropriate mechanisms.
The remainder of this document is structured as follows. After
defining terminology in Section 2, we define the syntax for the two
new SIP header fields in Section 3 and then describe protocol
behavior in Section 4. The two principal mechanisms for
differentiated treatment of SIP requests (namely, preemption and
queueing) are described in Section 4.5. Error conditions are covered
in Section 4.6. Sections 4.7.1 through 4.7.3 detail the behavior of
specific SIP elements. Third-party authentication is briefly
summarized in Section 5. Section 6 describes how this feature
affects existing systems that do not support it.
Since calls may traverse multiple administrative domains with
different namespaces or multiple elements with the same namespace, it
is strongly suggested that all such domains and elements apply the
same algorithms for the same namespace, as otherwise the end-to-end
experience of privileged users may be compromised.
Protocol examples are given in Section 7. Section 8 discusses what
happens if a request contains multiple namespaces or an element can
handle more than one namespace. Section 9 enumerates the information
that namespace registrations need to provide. Section 10 defines the
properties of five namespaces that are registered through this
document. Security issues are considered in Section 11, but this
document does not define new security mechanisms. Section 12
discusses IANA considerations and registers parameters related to
this document.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119], and indicate requirement levels for compliant
implementations.
3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields
This section defines the ’Resource-Priority’ and
’Accept-Resource-Priority’ SIP header field syntax. Behavior is
described in Section 4.
3.1. The ’Resource-Priority’ Header Field
The ’Resource-Priority’ request header field marks a SIP request as
desiring prioritized access to resources, as described in the
introduction.
There is no protocol requirement that all requests within a SIP
dialog or session use the ’Resource-Priority’ header field. Local
administrative policy MAY mandate the inclusion of the
’Resource-Priority’ header field in all requests. Implementations of
this specification MUST allow inclusion to be either by explicit user
request or automatic for all requests.
The syntax of the ’Resource-Priority’ header field is described
below. The "token-nodot" production is copied from [RFC3265].
Resource-Priority = "Resource-Priority" HCOLON
r-value *(COMMA r-value)
r-value = namespace "." r-priority
namespace = token-nodot
r-priority = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "’" / "~" )
An example ’Resource-Priority’ header field is shown below:
Resource-Priority: dsn.flash
The ’r-value’ parameter in the ’Resource-Priority’ header field
indicates the resource priority desired by the request originator.
Each resource value (r-value) is formatted as ’namespace’ ’.’
’priority value’. The value is drawn from the namespace identified
by the ’namespace’ token. Namespaces and priorities are case-
insensitive ASCII tokens that do not contain periods. Thus,
"dsn.flash" and "DSN.Flash", for example, are equivalent. Each
namespace has at least one priority value. Namespaces and priority
values within each namespace MUST be registered with IANA
(Section 12). Initial namespace registrations are described in
Section 12.5.
Since a request may traverse multiple administrative domains with
multiple different namespaces, it is necessary to be able to
enumerate several different namespaces within the same message.
However, a particular namespace MUST NOT appear more than once in the
same SIP message. These may be expressed equivalently as either
comma-separated lists within a single header field, as multiple
header fields, or as some combination. The ordering of ’r-values’
within the header field has no significance. Thus, for example, the
following three header snippets are equivalent:
Resource-Priority: dsn.flash, wps.3
Resource-Priority: wps.3, dsn.flash
Resource-Priority: wps.3
Resource-Priority: dsn.flash
3.2. The ’Accept-Resource-Priority’ Header Field
The ’Accept-Resource-Priority’ response header field enumerates the
resource values (r-values) a SIP user agent server is willing to
process. (This does not imply that a call with such values will find
sufficient resources and succeed.) The syntax of the ’Accept-
Resource-Priority’ header field is as follows:
Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
[r-value *(COMMA r-value)]
An example is given below:
Accept-Resource-Priority: dsn.flash-override,
dsn.flash, dsn.immediate, dsn.priority, dsn.routine
Some administrative domains MAY choose to disable the use of the
’Accept-Resource-Priority’ header for revealing too much information
about that domain in responses. However, this behavior is NOT
RECOMMENDED, as this header field aids in troubleshooting.
3.3. Usage of the ’Resource-Priority’ and ’Accept-Resource-Priority’
Header Fields
The following table extends the values in Table 2 of RFC 3261
[RFC3261]. (The PRACK method, labeled as PRA, is defined in
[RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT)
methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the
MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in
[RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB)
method in [RFC3903].)
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o - o o o o o
Accept-Resource-Priority 417 amdr o - o o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o o o o o o o
Accept-Resource-Priority 417 amdr o o o o o o o
Other request methods MAY define their own handling rules; unless
otherwise specified, recipients MAY ignore these header fields.
3.4. The ’resource-priority’ Option Tag
This document also defines the "resource-priority" option tag. The
behavior is described in Section 4.3, and the IANA registration is in
Section 12.3.
4. Behavior of SIP Elements That Receive Prioritized Requests
4.1. Introduction
All SIP user agents and proxy servers that support this specification
share certain common behavior, which we describe below in
Section 4.2. The behavior when a ’resource-priority’ option tag is
encountered in a ’Require’ header field is described in Section 4.3.
Section 4.4 describes the treatment of OPTIONS requests. The two
fundamental resource contention resolution mechanisms, preemption and
queueing, are described in Section 4.5. Section 4.6 explains what
happens when requests fail. Behavior specific to user agent clients,
servers, and proxy servers is covered in Section 4.7.
4.2. General Rules
The ’Resource-Priority’ header field is potentially applicable to all
SIP request messages. At a minimum, implementations of the following
request types MUST support the Resource-Priority header to be in
compliance with this specification:
o INVITE [RFC3261]
o ACK [RFC3261]
o PRACK [RFC3262]
o UPDATE [RFC3311]
o REFER [RFC3515]
Implementations SHOULD support the ’Resource-Priority’ header field
in the following request types:
o MESSAGE [RFC3428]
o SUBSCRIBE [RFC3265]
o NOTIFY [RFC3265]
Note that this does not imply that all implementations have to
support all request methods listed.
If a SIP element receives the ’Resource-Priority’ header field in a
request other than those listed above, the header MAY be ignored,
according to the rules of [RFC3261].
In short, an RP actor performs the following steps when receiving a
prioritized request. Error behavior is described in Section 4.6.
1. If the RP actor recognizes none of the name spaces, it treats the
request as if it had no ’Resource-Priority’ header field.
2. It ascertains that the request is authorized according to local
policy to use the priority levels indicated. If the request is
not authorized, it rejects it. Examples of authorization
policies are discussed in Security Considerations (Section 11).
3. If the request is authorized and resources are available (no
congestion), it serves the request as usual. If the request is
authorized but resources are not available (congestion), it
either preempts other current sessions or inserts the request
into a priority queue, as described in Section 4.5.
4.3. Usage of Require Header with Resource-Priority
Following standard SIP behavior, if a SIP request contains the
’Require’ header field with the ’resource-priority’ option tag, a SIP
user agent MUST respond with a 420 (Bad Extension) if it does not
support the SIP extensions described in this document. It then lists
"resource-priority" in the ’Unsupported’ header field included in the
response.
The use of the ’resource-priority’ option tag in ’Proxy-Require’
header field is NOT RECOMMENDED.
4.4. OPTIONS Request with Resource-Priority
An OPTIONS request can be used to determine if an element supports
the mechanism. A compliant implementation SHOULD return an ’Accept-
Resource-Priority’ header field in OPTIONS responses enumerating all
valid resource values, but an RP actor MAY be configured not to
return such values or only to return them to authorized requestors.
Following standard SIP behavior, OPTIONS responses MUST include the
’Supported’ header field that includes the ’resource-priority’ option
tag.
According to RFC 3261, Section 11, proxies that receive a request
with a ’Max-Forwards’ header field value of zero MAY answer the
OPTIONS request, allowing a UAC to discover the capabilities of both
proxy and user agent servers.
4.5. Approaches for Preferential Treatment of Requests
SIP elements may use the resource priority mechanism to modify a
variety of behaviors, such as routing requests, authentication
requirements, override of network capacity controls, or logging. The
resource priority mechanism may influence the treatment of the
request itself, the marking of outbound PSTN calls at a gateway, or
of the session created by the request. (Here, we use the terms
session and call interchangeably, both implying a continuous data