WDIFF

draft-ietf-sip-resource-priority-05.txt --> draft-ietf-sip-resource-priority-06.txt

SIP Working Group J. Polk
Internet-Draft Cisco
Expires: August 21st, 2005 H. Schulzrinne
Internet-Draft
Columbia U.
Expires: April 25th,
February 21st, 2005 J. Polk
Cisco
October 25th, 2004

Communications Resource Priority for the Session Initiation Protocol
(SIP)
draft-ietf-sip-resource-priority-05
draft-ietf-sip-resource-priority-06

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 any of which I become aware will be disclosed, in accordance
with RFC 3668.

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

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

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

This Internet-Draft will expire on April 25th, August 21st, 2005.

Abstract

This document defines two new 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 Session Initiation Protocol (SIP) SIP proxies. It does not directly influence the
forwarding behavior of IP routers.

Schulzrinne &

Polk [Page & Schulzrinne [page 1]
Internet-Draft SIP Resource Priority October 25th, 2004 February 21st, 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 5 6
3.1 The 'Resource-Priority' Header Field . . . . . . . . . . . 5 6
3.2 The 'Accept-Resource-Priority' Header Field . . . . . . . 6 7
3.3 Usage of the 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . . . . . . . . . 7
3.4 The 'resource-priority' Option Tag . . . . . . . . . . . . 8
4. Behavior of SIP Elements that Receive Prioritized Requests . . 8
4.1 General Rules . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 Policy Guidelines Involving Preemption Policy . . . . . 9
4.2 Rejection Messages Usage of Require Header with Resource-Priority . . . . . . . 9
4.3 OPTIONS Request with Resource-Priority . . . . . . . . . . . 9
4.4 Alternatives for Preferential Treatment of Requests . . 9
4.3 Error Conditions . . 10
4.4.1 Preemption Policy . . . . . . . . . . . . . . . . . . . 10
4.3.1 Known Namespace and
4.4.2 Priority Value . . . . . Queuing Policy . . . . . 10
4.3.2 Handling Unknown Namespaces and Priority Values . . . 11
4.3.3 Strict Mode . . . . . . . . 10
4.5 Rejection Messages . . . . . . . . . . . . . 11
4.3.4 Semi-Strict Mode . . . . . . . 11
4.6 Error Conditions . . . . . . . . . . . . 12
4.3.5 Loose Mode . . . . . . . . . 12
4.6.1 Known Namespace and Priority Value . . . . . . . . . . 12
4.6.2 Handling Unknown Namespaces and Priority Values . . . 14
4.4 12
4.7 User Agent Client Behavior . . . . . . . . . . . . . . . . 14
4.5 13
4.7.1 User Agent Client Behavior with a Preemption Policy . . 13
4.7.2 User Agent Client Behavior with a Priority Queue Policy 13
4.8 User Agent Server Behavior . . . . . . . . . . . . . . . . 14
4.5.1 13
4.8.1 User Agent Servers and Preemption Policy . . . . . . . . 15
4.6 Proxy Behavior . . . . . . . 14
4.8.1 User Agent Servers and Priority-Queue Policy . . . . . . 14
4.9 Proxy Behavior . . . . . . . . . 15
4.6.1 Proxies and Preemption Policy . . . . . . . . . . . . . 16 14
5. Third-Party Authentication . . . . . . . . . . . . . . . . . . 16 15
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 16 15
7. Namespace Description Multiple Namespaces in a Message . . . . . . . . . . . . . . 16
8. Namespace Definitions . . . . . . 17
7.1 Multiple Namespaces in a Message . . . . . . . . . . . . . . 19
8. Examples 18
8.1 Namespace Descriptions . . . . . . . . . . . . . . . . . . . 18
8.1.1 The "DSN" Namespace . . . . . . . . 21
8.1 Simple Call . . . . . . . . . . 18
8.1.2 The "DRSN" Namespace . . . . . . . . . . . . . 21
8.2 Receiver Does Not Understand Namespace . . . . . 19
8.1.3 The "Q735" Namespace . . . . . 22
9. Security Considerations . . . . . . . . . . . . . 20
8.1.4 The "ETS" Namespace . . . . . . 24
9.1 Authentication and Authorization . . . . . . . . . . . . 20
8.1.5 The "WPS" Namespace . 25
9.2 Confidentiality and Integrity . . . . . . . . . . . . . . 26
9.3 Anonymity . . . 22
8.2 Future Namespace Considerations . . . . . . . . . . . . . . 24
9. Examples . . . . . . . 27
9.4 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . 25
9.1 Simple Call . . . . . . . . . . . . . . . . . 27
10.1 IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . . . . . . 25
9.2 Receiver Does Not Understand Namespace . . . 27 . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1 Authentication and Authorization . . . . . . . . . . . . . 29
10.2 Confidentiality and Integrity . . . . . . . . . . . . . . 30
10.3 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 31
10.4 Denial-of-Service Attacks . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11.1 IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields . . . . . . . . . 32
11.2 IANA Registration for Option Tag resource-priority . . . . 28
10.3 32

Polk & Schulzrinne [page 2]
Internet-Draft SIP Resource Priority February 21st, 2005

11.3 IANA Registration for Response Code 417 . . . . . . . . . 28
10.4 32
11.4 IANA Namespace Registrations . . . . . . . . . . . . . . . 28
10.5 32
11.5 IANA Priority-Value Registrations . . . . . . . . . . . . 29
11. 33
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
12. . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1 . 34
13.1 Normative References . . . . . . . . . . . . . . . . . . . . 30
12.2 34
13.2 Informative References . . . . . . . . . . . . . . . . . . . 30 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 36
Intellectual Property and Copyright Statements . . . . . . . . 32

Schulzrinne & Polk [Page 2]
Internet-Draft SIP Resource Priority October 25th, 2004 36

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.

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

Polk & Schulzrinne [page 3]
Internet-Draft SIP Resource Priority February 21st, 2005

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) a new SIP [RFC3261] header field
for communications resource priority, called 'Resource-Priority' This
header field MAY be used by SIP user agents, including General
Switched Telephone Network (GSTN) gateways and terminals, and SIP

Schulzrinne & Polk [Page 3]
Internet-Draft SIP Resource Priority October 25th, 2004
proxy servers to influence their treatment of SIP requests, including
the priority afforded to GSTN calls. For GSTN gateways, the behavior
translates into analogous schemes in the GSTN, for example the ITU
Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both
the GSTN-to-IP and IP-to-GSTN directions. ITU Recommendation I.255.3
[I.255.3] is another example.

The 'Resource-Priority' header field may be used in several
situations. A SIP request with such an indication can be treated
differently in 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 [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 delay, reject or error existing signaling requests or bypass
GSTN gateway capacity limits in effect for
of lower priorities.

This header field is related to, but differs in semantics from, the
'Priority' header field (RFC 3261 [RFC3261], Section 20.26). The
'Priority' header field describes the importance that the SIP request
should have to the receiving human or its agent. For example, that
header may be factored into decisions about call routing to mobile
devices and assistants and call acceptance when the call destination
is busy. The 'Priority' header field does not affect the usage of
GSTN gateway or proxy resources, for example. In addition, any User
Agent Client (UAC) can assert any 'Priority' value, while access to
resource priority values are subject to authorization.

While 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 the

Polk & Schulzrinne [page 4]
Internet-Draft SIP Resource Priority February 21st, 2005

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.

Schulzrinne & Polk [Page 4]
Internet-Draft SIP Resource Priority October 25th, 2004

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

We define the header field syntax in Section

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 the protocol
behavior in Section 4. The two principal mechanisms for
differentiated treatment of user agents SIP requests, namely preemption and proxies
queuing, are described in Section 4.3 4.4. Rejection messages are
covered in Section 4.5, error conditions in Section 4.6. Section 4.7
through Section
4.5. 4.9 detail the behavior of specific SIP elements.
Third-party authentication is briefly summarized in Section 5.
Section 6 briefly describes how this feature affects existing systems that
do not support it. Third-party authentication is
discussed Sections 7 and 8 delve into namespace issue,
namely their general properties, how to deal with multiple
namespaces on the same SIP element and in the same SIP message,
as well as enumerating five namespaces that are registered through
this document. Protocol examples are given in Section 5, while general security 9. Security
issues are enumerated considered in Section 8. This specification 10, but this document does not propose any
define new SIP security mechanisms. Examples can be found in Section 7.

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

Polk & Schulzrinne [page 5]
Internet-Draft SIP Resource Priority February 21st, 2005

implementations.

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

This document defines the 'Resource-Priority' and
'Accept-Resource-Priority' SIP header fields. field syntax. Behavior is
described in Section 4..

The SIP element behavior is described for user agent clients (UACs)
in Section 4.3, 4.7, for UAS in Section 4.4 4.8 and for SIP proxy servers in
Section 4.5. 4.9.

3.1 The 'Resource-Priority' Header Field

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

Schulzrinne & Polk [Page 5]
Internet-Draft SIP Resource Priority October 25th, 2004
resource priority that was granted to the request. While it is
likely those responses contain the same 'Resource-Priority' header
field value as the requests, local policy MAY call for the UAS to
insert no header field or a different value.

There is no protocol requirement that all requests within a SIP
dialog or session use the 'Resource-Priority' header field. Again, local Local
administrative policy dictates MAY mandate the appropriate behavior; thus, implementations inclusion of the 'Resource-
Priority' header field in all requests. Implementations of this
specification MUST allow inclusion to be configurable accordingly. either by explicit user
request or automatic.

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: q735.1, dsn.flash

The 'Resource-value' parameter in the '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 in a SIP message.
Each resource 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.
ASCII tokens that do not contain periods. Thus, �dsn.flash� and

Polk & Schulzrinne [page 6]
Internet-Draft SIP Resource Priority February 21st, 2005

�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
9). 11). Initial
namespace registrations are described in Section 9.5.

