Network Working Group                                     H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: August 15, 2004                                         J. Polk
                                                                   Cisco
                                                       February 15, 2004


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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

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

   This Internet-Draft will expire on August 15, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

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







Schulzrinne & Polk      Expires August 15, 2004                 [Page 1]

Internet-Draft             Resource Priority               February 2004


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.    The Resource-Priority and Accept-Resource-Priority SIP
         Header Fields  . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1   The Resource-Priority Header Field . . . . . . . . . . . . .  7
   3.2   The Accept-Resource-Priority Header Field  . . . . . . . . .  8
   3.3   Usage of the Resource-Priority and
         Accept-Resource-Priority Header Fields . . . . . . . . . . .  8
   3.4   The Resource-Priority Option Tag . . . . . . . . . . . . . .  8
   4.    Behavior of SIP Elements that Receive Prioritized
         Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1   General Rules  . . . . . . . . . . . . . . . . . . . . . . . 10
   4.2   Error Conditions . . . . . . . . . . . . . . . . . . . . . . 10
   4.2.1 Known Namespace and Priority Value . . . . . . . . . . . . . 10
   4.2.2 Handling Unknown Namespaces and Priority Values  . . . . . . 11
   4.3   User Agent Client Behavior . . . . . . . . . . . . . . . . . 12
   4.4   User Agent Server Behavior . . . . . . . . . . . . . . . . . 12
   4.5   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
   5.    Third-Party Authentication . . . . . . . . . . . . . . . . . 14
   6.    Backwards Compatibility  . . . . . . . . . . . . . . . . . . 15
   7.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.1   Simple Call  . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.2   Receiver Does Not Understand Namespace . . . . . . . . . . . 17
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 20
   8.1   Authentication and Authorization . . . . . . . . . . . . . . 20
   8.2   Confidentiality and Integrity  . . . . . . . . . . . . . . . 21
   8.3   Anonymity  . . . . . . . . . . . . . . . . . . . . . . . . . 21
   8.4   Denial-of-Service Attacks  . . . . . . . . . . . . . . . . . 22
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 23
   9.1   IANA Registration of 'Resource-Priority' and
         'Accept-Resource-Priority' Header Fields . . . . . . . . . . 23
   9.2   IANA Registration for Option Tag resource-priority . . . . . 23
   9.3   IANA Registration for Response Code 417  . . . . . . . . . . 23
   9.4   IANA Namespace and Priority Registrations  . . . . . . . . . 24
   9.5   Initial Namespace Registrations  . . . . . . . . . . . . . . 25
   9.5.1 Namespace dsn  . . . . . . . . . . . . . . . . . . . . . . . 25
   9.5.2 Namespace q735 . . . . . . . . . . . . . . . . . . . . . . . 25
   9.5.3 Namespace DRSN . . . . . . . . . . . . . . . . . . . . . . . 26
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 27
         Normative References . . . . . . . . . . . . . . . . . . . . 28
         Informative References . . . . . . . . . . . . . . . . . . . 29
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
         Intellectual Property and Copyright Statements . . . . . . . 31






Schulzrinne & Polk      Expires August 15, 2004                 [Page 2]

Internet-Draft             Resource Priority               February 2004


1. Introduction

   During emergencies, communications resources including telephone
   circuits, IP bandwidth and gateways between the circuit-switched and
   IP networks may become congested.  Congestion can occur due to heavy
   usage, loss of resources caused by the natural or man-made disaster
   and attacks on the network during man-made emergencies.  This
   congestion may make it difficult for persons charged with emergency
   assistance, recovery or law enforcement to coordinate their efforts.
   As IP networks become part of converged or hybrid networks along with
   public and private circuit-switched (telephone) networks, it becomes
   necessary to ensure that these networks can assist during such
   emergencies.

   Also, users may want to interrupt their lower-priority communications
   activities and dedicate their end system resources to the
   high-priority 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
   SIP, including voice-over-IP, multimedia conferencing and instant
   messaging/presence.

   Session Initiation Protocol (SIP) [RFC3261] 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".

   Currently, SIP does not include a mechanism that allows a request
   originator to indicate to a SIP element that it wishes the request to
   invoke such resource prioritization. To address this need, this
   document adds a SIP protocol element that labels certain SIP
   requests.

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



