WDIFF

draft-ietf-sip-resource-priority-01.txt --> draft-ietf-sip-resource-priority-03.txt

Internet Engineering Task Force
Internet Draft Schulzrinne/Polk

Network Working Group H. Schulzrinne
Internet-Draft Columbia U./Cisco
draft-ietf-sip-resource-priority-01.txt
July 24, 2003 U.
Expires: December 2003 September 18, 2004 J. Polk
Cisco
March 20, 2004

Communications Resource Priority for the Session Initiation Protocol
(SIP)

STATUS OF THIS MEMO

This document is an Internet-Draft
draft-ietf-sip-resource-priority-03

Status of this Memo

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026.
RFC 3667.

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.

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". progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

To view the http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories, see Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 18, 2004.

Abstract

This document defines two new SIP header fields for communications
resource priority, namely "Resource-Priority" and "Accept-Resource-
Priority".
"Accept-Resource-Priority". The Resource-Priority "Resource-Priority" header field can
influence the behavior of SIP UAs, such as GSTN gateways, and SIP
proxies. It does not directly influence the forwarding behavior of
IP routers.

Schulzrinne/Polk

Schulzrinne & Polk Expires September 18, 2004 [Page 1]

Internet Draft

Internet-Draft Resource Priority July 24, 2003

1 Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].

2 March 2004

Table of Contents

1. Introduction

During emergencies, communications resources including telephone
circuits, IP bandwidth and gateways between the circuit-switched . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Resource-Priority and
IP networks may become congested. Congestion can occur due to heavy
usage, loss Accept-Resource-Priority SIP
Header Fields . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 The Resource-Priority Header Field . . . . . . . . . . . . . 5
3.2 The Accept-Resource-Priority Header Field . . . . . . . . . 6
3.3 Usage of resources caused by the natural or man-made disaster Resource-Priority 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
Accept-Resource-Priority Header Fields . . . . . . . . . . . 7
3.4 The Resource-Priority Option Tag . . . . . . . . . . . . . . 7
4. Behavior of converged or hybrid networks along with
public and private circuit-switched (telephone) networks, it becomes
necessary to ensure SIP Elements that these networks can assist during such
emergencies.

Also, users may want to interrupt their lower-priority communications
activities Receive Prioritized
Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 General Rules . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Error Conditions . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1 Known Namespace and Priority Value . . . . . . . . . . . . . 8
4.2.2 Handling Unknown Namespaces and Priority Values . . . . . . 9
4.3 User Agent Client Behavior . . . . . . . . . . . . . . . . . 10
4.4 User Agent Server Behavior . . . . . . . . . . . . . . . . . 10
4.5 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
5. Third-Party Authentication . . . . . . . . . . . . . . . . . 11
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Simple Call . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2 Receiver Does Not Understand Namespace . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . 15
8.1 Authentication and Authorization . . . . . . . . . . . . . . 16
8.2 Confidentiality and Integrity . . . . . . . . . . . . . . . 16
8.3 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.4 Denial-of-Service Attacks . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
9.1 IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . . . . . . . . . . 18
9.2 IANA Registration for Option Tag resource-priority . . . . . 18
9.3 IANA Registration for Response Code 417 . . . . . . . . . . 18
9.4 IANA Namespace and Priority Registrations . . . . . . . . . 18
9.5 Initial Namespace Registrations . . . . . . . . . . . . . . 19
9.5.1 Namespace dsn . . . . . . . . . . . . . . . . . . . . . . . 19
9.5.2 Namespace q735 . . . . . . . . . . . . . . . . . . . . . . . 20
9.5.3 Namespace DRSN . . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . 23

Schulzrinne & Polk Expires September 18, 2004 [Page 2]

Internet-Draft Resource Priority March 2004

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
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 requirements for real-time communications applications involving
SIP, including voice-over-IP, multimedia conferencing and instant
messaging/presence.

Session Initiation Protocol (SIP) [2] [RFC3261] applications may involve
at least five different resources that may become scarce and
congested during emergencies. These resources include gateway
resources, circuit-
switched 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.

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".

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.

Schulzrinne/Polk [Page 2]

Internet Draft Resource Priority July 24, 2003

This document defines (Section 3) a new SIP [2] [RFC3261] header field
for communications resource priority, called Resource-Priority. 'Resource-Priority' This
header field MAY be used by SIP user agents, including GSTN gateways
and terminals, and SIP proxy servers to influence their treatment of
SIP requests, including the priority afforded to GSTN calls. For

Schulzrinne & Polk Expires September 18, 2004 [Page 3]

Internet-Draft Resource Priority March 2004

GSTN gateways, the behavior translates into analogous schemes in the
GSTN, for example the ITU Recommendation Q.735.3 [3] [Q.735.3]
prioritization mechanism, in both the GSTN-to-IP and IP-to-GSTN
directions.

The Resource-Priority 'Resource-Priority' header field may be used in several
situations. A SIP request with such an indication can be treated
differently in
several these situations:

1. The request can be given elevated priority for access to GSTN
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 [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
GSTN gateway capacity limits in effect for lower priorities.

This header field is related to, but differs in semantics from, the
Priority
'Priority' header field (RFC 3261 [2], [RFC3261], Section 20.26). The Priority
'Priority' header field describes the priority importance that the SIP request
should have to the receiving human or its agent. For example, it that
header may be factored into decisions about call routing to mobile
devices and acceptance. assistants and 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 UAC
can assert any 'Priority' value, while access to resource priority
values is subject to authorization.

While it the 'Resource-Priority' header 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 to cause such influence may be defined in other
documents.

Existing implementations of RFC 3261 that do not participate in this the
resource priority mechanism follow the normal rules of RFC 3261,
Section 8.2.2: " If "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.

Schulzrinne/Polk implementations
unless the request includes the Require header field with the
Resource-Priority option flag.

Schulzrinne & Polk Expires September 18, 2004 [Page 3]

Internet Draft 4]

Internet-Draft Resource Priority July 24, 2003 March 2004

The mechanism described here can be used for emergency preparedness
in emergency telecommunications systems (ETS), systems, but is only a small part of
an emergency preparedness network. network and is not restricted to such use.

The mechanism is structured so that it works in all SIP/RTP
transparent networks [11], defined in [RFC3487], i.e., 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 that act on
the Resource-Priority 'Resource-Priority' header field as an RP actor. actors.