There may be 11.4.

Since a request may traverse multiple resource values or, equivalently, administrative domains with
multiple
'Resource-Priority' 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 some combination. The ordering of r-values
within the header field instances. 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
accept. The syntax of the 'Accept-Resource-Priority' header field is
as follows:

Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
[r-value *(COMMA r-value)]

Schulzrinne & Polk [Page 6]
Internet-Draft SIP Resource Priority October 25th, 2004

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 as 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 RFC3261
[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

Polk & Schulzrinne [page 7]
Internet-Draft SIP Resource Priority February 21st, 2005

[RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB)
method is in [I-D.ietf-sip-publish].) [RFC3903].)

Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Resource-Priority r amdr c c c c c c c o o o o o o o
Resource-Priority 200 - amdr o - o o o o o
Accept-Resource-Priority 200 - o amdr o - o o o o o
Accept-Resource-Priority 417 amdr o - m - m m m m m o o o o o
Accept-Resource-Priority 420 - 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
Resource-Priority r amdr c c c c c c c o o o o o o o
Resource-Priority 200 - amdr o o o o o o o
Accept-Resource-Priority 200 - amdr o o o o o o o
Accept-Resource-Priority 417 - m m m m m m m amdr o o o o o o o
Accept-Resource-Priority 420 - amdr o o o o o o o

Section 4 will change this table depending on the 'mode' a SIP
element is operating under.

Other request methods MAY define their own handling rules; unless
otherwise specified, recipients MAY ignore these header fields.
The 'Accept-Resource-Priority' MUST SHOULD be returned in 420 (Not Supported) (Bad
Extension) responses marked as 'o' in table above if the element
implements the resource priority mechanism with some other
namespaces or priority values, but does not implement the particular
namespace or priority value contained in the this current request.

While all methods listed above allow

3.4 The 'resource-priority' Option Tag

This document also defines the optional use of "resource-priority" option tag. The
behavior is described in Section 4.2. and the
'Resource-Priority' header fields, only request methods that start a
dialog or deliver content, such as MESSAGE, are likely to benefit
from this mechanism and other methods SHOULD NOT use them. This
consideration also applies to methods not listed above.

Schulzrinne & Polk [Page 7]
Internet-Draft SIP Resource Priority October 25th, 2004

The 'Resource-Priority' header field included in a Request message
MUST be copied in the SIP response, subject to further rules in each
mode of operation (listed in section 4 of this document).

3.4 The 'resource-priority' 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 IANA registration is
in Section 11.2.

4. Behavior of SIP Elements that Receive Prioritized Requests

All SIP user agents and proxy servers that support this
specification share certain common behavior, which we describe
below.
below in Section 4.1. The behavior when encountering a 'resource-
priority' option tag in a 'Require' header field is describe in
Section 4.2. Section 4.3 describes the treatment of OPTIONS
requests. The two fundamental resource contention resolution
mechanisms, preemption and queuing, are described in Section 4.4.
Rejection Behavior specific to user agent clients is covered in
section 4.4, 4.7, for user agent servers in Section 4.5, 4.8, while Section
4.6
4.9 deals with proxy behavior.

Polk & Schulzrinne [page 8]
Internet-Draft SIP Resource Priority February 21st, 2005

4.1 General Rules

The Resource-Priority header field is potentially applicable to all
SIP request messages. As At a minimum, implementations of this
specification supporting any of the following
request types MUST support the use of Resource-Priority header to be in
compliance with this specification for those request types: specification:

1) INVITE [RFC3261]
2) ACK [RFC3261]
3) PRACK [RFC3262]
4) MESSAGE [RFC3428]
5) UPDATE [RFC3311]
5) REFER [RFC3515]

and SHOULD support the Resource-Priority header in the following
request types (if the SIP element does) to be in compliance with
this specification:

6) MESSAGE [RFC3428]
7) SUBSCRIBE [RFC3265]
7)
8) NOTIFY [RFC3265]
8) REFER [RFC3515]

Note that this does not require imply all implementations to support every
request type method listed.

If a SIP element receives the Resource-Priority header in a Request
message other than what is listed above, the header MAY be ignored,
but not
according to the message because foundational rules of [RFC3261].

4.2 Usage of Require Header with Resource-Priority

Following standard SIP behavior, if a SIP request contains the
Require header was present (but could be for
other reasons not listed here).

An OPTIONS request can be used to determine if an element supports field with the mechanism. A compliant implementation �resource-priority� option tag, a SIP
element MUST return respond with a
'Accept-Resource-Priority' header field in 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.3 OPTIONS Request with Resource-Priority

An OPTIONS request can be used to determine if an element supports
the mechanism. A compliant implementation MUST return a
'Accept-Resource-Priority' header field in OPTIONS responses
enumerating all valid resource values. An implementation RP actor MAY reveal
this capability be
configured not to return such values or only return them to
authorized UACs.

Note that an overloaded UAS may not be able to provide this

Schulzrinne & Polk [Page 8]
Internet-Draft SIP Resource Priority October 25th, 2004

information at all times.) requestors.

Note that according to RFC 3261, proxies reached with a Max-Forwards

Polk & Schulzrinne [page 9]
Internet-Draft SIP Resource Priority February 21st, 2005

value of zero answer the OPTIONS request, allowing a UAC to discover
the capabilities of both proxy and user agent servers.

4.1.1 Policy Guidelines Involving Preemption Policy

Not every implementation

4.4 Alternatives for Preferential Treatment of Requests

SIP elements may use the Resource Priority Header involves
preemption. In fact, it is expected that resource priority mechanism to modify a minority
variety of domains
implementing this specification will enable preemption, though
critical in those domains; thus preemption policies cannot be
minimized. With that said, a word behavior such as routing requests, authentication
requirements or two is needed to address logging. the
expected general behavior of a policy that includes preemption request itself or of
resources for SIP elements supporting this specification:

SIP messages themselves are not preempted due to this header.

For SIP elements compliant with the session
created by the request. We use the terms session and call
interchangeably in this specification, SIP messages
containing document, both implying a valid Resource Priority header are prioritized higher continuous data
stream between two or lower than other messages. Since [RFC3261] states SIP headers
not understood more parties. Sessions are ignored, the presence of this header SHOULD NOT
adversely affect established by SIP elements that are not aware of, nor supports
this specification. If
dialogs.

Below, we define two common policies, namely preemption and priority
queuing. Preemption applies only to sessions created by SIP
requests, while both sessions and request handling can be subject to
priority queuing. Both policies can sometimes be combined in the presence
same element, although none of this header is supported,
but either the namespace or the priority value are not recognized,
section 4.3 of namespaces described in this
document addresses appropriate error responses. do this. Policies can be defined for each namespace or, in
some cases, can be specific to an administrative domain.

Naturally, only SIP messages elements that create understand this mechanism and the
namespace and resource value perform these policies. Section 4.8
discusses what happens if an RP actor does not understand namespaces
or have created priority values contained in a request.

4.4.1 Preemption Policy

An RP actor following a dialog can cause preemption policy may disrupt an existing
session to make room for a higher-priority incoming session. Since
sessions may require different amounts of another dialog with the usage bandwidth or number of this specification.
The specific behaviors
circuits, a single higher priority session may displace more than
one lower-priority session. As noted above, the processing of SIP elements with regard to preemption
policy
requests itself is included in 4.5 not preempted. Thus, since proxies do not manage
sessions, they do not perform preemption.

[I-D.ietf-sipping-reason-header-for-preemption] for UAS and gateway behavior, more details
and section
4.6 examples of this behavior.

UAS behavior for Proxy Servers.

4.2 Rejection Messages

The following preemption is discussed in Section 4.8.

4.4.2 Priority Queuing Policy

In a list of rejections to SIP messages priority queuing policy, requests that contain find no available
resources are queued on a
Resource-Priority header specifically because of first-come, first-served basis to the contents of
queue assigned to the
header.