Schulzrinne & Polk      Expires August 15, 2004                 [Page 3]

Internet-Draft             Resource Priority               February 2004


   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.

   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 existing signaling requests or bypass
       GSTN gateway capacity limits in effect for lower priorities.

   This header field is related to, but differs in semantics from, the
   'Priority' 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
   PSTN gateway or proxy resources, for example.  In addition, any UAC
   can assert any 'Priority' value, while access to resource priority
   values is subject to authorization.

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



Schulzrinne & Polk      Expires August 15, 2004                 [Page 4]

Internet-Draft             Resource Priority               February 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 is structured so that it works in all SIP/RTP
   transparent networks defined in [RFC3487], i.e., all network elements
   and SIP proxies let valid SIP requests pass through unchanged.  This
   is important since it is likely that this mechanism will often be
   deployed in networks where the edge networks are unaware of the
   resource priority mechanism and provide no special privileges to such
   requests.  The request then reaches a PSTN gateway or set of SIP
   elements that are aware of the mechanism.

   For conciseness, we refer to SIP proxies and user agents that act on
   the 'Resource-Priority' header field as RP actors.

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

   The mechanism aims to satisfy the requirements in [RFC3487].


























Schulzrinne & Polk      Expires August 15, 2004                 [Page 5]

Internet-Draft             Resource Priority               February 2004


2. Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant
   implementations.












































Schulzrinne & Polk      Expires August 15, 2004                 [Page 6]

Internet-Draft             Resource Priority               February 2004


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

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

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

3.1 The Resource-Priority Header Field

   The 'Resource-Priority' header field marks a SIP request as desiring
   prioritized resource access, as described in the introduction.  In
   responses, the 'Resource-Priority' header fields indicates the actual
   resource priority that was granted to the request.  While it is
   usually the same value contained in the request, implementations MAY
   insert a different value based on local policy.

   There is no requirement that all requests within a SIP dialog or call
   use the 'Resource-Priority' header field.

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

   Resource-Priority  = "Resource-Priority" HCOLON
                        Resource-value (*COMMA Resource-value)
   Resource-value     = namespace "." r-priority
   namespace          = alphanum / "-"
   r-priority         = 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-independent ASCII.  Each
   namespace has at least one priority value.  Namespaces and priority
   values within each namespace are registered with IANA (Section
   Section 9); some initial namespaces are described in Section Section
   9.5.




Schulzrinne & Polk      Expires August 15, 2004                 [Page 7]

Internet-Draft             Resource Priority               February 2004


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

3.2 The Accept-Resource-Priority Header Field

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

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

   An example is given below:

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


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

   Header field             where proxy INV ACK CAN BYE REG OPT PRA
   ----------------------------------------------------------------
   Resource-Priority        R     amd    o   o   o   o   o   o   o
   Resource-Priority        200   -      o   -   -   -   -   -   -
   Accept-Resource-Priority 200   -      o   -   -   -   -   -   -
   Accept-Resource-Priority 417   -      o   -   -   -   -   -   -
   Accept-Resource-Priority 420   -      o   -   -   -   -   -   -

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

   Other request methods MAY define their own handling rules; unless
   otherwise specified, recipients MAY ignore these header fields.
   'Accept-Resource-Priority' MUST be returned in 420 (Not Supported)
   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 request.

3.4 The Resource-Priority Option Tag

   This document also defines the "resource-priority" option tag. The



Schulzrinne & Polk      Expires August 15, 2004                 [Page 8]

Internet-Draft             Resource Priority               February 2004


   behavior is described in Section 4.2.2 and the IANA registration is
   in Section 9.2.

















































Schulzrinne & Polk      Expires August 15, 2004                 [Page 9]

Internet-Draft             Resource Priority               February 2004


4. Behavior of SIP Elements that Receive Prioritized Requests

