< draft-polk-sipping-resource-00.txt   draft-polk-sipping-resource-01.txt >
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft Polk/Schulzrinne Internet Draft Polk/Schulzrinne
Cisco/Columbia U. Cisco/Columbia U.
draft-polk-sipping-resource-00.txt draft-polk-sipping-resource-01.txt
February 19, 2002 March 2, 2002
Expires: June 2002 Expires: August 2002
SIP Communications Resource Priority Header SIP Communications Resource Priority Header
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 39
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a new SIP header field for communications This document defines a new SIP header field for communications
resource priority, called "Resource-Priority". This header field resource priority, called "Resource-Priority". This header field
influences the behavior of gateways and SIP proxies. It does not influences the behavior of gateways and SIP proxies. It does not
influence the forwarding behavior of IP routers. influence the forwarding behavior of IP routers.
Table of Contents
1 Conventions used in this document ................... 2
2 Introduction ........................................ 2
3 The Resource-Priority Header Field .................. 3
4 IANA Considerations ................................. 4
5 Security Considerations ............................. 4
A Namespace dsn ....................................... 4
B Namespace q735 ...................................... 4
C Bibliography ........................................ 4
D Acknowledgements .................................... 5
E Authors' Addresses .................................. 5
1 Conventions used in this document 1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2 Introduction 2 Introduction
This document defines a new SIP [2] header field for communications This document defines a new SIP [2] header field for communications
resource priority, called "Resource-Priority". This header MAY be resource priority, called "Resource-Priority". This header MAY be
skipping to change at page 1, line 63 skipping to change at page 2, line 28
Recommendation Q.735.3 [3] prioritization mechanism, in both GSTN- Recommendation Q.735.3 [3] prioritization mechanism, in both GSTN-
to-IP and IP-to-GSTN directions. For IP networks, proxies may offer to-IP and IP-to-GSTN directions. For IP networks, proxies may offer
mechanisms beyond the scope of this document to influence, for mechanisms beyond the scope of this document to influence, for
example, admission control or IP packet marking. example, admission control or IP packet marking.
The Resource-Priority header field may be inserted by proxies and SIP The Resource-Priority header field may be inserted by proxies and SIP
user agents. user agents.
The Resource-Priority header field may be used in several situations: The Resource-Priority header field may be used in several situations:
1. Requesting elevated priority for access to PSTN gateway 1. Requesting elevated priority for access to GSTN gateway
resources such as trunk circuits. resources such as trunk circuits.
2. Carrying information from one multi-level priority domain 2. Carrying information from one multi-level priority domain
in the telephone network, e.g., using the facilities of in the telephone network, e.g., using the facilities of
Q.735.3 [3], to another, without the SIP proxies themselves Q.735.3 [3], to another, without the SIP proxies themselves
inspecting the header field. inspecting the header field.
3. Indicating signaling priority in SIP proxies and back-to- 3. Indicating signaling priority in SIP proxies and back-to-
back user agents, with higher priorities displacing back user agents, with higher priorities displacing
existing signaling requests or bypassing PSTN gateway existing signaling requests or bypassing GSTN gateway
capacity limits in effect for lower priorities. capacity limits in effect for lower priorities.
This header is related to, but differs in semantics from, the This header is related to, but differs in semantics from, the
Priority header field (RFC 2543, Section 6.25). The Priority header Priority header field (RFC 2543, Section 6.25). The Priority header
field describes the priority that the SIP request should have to the field describes the priority that the SIP request should have to the
receiving human or its agent. For example, it may be factored into receiving human or its agent. For example, it may be factored into
decisions about call routing and acceptance. It does not influence decisions about call routing and acceptance. It does not influence
the use of communications resources such as packet forwarding the use of communications resources such as packet forwarding
priority in routers. priority in routers.
Header field where proxy ACK BYE CAN INV OPT REG
_____________________________________________________________
Resource-Priority Rr a - - - o - -
The mechanism described here can be used for emergency preparedness, The mechanism described here can be used for emergency preparedness,
but is only a small part of an emergency preparedness network. but is only a small part of an emergency preparedness network.
SIP entities supporting this specification MUST be able to generate SIP entities supporting this specification MUST be able to generate
and process this header. and process this header.
3 The Resource-Priority Header Field 3 The Resource-Priority Header Field
This document defines the Resource-Priority general header field. This document defines the Resource-Priority general header field.
skipping to change at page 1, line 120 skipping to change at page 3, line 40
Resource-Priority c ar - - - o - - Resource-Priority c ar - - - o - -
SIP elements MAY downgrade the Resource-Priority of or reject SIP elements MAY downgrade the Resource-Priority of or reject
unauthenticated requests. Details are a matter of local policy. unauthenticated requests. Details are a matter of local policy.
Proxies MAY downgrade the Resource-Priority value of unauthenticated Proxies MAY downgrade the Resource-Priority value of unauthenticated
requests. Details are specific to each administrative domain and requests. Details are specific to each administrative domain and
beyond the scope of this document. Proxies SHOULD NOT reject requests beyond the scope of this document. Proxies SHOULD NOT reject requests
with such headers but instead downgrade the resource priority value. with such headers but instead downgrade the resource priority value.
SIP elements MUST ignore a Resource-Priority header value with an
unknown name space or priority value.
A proxy or user agent MAY return status code 503 (Service A proxy or user agent MAY return status code 503 (Service
Unavailable) if there are insufficient resources at the resource Unavailable) if there are insufficient resources at the resource
priority level specified. The response MAY also include a Warning priority level specified. The response MAY also include a Warning
header with warning code 370 (Insufficient Bandwidth) if the request header with warning code 370 (Insufficient Bandwidth) if the request
failed due to insufficient capacity for the media streams, rather failed due to insufficient capacity for the media streams, rather
than insufficient signaling capacity. than insufficient signaling capacity.
4 IANA Considerations 4 IANA Considerations
Additional name spaces and priority values are registered with IANA. Additional name spaces and priority values are registered with IANA.
Within each namespace, The registration MUST indicate the relative Within each namespace, The registration MUST indicate the relative
precedence levels, expressed as an ordered list. Existing lists of precedence levels, expressed as an ordered list. New labels SHOULD
priorities can only be extended at the bottom, i.e., by adding values NOT be added to existing namespaces; as noted above, implementations
with lower priority than any currently registered values. TBD: Any predating the addition will ignore such values.
restrictions on new namespaces?
5 Security Considerations 5 Security Considerations
The Resource-Priority header field can be abused to consume scarce The Resource-Priority header field can be abused to consume scarce
communications resources. Thus, authentication of the requester is of communications resources. Thus, authentication of the requester is of
particular importance. Authentication MAY be SIP-based. particular importance. Authentication MAY be SIP-based.
A Namespace dsn A Namespace dsn
An initial namespace, "dsn" (Defense Switched Network), contains the This document defines the namespace "dsn". The namespace "dsn"
priority values, "flash-override", "flash", "immediate", "priority", (Defense Switched Network), contains the priority values "critic-
"routine", where "flash-override" is the highest priority and ecp", "flash-override", "flash", "immediate", "priority", "routine".
"routine" is the lowest. [TBD: Should this just be registered by IANA
rather than appear in the document?]
The values are adopted from RFC 791 [4], omitting the levels "network The values are adopted from RFC 791 [4], omitting the levels "network
control" and "internetwork control", as these are inappropriate here. control" and "internetwork control", as these are inappropriate here.
The values are prioritized in the order "critic-ecp" (highest), The values are prioritized in the order "critic-ecp" (highest),
"flash-override", "flash", "immediate", "priority" and "routine" "flash-override", "flash", "immediate", "priority" and "routine"
(lowest). Additional values in the extension parameter are treated as (lowest).
"routine" by entities that do not understand the value.
The value "critic-ecp" stands for "Critical and Emergency Call The value "critic-ecp" stands for "Critical and Emergency Call
Processing" [4]. This value SHOULD only be used for authorized Processing" [4]. This value SHOULD only be used for authorized
emergency communications, for example in the United States Government emergency communications, for example in the United States Government
Emergency Telecommunications Service (GETS) [5], the United Kingdom Emergency Telecommunications Service (GETS) [5], the United Kingdom
Government Telephone Preference Scheme (GTPS) and similar government Government Telephone Preference Scheme (GTPS) and similar government
emergency preparedness or reactionary implementations elsewhere. emergency preparedness or reactionary implementations elsewhere.
B Namespace q735 B Namespace q735
The namespace "q735" is registered here. It supports carrying This document also defines the namespace "q735". The namespace "q735"
information between Q.735.3 (or equivalent) PSTN/ISDN entities supports interworking with Q.735.3 (or equivalent) GSTN (ISDN)
without intervening interpretation by SIP proxies and avoids entities; this allows, for example, carrying information between
unnecessary interpretation between different networks. The namespace Q.735.3 entities without loss of information. One or both of the SIP
contains the priority values "0", "1", "2", "3" and "4", with "0" endpoints might be PSTN gateways. The namespace contains the priority
being the lowest value and the "4" the highest. values "0", "1", "2", "3" and "4", with "4" representing the lowest
priority and "0" the highest.
C Bibliography C Bibliography
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force, levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997. Mar. 1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
skipping to change at page 1, line 216 skipping to change at line 230
Richardson, TX 75082 USA Richardson, TX 75082 USA
electronic mail: jmpolk@cisco.com electronic mail: jmpolk@cisco.com
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
Table of Contents
1 Conventions used in this document ................... 2
2 Introduction ........................................ 2
3 The Resource-Priority Header Field .................. 3
4 IANA Considerations ................................. 3
5 Security Considerations ............................. 4
A Namespace dsn ....................................... 4
B Namespace q735 ...................................... 4
C Bibliography ........................................ 4
D Acknowledgements .................................... 5
E Authors' Addresses .................................. 5
 End of changes. 12 change blocks. 
23 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/