If a UA is currently occupied with another session and receives a
dialog generating message priority value. Each priority value may have
its own queue or several priority values may share a single queue.
If a resource becomes available, a request from the queue with the
highest priority is served. Each queue can hold a finite number of

Polk & Schulzrinne [page 10]
Internet-Draft SIP Resource Priority February 21st, 2005

pending requests. If the queue for a newly arriving request is full,
the request is rejected immediately. In addition, a priority queuing
policy MAY impose a residence time limit. If a request exceeds a
specified waiting time, the RP actor then rejects the request and
removes it from the queue.

In addition, an RP actor MAY impose a global queue size limit summed
across all queues and drop waiting lower-priority requests. This
does not imply preemption since the session has not been established
yet.

Often, normal, non-prioritized requests will not be queued, i.e.,
the queue size for such requests is zero.

4.5 Rejection Messages

The following is a list of rejections to SIP messages that contain a
Resource-Priority header specifically because of the contents of the
header.

If a UA is currently occupied with another session and receives a
dialog generating message containing a valid Resource-Priority
header of equal or lower relative priority value, the response is
the same as stated in section 13.3.1.3 of [RFC3261]:

- a 486 (Busy Here) is returned if the UAS knows it cannot or will
not accept the request,

- a 600 (Busy Everywhere) is returned if the UAS knows there are no
other SIP elements that can accept the INVITE, and

Schulzrinne & Polk [Page 9]
Internet-Draft SIP Resource Priority October 25th, 2004

- a 488 (Not Acceptable Here) if the UAS is rejecting the INVITE.

[RFC3261] advises that a 488 response SHOULD include a warning
header with a reason for the rejection.

If the message from the UAC contains a known namespace, and the
priority-value is higher than is authorized, this error condition is
addressed in the next subsection (4.3). (4.6).

In the case in which a UA UAS is currently occupied with another
session and receives an INVITE containing a valid Resource-Priority
header of higher relative priority than that of the current dialog,
this does not create an error condition. The UAS will act according
to the
current dialog is rejected with a BYE Request as per
[I-D. ietf-sipping-reason-header-for-preemption] and behaviors defined for that namespace within that
administrative domain. Section 8.1.1 through 8.1.5 define the new Request
is successful responded to.

If rules
for the 5 namespaces that are created with this document.

It can also be stated that if a Proxy Server is currently
experiencing process processing difficulties (perhaps due to overload), overload
conditions), this is an error condition that will be addressed in

Polk & Schulzrinne [page 11]
Internet-Draft SIP Resource Priority February 21st, 2005

section 4.3.1.

4.3 4.6.1.

4.6 Error Conditions

4.3.1

4.6.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'
header with warning code 370 (Insufficient Bandwidth) if the
request failed due to insufficient capacity for the media streams,
rather than insufficient signaling capacity.

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 if no Resource-Priority header
was present in the original request (which may be local policy
not to include one for normal level calls), to add a resource
priority indication, if authorized.

Schulzrinne & Polk [Page 10]
Internet-Draft SIP Resource Priority October 25th, 2004

4.3.2

4.6.2 Handling Unknown Namespaces and Priority Values

When handling requests with unknown namespaces or priority values,
elements can will operate in one according to local policy. Some
administrative domains will openly reject with a 417 (Unknown
Resource-Priority) Response message regardless of three modes, "strict", "semi-strict"
and "loose". 'Strict' and 'semi-strict' are identified by whether the
presence
namespace or absence of a 'Require' header field with the 'Resource-
Priority' option tag. 'Loose' mode does (or both) are not contain a Require
header. If known, giving no further
details to the request includes a 'Require' header field requestor. Other administrative domains will return
417 (Unknown Resource-Priority) Response with the
'Resource-Priority' option tag, a UAS MUST follow the strict or
semi-strict mode rules, otherwise UAS and proxies MUST operate in
loose mode. Stating the presence of the Require an Accept-Resource-
Priority header (with the
'Resource-Priority' option tag) in indicating which valid namespace(s) and priority-
value(s) are "good" within that domain. As previously stated, a
single SIP message explicitly
determines adherence to can have more than one Resource-Priority header.
If one of two modes seems counterintuitive;
however, the differences are slight between the two modes and are
detailed below.

The use of the 'resource-priority' option tag in 'Proxy-Require' header field is NOT RECOMMENDED in any mode.

4.3.3 Strict Mode

Strict Mode is for administrative domains (or realms) that require
the presence of understood, the remaining Resource-Priority Header with a known namespace
and priority-value in all SIP messages listed in section 4.1. UACs
will include headers
SHOULD NOT be modified, deleted or cause a Requires header rejection of 'Resource-Priority' in all such
SIP Requests to ensure all Responses include the 'Resource-Priority'
header. Domains message.
The reason for this is that require inclusion there will be cases where multiple
namespaces will be necessary for end-to-end communications.
Allowing multiple instances of the 'Resource-Priority' header in these the same message types have a proactive mechanism for
preferential treatment of SIP messages even in congestion instances.

When operating in strict mode, a SIP element MAY provide
preferential processing treatment of messages regardless of
processing load.

The following table extends the values in Table 2 of RFC3261
[RFC3261] operating in 'strict mode'. This table supercedes allows
the
table in section 3.2 of this document.

Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr m m m m m m m
Resource-Priority r amdr c c c c c c c
Resource-Priority 200 - m - m m m m m

Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Resource-Priority R amdr m m m m m m m
Resource-Priority r amdr c c c c c c c
Resource-Priority 200 - m message to traverse multiple administrative domains - m m m m m

Schulzrinne & without

Polk [Page 11] & Schulzrinne [page 12]
Internet-Draft SIP Resource Priority October 25th, 2004

The 'Resource-Priority' header field included in a Request message
MUST be copied in the reply unchanged in 'strict' mode.

SIP elements in this mode will verify February 21st, 2005

each having to know about the namespace contained in policy of the
SIP message other(s) - all while
providing a valid resource-Priority per administrative domain. An
example of this is exactly as the domain expects, as well case where the supplied
priority-value MUST ETS namespace will be one of enabled
by the known priority-values for US Government networks (used by very few individuals within
that
namespace (registered via IANA).

If a administrative domain) that also support the DSN and/or DRSN
namespaces for most (if not all) individuals in those domains.
These namespaces will be defined later in this document.

Some SIP element receives a Resource-Priority elements MAY allow process messages with unknown values
for either the namespace or priority-value, an error message of 417
(Unknown Resource-Priority) MUST be returned Resource-
Priority headers without exception.

Following standard SIP behavior (Section 8.2.2.3 of [RFC3261]), returning a UAS
operating in strict mode MUST reject 417. This is a request with response code
420 (Bad Extension) if it does not support matter of local
policy.

4.7 User Agent Client Behavior

SIP UACs supporting this specification MUST be able to generate the
'Resource-Priority'
option tag.

For example, a gateway header field for requests that is unaware of a require elevated
resource priority
namespace might accept access priority. As stated previously, the UAC SHOULD be
able to generate more than one resource value in a single SIP request.

If a 417 (Unknown Resource-Priority) is received, the
UAC MAY attempt a subsequent request at non-elevated priority, but
then with the same combination
of namespace/priority-value, or the retry the request could later be preempted by other requests.
Also, use with a
different set of namespace/priority combinations, drawing from the 'Require' restriction ensures that in parallel
forking, only branches that support
values returned by the resource-priority
mechanism succeed.

In strict mode operations, any failure response MUST NOT include an 'Accept-Resource-Priority' header field on in
the final hop of
signaling. In other words, response, if an 'Accept-Resource-Priority' header
field is included in included, and if authorized for that user.

4.7.1 User Agent Client Behavior with a SIP failure Response message, it MUST be
removed by the last Proxy (generally element Preemption Policy

A UAC in the second to last
Via entry). Revelation of this information to an unauthorized UAC
is not to occur as it would provide too much information to a UA administrative domain that might not employs preemption MUST be authorized
prepared to access that network.

UAS and Proxy implementations SHOULD support returning receive a BYE Request with a 'Accept-
Resource-Priority' Reason header field enumerating all explaining
why the resource values session was terminated.

[I-D.ietf-sipping-reason-header-for-preemption] discusses this.

4.7.2 User Agent Client Behavior with a Priority Queue Policy

By standard SIP protocol rules, a UAC MUST be prepared to receive a
182 (Queued) response from an RP actor that the server is willing to process. currently at
capacity, but has put the original request into a queue. This 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.3.4 Semi-Strict Mode

Semi-Strict Mode UAC
SHOULD be the operational mode when strict
adherence indicate this queued status to the usage of the Resource-Priority header is granted user by some audio or
visual indication to authorized personnel in an otherwise public domain. In this mode, prevent the Resource-Priority header MUST only be used when a user is
authorized for preferential treatment of their SIP messages.