4.1 General Rules

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

   A SIP element supporting this specification MUST be able to interpret
   the 'Resource-Priority' header field in INVITE, MESSAGE [RFC3428],
   UPDATE [RFC3311], SUBSCRIBE [RFC3265] and NOTIFY [RFC3265] requests,
   if it supports a particular request.  (This does not imply that all
   elements supporting this specification need to support all of these
   request methods.) In all such requests, the priority MAY influence
   the order in which requests are handled and MUST influence the
   resources, such as circuits, bandwidth or memory, allocated based on
   the request.  For example, for SUBSCRIBE, a higher-priority request
   may get preferential treatment if storage or bandwidth for
   notifications are scarce, possibly displacing a lower-priority
   subscription.  (As always, the precise behavior is defined by a
   namespace definition, or, if left unspecified, by an implementation
   or configuration.)

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

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

4.2 Error Conditions

4.2.1 Known Namespace and Priority Value

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

   Insufficient authorization: If the element receives a request with a
      namespace and priority value it recognizes, but the originator is
      not authorized for that level of service, the element MUST return
      a 403 (Forbidden) response.






Schulzrinne & Polk      Expires August 15, 2004                [Page 10]

Internet-Draft             Resource Priority               February 2004


   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 priority
      indication, if authorized.


4.2.2 Handling Unknown Namespaces and Priority Values

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

   Following standard behavior (Section 8.2.2.3 of [RFC3261]), a UAS
   MUST then reject the request with response code 420 (Bad Extension)
   if it does not understand the resource priority mechanism.

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

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

4.2.2.1 Strict Mode

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




Schulzrinne & Polk      Expires August 15, 2004                [Page 11]

Internet-Draft             Resource Priority               February 2004


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


4.2.2.2 Loose Mode

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

4.3 User Agent Client Behavior

   SIP UACs supporting this specification MUST be able to generate the
   'Resource-Priority' header field for requests that require elevated
   resource access priority.

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

4.4 User Agent Server Behavior

   The OPTIONS request can be used to determine if a UAS supports the
   mechanism.  A compliant implementation MUST return a
   'Accept-Resource-Priority' header field in OPTIONS responses
   enumerating all valid resource values.  An implementation MAY reveal
   this capability only to authorized UACs. (Note that an overloaded UAS
   may not be able to provide this information at all times.)

   If the UAS understands the resource value, but refuses to honor the
   request with elevated priority for this particular user, it returns
   the 403 (Forbidden) response code.  It MAY include the list of
   resource values that the user is allowed to use in the
   'Accept-Resource-Priority' response header field.

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

   The precise effect of the 'Resource-Priority' indication depends on
   the type of UAS, the namespace and local policy.  For example, a



Schulzrinne & Polk      Expires August 15, 2004                [Page 12]

Internet-Draft             Resource Priority               February 2004


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

4.5 Proxy Behavior

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

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

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

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

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

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

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




Schulzrinne & Polk      Expires August 15, 2004                [Page 13]

Internet-Draft             Resource Priority               February 2004


5. Third-Party Authentication

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








































Schulzrinne & Polk      Expires August 15, 2004                [Page 14]

Internet-Draft             Resource Priority               February 2004


