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 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]