The following table extends from interpreting the values in Table 2 call as
having failed.

4.8 User Agent Server Behavior

The precise effect of RFC3261
[RFC3261] operating in 'semi-strict mode' for the authorized UAC.
This table supercedes 'Resource-Priority' indication depends on
the table in section 3.2 type of this document. A

Schulzrinne & UAS, the namespace and local policy.

Polk [Page 12] & Schulzrinne [page 13]
Internet-Draft SIP Resource Priority October 25th, 2004 February 21st, 2005

4.8.1 User Agent Servers and Preemption Policy

A UAS will copy compliant with this specification MUST terminate a session
established with a valid namespace and lower priority value in favor
of a new session set-up with a valid namespace and higher relative
priority-value, unless local policy has some form of call-waiting
capability enabled. If a session is terminated, the 'Resource-Priority' BYE method is
used with a Reason header into indicating why/where the SIP Response preemption took
place.

[I-D.ietf-sipping-reason-header-for-preemption] provides additional
information in the case of purposeful or administrative termination
of a session by including the Reason header in the BYE message from an authorized Request message. It is not expected that
a UAS can authenticate
states why the Request, but BYE was sent (in this case, a preemption event).
That document offers several reasons for where the Response needs to be
given termination
occurred ('at the same preferential treatment possibilities as UA', 'in the Request.

The 'Resource-Priority' header field included in network', 'at a Request message
MUST be copied in the reply unchanged in 'semi-strict' mode.

One IP/PSTN gateway'),
and includes call flow examples of the following MUST be included each reason.

4.8.2 User Agent Servers and Priority-Queue Policy

A UAS compliant with this specification SHOULD generate a 182
(Queued) Response if that element's resources are busy, until it is
able to differentiate handle the normal
users of request and provide a domain from those that final response.

Local policy will receive preferential
treatment:

1) Inclusion determine additional behaviors of a queue-based
SIP element. However, the authorization header, or

2) What will come out frequency of the Trait-Based Authorization
[I-D.ietf-sipping-trait-authz] effort currently under way

Semi-strict mode differs from Strict mode provisional messages
indicated in that it is not required
that every [RFC3261] still need to apply to keep each session set-
up active until successful or rejected.

4.9 Proxy Behavior

SIP message have a Resource-Priority header. When proxies MAY ignore or inspect the
Resource-Priority 'Resource-Priority' header is used, is MUST be exactly as is expected
by the
field. SIP elements within a domain - otherwise a 417 (Unknown
Resource Priority) error is proxies MAY reject any unauthenticated request bearing
the response. If no Resource-Priority header is present, field.

A compliant SIP Server experiencing a processing queue due to
excessive load MUST process messages containing higher relative
priority-values up to the message does not receive preferential
treatment. Thus, queue the modified table 2 above would be filled with
'-' in each column for all Methods for header indicates on a FIFO basis
based on the unauthorized UA.

An example usage arrival time of this mode is the US-based Government Emergency
Telephone Service (GETS), in which a very small number of
individuals have the ability to authorize with message. It is conceivable
that priority-levels within a centralized service
to provide proxy are grouped to them preferential access for their next voice call. include more than
one level per queue. This includes the ability to camp on a busy trunk group or circuit
in is a Class 5 or Tandem switch until any one matter of the circuits becomes
free. The authorized user then local policy.

If a Proxy is given access expecting a message to have a 'Resource-Priority'
header and the newly-
available circuit before anyone else has knowledge of it becoming
free. [RFC3487] header is based on this GETS-type service.

Schulzrinne & Polk [Page 13]
Internet-Draft protected via S/MIME encapsulation in a SIP Resource Priority October 25th, 2004

4.3.5 Loose Mode

In loose mode, unknown priority values or namespaces are ignored and
message fragment [RFC3420], the request Proxy MUST return an error response.
Therefore, the use of SIPFRAG in administrative domains with this
type of policy is treated as if these values were not included. recommended.

If
there are no valid priority values S/MIME is used, SIP proxies MAY downgrade or namespaces, upgrade the
'Resource-Priority' of a request is
treated as if it had no or insert a new 'Resource-Priority'

Polk & Schulzrinne [page 14]
Internet-Draft SIP Resource Priority February 21st, 2005

header field. Thus, no
417 (Unknown Resource-Priority) is generated. There if allowed by local policy.

This behavior is no
modification similar to the [RFC3261] table 2 extension in section 3.3 of
this document that for any header field, as a UA can
decide to reject a request for loose mode.

Loose mode maintains the presence, absence or value extension table in section 3.3 of
this document (which is an extension of Table 2 of RFC3261).

4.4 User Agent Client Behavior

SIP UACs supporting this specification MUST be able to generate any
information in the
'Resource-Priority' header field for requests that require elevated request.

If a stateful proxy has authorized a particular resource access priority. As stated previously, priority
level and if it offers differentiated treatment to responses
containing resource priority levels, the UAC proxy SHOULD be
able ignore any
higher value contained in responses, to generate more than one valid avoid that colluding user
agents artificially raise the priority level.

A SIP proxy MAY use the 'Resource-Priority' header
field indication in its
routing decisions, e.g., to retarget to a single SIP Request, depending on the nature of the node or SIP
message.

If the request URI that
is returned with 417 (Unknown Resource-Priority), the
UAC MAY retry the request with reserved for a different set of namespace/priority
combinations, drawing from the values returned by particular resource priority.

When the
'Accept-Resource-Priority' 'Require' header field is included in a message, it ensures that
in parallel forking, only branches that support the response, if included.

4.5 User Agent Server Behavior

If the UAS understands the resource value, but refuses to honor the
request with elevated resource-
priority mechanism succeed. There are not additional special
considerations for this particular user, it returns
the 403 (Forbidden) response code. It MAY include the list of
resource values proxies when forking requests that contain a
resource priority indication.

Otherwise, the user proxy behavior is allowed to use in the
'Accept-Resource-Priority' response header field. If the UAS
refuses to honor the request same as for a reason other than user agent servers
Section 4.7).

5. Third-Party Authentication

In some cases, the Resource
Priority header, RP actor may not be able to authenticate the proper response
requestor or determine whether an authenticated user is authorized to
make such a 488 (Not Acceptable Here).
A warning header MAY be included.

The lookup of request. In these circumstances, the authorized values may take significant resources
since it SIP entity 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
avail itself of general SIP mechanisms that they are
entitled to. not specific to this
application. The precise effect of the 'Resource-Priority' indication depends on authenticated identity management mechanism
[RFC3893] allows a third party to verify the type identity of UAS, the namespace
requestor and local policy. For example, a
circuit-switched telephony gateway might move requests certify this towards an RP actor. In networks with elevated
priority to
mutual trust, the front of SIP asserted identity mechanism [RFC3325] can help
the queue RP actor determine the identity of requests waiting for outbound
lines, it the requestor.

6. Backwards Compatibility

The resource priority mechanism described in this document is fully
backwards compatible with SIP systems following [RFC3261]. Systems
that do not understand the mechanism can only deliver standard, not
elevated, service priority. User agent servers and proxies can ignore
any 'Resource-Priority' header field just like any other unknown
header field and then treat the request like any other request.
Naturally, the request may utilize additional resources still succeed.

Introducing 'Require' or it may preempt existing
calls. For a terminal, such 'Proxy-Require' would not help backwards
compatibility, as a SIP phone, requests with elevated

Schulzrinne & systems that do not support these mechanism are no
better off rejecting the request due to feature failure. Since the

Polk [Page 14] & Schulzrinne [page 15]
Internet-Draft SIP Resource Priority October 25th, 2004 February 21st, 2005

intent of resource priority might trigger a special alert tone or preempt other,
lower-priority existing calls. The generic protocol mechanism
described here does not mandate the particular element behavior, but
namespace definitions, such as the ones in Section 9.5, MUST describe indications is to increase the desired behavioral properties
probability of user agents and proxy servers.

4.5.1 User Agent Servers call completion, adding failure modes appears
counterproductive.

7. Multiple Namespaces in a Message

There are two cases where multiple namespaces might occur. Namely,
a single RP actor may understand more than one namespace and Preemption Policy

Within a UAS, the priority SIP
request may contain more than one resource value (if higher from different
namespaces. As noted earlier, the order of resource values in relative priority)
MUST cause a session to be terminated in favor of
SIP request is immaterial.

o If a newly signaled
session set-up (in strict mode). Consistent SIP termination
indications will be sent in element understands multiple namespaces, it must create
a total ordering across all resource values from these cases (using
namespaces, maintaining the BYE Method).
[I-D.ietf-sipping-reason-header-for-preemption] provides additional
information in relative ordering within each
namespace. It is RECOMMENDED that the case of purposeful or same ordering is used
across an administrative termination
of domain.

