Internet DRAFT - draft-gross-cops-sip
draft-gross-cops-sip
Internet Engineering Task Force G. Gross
INTERNET DRAFT Intel Corporation
draft-gross-cops-sip-01.txt
April, 2001 D. Rawlins
Expires: October 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 October 2001 [Page 1]
Internet Draft COPS Usage for SIP April 2001
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.4. Decision Object (Decision)....................................4
4. Usage...........................................................4
4.1. INVITE........................................................5
4.1.1. Request.....................................................5
4.1.2. Decision....................................................5
4.2. 2xx Response to INVITE........................................6
4.3. ACK...........................................................6
4.4. BYE...........................................................7
4.5. REGISTER......................................................7
4.5.1. Request.....................................................7
4.5.2. Decision....................................................7
4.5.3. COPS State Removal..........................................7
4.6. CANCEL........................................................8
5. Accounting......................................................8
6. Security Considerations.........................................8
7. Acknowledgments.................................................8
8. References......................................................9
9. Author's Address................................................9
10. Full Copyright Statement......................................10
Gross et al. Expires October 2001 [Page 2]
Internet Draft COPS Usage for SIP April 2001
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 October 2001 [Page 3]
Internet Draft COPS Usage for SIP April 2001
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)
All objects contained in the SIP message are encapsulated inside the
Signaled Client Specific Info Object (Signaled ClientSI) of the COPS
Request. The objects within the SIP message contain 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.
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)
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
Gross et al. Expires October 2001 [Page 4]
Internet Draft COPS Usage for SIP April 2001
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
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, or an associated AAA service, 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
Gross et al. Expires October 2001 [Page 5]
Internet Draft COPS Usage for SIP April 2001
required, the PDP may obtain one or more tokens through outsourcing
or internal generation.
The Context Object of the COPS Decision messaged specifies INVITE
for the M-Type. 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
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 throughout the descriptive text. 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 throughout the descriptive text.
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
Gross et al. Expires October 2001 [Page 6]
Internet Draft COPS Usage for SIP April 2001
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 throughout the
descriptive text. 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 throughout
the descriptive text.
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 with M-Type = REGISTER.
4.5.2. Decision
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.
Gross et al. Expires October 2001 [Page 7]
Internet Draft COPS Usage for SIP April 2001
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.
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
Gross et al. Expires October 2001 [Page 8]
Internet Draft COPS Usage for SIP April 2001
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.
[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.
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
Gross et al. Expires October 2001 [Page 9]
Internet Draft COPS Usage for SIP April 2001
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
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 than
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 THE INTERNET ENGINEERING
TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gross et al. Expires October 2001 [Page 10]