We define the header field syntax in Section 3 and then describe the
behavior of user agents and proxies in Sections 4.5 Section 4.3 through 4.7. Section
4.5. Section 6 briefly describes how this feature affects existing
systems that do not support it. Third-party authentication is
discussed in Section 5, while general security issues are enumerated
in Section 8. This specification does not propose any new SIP
security mechanisms. Examples can be found in Section 7.

The mechanism aims to satisfy the requirements in [11]. We present a
detailed analysis [RFC3487].

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 Section A.

3 BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.

3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields

This document defines the Resource-Priority 'Resource-Priority' and Accept-Resource-
Priority
'Accept-Resource-Priority' SIP header fields.

The SIP element behavior is described for UACs in Section 4.3, for
UAS in Section 4.4, for proxies in Section 4.5.

3.1 The Resource-Priority Header Field

The 'Resource-Priority' header field marks a SIP request as desiring
prioritized resource access, as described in the introduction. In
responses, it the 'Resource-Priority' header fields indicates the actual
resource priority that was granted to the request.

Implementations MAY change While it is

Schulzrinne & Polk Expires September 18, 2004 [Page 5]

Internet-Draft Resource Priority March 2004

usually the same value offered in the request; contained in some
environments, the response request, implementations MAY
insert a different value based on local policy.

There is known to be the same as in the
request.

The no requirement that all requests within a SIP element behavior is described for UACs in Section 4.5, for
UAS in Section 4.6, for proxies in Section 4.7. dialog or call
use the 'Resource-Priority' header field.

The syntax of the
Resource-Priority 'Resource-Priority' header field is as follows:

Resource-Priority = "Resource-Priority" HCOLON
(*COMMA
Resource-value *(COMMA Resource-value)
Resource-value = namespace "." priority

Schulzrinne/Polk [Page 4]

Internet Draft Resource Priority July 24, 2003 r-priority
namespace = alphanum *(alphanum / "-"
priority "-")
r-priority = alphanum *(alphanum / "-" "-")

An example 'Resource-Priority' header field is: is shown below:

Resource-Priority: q735.1 q735.1, dsn.flash

The Resource-value 'Resource-value' parameter in the Resource-Priority 'Resource-Priority' header
indicates the resource priority desired by the request originator.
Since a request may traverse multiple administrative domains with
multiple different namespaces, it is necessary to be able to
enumerate several different namespaces. However, each namespace MUST
NOT appear more than once. once in a SIP message.

Each resource value is formatted as "namespace" "." "priority value". 'namespace' '.' 'priority value'.
The value is drawn from the namespace identified by the namespace 'namespace'
token. Namespaces and priorities are case-independent ASCII. Each
namespace has at least one priority value. Namespaces and priority
values within each namespace are registered with IANA (Section 12); 9);
some initial namespaces are described in Section B.

We require that even namespaces with only one priority
value list that value to avoid problems if additional
priority values are added later. 9.5.

There may be multiple resource values or, equivalently, multiple
Resource-Priority
'Resource-Priority' header fields.

For example, the United States Wireless Priority System
(WPS) includes both a priority and high-probability-of-
call-completion parameter in a single call. field instances.

3.2 The Accept-Resource-Priority Header Field

The 'Accept-Resource-Priority' response header field indicates what enumerates the
resource values the a SIP element supports. user agent server implements. The syntax of
the Accept-
Resource-Priority 'Accept-Resource-Priority' header field is as follows:

Accept-Resource-Priority _ = "Accept-Resource-Priority" HCOLON
Resource-value (*COMMA Resource-value)

Schulzrinne/Polk [Page 5]

Internet Draft Resource Priority July 24, 2003

Example:
[Resource-value *(COMMA Resource-value)]

An example is given below:

Accept-Resource-Priority: dsn.flash-override,
dsn.flash, dsn.immediate, dsn.priority, dsn.routine

Schulzrinne & Polk Expires September 18, 2004 [Page 6]

Internet-Draft Resource Priority March 2004

3.3 Usage of the Resource-Priority and Accept-Resource-Priority Header
Fields

Header field where proxy INV UPD MES ACK CAN BYE REG OPT NOT SUB
______________________________________________________________ PRA
----------------------------------------------------------------
Resource-Priority R amd o o o - o o o o
Resource-Priority 200 - o - o o o - o o
Accept-Resource-Priority 200 - o o - o - - o o o o
Accept-Resource-Priority 417 - m - m m m - m m
Accept-Resource-Priority 420 - o - o o o o o

Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Resource-Priority R amd o o o o o o o
Resource-Priority 200 - o o o o o o o
Accept-Resource-Priority 200 - o o o o o o o
Accept-Resource-Priority 417 - m m m - m m

Use of the header fields in requests with methods such as ACK, BYE,
CANCEL, INFO, PRACK and REGISTER are unlikely to be meaningful and
the header field MAY be ignored by recipients of such requests.
(Other m m
Accept-Resource-Priority 420 - 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.)
Accept-Resource-Priority is only fields.
'Accept-Resource-Priority' MUST be returned in 420 (Not Supported)
responses marked as 'o' in table above if the element supports implements the
resource priority mechanism, mechanism with some other namespaces or priority
values, but does not support implement the particular namespace or priority value.

There is no requirement that all requests within a SIP dialog or call
use
value contained in the request.

3.4 The Resource-Priority header field.

4 Option Tag

This document also defines the "resource-priority" option tag. The
behavior is described in Section 4.2.2 and the IANA registration is
in Section 9.2.

4. Behavior of SIP Elements that Receive Prioritized Requests

4.1 General Rules

All user agent servers and proxy servers that receive SIP requests
share certain common behavior, which we describe below. Behavior
that is specific to user agent servers is covered in Section 4.6, 4.4,
while Section 4.7 4.5 deals with proxy behavior.

A SIP element supporting this specification MUST be able to interpret
the Resource-Priority 'Resource-Priority' header field in INVITE, ACK, PRACK [RFC3262],
MESSAGE [4], [RFC3428], UPDATE
[5], [RFC3311], SUBSCRIBE [6] [RFC3265] and NOTIFY [6] requests. It MAY ignore the header
field in other requests unless
[RFC3265] requests, if it supports a particular request. (This does
not imply that all elements supporting this specification need to
support all of these request methods.) In all such requests, the

