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]