One document matched: draft-gross-cops-sip-00.txt
Internet Engineering Task Force G. Gross
INTERNET DRAFT Intel Corporation
draft-gross-cops-sip-00.txt
November, 2000 D. Rawlins
Expires: May 2001 H. Sinnreich
SIP Working Group MCI WorldCom
S. Thomas
TransNexus
COPS Usage for SIP
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.
Abstract
The development of QoS enhanced IP communication requires an
infrastructure that supports AAA services. General accounting and
settlement on the intra-domain level and inter-domain level are
necessary. As part of the solution to these requirements, this
document describes a new COPS outsourcing extension for SIP . A
description of COPS objects that have special meaning in the SIP
environment is provided. The usage of the COPS extension for SIP is
given for clients and servers.
Gross et al. Expires May 2001 [Page 1]
Internet Draft COPS Usage for SIP November 2000
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
1. Introduction....................................................3
2. Terminology.....................................................3
3. SIP Values for COPS Objects.....................................3
3.1. Common Header, Client-Type....................................3
3.2. Context Object (Context)......................................3
3.3. Client Specific Info (ClientSI)...............................4
3.3.1. Session-level Description...................................5
3.3.2. Media-level Description.....................................6
3.4. Decision Object (Decision)....................................6
4. Usage...........................................................7
4.1. INVITE........................................................7
4.1.1. Request.....................................................7
4.1.2. Decision....................................................8
4.2. 2xx Response to INVITE........................................8
4.3. ACK...........................................................9
4.4. BYE...........................................................9
4.5. REGISTER......................................................9
4.5.1. Request.....................................................9
4.5.2. Decision....................................................9
4.5.3. COPS State Removal.........................................10
4.6. CANCEL.......................................................10
5. Accounting.....................................................10
6. Security Considerations........................................11
7. Acknowledgments................................................11
8. References.....................................................11
9. Author's Address...............................................12
10. Full Copyright Statement......................................13
Gross et al. Expires May 2001 [Page 2]
Internet Draft COPS Usage for SIP November 2000
1. Introduction
The Common Open Policy Service (COPS) protocol is a request response
protocol for exchanging policy information and policy based
decisions [1]. It facilitates policy-based admission control over
network resources. One such resource is bandwidth reservation. A
COPS extension for RSVP has been developed to provide policy-based
admission control support for RSVP within networks [2], [3].
This document describes a new COPS outsourcing extension for SIP
[4]. The extension facilitates policy-based admission control over
SIP services and quality of service (QoS) resources that may be
requested through SIP. The extension also facilitates authorization,
authentication, and accounting (AAA) services for user and inter-
domain agreements. This is accomplished by offering a means of
transporting COPS opaque authorization tokens within COPS messages.
The framework that serves as a context for this work is described in
other documents [5], [6], [7], [8]. This document assumes prior
knowledge of SIP and the basic COPS protocol.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [9].
3. SIP Values for COPS Objects
This section describes the format and semantics of the COPS objects
that have a specific format and meaning when used with the SIP
client type.
3.1. Common Header, Client-Type
SIP is COPS client type [TBD].
3.2. Context Object (Context)
The semantics of the Context object for SIP is described in this
section. The R-Type flag applies to SIP messages specified in the M-
Type field.
R-Type (Request Type Flag)
Resource-Allocation request
This context identifies a PEP request to allow a SIP multimedia
session to be established. It applies to INVITE and REGISTER
messages only. When used with the INVITE context an install
decision implies that the multimedia session with the specified
media parameters may continue to be established. When used with
Gross et al. Expires May 2001 [Page 3]
Internet Draft COPS Usage for SIP November 2000
the REGISTER context an install decision implies that the REGISTER
request SHOULD be forwarded to the SIP registrar.
M-Type (Message Type)
The applicable SIP message type for the Context Object is identified
by the value in the M-Type field. The values are identical to those
used in the SIP message Request-Line of the SIP message header.
The following SIP message types can be used in the COPS Context
Object M-Type field:
INVITE, REGISTER
The use of other SIP message types in the M-Type field may only be
supported in a later version of SIP or a later version of this
document.
3.3. Client Specific Info (ClientSI)
The Signaled Client Specific Info Object (Signaled ClientSI)
contains session information including source, destination, media
and quality of service parameters. The PDP may use this information
for policy-based admission control and accounting purposes.
The Signaled ClientSI Object consists of one or more sub-objects, or
items. Each item is variable length and is not required to fall on
32 bit boundaries. Each item begins with a four-octet header
comprised of a two-octet length field and a two-octet I-Type (Item
Type) field. The structure of an item is formatted as follows:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | I-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
The length gives the number of octets, including the item header,
which composes the object. The I-Type uniquely identifies the item.
The value in the length field may be zero in which case the object
contents field would be absent. The contents are text-based using
ISO 10646 in UTF-8 encoding following the same rules outlined in SIP
[10].
When supplied in a COPS Request or update Request message in
response to a SIP INVITE, ACK or 2xx response message, the items in
a ClientSI Object describe the multimedia session. Each session may
consist of multiple media streams. Following the format used by SDP
[11], the items in the ClientSI Object are divided into two levels
Gross et al. Expires May 2001 [Page 4]
Internet Draft COPS Usage for SIP November 2000
of description: session-level description and media-level
description.
The items in the session-level description apply to the whole
session. The items in the media-level description apply to a
specific media stream. There may be only one session-level
description in a ClienSI Object and each item in the session-level
description may appear more than once.
The list of I-Types and their corresponding decimal values are:
Session description:
1 = SIP context
2 = Request URI (SIP header)
3 = To (SIP header)
4 = From (SIP header)
5 = Contact (SIP header)
6 = CallID (SIP header)
7 = authorization token (SIP header)
8 = owner address
Media description:
9 = media info
10 = address type
11 = source address
12 = source port
13 = destination address
14 = destination port
The session-level description (I-Types 1 - 8) must appear first in
the ClientSI Object. There may be zero or more media-level
descriptions in a ClienSI Object. Each media-level description (I-
Types 9 - 14) begins with a REQUIRED media info item (I-Type = 9).
The end of a media-level description is marked by the next media
info item, or the end of the ClientSI Object. The media-level
description items are associated with the media info item
immediately preceding them. All items in each level description must
appear in exactly the same order as shown here.
3.3.1. Session-level Description
I-Type items 1 through 8, inclusive, comprise the session-level
description of the ClientSI Object. The SIP context item MUST be
included in the ClientSI Object for all COPS messages. It informs
the PDP of the type of SIP message that this COPS message
corresponds with. The possible values of this field are described by
the following BNF:
SIP context = ("INVITE" | "REGISTER" | "BYE" | "CANCEL" | "ACK" |
"2xx")
I-Type values from 2 through 6, inclusive, are optional and are
taken directly from the SIP header. A description of these fields is
Gross et al. Expires May 2001 [Page 5]
Internet Draft COPS Usage for SIP November 2000
given in [4]. The authorization token item (I-Type = 7) is optional
and is also taken from the SIP header [8]. If the SIP message
contains multiple authorization tokens, each is placed adjacent to
the other(s) in an I-Type = 7 item within the same ClientSI Object.
The SIP header labels (e.g. "To:") are not included in the ClientSI
Object items.
The owner address item (I-Type = 8) is optional and may be taken
from the SDP session description in the SIP message [11]. The SDP
header label "o=" is not included in the item.
3.3.2. Media-level Description
I-Type items 9 through 14, inclusive, comprise a media-level
description of a ClientSI Object. Each media-level description MUST
contain a media info item. All other items are optional. The media
info item (I-Type = 9) contains the media type, transport protocol,
and any media format specifiers [12]. These entries are defined in
[11]. This item MUST be formatted identically as the SDP "m=" line
of the SIP message, with the exception that the port number is not
included [11]. As described in [11] each entry in this item MUST be
separated with a space.
I-Type items 10 through 14 specify the source, destination and
address type quintuple of the media stream. The address type refers
to the protocol type and version that the addresses of items 10 and
12 correspond with. An address type of "IP4" identifies Internet
Protocol version 4. This information may be taken from the SDP "c="
line of the SIP message, if present [11]. Source and destination
addresses and port numbers may be taken from the SDP "c=" and "m="
lines or the SIP header fields of the SIP message.
When the SIP context item (I-Type = 1) is REGISTER, a session-level
description is REQUIRED and any media-level descriptions are
ignored. When the SIP context item is BYE or CANCEL, only the SIP
context item is REQUIRED. All other items are ignored.
It is up to the PEP to know which optional items are required by the
PDP. This set of information may depend on policy administration,
authorization, and accounting practices. The inclusion of some
optional items may require specific behaviors by the PDP such as
processing of authorization tokens.
If the PDP detects the absence of information that it needs to
render a decision, it should respond with an <Error> in the Decision
message indicating, "Mandatory client specific info missing".
3.4. Decision Object (Decision)
Decision Objects enable PDPs to allow or deny SIP sessions and SIP
registration requests.
DECISION COMMANDS (C-Num = 6, C-Type = 1)
Gross et al. Expires May 2001 [Page 6]
Internet Draft COPS Usage for SIP November 2000
The following commands apply to SIP
Install
Positive Response:
Accept/Allow/Admit a SIP message or SIP session establishment.
Remove
Negative Response:
Deny/Reject a SIP message or the establishment of a SIP session.
Client Specific Decision Data (ClientSI Data) (C-Num = 6, C-Type =
4)
This object is used to carry a variable length authorization token
from the PDP to the PEP.
4. Usage
This section details the usage of COPS in the context of SIP
messaging. Each SIP message that triggers COPS messaging is
addressed individually.
4.1. INVITE
The SIP INVITE message is the first step in the establishment of a
SIP session. Typically, the INVITE message contains a subset of the
complete session information. The remainder of the session
information is contained in SIP response messages to the INVITE
message and/or the SIP ACK message.
4.1.1. Request
When a PEP receives a SIP INVITE message that requires a policy-
based decision, the PEP sends the PDP a COPS Request. The Context
Object specifies INVITE for the M-Type. The relevant information
required by the PDP to make a decision is placed in the ClienSI
object of the Request. The only allowable R-Type is resource
allocation.
The PEP should include all authorization tokens, if any, found in
the INVITE message in the COPS Request. Each token MUST be enclosed
within the ClientSI Object. One or more tokens may be included in
cases where they have been obtained by one or more domains in
previous hops. The PDP may process tokens for inter-domain
authorization.
Multiple authorization tokens may be required in roaming scenarios
where the caller, callee, or both have roamed into foreign (non-
home) domains. In such cases, AAA and policy servers in each domain
may not authorize the IP communication session unless a business
Gross et al. Expires May 2001 [Page 7]
Internet Draft COPS Usage for SIP November 2000
relationship exists with specific domains and a clearinghouse [5].
This may be required for account settlement, including charging and
billing.
The PDP may obtain one or more authorization tokens by outsourcing
or by internal generation. If authorization tokens are obtained,
they are returned in a COPS Decision message.
4.1.2. Decision
The PDP receiving an INVITE Request may first apply admission and
other intra-domain policies to determine if it should allow the
session to be established. If so, it may then decide whether it
needs to supply inter-domain authorization. If inter-domain
authorization is required the PDP may parse through the
authorization tokens supplied in the Request message, if any are
present. If present, the PDP processes any applicable tokens to
authenticate the identified domain(s). If no applicable tokens are
found in the Request and one or more are required, the PDP may
obtain one or more tokens through outsourcing or internal
generation.
If the Decision command is Install any tokens obtained by the PDP
SHOULD be included in the Decision message. Tokens received by the
PEP in the COPS Request message SHOULD not be included in the
Decision message. Authorization tokens are placed within Client
Specific Decision Data Objects of the Decision message, one token
per Object.
Install Decisions may require additional processing in cases where
services such as bandwidth reservation are requested or required.
For example, source, destination and media information may be used
by the PDP to provide RSVP support for the IP communication session.
Under device configuration models, the information may be used to
configure one or more RSVP enabled network devices.
Upon reception of the Decision message the PEP checks the Decision
flags. If the command is Install, the PEP adds all authorization
tokens included in the COPS Decision Object to the SIP INVITE
message. All authorization tokens that were already in the SIP
INVITE message SHOULD remain [8]. The PEP may only add tokens to an
INVITE message and MUST NOT delete any. The PEP may then forward the
INVITE as defined by SIP.
If the PDP decides, based on intra-domain or inter-domain policy,
that the SIP session cannot be established, the Decision command is
Remove. In this case, authorization tokens SHOULD NOT be included in
the Decision message. The PEP MUST NOT forward the SIP INVITE
message. Instead, the PEP SHOULD respond to the originator of the
INVITE message with an appropriate error message.
4.2. 2xx Response to INVITE
Gross et al. Expires May 2001 [Page 8]
Internet Draft COPS Usage for SIP November 2000
The 2xx SIP responses indicate that the SIP request was successfully
received, understood and accepted. They may contain new source,
destination or media information that is not already known by the
PDP.
If the 2xx response contains session information not already known
by the PDP, the PEP MUST send an update COPS Request to the PDP with
M-Type = INVITE. The PDP interprets this Request as it does for
INVITE messages described in a previous section, replacing 2xx for
INVITE in all cases. The PDP sends a COPS Decision message to the
PEP. The PEP interprets this Response as it does for INVITE messages
described in a previous section, replacing 2xx for INVITE in all
cases.
4.3. ACK
The SIP ACK message is sent by the session initiator to acknowledge
that the initiator has received a final response to an INVITE
message. This message may contain new source, destination or media
information that is not already known by the PDP. This may happen
under conditions of session parameter negotiation.
If the ACK message contains new session information, the PEP MUST
send an update COPS Request to the PDP with M-Type = INVITE. The PDP
interprets this Request as it does for INVITE messages described in
a previous section, replacing ACK for INVITE in all cases. The PDP
sends a COPS Decision message to the PEP. The PEP interprets this
Response as it does for INVITE messages described in a previous
section, replacing ACK for INVITE in all cases.
4.4. BYE
The SIP BYE message indicates the completion of an IP communication
session. The PEP MAY send an unsolicited Report State (RPT) message
to the PDP for intra-domain accounting purposes. The PEP MUST send a
Delete Request State (DRQ) message to the PDP to remove the COPS
state associated with the included COPS client handle. Note that if
a RPT message is sent, it must be sent before the DRQ message is
sent since the Client handle is rendered invalid by the DRQ.
4.5. REGISTER
4.5.1. Request
The SIP REGISTER message can be used to register a user with a SIP
registrar service. The PEP may outsource a policy decision regarding
the REGISTER message to the PDP. The PDP may or may not allow the
registration request, based on policy data. The relevant information
required by the PDP to make a decision is placed in the ClientSI
object of the Request. The only allowable R-Type is resource
allocation.
4.5.2. Decision
Gross et al. Expires May 2001 [Page 9]
Internet Draft COPS Usage for SIP November 2000
If the Decision command is Install the PEP MUST forward the SIP
REGISTER message in the manner defined by SIP. If the PEP receives a
Remove Decision command the PEP MUST NOT forward the REGISTER
message. Additionally, the PEP SHOULD respond to the originator of
the INVITE message with an appropriate error message.
4.5.3. COPS State Removal
Removal of SIP REGISTER entries from the SIP registrar can be
performed by SIP in one of two ways. The first method is to specify
a duration, or lifetime, for the registration. After the duration
time expires, the registration entry is removed. The second method
is for a user to send another SIP REGISTER message with specific
sub-fields set to indicate entry removal.
In both of the two cases described above, the PEP MUST send a DRQ
message to the PDP to delete the COPS state corresponding to the
REGISTER Request. In the first case, this happens when the time
interval expires. In the second case, this happens when the PEP
detects a REGISTER method meant for removing one or more
registrations. Additionally, in the second case, the PEP MUST
forward the REGISTER method in the manner defined by SIP.
4.6. CANCEL
The SIP CANCEL message attempts to cancel a pending SIP Request.
This document only addresses CANCEL messages pertaining to SIP
INVITE or REGISTER messages. The SIP Response to the CANCEL message
determines whether the CANCEL was successful or whether the pending
SIP Request was completed. Either is possible due to the ability of
messages to cross on the wire. If the PEP determines that a
successful Response to the CANCEL message was received, the PEP MAY
send a RPT message to the PDP and MUST send a DRQ message to the
PDP.
If the CANCEL message fails, the PEP MUST NOT send a DRQ message.
The COPS state is expected to remain until it is deleted as
discussed in previous sections concerning the SIP BYE and REGISTER
messages.
5. Accounting
The details concerning accounting are out of the scope of this
document. Some details are given in [5]. Briefly, two levels of
accounting may be considered: intra-domain accounting and inter-
domain accounting. Intra-domain accounting may be in the interest of
bookkeeping and does not consider billing issues. Inter-domain
accounting may involve a third party such as a clearinghouse for
account, billing and charge settlement, based on business
relationships.
Gross et al. Expires May 2001 [Page 10]
Internet Draft COPS Usage for SIP November 2000
In both cases, a AAA and policy server (APS) acting as the PDP for
SIP and RSVP would likely be responsible for keeping track of QoS
usage and session duration. As a billable service, consumed QoS
resources such as bandwidth may be tracked by the APS through RSVP
Resv and ResvTear messages. After session completion a usage report
may be generated and passed on to a clearinghouse for final
settlement.
6. Security Considerations
The protocols at issue in this document, COPS and SIP, contain their
own security mechanisms. This work is an extension of COPS and
therefore incorporates all of the security features of COPS. Any
security issues not addressed by SIP or COPS have not been
considered in this work and are left as open issues.
7. Acknowledgments
The authors would like to thank Russ Fenger, Arun Raghunath,
Changwen Liu, Mark Grosen, Jeff Mark, Kalon Kelley and Dave Durham
for insightful discussions and valuable contributions.
8. References
[1] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748,
January 2000.
[2] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) û Functional Specification",
RFC 2205, September 1997.
[3] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and
Sastry, A., "COPS Usage for RSVP", RFC 2749, January 2000.
[4] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[5] Gross, G., Sinnreich, H., Rawlins, D., Thomas, S., "QoS and AAA
Usage with SIP Based IP Communications", Internet Draft, Internet
Engineering Task Force, November 2000, Work in progress.
[6] Sinnreich, H., Donovan, S., Rawlins, D., Thomas, S.,
"Interdomain IP Communications with QoS, Authorization and Usage
Reporting", Internet Draft, Internet Engineering Task Force,
February 2000, Work in progress.
[7] Sinnreich, H., Rawlins, D., Johnston, A., Donovan, S., Thomas,
S., "AAA Usage for IP Telephony with QoS", Internet Draft, Internet
Engineering Task Force, July 2000, Work in progress.
Gross et al. Expires May 2001 [Page 11]
Internet Draft COPS Usage for SIP November 2000
[8] Johnston, A., Rawlins, D., Sinnreich, H., Thomas, S., "OSP
Authorization Token Header for SIP", Internet Draft, Internet
Engineering Task Force, November 2000, Work in progress.
[9] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[10] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[11] Handley, M. and Jacobson, V., "SDP: Session Description
Protocol", RFC 2327, April 1998.
[12] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[13] Marshall, W., et al. "Integration of Resource Management and
SIP", Internet Draft, Internet Engineering Task Force, June 2000,
Work in progress.
9. Author's Address
Gerhard Gross
Intel Corporation
MS JF3-206
2111 NE 25th Ave.
Hillsboro, OR 97124
Phone: +1-503-264-6389
Fax: +1-503-264-3483
gerhard.gross@intel.com
Diana Rawlins
WorldCom
901 International Parkway
Richardson, Texas 75081
USA
diana.rawlins@wcom.com
Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA
henry.sinnreich@wcom.com
Stephen Thomas
TransNexus, LLC
430 Tenth Street NW
Suite N-204
Atlanta, GA 30318
USA
stephen.thomas@transnexus.com
Gross et al. Expires May 2001 [Page 12]
Internet Draft COPS Usage for SIP November 2000
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it maybe 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 then
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING
TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gross et al. Expires May 2001 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 23:26:03 |