Schulzrinne & Polk Expires September 18, 2004 [Page 7]

Internet-Draft Resource Priority March 2004

priority MAY influence the order in which requests are handled and
MUST influence the resources, such as circuits, bandwidth or memory,
allocated based on the request. For example, for SUBSCRIBE, a
higher-priority request may get preferential treatment if storage or
bandwidth for notifications are scarce, possibly displacing a
lower-priority subscription. (As always, the precise behavior is
defined by a namespace definition, or, if left unspecified, by an
implementation or configuration.)

A SIP element MAY ignore the header field in other requests unless
the request definition defines behavior for the particular method.

If a request contains multiple valid namespace/priority values, it the
request is
up treated according to the highest supported and authorized
value. The total ordering of priorities between different namespaces
is defined by local policy policy.

The OPTIONS request can be used to determine how if an element supports
the request is treated.

Schulzrinne/Polk [Page 6]

Internet Draft Resource Priority July 24, 2003 mechanism. A compliant implementation MUST return a
'Accept-Resource-Priority' header field in OPTIONS responses
enumerating all valid resource values. An implementation MAY reveal
this capability only to authorized UACs. (Note that an overloaded
UAS may not be able to provide this information at all times.) Note
that according to RFC 3261, proxies reached with a Max-Forwards value
of zero answer the OPTIONS request, allowing a UAC to discover the
capabilities of both proxies and the UAS.

4.2 Error Conditions

4.3

4.2.1 Known Namespace and Priority Value

Two error conditions can occur if a request reaches an element that
supports the namespace and resource priority. Elements receiving
requests with namespaces or priority values that they do not
understand act according to the rules in the next section.

Insufficient authorization: If the element receives a request with a
namespace and priority value it recognizes, but the originator is
not authorized for that level of service, the element MUST return
a 403 (Forbidden) response.
Insufficient resources: If there are insufficient resources at an
element for a given priority, a request might be delayed or
refused, depending on local policy or the definition of the
namespace. If it is refused, the element returns a 503 (Service
Unavailable) response. The response MAY also include a Warning 'Warning'
header with warning code 370 (Insufficient Bandwidth) if the
request failed due to insufficient capacity for the media streams,
rather than insufficient signaling capacity.

Schulzrinne & Polk Expires September 18, 2004 [Page 8]

The 503 (Service Unavailable) response provides sufficient
indication to the originator to re-attempt with a higher
appropriate resource priority or to add a resource priority
indication, if authorized.

4.4

4.2.2 Handling Unknown Namespaces and Priority Values

When handling requests with unknown namespsaces or priority values,
elements can operate in two modes, "strict" and "loose". If the
request includes a Require 'Require' header field with the Resource-Priority
'Resource-Priority' option tag, a UAS MUST follow the strict strict-mode
rules, otherwise UAS and proxies may choose either mode according to
local policy.

Following standard SIP behavior (Section 8.2.2.3 of [2]), [RFC3261]), a UAS
operating in strict mode MUST then reject the request with response code
420 (Bad Extension) if it does not understand the resource priority mechanism.
mechanisms such as the 'Resource-Priority' header field.

For example, a gateway that is unaware of a resource priority
namespace might accept a request at non-elevated priority, but
then the request could later be preempted by other requests.
Also, use of the Require 'Require' restriction ensures that in parallel
forking, only branches that support the resource priority
mechanism succeed.

Schulzrinne/Polk [Page 7]

Internet Draft Resource Priority July 24, 2003

The use of the Resource-Priority 'Resource-Priority' option tag with Proxy-Require 'Proxy-Require' is
NOT RECOMMENDED.

4.4.1

4.2.2.1 Strict Mode

In strict mode, an element that receives a request with a Resource-
Priority
'Resource-Priority' header field containing one or more namespace or
priority values that it does not know implement rejects the request with
status code 417 (Unknown Resource-Priority) and includes a Accept-Resource-Priority
'Accept-Resource-Priority' header field enumerating all the resource
values that the server is willing to process. Note that the user may
not be authorized to use all of these resource values.

Strict mode is particularly useful for operational testing of
systems supporting resource priority, as otherwise it might be
difficult to detect under non-overload conditions whether an
element supports the functionality or not.

4.4.2

4.2.2.2 Loose Mode

In loose mode, unknown priority values or namespaces are ignored; the
request is treated as if these values were not included. If there
are no valid priority values or namespaces, the request is treated as
if it had no Resource-Priority 'Resource-Priority' header field. Thus, no 417 (Unknown

Schulzrinne & Polk Expires September 18, 2004 [Page 9]

Internet-Draft Resource Priority March 2004

Resource-Priority) is generated.

4.5

4.3 User Agent Client Behavior

SIP UACs supporting this specification MUST be able to generate the
Resource-Priority
'Resource-Priority' header field for requests that require elevated
resource access priority. The UAC MUST only include at most one
Resource-Priority header field in the request.

If the request is returned with 417 (Unknown Resource-Priority), the
UAC MAY retry the request with a different namespace value, set of namespace/priority
combinations, drawing from the values returned by the Accept-Resource-Priority
'Accept-Resource-Priority' header field in the response.

4.6

4.4 User Agent Server Behavior

The OPTIONS request can be used to determine if a UAS supports the
mechanism. A compliant implementation SHOULD return a Accept-
Resource-Priority header field in OPTIONS responses enumerating all
valid resource values. An implementation MAY reveal this capability
only to authorized UACs.

If the UAS understands the resource value, but refuses to honor the

Schulzrinne/Polk [Page 8]

Internet Draft Resource Priority July 24, 2003
request with elevated priority for this particular user, it returns
the 403 (Forbidden) response code. It MAY include the list of
resource values that the user is allowed to use in the Accept-
Resource-Priority
'Accept-Resource-Priority' response header field.

The lookup of the authorized values may take significant resources
since it may involve an AAA interaction. Thus, it seems imprudent
to require that the list is customized to the user. In general,
legitimate users know their highest resource value that they are
entitled to.

The precise effect of the Resource-Priority 'Resource-Priority' indication depends on
the type of UAS, the namespace and local policy. For example, a circuit-
switched
circuit-switched telephony gateway might move requests with elevated
priority to the front of the queue of requests waiting for outbound
lines, it may utilize additional resources or it may preempt existing
calls. For a terminal, such as a SIP phone, requests with elevated
priority might trigger a special alert tone or preempt other,
lower-priority ongoing calls. The generic protocol mechanism
described here does not mandate the particular element behavior, but
namespace definitions, such as the ones in Section B, 9.5, need to spell
out the desired behavioral properties of user agents and proxy
servers.