6. Backwards Compatibility

   The resource priority mechanism described in this document is fully
   backwards compatible with SIP systems following RFC 3261 [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 still succeed.

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




































Schulzrinne & Polk      Expires August 15, 2004                [Page 15]

Internet-Draft             Resource Priority               February 2004


7. Examples

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

7.1 Simple Call

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

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

   F1 INVITE User A -> User B

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

   ...

   F2 180 Ringing User B -> User A

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9
     ;received=192.0.2.101
   From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
   To: LittleGuy <sip:UserB@biloxi.com>;tag=8321234356



Schulzrinne & Polk      Expires August 15, 2004                [Page 16]

Internet-Draft             Resource Priority               February 2004


   Call-ID: 3848276298220188511@atlanta.com
   CSeq: 1 INVITE
   Resource-Priority: dsn.flash
   Contact: <sip:UserB@client.biloxi.com;transport=tcp>
   Content-Length: 0


   F3 200 OK User B -> User A

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

   ...


7.2 Receiver Does Not Understand Namespace

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





















Schulzrinne & Polk      Expires August 15, 2004                [Page 17]

Internet-Draft             Resource Priority               February 2004


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


   F1 INVITE User A -> User B

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

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

   ...

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

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



Schulzrinne & Polk      Expires August 15, 2004                [Page 18]

Internet-Draft             Resource Priority               February 2004


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

   F3 ACK User A -> User B

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

   F4 INVITE User A -> User B

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

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




















Schulzrinne & Polk      Expires August 15, 2004                [Page 19]

Internet-Draft             Resource Priority               February 2004


8. Security Considerations

   Any resource priority mechanism can be abused to obtain resources and
   thus deny service to other users.  An adversary may be able to take
   over a particular gateway, cause additional congestion during PSTN
   during emergencies or deny service to legitimate users.

   While the indication itself does not have to provide separate
   authentication, any SIP request carrying such information has higher
   authentication requirements than regular requests.  Below, we
   describe authentication and authorization aspects, confidentiality
   and privacy requirements, protection against denial of service
   attacks and anonymity requirements.  Naturally, the general
   discussion in RFC 3261 [RFC3261] applies.

8.1 Authentication and Authorization

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

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

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

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

   Authentication MAY be SIP-based or use other mechanisms.  Use of
   Digest authentication and/or S/MIME is RECOMMENDED for UAS
   authentication.  Digest authentication requires that the parties
   share a common secret, thus limiting its use across administrative
   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, asserted identity [RFC3325] and
   transitive trust may be used to build a sufficiently robust system.
   Section 5 describes third-party authentication.

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



Schulzrinne & Polk      Expires August 15, 2004                [Page 20]

Internet-Draft             Resource Priority               February 2004


   user identifiers to authorizations.

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

8.2 Confidentiality and Integrity

   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', 'Subject' and 'Via' 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].  Encapsulation allows to protect
   this header field against inspection or modification by proxies,
   using S/MIME.  However, in many cases, proxies will need to
   authenticate and authorize the request, so that encapsulation is
   undesirable.

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

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

8.3 Anonymity

   Some users may wish to remain anonymous to the request destination.
   Anonymity for requests with resource priority is no different than
   for any other authenticated SIP request.  For the reasons noted
   earlier, users have to authenticate themselves towards the SIP



Schulzrinne & Polk      Expires August 15, 2004                [Page 21]

Internet-Draft             Resource Priority               February 2004


   elements carrying the request where they desire resource priority
   treatment.  The authentication may be based on capabilities and noms,
   not necessarily their civil name.  Clearly, they may remain anonymous
   towards the request destination, using the network-asserted identity
   and general privacy mechanisms [RFC3323][RFC3325].

8.4 Denial-of-Service Attacks

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



































Schulzrinne & Polk      Expires August 15, 2004                [Page 22]

Internet-Draft             Resource Priority               February 2004


9. IANA Considerations

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

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

   The following is the registration for the 'Resource-Priority' 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


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


9.3 IANA Registration for Response Code 417

   RFC number: XXXX

   Response code: 417

   Default reason phrase: Unknown Resource-Priority







Schulzrinne & Polk      Expires August 15, 2004                [Page 23]

Internet-Draft             Resource Priority               February 2004


9.4 IANA Namespace and Priority Registrations

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

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

   Below is a template for the registration of a new namespace:

   Namespace: Designation of the namespace, according to the BNF
      'namespace' in Section 3.

   Description: Description of the use and application of this
      particular namespace.

   Documentation: If applicable, reference to a document describing the
      namespace in more detail.

   Organization: If applicable, organization definining this namespace.
      (For example, an IETF standards-track RFC could also define a
      namespace, not just an external organization.)

   Policy: Either if not defined normatively elsewhere or for
      informative purposes, this element describes how a SIP element
      handles requests containing priority values with this namespace.
      There are many possible behaviors that cannot be exhaustively
      anticipated.  Three common behaviors are preemption, precedence
      and threshold-exemption. Preemption means that a request with
      greater priority can displace an existing request with lower
      priority that is already in progress. Precedence means that a
      higher-priority request assumes a position in the queue aheadd of
      a lower-priority request, but any in-progress request is not
      affected by its arrival.  In addition, systems with preemption MAY
      specify whether requests that cannot obtain resources immediately
      are queued or rejected immediately.  Threshold-exemption allows
      higher-priority calls to access resources, such as circuits, that
      are unavailable to lower-priority calls, e.g., because they are
      held in reserve.



Schulzrinne & Polk      Expires August 15, 2004                [Page 24]

Internet-Draft             Resource Priority               February 2004


   Behavior: Either a reference to a stable document describing the
      behavior of SIP elements when receiving priority indications from
      this namespace, or the description itself. There are many detailed
      Additional behavior could describe whether a particular call is,
      for example, exempt from capacity restrictions.

   Priority values (least to greatest): A list of priority values,
      ordered from least to highest priority.


9.5 Initial Namespace Registrations

9.5.1 Namespace dsn

   Namespace: dsn

   Description: United States Defense Switched Network.  The values are
      adopted from RFC 791 [RFC0791], omitting the levels "critic-ecp",
      "network control" and "internetwork control", as these are
      inappropriate here.

   Documentation: ANSI T1.619, Section B1

   Organization: United States Department of Defense, Defense
      Information Systems Agency (DISA).

   Preemption or precedence: Preemption with rejection.

   Priority values (least to greatest): "routine", "priority",
      "immediate", "flash", "flash-override"


9.5.2 Namespace q735

   Namespace: q735

   Description: ITU Q.735.3 describes multi-level precedence and
      preemption in SS7.  The namespace "q735" supports interworking
      with Q.735.3 (or equivalent) GSTN (ISDN) entities; this allows,
      for example, carrying information between Q.735.3 entities without
      loss of information.  One or both of the SIP endpoints might be
      PSTN gateways.

   Documentation: Q.735.3 [Q.735.3]

   Organization: ITU-T





Schulzrinne & Polk      Expires August 15, 2004                [Page 25]

Internet-Draft             Resource Priority               February 2004


   Preemption or precedence: Precedence.

   Priority values (least to greatest): "4", "3", "2", "1", "0"


9.5.3 Namespace DRSN

   Namespace: drsn

   Description: United States Defense Red Switched Network.

   Organization: United States Department of Defense, Defense
      Information Systems Agency (DISA).

   Preemption or precedence: Preemption with rejection.

   Priority values (least to greatest): "routine", "priority",
      "immediate", "flash", "flash-override", "flash-override-override"

































Schulzrinne & Polk      Expires August 15, 2004                [Page 26]

Internet-Draft             Resource Priority               February 2004


10. Acknowledgments

   Ben Campbell, Paul Kyzivat, Rohan Mahy, and Mike Pierce provided
   helpful comments.















































Schulzrinne & Polk      Expires August 15, 2004                [Page 27]

Internet-Draft             Resource Priority               February 2004


Normative References

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

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", 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.

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






















Schulzrinne & Polk      Expires August 15, 2004                [Page 28]

Internet-Draft             Resource Priority               February 2004


Informative References

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

   [I-D.ietf-ieprep-sip-reqs]
              Schulzrinne, H., "Requirements for Resource Priority
              Mechanisms for the Session Initiation  Protocol",
              draft-ietf-ieprep-sip-reqs-00 (work in progress), August
              2002.

   [I-D.ietf-sip-identity]
              Peterson, J., "Enhancements for Authenticated Identity
              Management in the Session  Initiation Protocol (SIP)",
              draft-ietf-sip-identity-01 (work in progress), March 2003.

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

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

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








Schulzrinne & Polk      Expires August 15, 2004                [Page 29]

Internet-Draft             Resource Priority               February 2004


Authors' Addresses

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

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


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

   EMail: jmpolk@cisco.com






























Schulzrinne & Polk      Expires August 15, 2004                [Page 30]

Internet-Draft             Resource Priority               February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

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


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Schulzrinne & Polk      Expires August 15, 2004                [Page 31]

Internet-Draft             Resource Priority               February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Schulzrinne & Polk      Expires August 15, 2004                [Page 32]