o If a session by including the Reason 'Resource-Priority' header in the BYE message that
states what happened (in this case, a preemption event). That
document offers several reasons for where contains multiple namespaces, the termination occurred
('at
RP actor MUST select one resource value, typically the UA', 'in one with
the network', 'at highest ranking.

o If a IP/PSTN gateway'), SIP element supports this specification and the request
includes call flow examples of each reason.

4.6 Proxy Behavior

SIP proxies MAY ignore or inspect a 'Require' header field with the 'Resource-Priority' header
field. SIP proxies MAY reject any unauthenticated request bearing
option tag, it MUST be possible to configure a UAS to copy the
Resource-Priority header field.

If there are multiple namespace value or priority choices available to the
user agent client, a proxy MAY return values from the request with an appropriate
'Accept-Resource-Priority' header field. Details are a matter of
local policy.

If a Proxy is expecting a message Request to have a 'Resource-Priority'
header and the header
Response without changing any field values (this means the
Offerer is protected via S/MIME encapsulation in a SIP
message fragment [RFC3420], the Proxy MUST error control of this message. header's value within an
administrative domain).

This rule MUST always be followed even if multiple instances of the case
Resource-Priority header exist in 'strict-mode' (in which all messages will
have a valid 'Resource-Priority' header). Therefore, Request, unless the use of
SIPFRAG in 'strict-mode' is not recommended. In 'semi-strict' mode,
SIP elements do not expect UAS lacks
the 'Resource-Priority' header, so there
will not be any preferential treatment authorization to copy unknown header fields. User authorization
of that message by that SIP
element.

If no S/MIME priority-values within a namespace is used, SIP proxies MAY downgrade or upgrade outside the
'Resource-Priority' scope of a request or insert a new 'Resource-Priority'
header if allowed by local policy.

This behavior this
document.

Here is similar to that for any header field, as a UA can
decide to reject a request for the presence, absence or value series of examples (both good and bad) 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 SIP element
that supports two namespaces (foo and bar). Foo's priority-values
are no privacy concerns 3 (highest), then 2 and then 1 (lowest ), and bar's priority-
values are C (highest), then B and then A (lowest).

The following are 3 lists of acceptable priority orders the

Schulzrinne & Polk [Page 15]
Internet-Draft SIP Resource Priority October 25th, 2004

resource priority mechanism does not involve message bodies
element MAY process are:

Foo.3 Foo.3 Bar.C (Highest Priority)
Foo.2 Bar.C Foo.3
Foo.1 or
session descriptions.

If a stateful proxy has authorized a particular resource priority
level Foo.2 or Foo.2
Bar.C Bar.B Foo.1
Bar.B Foo.1 Bar.B
Bar.A Bar.A Bar.A (Lowest Priority)

Polk & Schulzrinne [page 16]
Internet-Draft SIP Resource Priority February 21st, 2005

Bar.C (Highest Priority)
Foo.3 Bar.B <= both are equivalently processed FIFO)
or Foo.2 Bar.A <= both are equivalently processed FIFO)
Foo.1 (Lowest Priority)

Bar.C (Highest Priority)
Foo.3
or Foo.2
Foo.1 (Lowest Priority)
Where Bar.A and if it offers differentiated treatment to responses
containing resource Bar.B are ignored within this example administrative
Domain;

Based on the stated priority levels, order of each namespace above, the proxy SHOULD ignore any
following (non-inclusive list of) combinations are NOT acceptable
and MUST NOT be configurable:

Example 1 Example 2 Example 3
--------- --------- ---------
Foo.3 Foo.3 Bar.C
Foo.2 Bar.A Foo.1
Foo.1 or Foo.2 or Foo.3
Bar.C Bar.B Foo.2
Bar.A Foo.1 Bar.A
Bar.B Bar.C Bar.B

Example 4
---------
Bar.C
Foo.1 Bar.B
or Foo.3 Bar.A
Foo.2

In Example 1 above, Bar.A is ordered higher value contained in responses, to avoid that colluding user
agents artificially raise than Bar.B - which is
not consistent within the priority level.

It order of the namespace of this section.

In Example 2 above, Bar.A is unlikely that ordered higher than Bar.B and Bar.C -
which is not consistent within the resource priority value in responses will
have any influence on response handling.

A SIP proxy MAY use order of the 'Resource-Priority' indication in its
routing decisions, e.g., to retarget to a SIP node or SIP URI that namespace of this
section.

In Example 3 above, Foo.1 is ordered higher than Foo.2 and Foo.3 -
which is reserved for a particular resource priority.

There do not appear to be any special considerations when forking
requests containing consistent within the order of the namespace of this
section.

In Example 4 above, Foo.1 is ordered higher than Foo.3 and Foo.2 is
ignored - which is not consistent within the order of the namespace
of this section.

Polk & Schulzrinne [page 17]
Internet-Draft SIP Resource Priority February 21st, 2005

8. Namespace Definitions

This specification defines five unique namespaces below: dsn, drsn,
q735, ets and wps, constituting their registration with IANA. Each
IANA registration contains:

1) The namespace label, a resource unique namespace label within the IANA
registry for the Resource-Priority header;

2) Number of Priority levels - the number of relative priority indication.

Otherwise,
levels the proxy behavior namespace has defined;

3) The "Intended Operation" - identifying whether the namespace is
to be used with priority queuing or preemption;

4) Any new Rejection codes or behaviors unique to the same as for user agent servers
Section 4.4).

4.6.1 Proxies namespace
being defined

5) Any new Error codes specific to the namespace being defined

6) The IETF Reference document specifying the parameters and Preemption Policy

Within a SIP Server, a preemption policy means (authorized) messages
with higher priority values MUST be processed before messages
containing lower priority values. It does not mean
specifications of the lower
priority SIP messages are deleted because they contain lower
priority values. That said, see section 4.3 for namespace, the listing of the priority-
values in relative order, any new rejection messages, and any new
error codes to
be returned to or error behaviors.

8.1 Namespace Descriptions

8.1.1 The "DSN" Namespace

The DSN namespace comes from the name of a UAC if US Government network
called "The Defense Switched Network".

The DSN namespace has a finite list of relative priority-values
listed here in the request had an insufficient order of lowest priority to
be processed.

5. Third-Party Authentication highest priority:

(lowest) dsn.routine
dsn.priority
dsn.immediate
dsn.flash
(highest) dsn.flash-override

In some case, compliant administrative domains utilizing the RP actor may not be able dsn namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to authenticate the
requestor or determine whether an authenticated user is authorized Response for every header in the message unless
the UAS lacks local authorization to
make such a request. In these circumstances, copy certain
namespace.priority-value combinations.

The dsn namespace introduces no new error behaviors.

The IANA Considerations section will have the following entry for
the DSN namespace:

Polk & Schulzrinne [page 18]
Internet-Draft SIP entity may
avail itself Resource Priority February 21st, 2005

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
dsn 5 preemption-based no no [This RFC]

8.1.2 The "DRSN" Namespace

The DRSN namespace comes from the name of general SIP mechanisms that are not specific to this
application. a US Government network
called "The Defense RED Switched Network".

The authenticated identity management mechanism
[RFC3893] allows DRSN namespace has a third party to verify finite list of relative priority-values
listed here in the identity order of lowest priority to highest priority:

(lowest) drsn.routine
drsn.priority
drsn.immediate
drsn.flash
drsn.flash-override
(highest) drsn.flash-override-override

One unique facet regarding the
requestor DRSN namespace relative to the DSN
and certify this towards an RP actor. In networks with
mutual trust, Q735 namespaces is the behavior of SIP asserted identity mechanism [RFC3325] can help elements with regard to
the RP actor determine 6th priority-value:

drsn.flash-override-override

This is the identity of highest relative priority-value within the requestor.

6. Backwards Compatibility

The resource priority mechanism described in this document DRSN
namespace, but it is fully
backwards compatible with SIP systems following [RFC3261]. Systems
that do not understand the mechanism can only deliver standard, not

Schulzrinne & Polk [Page 16]
Internet-Draft to be used at this higher level in message
processing in SIP Resource Priority October 25th, 2004

elevated, service priority. User agent servers Proxies, and proxies can ignore dialog establishment in SIP UAs
(including gateways). In any 'Resource-Priority' header field just like UAS, once the session is established
at the drsn.flash-override-override priority level, it defends that
dialog with a priority level of drsn.flash-override only; thus
allowing a new drsn.flash-override-override to preempt any other unknown existing
session. This behavior MUST be followed to be compliant with this
specification.

In compliant administrative domains utilizing the drsn namespaces,
the UAS MUST copy the Resource-Priority header field and then treat priority-values from
the request like any other request.
Naturally, Request to the request may still succeed.

Introducing 'Require' or 'Proxy-Require' would not help backwards
compatibility, as systems that do not support these mechanism are Response for every header in the message unless
the UAS lacks local authorization to copy certain (perhaps
restricted) namespace.priority-value combinations.