4.7

4.5 Proxy Behavior

SIP proxies may MAY ignore, inspect, insert and modify the Resource-
Priority
'Resource-Priority' header field. SIP proxies MAY downgrade the Resource-
Priority
'Resource-Priority' of a request or reject unauthenticated requests.
If there are multiple namespace or priority choices available to the
user agent, a proxy MAY return the request with an appropriate
'Accept-Resource-Priority' header field. Details are a matter of

Schulzrinne & Polk Expires September 18, 2004 [Page 10]

Internet-Draft Resource Priority March 2004

local policy.

This behavior is similar to that for any header field, as a UA can
decide to reject a request for the presence, absence or value of
any information in the request. The session policy mechanism does
not fit well, as user agents may not have a choice in the
namespace or priority available to them, there are no privacy
concerns and the resource priority mechanism does not involve
message bodies or session descriptions.

If a stateful proxy has authorized a particular resource priority
level and if it offers differentiated treatement to responses
containing resource priority levels, the proxy SHOULD ignore any
higher value contained in responses, to avoid that colluding user
agents artificially raise the priority level.

It is unlikely that the resource priority value in responses will
have any influence on response handling.

A SIP proxy MAY use the Resource-Priority 'Resource-Priority' indication in its
routing decisions, e.g., to find a next hop that is reserved for a
particular resource priority.

There do not appear to be any special considerations when forking
requests containing a resource priority indication.

Otherwise, the proxy behavior is the same as for user agent
servers
(Section 4.6).

5 Section 4.4).

5. Third-Party Authentication

Schulzrinne/Polk [Page 9]

Internet Draft Resource Priority July 24, 2003

In some case, the RP actor may not be able to authenticate the
requestor or determine whether an authenticated user is authorized to
make such a request. In these circumstances, the SIP entity may
avail itself of general SIP mechanisms that are not specific to this
application. The authenticated identity management mechanism [7]
[I-D.ietf-sip-authid-body] allows a third party to verify the
identity of the requestor and certify this towards an RP actor. In
networks with mutual trust, the SIP asserted identity mechanism [13]
[RFC3325] can help the RP actor determine the identity of the
requestor.

6. Backwards Compatibility

The resource priority mechanism described in this document is fully
backwards compatible with SIP systems following RFC 3261 [2].
Naturally, systems [RFC3261].
Systems that do not understand the mechanism can only deliver
standard, not elevated, service priority. User agent servers and

Schulzrinne & Polk Expires September 18, 2004 [Page 11]

Internet-Draft Resource Priority March 2004

proxies can ignore any Resource-Priority 'Resource-Priority' header field just like any
other unknown header field and then treat the request like any other
request. Naturally, the request may still succeed.

Introducing Require 'Require' or Proxy-Require 'Proxy-Require' would not help, as systems
that do not support the mechanism will not improve by rejecting the
request due to feature failure. Since the intent of resource
priority indications is to increase the probability of call
completion, adding failure modes appears counterproductive.

7. Examples

The SDP message body and the BYE and ACK exchanges are the same as in
[8]
RFC 3665 [RFC3665] and omitted for brevity.

7.1 Simple Call

User A User B
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |

Schulzrinne/Polk [Page 10]

Internet Draft Resource Priority July 24, 2003

In this scenario, User A completes a call to User B directly. The
call from A to B is marked with a resource priority indication.

F1 INVITE User A -> User B

INVITE sip:UserB@biloxi.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.com>
Call-ID: 3848276298220188511@atlanta.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...

Schulzrinne & Polk Expires September 18, 2004 [Page 12]

Internet-Draft Resource Priority March 2004

...

F2 180 Ringing User B -> User A

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserB@client.biloxi.com;transport=tcp>
Content-Length: 0

F3 200 OK User B -> User A

SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserB@client.biloxi.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...

Schulzrinne/Polk [Page 11]

Internet Draft Resource Priority July 24, 2003

...

7.2 Receiver Does Not Understand Namespace

In this example, the receiving UA does not understand the "dsn"
namespace and thus returns a 417 (Unknown Resource-Priority) status
code. We omit the message details for messages F5 through F7 since
they are essentially the same as in the first example.

Schulzrinne & Polk Expires September 18, 2004 [Page 13]

Internet-Draft Resource Priority March 2004

User A User B
| |
| INVITE F1 |
|----------------------->|
| 417 R-P failed F2 |
|<-----------------------|
| ACK F3 |
|----------------------->|
| |
| INVITE F4 |
|----------------------->|
| 180 Ringing F5 |
|<-----------------------|
| 200 OK F6 |
|<-----------------------|
| ACK F7 |
|----------------------->|
| |
| Both Way RTP Media |
|<======================>|

F1 INVITE User A -> User B

Schulzrinne/Polk [Page 12]

Internet Draft Resource Priority July 24, 2003

Content-Type: application/sdp
Content-Length: ...

...

F2 417 Resource-Priority failed User B -> User A

SIP/2.0 417 Resource-Priority failed
Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.com
CSeq: 1 INVITE

Schulzrinne & Polk Expires September 18, 2004 [Page 14]

Internet-Draft Resource Priority March 2004

Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4
Contact: <sip:UserB@client.biloxi.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 0

F3 ACK User A -> User B

ACK sip:UserB@biloxi.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bd5
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.com
CSeq: 1 ACK
Content-Length: 0

F4 INVITE User A -> User B

INVITE sip:UserB@biloxi.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.com>
Call-ID: 3848276298220188511@atlanta.com
CSeq: 2 INVITE
Resource-Priority: q735.3
Contact: <sip:UserA@client.atlanta.com;transport=tcp>

Content-Type: application/sdp
Content-Length: ...
...

Schulzrinne/Polk [Page 13]

Internet Draft Resource Priority July 24, 2003

8. Security Considerations

Any resource priority mechanism can be abused to obtain resources and
thus deny service to other users. An adversary may be able to take
over a particular gateway, cause additional congestion during PSTN
during emergencies or deny service to legitimate ETS 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. Below, we
describe authentication and authorization aspects, confidentiality
and privacy requirements, protection against denial of service
attacks and anonymity requirements. Naturally, the general
discussion in RFC 3261
[2] [RFC3261] applies.

Schulzrinne & Polk Expires September 18, 2004 [Page 15]

Internet-Draft Resource Priority March 2004

8.1 Authentication and Authorization

Prioritized access to network and end system resources imposes
particularly stringent requirements on authentication and
authorization mechanisms since access to prioritized resources may
impact overall system stability and performance, not just result in
theft of, say, a single phone call.

Under certain emergency conditions, the network infrastructure,
including its authentication and authorization mechanism, may be
under attack.

Given the urgency during emergency events, normal statistical fraud
detection may be less effective, thus placing a premium on reliable
authentication.

Common requirements for authentication mechanisms apply, such as
resistance to replay, cut-and-paste and bid-down attacks.

Authentication MAY be SIP-based or use other mechanisms. Use of
Digest authentication and/or S/MIME is RECOMMENDED for UAS
authentication, but it
authentication. Digest authentication requires that the parties
share a common
secret. secret, thus limiting its use across administrative
domains. SIP systems employing resource priority MUST SHOULD implement
S/MIME S/
MIME at least for integrity, as described in Section 23 of [2]. [RFC3261].
However, in some environments, asserted identity [RFC3325] and
transitive trust may be used to build a sufficiently robust system.
Section 5 describes third-party authentication.

Role-based

Trait-based authorization [14] [I-D.ietf-sipping-trait-authz] "entails an
assertion by a authorization service of attributes associated with an
identity" and may be appropriate for this application as it avoids
that all network elements need to maintain or consult a mapping from
user identifiers to authorizations.

Authorization may be based on factors beyond the identity of the
caller, such as the requested destination. Namespaces MAY also
impose particular authentication or authorization consideration that
are stricter than the baseline described here.

8.2 Confidentiality and Integrity

Schulzrinne/Polk [Page 14]

Internet Draft Resource Priority July 24, 2003

All aspects of Emergency Telecommunications Systems (ETS)

Calls which use elevated resource priority levels provided by the
'Resource-Priority' header field are likely to be sensitive and must often
need to be protected from intercept and alteration. In particular,
requirements for protecting the confidentiality of communications
relationships may be higher than for normal commercial service. For
SIP, the To, From, Organization, Subject 'To', 'From', 'Organization', 'Subject' and Via 'Via' header

Schulzrinne & Polk Expires September 18, 2004 [Page 16]

Internet-Draft Resource Priority March 2004

fields are examples of particularly sensitive information. Systems
MUST provide for implement encryption at the transport level using TLS and MAY
implement other transport-layer or network-layer security mechanisms.
UACs SHOULD use the "sips" URI to request a secure transport
association to the destination.

The Resource-Priority 'Resource-Priority' header field can be carried in the SIP
message header or can be encapsulated in a message fragment carried
in the SIP message body [9]. [RFC3420]. Encapsulation in S/MIME body
parts allows the user to protect this header field against inspection
or modification by proxies, using S/MIME. proxies. However, in many cases, proxies will
need to authenticate and authorize the request, so that encapsulation
is undesirable.

Removal of a Resource-Priority header field or downgrading its
priority value affords no additional opportunities to an adversary
since that man-in-the-middle could simply drop or otherwise
invalidate the SIP request and thus prevent call completion.

Only SIP elements within the same administrative trust domain
employing a secure channel between their SIP elements will trust a
Resource-Priority header field that is not appropriately signed.
Others will need to authenticate the request independently. Thus,
insertion of a Resource-Priority header field or upgrading the
priority value has no further security implications except causing a
request to fail (see discussion in the previous paragraph).

8.3 Anonymity

Some users may wish to remain anonymous to the request destination.
Anonymity for requests with resource priority is no different than
for any other authenticated SIP request. For the reasons noted
earlier, users have to authenticate themselves towards the SIP
elements carrying the request where they desire resource priority
treatment. The authentication may be based on capabilities and noms,
not necessarily their civil name. Clearly, they may remain anonymous
towards the request destination, using the network-asserted identity
and general privacy mechanisms [15,13]. [RFC3323][RFC3325].

8.4 Denial-of-Service Attacks

As noted, ETS systems described here are likely to be subject to
deliberate denial- of-service attacks during certain types of
emergencies. DOS attacks may be launched on the network itself as
well as its authentication and authorization mechanism. As noted,
systems should minimize the amount of state, computation and network
resources that an unauthorized user can command. The system must not
amplify attacks by causing the transmission of more than one packet

Schulzrinne & Polk Expires September 18, 2004 [Page 17]

Internet-Draft Resource Priority March 2004

to a network address whose reachability has not been verified.

9. IANA Considerations

9.1 IANA Registration of Resource-Priority 'Resource-Priority' and Accept-Resource-Priority
'Accept-Resource-Priority' Header Fields

[NOTE TO RFC EDITOR: Replace RFC XXXX with RFC number of this
document.]

The following is the registration for the Resource-Priority 'Resource-Priority' header
field:

RFC number: RFCxxxx

Schulzrinne/Polk [Page 15]

Internet Draft Resource Priority July 24, 2003 XXXX
Header name: Resource-Priority 'Resource-Priority'
Compact form: none

The following is the registration for the Accept-Resource-Priority 'Accept-Resource-Priority'
header field:

RFC number: RFCxxxx XXXX
Header name: Accept-Resource-Priority
Compact form: none

9.2 IANA Registration for Option Tag Resource-Priority resource-priority

RFC number: RFCxxxx XXXX
Name of option tag: Resource-Priority 'resource-priority'
Descriptive text: Indicates or requests support for the resource
priority mechanism.

9.3 IANA Registration for Response Code 417

RFC number: RFCxxxx XXXX
Response code: 417
Default reason phrase: Unknown Resource-Priority

9.4 IANA Considerations Namespace and Priority Registrations

Additional namespaces and priority values are registered with IANA.
Within each namespace, the registration may indicate the relative
precedence levels, expressed as an ordered list. New labels should
not be added to existing namespaces. The registration MUST indicate the default level to be assumed describe,
in the absence of the
priority value or if an implementation does not understand a level
from the namespace. New labels should not be added to existing
namespaces. The registration SHOULD describe itself or by reference, how SIP elements should
treat requests from that namespace, e.g., whether preemption or only
preferential queueing are allowed. A reference to a stable external
document, e.g., by the International Telecommunication Union, other
SDOs or national regulatory bodies, suffices. An expert review, by