The drsn namespace operates on the preemption policy.

The drsn namespace introduces no new error behavior.

The IANA Considerations section will have the following entry for
the DRSN namespace:

Polk & Schulzrinne [page 19]
Internet-Draft SIP Resource Priority February 21st, 2005

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
drsn 6 preemption-based no
better off rejecting no [This RFC]

8.1.3 The "Q735" Namespace

The Q735 namespace is defined here as Q.735.3 was defined, namely as
operationally equivalent to the request due DSN specification for MLPP. Q.735.3
was created to feature failure. Since be a commercial version of the
intent same specification.

The Q735 namespace has a finite list of resource relative priority-values
listed here in the order of lowest priority indications is to increase highest priority:

(lowest) q735.4
q735.3
q735.2
q735.1
(highest) q735.0

In compliant administrative domains utilizing the
probability of call completion, adding failure modes appears
counterproductive.

7. Namespace Description

A 'Resource-Priority' namespace q735 namespaces,
the UAS MUST be unique with respect copy the Resource-Priority header priority-values from
the Request to other
'Resource-Priority' namespaces. There are 5 unique namespaces
defined the Response for every header in this specification. This the message unless
the UAS lacks local authorization to copy certain (perhaps
restricted) namespace.priority-value combinations.

The q735 namespace operates according to the preemption policy.

The q735 namespace introduces no new error behaviors.

The IANA Considerations section will define each, as
well as their individual parameters. The case insensitive
namespaces are as follows:

- dsn
- drsn
- have the following entry for
the Q735 namespace:

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
q735
- ets
- wps

Each 5 preemption-based no no [This RFC]

8.1.4 The "ETS" Namespace

The ETS namespace derives its name indirectly from the name of the
US Government Telecommunications Service called "Government
Emergency Telecommunications Service" (or GETS), though the
organization responsible for the GETS service chose the acronym
"ETS" for its GETS over IP service, which stands for "Emergency
Telecommunications Service".

The ETS namespace has a finite list of relative priority-values. Each
is priority-values
listed here in the order of lowest priority to highest priority:

(lowest) dsn.routine
dsn.priority
dsn.immediate
dsn.flash
(highest) dsn.flash-override

(lowest) drsn.routine
drsn.priority
drsn.immediate
drsn.flash
drsn.flash-override
(highest) drsn.flash-override-override

(lowest) q735.4
q735.3
q735.2
q735.1
(highest) q735.0

(lowest) ets.4
ets.3
ets.2

Schulzrinne &

Polk [Page 17] & Schulzrinne [page 20]
Internet-Draft SIP Resource Priority October 25th, 2004 February 21st, 2005

(lowest) ets.4
ets.3
ets.2
ets.1
(highest) ets.0

(lowest) wps.4
wps.3
wps.2
wps.1
(highest) wps.0

More than one

The ets namespace listed here adheres operates according to the priority queuing policy.
ETS-based administrative domains will not queue normal, non-
prioritized requests.

ETS-based administrative domains will not queue normal, non-
prioritized messages. If a 'strict mode' queue depth exists, the messages will be
rejected according to section 4.5.

A UAS within this type of
operation (dsn, drsn and q735). More than one adheres administrative domain SHOULD be
configurable to limit the number of requests in a 'semi-
strict mode' queue. One of operation (ets two
different ways of limiting the queue depth is RECOMMENDED:

1) having a maximum number within a queue (perhaps with a different
number queued per priority-level), and wps). No namespaces listed here
operate under 'loose mode'.

The dsn, drsn

2) consider all requests above the default level to be in a single
queue on a FIFO basis (for example, based on the reception
timestamp of the request)

A UAS within this type of administrative domain SHOULD be
configurable to limit the time a request sits in a queue. One of
two different ways of limiting the time in queue is RECOMMENDED:

1) having a maximum time within a queue (perhaps with a different
time per priority-level) before a/each message moves into a
rejection condition discussed in section 4.5., and q735 namespaces operate under

2) considering all requests above the default level in a single
queue on a FIFO basis (for example, based on the reception
timestamp of the request), all with the same maximum time in
queue before a/each message moves into a rejection condition
discussed in section 4.5.

Local policy will determine additional behaviors of
providing preferential message treatment to a queue-based
SIP element. However, the point frequency of preempting
lower relative priority requests provisional messages
indicated in favor of processing higher
relative priority requests.

In SIP Servers, this translates [RFC3261] still need to giving preferential apply to keep each session set-
up active until successful or rejected.

A compliant SIP Server experiencing a processing
treatment queue due to those
excessive load MUST move the messages containing higher priority values (a
"move relative
priority-values up to the front queue the header indicates on a FIFO basis
based on the arrival time of the line" scenario). During light to medium
processing loads, this should not message (as there may be evident more than
one message at all to other
messages. During heavier loads on servers, these labels provide for
a domain ensuring (by their own configuration) the same level already in queue). It is conceivable
that priority-levels within a certain
classification(s) of messages proxy are processed before other
classification(s) grouped to include more than
one level per queue. This is a matter of messages. local policy.

Polk & Schulzrinne [page 21]
Internet-Draft SIP Resource Priority February 21st, 2005

In UAs, just as compliant administrative domains utilizing the ets namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to the Response for every header in SIP servers, this translates the message unless
the UAS lacks local authorization to giving
preferential processing treatment copy certain (perhaps
restricted) namespace.priority-value combinations.

Additional ETS policy is left to those messages containing
higher priority values (a "move domain administrators, and to
future efforts.

The ets namespace does not define new error behaviors.

The IANA Considerations section will have the front of the line" scenario).
But following entry for dialog requests, this behavior translates into preemption of
dialog events if
the ETS namespace:

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
ets 5 queue-based no no [This RFC]

8.1.5 The "WPS" Namespace

The WPS namespace derives its name from the "Wireless Priority
Service" defined in GSM and other wireless technologies.

Each namespace has a new INVITE is received that finite list of relative priority-values. Each
is indicating a
higher priority value than listed here in the one assigned order of lowest priority to the current dialog. highest priority:

(lowest) wps.4
wps.3
wps.2
wps.1
(highest) wps.0

The ets and wps namespaces operate namespace operates with the intended preferential treatment but
without preemption. These namespaces operate under
of a queue-based policy of
provide preferential treatment to (as defined in section 4), where higher
relative priority requests
instead are queued ahead of processing lower relative
priority requests. Messages
are not preempted, or deleted, except under extreme loads in which
all available requests for processing is taken up with higher priority messages.

An example of this is at a IP/PSTN gateway with all of the PSTN side
circuits utilized. In strict mode one any point of scarce resource
constraints in an administrative domain.

WPS-based administrative domains will not queue normal, non-
prioritized messages. If a queue depth exists, the lower priority
circuits would be freed using preemption. In semi-strict mode, the
SIP request May messages will be granted access
rejected according to the next available circuit
based on section 4.5.

A UAS within this header's presence in type of administrative domain SHOULD be
configurable to limit the authorized message,
regardless number of how many other "regular" requests are received at that
gateway.

There are no unique rejection messages to in a SIP message containing
any one queue. One of these namespaces (outside two
different ways of limiting the rules queue depth is RECOMMENDED:

1) having a maximum number within the mode

Schulzrinne & a queue (perhaps with a different
number queued per priority-level), and

Polk [Page 18] & Schulzrinne [page 22]
Internet-Draft SIP Resource Priority October 25th, 2004

SIP elements adhere to).

The 417 (Unknown Resource Priority) error message is February 21st, 2005

2) consider all requests above the default level to be in a single
queue on a FIFO basis (for example, based on the reception
timestamp of the request)

A UAS within this type of administrative domain SHOULD be
configurable to reject a queued lower priority request in lieu of
the proper
response to any SIP newly arrived higher priority level request (authorized if that domain requires it,
and it SHOULD) if the namespace is unknown to maximum
aggregate queue depth has been reached for that SIP element in
strict or semi-strict mode. A 417 element. This
behavior is also not considered a "preemption event" because the proper error response session
had not been previously established. This bumping will result in
the case the namespace is known, but the priority-value is either
unknown, or does not correspond lower level request being rejected (discussed in section 4.5)

A UAS within this type of administrative domain SHOULD be
configurable to limit the list time a request sits in a queue. One of priority-values
associated with that particular namespace
two different ways of limiting the time in strict or semi-strict
mode.

The following table will be repeated queue is RECOMMENDED:

1) having a maximum time within a queue (perhaps with a different
time per priority-level) before a/each message moves into a
rejection condition discussed in the IANA considerations section as 4.5., and