Schulzrinne & Polk Expires September 18, 2004 [Page 18]

Internet-Draft Resource Priority March 2004

an expert designated by the Transport Area Director or designate, is
required.

Namespaces do not describe how they relate to other existing
namespaces, as each namespace is independent of other registrations.

Schulzrinne/Polk [Page 16]

Internet Draft Resource Priority July 24, 2003

Namespaces MAY also impose particular authentication or authorization
consideration that are stricter than

Below is a template for the baseline described here.

A Addressing registration of a new namespace:

Namespace: Designation of the IEPREP Requirements

[This section may be removed before publication, depending on WG/IESG
feedback.]

Below, we describe how namespace, according to the mechanism BNF
'namespace' in this memo as well as
plausible alternatives address Section 3.
Description: Description of the requirements in [12]. For each
requirement, we indicate what existing mechanism can be used or what
candidate extensions might be suitable. In general, none use and application of this
particular namespace.
Documentation: If applicable, reference to a document describing the
currently standardized
namespace in more detail.
Organization: If applicable, organization definining this namespace.
(For example, an IETF standards-track RFC could also define a
namespace, not just an external organization.)
Policy: Either if not defined normatively elsewhere or proposed for
informative purposes, this element describes how a SIP features indicate whether element
handles requests containing priority values with this namespace.
There are many possible behaviors that cannot be exhaustively
anticipated. Three common behaviors are preemption, precedence
and threshold-exemption. Preemption means that a request makes special claims to SIP-mediated resources or not. (The
Priority header indicates the urgency to with
greater priority can displace an existing request with lower
priority that is already in progress. Precedence means that a
higher-priority request assumes a position in the human recipient queue ahead of the a
lower-priority request, but any in-progress request and is orthogonal to this issue.) not
affected by its arrival. In general, SIP offers four mechanisms to convey protocol semantics:
URIs scheme (US) or parameter (UP), header fields (H), request
methods (M), caller preferences (C) and body content (B).

Thus, there addition, systems with preemption MAY
specify whether requests that cannot obtain resources immediately
are three choices:

Deduce: Information in U, H, M, C queued or B is used rejected immediately. Threshold-exemption allows
higher-priority calls to deduce the
resource priority demand.

New: A new H, M, C or B is added.

Out-of-band: Some other protocol indicates the choice.

Where applicable, we indicate which of these three approaches and
which element might be suitable.

A.1 General Requirements

REQ-1: Not specific to one scheme or country: This requirement
implies that any SIP indication is flexible enough to
accommodate a variety of namespaces. There currently is no
indication, so current SIP cannot satisfy the requirement.

REQ-2: Independent of particular network architecture: This
requirement rules out use of a new URI type (U), since all
SIP-addressable resources need to be included. It also
makes an out-of-band protocol difficult, as that typically
pre-supposes support from network elements such as
firewalls.

REQ-3: Invisible to network (IP) layer: This requirement makes

Schulzrinne/Polk [Page 17]

Internet Draft Resource Priority July 24, 2003

use of out-of-band mechanisms difficult. Out-of-band
mechanisms also would have to be directed to the all the
same locations that the SIP request travels, adding
difficulty.

REQ-4: Mapping of existing schemes: This requirement has similar
implications as REQ-1. It calls for the ability to
accommodate multi-valued enumerations of priority levels.

REQ-5: No loss of information: This requirement stipulates that
there cannot be a many-to-one mapping, e.g., from some
scheme to a set of integers, since information about the
original scheme would be lost.

REQ-6: Extensibility: This requirement indicates the need for an
IANA registry to add additional items later.

REQ-7: Separation of policy and mechanism: The mechanism must be
labels, not prescriptions for detailed call handling.

REQ-8: Method-neutral: This rules out adding a new method that
calls for prioritized handling.

REQ-9: Default behavior: This requirement only indicates that
the specification of any such scheme needs to address
default behavior in elements that expect to receive such an
indication.

REQ-10: Address-neutral: This requirement rules out the use of
special URIs or a new URI type. It may, however, be
satisfied with a new URI parameter on all URI schemes that
may be carried in SIP. This requirement is satisfied by H,
M, B, and C.

REQ-11: Identity-independent: This rules out the use of a
special From value.

REQ-12: Independent of network location: This requirement rules
out the use of the Contact header or Via information.

REQ-13: Multiple simultaneous schemes: This requirement mandates
that the indication allow a list of names.

REQ-14: Discovery: This requirement argues for the use of
standard SIP negotiation mechanisms to determine the
capabilities of the other side, such as Require, Proxy-
Require or OPTIONS.

Schulzrinne/Polk [Page 18]

Internet Draft Resource Priority July 24, 2003

REQ-15: Testing: It does not appear that this adds additional
protocol requirements.

REQ-16: 3PCC: All mechanisms indicated appear to satisfy this
requirement.

REQ-17: Proxy-visible: This requirement rules out the use of
message bodies, since these are not meant to be inspected
or modified by proxies.

Given REQ-8, REQ-10, REQ-11, there does not appear to be an existing
indication from which a recipient can reliably deduce resource
priority. In addition, mechanisms B, M, and US fail one or more
requirements, leaving mechanisms H, C and UP.

UP requires that all SIP schemes be fitted with this parameter and
thus may make satisfying REQ-10 difficult.

Caller preferences describe desired capabilities and properties of
the end system and are used to select among a set of candidate
locations. This does not match the semantics desired here.

Thus, we will focus our attention below on the H and UP mechanisms.

The information that needs to be conveyed according to REQ-1, REQ-4,
REQ-5, REQ-10, REQ-11, and REQ-12 appears to be more suitable for a
request header. It logically does not describe the destination or
source, but rather a property of the request. URI parameters are
meant to describe properties of the

Also, there is currently no mechanism in place to negotiate support
for URI parameters.

A.2 Security Requirements

SEC-1: More rigorous: SIP-related mechanisms, access resources, such as Digest
authentication and hop-by-hop authentication, offer
suitably strong authentication mechanisms.