2) considering all requests above the new registry for 'Resource-Priority' default level in a single
queue on a FIFO basis (for example, based on the SIP
parameters section.

New New Error
Namespace Levels Mode Operation Rej. code code Reference
--------- ------ ---- --------- --------- ---- ---------
dsn 5 strict preemption no 417 [This RFC]

drsn 6 strict preemption no 417 [This RFC]

q735 5 strict preemption no 417 [This RFC]

ets 5 semi-strict preferential no 417 [This RFC]

wps 5 semi-strict preferential no 417 [This RFC]

Table 1. Namespace Parameters

New namespace/priority-value combinations proposed in reception
timestamp of the future
MUST be defined request), all with the same maximum time in
queue before a/each message moves into a Standards Track RFC and MUST include an
augmentation to Table 1 of this document rejection condition
discussed in that effort, as well as
list section 4.5.

Local policy will determine additional behaviors of a queue-based
SIP element. However, the finite set frequency of priority values provisional messages
indicated in [RFC3261] still need to apply to keep each session set-
up active until successful or rejected.

A compliant SIP Server experiencing a processing queue due to
excessive load MUST move the messages containing higher relative priority order
(with no wildcards) for IANA Registration. New
priority-values MUST
NOT be added up to any previously (IANA) registered finite list
associated with a particular namespace. This will cause
interoperability problems.

7.1 Multiple Namespaces in the queue the header indicates on a Message

The only rules stipulated here regarding FIFO basis
based on the arrival time of the message (as there may be more than
one namespace in
a SIP message are:

o There MUST be one order of priorities a SIP element has to
process to.

o at the same level already in queue). It MUST be configurable is conceivable
that priority-levels within a proxy are grouped to have include more than zero namespaces be
ignored, while
one level per queue. This is a matter of local policy.

In compliant administrative domains utilizing the SIP element adheres wps namespaces,
the UAS MUST copy the Resource-Priority header priority-values from
the Request to any number of Resource-
Priority headers (if placed the Response for every header in one overall relative order).

Schulzrinne & the message unless
the UAS lacks local authorization to copy certain (perhaps
restricted) namespace.priority-value combinations.

Additional WPS policy is left to domain administrators, and to
future efforts.

The wps namespace operates according to the priority queuing policy
and will not queue normal, non-prioritized messages.

The wps namespace defines no new error behaviors.

Polk [Page 19] & Schulzrinne [page 23]
Internet-Draft SIP Resource Priority October 25th, 2004

o February 21st, 2005

The header order in IANA Considerations section will have the following entry for
the WPS namespace:

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
wps 5 queue-based no no [This RFC]

8.2 Future Namespace Considerations

Organizations considering the message use of which the Resource-Priority header
is chosen MUST not matter. SIP elements MUST parse to any header
location it has visibility to.

For example,
should investigate if a SIP element supports two namespaces (foo an existing combination of namespace and bar).
Foo's
priority-values meets the needs. For example, emergency first
responders around the world are 1, 2 and 3 (lowest to highest), discussing utilizing this mechanism
for preferential treatment in future networks. There should not be
a unique namespace for different jurisdictions. This will greatly
increase interoperability and bar's
priority-values are A , B reduce development time, and C (lowest probably
reduce future confusion if there is ever a need to highest).

The following (not all inclusive list of) acceptable priority orders
the SIP element MAY process are:

Foo.3 Foo.3 Bar.C (highest)
Foo.2 Bar.C Foo.3
Foo.1 or Foo.2 or Foo.2
Bar.C Bar.B Foo.1
Bar.B Foo.1 Bar.B
Bar.A Bar.A Bar.A (lowest)

Bar.C (highest)
Foo.3 Bar.B <= these 2 are considered equivalent)
or Foo.2 Bar.A <= these 2 are considered equivalent)
Foo.1 (lowest)

Bar.C (highest)
Foo.3
or Foo.2
Foo.1 (lowest)
Where Bar.A and Bar.B are ignored

The following (not all inclusive list) are not acceptable priority
orders map one namespace
to another in an interworking function.

In the SIP element MUST NOT process are:

Foo.3 Foo.3 Bar.C
Foo.2 Bar.A Foo.1
Foo.1 or Foo.2 or Foo.3
Bar.C Bar.B Foo.2
Bar.A Foo.1 Bar.A
Bar.B Bar.C Bar.B

Bar.C
Foo.1 Bar.B specification of any future namespace, several facets need to
be done or Foo.3 Bar.A
Foo.2

Local policy determines which included:

1) New namespace/priority-value combinations
are acceptable (if more than one is authorized for use within proposed in the future
MUST be defined in a
domain). The relative order of priority Standards Track RFC and MUST include an
augmentation to following table offered to IANA for Registration:

Intended New New Error
Namespace Levels Operation Rej. code code Reference
--------- ------ ---------------- --------- ---- ---------
<new <# of <preemption <new error <new Rej <which
namespace> Levels> or queue> code> code> IETF doc>

- as well as list the finite set of priority values in relative
priority order (with no wildcards) for IANA Registration.

2) New priority-values
within MUST NOT be added to any previously (IANA)
registered list associated with a particular namespace. This
will cause interoperability problems.

3) If there is a new "intended behavior" (other than preemption-
based or priority queue-based), the same parameters for that behavior
must be provided and how said behavior affects different types of
RP actors.

4) Any new Response Codes unique to this new namespace MUST never change.

Schulzrinne & need to be
explained.

Polk [Page 20] & Schulzrinne [page 24]
Internet-Draft SIP Resource Priority October 25th, 2004

8. February 21st, 2005

5) Any new Rejection Codes or changes to existing rejections codes
as a result of the creation of the namespace need to be offered
and explained.

9. Examples

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

8.1

9.1 Simple Call

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

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

...

F2 180 Ringing User B -> User A

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101

Polk & Schulzrinne [page 25]
Internet-Draft SIP Resource Priority February 21st, 2005

From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash

Schulzrinne & Polk [Page 21]
Internet-Draft SIP Resource Priority October 25th, 2004
Contact: <sip:UserB@client.biloxi.example.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.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: ...

...

8.2

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

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

Polk & Schulzrinne [page 26]
Internet-Draft SIP Resource Priority February 21st, 2005

| Both Way RTP Media |
|<======================>|

F1 INVITE User A -> User B

INVITE sip:UserB@biloxi.example.com SIP/2.0

Schulzrinne & Polk [Page 22]
Internet-Draft SIP Resource Priority October 25th, 2004
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Resource-Priority: dsn.flash
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>

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.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4
Contact: <sip:UserB@client.biloxi.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 0

F3 ACK User A -> User B

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

F4 INVITE User A -> User B

Polk & Schulzrinne [page 27]
Internet-Draft SIP Resource Priority February 21st, 2005

Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Resource-Priority: q735.3
Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>

Content-Type: application/sdp

Schulzrinne & Polk [Page 23]
Internet-Draft SIP Resource Priority October 25th, 2004
Content-Length: ...
...

10. 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
emergencies or deny service to legitimate users. In the Internet,
or any IP domain, this mechanism can cause certain messages or
sessions (calls) to be given a higher relative priority of
processing within a SIP element (move to the head of the line
scenario), to the point of prematurely terminating an existing
session in favor of a newer one. In some administrative domains,
this will be the expected behavior for authenticated and authorized
users (see section 7). 8). Unauthorized users MUST NOT be given this
opportunity to abuse network/element resources.

While the indication itself does not have to provide separate
authentication, any SIP request containing this header has higher
authentication requirements than regular requests.

A poor implementation of authentication and authorization will
likely cause illegitimate higher priority messages to process
without being successfully challenged for the privilege to do so.
While this will not likely have a great affect on the performance of
SIP Servers, this could have some (to a great) impact on the
premature termination of existing sessions. Those domains wishing
to utilize a namespace with an operation of preemption of lower
relative priority sessions should use caution to ensure only the
proper usage of this header is granted.

Care should be taken on 3 fronts:

1) To the domain that enables usage of the Resource-Priority header
such that adequate control exists to prevent unwanted
preferential message treatment from internal users.

Without an authentication and authorization mechanism to validate
each user request, unwanted usage (and potentially user hacked
settings) can have undesired affects on any internal network.

2) To the domain that enables usage of the Resource-Priority header
such that inadequate control exists to prevent unwanted
preferential message treatment from SIP messages from outside the

Polk & Schulzrinne [page 28]
Internet-Draft SIP Resource Priority February 21st, 2005

domain coming into the domain (and outside the area of direct AAA
control).

3) In the choosing of a namespace itself, to make sure the desired
behavior of SIP elements have equivalent behaviors defined in this
document to ensure interoperability and no surprises.

Schulzrinne & Polk [Page 24]
Internet-Draft SIP Resource Priority October 25th, 2004

An example of this is choosing a namespace throughout a domain and
configuring it for preferential treatment with no preemption, even
though a neighbor domain uses it as it is IANA defined (with
preemption as one expected behavior), resulting in poor performance
of fist domain's calls into the second administrative domain's
network.

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 [RFC3261] applies.