However, Digest authentication can currently only provide
integrity of the method, request URI and body, not header
fields. Thus, an adversary could remove the indication
header without detection. However, that is not likely to be
more disruptive than simply removing the whole request or
modifying the destination address.

Modification of the indication is not likely to be useful
to an adversary unless some form of trust domain [16] is

Schulzrinne/Polk [Page 19]

Internet Draft Resource Priority July 24, 2003

used where one element authenticates the request at a lower
priority, the adversary modifies it to a higher one and
then abuses those privileges in later SIP elements as circuits, that
trust the first element. Otherwise, increasing the priority
will only incur additional authentication requirements and
likely cause the request to fail.

The discussion in [17] investigates how signed SIP message
bodies may be used to address this issue.

SEC-2: Attack protection: This is a generic SIP requirement.
Denial of service issues
are discussed at length in [2].
The reader is referred unavailable to that document for further
details.

SEC-3: Independent of mechanism: The candidate mechanisms work
with all existing SIP security techniques.

SEC-4: Non-trusted end systems: This requirement suggests the
use of one-time passwords lower-priority calls, e.g., because they are
held in SIP. This may be implementable
on top of the existing Digest mechanism, but no such
specification exists.

SEC-5: Replay: The approved SIP authentication mechanisms
address this concern.

SEC-6: Cut-and-paste: The approved SIP authentication mechanisms
address this concern.

SEC-7: Bid-down: This concern is addressed by [stalled Digest
draft].

SEC-8: Confidentiality: reserve. If H or UP are used, body encryption is the namespace does not effective, so that channel security is called for.
Currently, SIP offers define a particular
policy, the use term 'implementation-defined' should be used.
Priority values (least to greatest): A list of IPsec and TLS.

SEC-9: Anonymity: The network-asserted identity and general
privacy mechanisms [15,13] are applicable.

SEC-10: Denial-of-service: See SEC-2.

SEC-11: Minimize resource use by unauthorized users: See SEC-2.

SEC-12: Avoid amplification: See SEC-2.

B priority values,
ordered from least to highest priority.

9.5 Initial Namespace Registrations

B.1

9.5.1 Namespace dsn

Schulzrinne/Polk [Page 20]

Internet Draft Resource Priority July 24, 2003

This document defines the namespace "dsn". The namespace "dsn"
(Defense

Namespace: dsn
Description: United States Defense Switched Network), contains the priority values "flash-
override", "flash", "immediate", "priority", "routine", with "flash-
override" as the highest priority value and "routine" as the lowest.
The default is "routine". Network. The values are
adopted from RFC 791 [10], [RFC0791], omitting the levels "critic-ecp",
"network control" and "internetwork control", as these are
inappropriate here.

B.2

Schulzrinne & Polk Expires September 18, 2004 [Page 19]

Internet-Draft Resource Priority March 2004

Documentation: ANSI T1.619, Section B1
Organization: United States Department of Defense, Defense
Information Systems Agency (DISA).
Policy: Preemption with rejection.
Priority values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override"

9.5.2 Namespace q735

This document also defines the namespace "q735".

Namespace: q735
Description: ITU Q.735.3 describes multi-level precedence and
preemption in SS7. The namespace "q735" supports interworking
with Q.735.3 (or equivalent) GSTN (ISDN) entities; this allows,
for example, carrying information between Q.735.3 entities without
loss of information. One or both of the SIP endpoints might be
PSTN gateways. The namespace contains the priority
Documentation: Q.735.3 [Q.735.3]
Organization: ITU-T
Policy: Precedence.
Priority values "0", "1", "2", "3" and (least to greatest): "4", with "4" representing the lowest
priority and "3", "2", "1", "0" the highest. The default is "4".

B.3

9.5.3 Namespace DRSN

This document defines the namespace "drsn". The namespace "drsn"
(Defense

Namespace: drsn
Description: United States Defense Red Switched Network) contains the priority Network.
Organization: United States Department of Defense, Defense
Information Systems Agency (DISA).
Policy: Preemption with rejection.
Priority values "flash-
override-override", "flash-override", "flash", "immediate",
"priority", (least to greatest): "routine", with "priority",
"immediate", "flash", "flash-override", "flash-override-override" as the highest
priority value

10. Acknowledgments

Ben Campbell, Janet Gunn, Paul Kyzivat, Rohan Mahy, Mike Pierce and "routine" as the lowest. "Routine" is the default.

C References

D
Samir Srivastava provided helpful comments.

Normative References

[1] S.

[Q.735.3] International Telecommunications Union, "Stage 3
description for community of interest supplementary
services using Signalling System No. 7: Multi-level
precedence and preemption", Recommendation Q.735.3, March
1993.

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement
levels," Indicate

Schulzrinne & Polk Expires September 18, 2004 [Page 20]

Internet-Draft Resource Priority March 2004

Requirement Levels", BCP 14, RFC 2119, Internet Engineering Task Force, Mar. March 1997.

[2] J.

[RFC3261] Rosenberg, H. J., Schulzrinne, G. H., Camarillo, A. R. G., Johnston, J.
A., Peterson, R. J., Sparks, M. R., Handley, M. and E. Schooler,
"SIP: session
initiation protocol," Session Initiation Protocol", RFC 3261, Internet Engineering Task Force, June 2002.

[3] International Telecommunication Union, "Stage 3 description for
community of interest supplementary services using signalling system
no. 7: Multi-level precedence and preemption," Recommendation
Q.735.3, Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Mar. 1993.

[4] B. Campbell, J.

[RFC3262] Rosenberg, J. and H. Schulzrinne, eds., "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.

[RFC3265] Roach, A., "Session
initiation protocol (SIP) extension for instant messaging," Initiation Protocol (SIP)-Specific
Event Notification", RFC 3428,

Schulzrinne/Polk [Page 21]

Internet Draft Resource Priority July 24, 2003

Internet Engineering Task Force, Dec. 3265, June 2002.

[5] J.

[RFC3311] Rosenberg, J., "The session initiation protocol Session Initiation Protocol (SIP)
UPDATE
method," Method", RFC 3311, Internet Engineering Task Force, Oct. October 2002.

[6] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002.

[7] J. L. Peterson, "Enhancements for authenticated identity
management in the session initiation protocol (SIP)," internet draft,
Internet Engineering Task Force, Mar. 2003. Work in progress.

[8] A. R. Johnston, "Session initiation protocol basic call flow
examples," internet draft, Internet Engineering Task Force, Apr.
2003. Work in progress.