All user agents and proxy servers which support this extension MUST
implement SIP over TLS [RFC3546] and the sips: URI scheme as
described in Section 26.2 of RFC 3261, and Digest Authentication
[RFC2617] as described in Section 22 of RFC 3261. In addition, user
agents which support this extension SHOULD also implement S/MIME
[RFC2633] as described in Section 23 of RFC 3261 to allow for signing
and verification of signatures over requests which use this
extension.

9.1

10.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. Digest authentication requires that the parties
share a common secret, thus limiting its use across administrative

Polk & Schulzrinne [page 29]
Internet-Draft SIP Resource Priority February 21st, 2005

domains. SIP systems employing resource priority SHOULD implement S/
MIME at least for integrity, as described in Section 23 of [RFC3261].
However, in some environments, receipt of asserted identity [RFC3325]
from a trusted entity may be sufficient authorization. Section 5
describes third-party authentication.

Trait-based authorization [I-D.ietf-sipping-trait-authz] "entails an

Schulzrinne & Polk [Page 25]
Internet-Draft SIP Resource Priority October 25th, 2004
assertion by a authorization service of attributes associated with an
identity" and may be appropriate for this application. With
trait-based authorization, a network element can directly determine,
by inspecting the certificate, that a request is authorized to obtain
a particular type of service, without having to consult a mapping
mechanism that converts user identities 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.

9.2

10.2 Confidentiality and Integrity

Calls which use elevated resource priority levels provided by the
'Resource-Priority' header field are likely to be sensitive and 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' and 'Subject' header fields are
examples of particularly sensitive information. Systems MUST
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' header field can be carried in the SIP
message header or can be encapsulated in a message fragment carried
in the SIP message body [RFC3420]. To be considered valid
authentication for the purposes of this specification, S/MIME signed
SIP messages or fragments MUST contain, at a minimum, the Date, To,
From, Call-ID, and Resource-Priority header fields. Encapsulation in
S/MIME body parts allows the user to protect this header field
against inspection or modification by 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

Polk & Schulzrinne [page 30]
Internet-Draft SIP Resource Priority February 21st, 2005

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

Schulzrinne & Polk [Page 26]
Internet-Draft SIP Resource Priority October 25th, 2004

9.3

10.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 mechanism described in [RFC3323].

9.4

10.4 Denial-of-Service Attacks

As noted, systems described here are likely to be subject to
deliberate denial-of-service (DoS) 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
to a network address whose reachability has not been verified.

10.

11. IANA Considerations

This section defines two new SIP headers (10.1), (11.1), one SIP OPTION tag
(10.2),
(11.2), one new 4XX error code (10.3), and (11.3), a new registry within the
sip-parameters section of IANA for Resource-Priority namespaces
(11.4) and a new registry within the sip-parameters section of IANA
for Resource-Priority and priority-values (10.4). (11.5).

Additional namespaces and priority values MUST be registered with
IANA. Within each namespace, the registration MUST indicate the
relative priority levels, expressed as an ordered list. New
priority-values MUST NOT be added to existing namespace registries.
The registration MUST describe, in the registration itself, how SIP
elements should treat requests from that namespace in 'operation',
e.g., whether preemption or only preferential queuing are allowed.

The SIP Change Process [RFC 3427] establishes a policy for the
registration of new SIP extension headers. Resource priority
namespaces and priority values have similar interoperability
requirements to those of SIP extension headers. Consequently,
registration of new resource priority namespaces and priority values

Polk & Schulzrinne [page 31]
Internet-Draft SIP Resource Priority February 21st, 2005

requires documentation in an RFC using the extension header approval
process specified in RFC 3427.

10.1

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

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

Schulzrinne & Polk [Page 27]
Internet-Draft SIP Resource Priority October 25th, 2004
document.]

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

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

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

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

10.2

11.2 IANA Registration for Option Tag resource-priority

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

10.3

11.3 IANA Registration for Response Code 417

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

10.4

11.4 IANA Namespace and Priority-Value Registrations

A new registry ("Resource-Priority Namespaces") in the
sip-parameters section of IANA is to be created taking a form
similar to this table below:

Intended New New Error
Namespace Levels Mode Operation Rej. code code Reference
--------- ------ ---- --------- ---------------- --------- ---- ---------
dsn 5 strict preemption no 417 no [This RFC]

drsn 6 strict preemption no 417 no [This RFC]

Polk & Schulzrinne [page 32]
Internet-Draft SIP Resource Priority February 21st, 2005

q735 5 strict preemption no 417 no [This RFC]

ets 5 semi-strict preferential priority-queue no no 417 [This RFC]

wps 5 semi-strict preferential priority-queue no no 417 [This RFC]

Schulzrinne & Polk [Page 28]
Internet-Draft SIP Resource Priority October 25th, 2004

Legend
------
Namespace = the name unique string of the namespace
Levels = the number of priority-values within the namespace
Operation = Expected Intended (or expected) operational behavior of SIP
elements encountering this namespace
New Rej. Code = New Rejection Codes introduced for this namespace
New Error Code = New Error Codes introduced for this namespace
Reference = IETF Document reference for this namespace

10.5

11.5 IANA Priority-Value Registrations

A new registry ("Resource-Priority Priority-values") in the
sip-parameters section of IANA is to be created taking a form
similar to this table below (Reference [XXXX] is this RFC):

Namespace: drsn
Reference: [XXXX]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"

Namespace: dsn
Reference: [XXXX]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override",

Namespace: q735
Reference: [XXXX]
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: ets
Reference: [XXXX]
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: wps
Reference: [XXXX]
Priority values (least to greatest): "4", "3", "2", "1", "0"

11.

12. Acknowledgments

Ben Campbell, Janet Gunn, Paul Kyzivat, Rohan Mahy, Mike Pierce, Samir
Srivastava and Allison Mankin provided helpful comments.

Polk & Schulzrinne [page 33]
Internet-Draft SIP Resource Priority February 21st, 2005

Dean Willis provided much help with this effort.

Martin Dolly, An Nguyen and Niranjan Sandesara assisted with the
ets and wps namespaces.

Schulzrinne & Polk [Page 29]
Internet-Draft SIP Resource Priority October 25th, 2004

12.

Janet Gunn helped improve the queue-based policy text.

13. References

12.1

13.1 Normative References

[I.255.3] International Telecommunications Union, "Integrated
Services Digital Network (ISDN) - General Structure and
Service Capabilities - Multi-Level Precedence and
Preemption", Recommendation I.255.3, July 1990.

[Q.735.3] International Telecommunications Union, "Stage 3
description for community of interest supplementary
services using Signaling 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", BCP 14, RFC 2119, March 1997.

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

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

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.

[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.

[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC
3420, November 2002.

[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.

12.2

[I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Reason Header for Preemption within the Session

Polk & Schulzrinne [page 34]
Internet-Draft SIP Resource Priority February 21st, 2005

Initiation Protocol (SIP)",
draft-ietf-sipping-reason-header-for-preemption-02 (work
in progress), August 2004

13.2 Informative References

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

Schulzrinne & Polk [Page 30]
Internet-Draft SIP Resource Priority October 25th, 2004

[RFC3893] Peterson, J., "SIP Authenticated Identity Body (AIB)
Format", RFC 3893, May 2004.

[I-D.ietf-sip-publish]

[RFC3903] Niemi, A., "An Event State Publication Extension to the
Session Initiation Protocol (SIP)",
draft-ietf-sip-publish-04 (work in progress), RFC3903, May 2004.

[I-D.ietf-sipping-trait-authz]
Peterson, J., "Trait-based Authorization Requirements for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-00
draft-ietf-sipping-trait-authz-01 (work in progress),
February 2004.

[I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Reason Header for Preemption within the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-reason-header-for-preemption-02 (work
in progress), August 2004 2005.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.

[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.

[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October
2000.

[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.

[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.

[RFC3325] Jennings, C., Peterson, J. and M. Watson, "Private
Extensions to the 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.

[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer

Polk & Schulzrinne [page 35]
Internet-Draft SIP Resource Priority February 21st, 2005

Method", RFC 3515, April 2003.

[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.

Schulzrinne & Polk [Page 31]
Internet-Draft SIP Resource Priority October 25th, 2004

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.

[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and
K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.

Authors' Addresses

James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082
USA

EMail: jmpolk@cisco.com

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
USA

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
US

EMail: jmpolk@cisco.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
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; 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 IETF Documents can
be found in BCP 78 and BCP 79.

Copies of IPR disclosures made 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

Polk & Schulzrinne [page 36]
Internet-Draft SIP Resource Priority February 21st, 2005

such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any

Schulzrinne & Polk [Page 32]
Internet-Draft SIP Resource Priority October 25th, 2004
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein 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 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.

Copyright (C) The Internet Society (2004). (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Schulzrinne &

Polk [Page 33] & Schulzrinne [page 37]

----