[9] R.

[RFC3420] Sparks, R., "Internet media type message/sipfrag," Media Type message/sipfrag", RFC
3420,
Internet Engineering Task Force, Nov. November 2002.

[10] J. B. Postel, "Internet protocol," RFC 791, Internet Engineering
Task Force, Sept. 1981.

E Informative References

[11] H. Schulzrinne, "Requirements for resource priority mechanisms
for the session initiation protocol (SIP)," RFC 3487, Internet
Engineering Task Force, Feb. 2003.

[12] H.

[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, "Requirements for resource priority mechanisms
for the session initiation protocol," internet draft, Internet
Engineering Task Force, Dec. 2002. Work in progress.

[13] H., Huitema, C. Jennings, J. Peterson,
and M. Watson, "Private extensions to
the session initiation protocol D. Gurle, "Session Initiation Protocol (SIP) Extension
for asserted identity within
trusted networks," Instant Messaging", RFC 3325, Internet Engineering Task Force, Nov. 3428, December 2002.

[14] J. L.

Informative References

[I-D.ietf-ieprep-framework]
Carlberg, K., Brown, I. and C. Beard, "Framework for
Supporting IEPS in IP Telephony",
draft-ietf-ieprep-framework-08 (work in progress),
February 2004.

[I-D.ietf-sip-authid-body]
Peterson, "Role-based authorization requirements J., "SIP Authenticated Identity Body (AIB)
Format", draft-ietf-sip-authid-body-02 (work in progress),
July 2003.

[I-D.ietf-sipping-trait-authz]
Peterson, J., "Trait-based Authorization Requirements for
the
session initiation protocol," internet draft, Internet Engineering
Task Force, Feb. 2003. Work in progress.

[15] J. Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-00 (work in progress),
February 2004.

[RFC3323] Peterson, J., "A privacy mechanism Privacy Mechanism for the session initiation
protocol (SIP)," Session
Initiation Protocol (SIP)", RFC 3323, Internet Engineering Task Force, Nov. November 2002.

[16] M.

[RFC3324] Watson, M., "Short term requirements Term Requirements for network asserted
identity," Network Asserted
Identity", RFC 3324, Internet Engineering Task Force, Nov. November 2002.

Schulzrinne/Polk

Schulzrinne & Polk Expires September 18, 2004 [Page 22]

Internet Draft 21]

Internet-Draft Resource Priority July 24, 2003

[17] R. Mahy, "Discussion of suitability: S/MIME instead of digest
authentication in March 2004

[RFC3325] Jennings, C., Peterson, J. and M. Watson, "Private
Extensions to the session initiation protocol (SIP)," internet
draft, Internet Engineering Task Force, July Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.

[RFC3487] Schulzrinne, H., "Requirements for Resource Priority
Mechanisms for the Session Initiation Protocol (SIP)", RFC
3487, February 2003. Work in progress.

F Acknowledgments

Mike Pierce

[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and Rohan Mahy provided helpful comments.

G
K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.

Authors' Addresses

Henning Schulzrinne
Dept.
Columbia University
Department of Computer Science
Columbia University
1214 Amsterdam Avenue
450 Computer Science Building
New York, NY 10027
United States
electronic mail: schulzrinne@cs.columbia.edu
US

Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu

James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082
United States
electronic mail:
US

EMail: jmpolk@cisco.com

Schulzrinne & Polk Expires September 18, 2004 [Page 22]

Internet-Draft Resource Priority March 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in standards-track and
standards-related documentation IETF Documents can
be found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors implementers or users of this
specification can be obtained from the IETF Secretariat. on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

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 implmentation may be prepared, copied, published and

Schulzrinne/Polk [Page 23]

Internet Draft Resource Priority July 24, 2003

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, patents or patent applications, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not proprietary
rights that may cover technology that may be
revoked by required to implement
this standard. Please address the Internet Society or its successors or assigns. information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein is are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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.

Schulzrinne/Polk [Page 24]

Table of Contents

1 Conventions Used in This Document ................... 2
2 Introduction ........................................ 2
3

Copyright (C) The Resource-Priority and Accept-Resource-Priority
SIP Header Fields .............................................. 4
4 Behavior of SIP Elements that Receive Prioritized
Requests ....................................................... 6
4.1 General Rules ....................................... 6
4.2 Error Conditions .................................... 7
4.3 Known Namespace and Priority Value .................. 7
4.4 Handling Unknown Namespaces and Priority Values ..... 7
4.4.1 Strict Mode ......................................... 8
4.4.2 Loose Mode .......................................... 8
4.5 User Agent Client Behavior .......................... 8
4.6 User Agent Server Behavior .......................... 8
4.7 Proxy Behavior ...................................... 9
5 Third-Party Authentication .......................... 9
6 Backwards Compatibility ............................. 10
7 Examples ............................................ 10
7.1 Simple Call ......................................... 10
7.2 Receiver Does Not Understand Namespace .............. 12
8 Security Considerations ............................. 14
8.1 Authentication and Authorization .................... 14
8.2 Confidentiality Internet Society (2004). This document is subject
to the rights, licenses and Integrity ....................... 14
8.3 Anonymity ........................................... 15
8.4 Denial-of-Service Attacks ........................... 15
9 IANA Registration of Resource-Priority restrictions contained in BCP 78, and
Accept-Resource-Priority Header Fields ......................... 15
10 IANA Registration for Option Tag Resource-Priority
................................................................ 16
11 IANA Registration
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for Response Code 417 ............. 16
12 IANA Considerations ................................. 16
A Addressing the IEPREP Requirements .................. 17
A.1 General Requirements ................................ 17
A.2 Security Requirements ............................... 19
B Initial Namespace Registrations ..................... 20
B.1 Namespace dsn ....................................... 20
B.2 Namespace q735 ...................................... 21
B.3 Namespace DRSN ...................................... 21
C References .......................................... 21
D Normative References ................................ 21
E Informative References .............................. 22

Schulzrinne/Polk [Page 1] RFC Editor function is currently provided by the
Internet Draft Resource Priority July 24, 2003

F Acknowledgments ..................................... 23
G Authors' Addresses .................................. 23

Schulzrinne/Polk Society.

Schulzrinne & Polk Expires September 18, 2004 [Page 2] 23]

----