Internet Draft E. Henrikson Document: draft-henrikson-sip-charging-information- Lucent Expires: August 2002 Technologies Category: Informational February 2002 Private SIP Extension for Mobile Charging Information draft-henrikson-sip-charging-information-00 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 This document proposes a private SIP extension header P-Charging- Function-Addresses used to pass the addresses of entities that provide a charging function. There is a need in the Third Generation Partnership Project (3GPP) for entities that process charging information. For a particular dialog or standalone transaction, a proxy (or UA within the network, e.g. a gateway) may need to pass information to one or more charging entities. The affected UAs and proxies associated with the dialog or standalone transaction need to know the identities or addresses of the appropriate charging entities. This document also proposes a private SIP extension header P- Charging-Vector to pass correlation information for charging purposes. The network entities in the 3GPP architecture share correlation information to ensure that charging activities are coordinated. The need applies for any SIP method used to initiate a dialog, standalone messages and some response messages. Henrikson Expires - October 2002 [Page 1] Private SIP Extension for Mobile Charging Information April 2002 Table of Contents 1. Background....................................................2 2. Discussion of Mechanism.......................................3 3. Applicability Statement.......................................3 4. Syntax........................................................3 5. Usage.........................................................4 5.1 Procedures at the UA......................................4 5.2 Procedures at the Proxy...................................4 5.3 Procedures at the Back to Back UA.........................5 6. Security Considerations.......................................5 7. IANA Considerations...........................................5 8. Normative References..........................................5 9. Non-Normative References......................................6 Author's Addresses...............................................6 1. Background 3GPP has defined a distributed architecture that results in multiple network entities becoming involved in providing access and service. Operators need the ability and flexibility to charge for the access and services as they see fit. This requires coordination among the network entities, which includes correlating charging records generated from different entities that are related to the same session. There is a need to inform each network entity involved about common charging functions to receive the generated records. The solution provided by 3GPP is to define a two types of charging functions: Charging Collection Function (CCF) and Event Charging Function (ECF). CCF is used for off-line charging and ECF is used for on-line charging. There may be a primary and secondary CCF and ECF, for redundancy purposes. The CCF and ECF addresses may be passed during the establishment of a dialog or standalone transaction. The details are specified in the 3GPP documents, see 3GPP TS 32.200 [6]. Additionally, a charging vector is defined that may be filled in during the establishment of a dialog or standalone transaction. The information inside the charging vector may be filled in by multiple network entities and retrieved by multiple network entities. There are three types of correlation information to be passed: IMS Charging ID (ICID), Inter Operator Identifiers (IOI) and access network charging information. ICID is a globally unique value that may be used to correlate charging records. There may an IOI generated from each side of the dialog to identify the network associated with each side. The access network charging information Henrikson Expires - October 2002 [Page 2] Private SIP Extension for Mobile Charging Information April 2002 consists of network specific identifiers for the access level (e.g. 3GPP radio access network or IEEE 802.11b). 2. Discussion of Mechanism The provided mechanism uses private headers "P-Charging-Function- Addresses" and "P-Charging-Vector" in either the initial request or subsequent response for a dialog or standalone transaction. The mechanisms by which an entity determines which values to populate in the P-Charging-Vector header and "P-Charging-Vector" are specific to the local implementation and outside the scope of this document. 3. Applicability Statement The P-Charging-Function-Addresses and P-Charging-Vector headers are applicable within a single network where coordination of charging is required according to the architecture specified in 3GPP TS 32.100 [6]. 4. Syntax All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [2]. Further, the BNF definitions from RFC 3261 [1] are inherited for the P-Charging-Function-Addresses header and are not repeated here. Implementers need to need to be familiar with the notation and content of RFC 3261 [2] and RFC 2234 [2] to understand this document. The syntax for the P-Charging-Function-Addresses header is: p-Charging-Function-Addresses = "P-Charging-Function-Addresses" HCOLON 1#( "primary-ccf" EQUAL primary-ccf SEMI "secondary-ccf" EQUAL secondary-ccf SEMI "primary-ecf" EQUAL primary-ecf SEMI "secondary-ecf" EQUAL secondary-ecf ) primary-ccf = gen-value secondary-ccf = gen-value primary-ecf = gen-value secondary-ecf = gen-value Henrikson Expires - October 2002 [Page 3] Private SIP Extension for Mobile Charging Information April 2002 The syntax for the P-Charging-Vector header is: p-ChargingVector = "P-Charging-Vector" HCOLON 1#( "icid" EQUAL icid SEMI "ioi-originating" EQUAL ioi-originating SEMI "ioi-terminating" EQUAL ioi-terminating SEMI "access-network-charging-info" EQUAL access-network-charging-info ) icid = gen-value ioi-originating = gen-value ioi-terminating = gen-value access-network-charging-info = gen-value The allowable usage of headers is described in Table 2 of SIP [1Error! Reference source not found.]. The following additions to this table are needed for the P-Charging-Vector header. Addition of P-Charging-Vector to SIP Table 2: Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT ------------------------------------------------------------------- P-Charging-Function -Addresses ard - o - o o o o o o P-Charging-Vector ard - o - o o o o o o 5. Usage 5.1 Procedures at the UA The UAC and UAS (originating and terminating UA) behave as usual. They are not required to understand the P-Charging-Function- Addresses header, but may retrieve the information if received. The UAC and UAS (originating and terminating UA) behave as usual. They are not required to understand the P-Charging-Vector header, but may retrieve the information if received. 5.2 Procedures at the Proxy The P-Charging-Function-Addresses and P-Charging-Vector headers are treated like any other unknown header by intermediate proxies. They simply forward it on towards the destination. Henrikson Expires - October 2002 [Page 4] Private SIP Extension for Mobile Charging Information April 2002 If a proxy that supports this extension receives a request or response without the P-Charging-Function-Addresses or P-Charging- Vector header, it may insert a P-Charging-Function-Addresses or P- Charging-Vector header prior to forwarding the message. If a proxy that supports this extension receives a request or response with the P-Charging-Function-Addresses or P-Charging- Vector header, it may retrieve the information from the header to use with application specific logic, i.e. charging. The proxy should retain the P-Charging-Function-Addresses or P-Charging- Vector header in the outbound message. If the next hop for the message is outside the closed network of the proxy, then the proxy shall remove the P-Charging-Function-Addresses and P-Charging- Vector headers from the message. 5.3 Procedures at the Back to Back UA If a B2BUA that understands the P-Charging-Function-Addresses header or P-Charging-Vector header receives a request/response with the P-Charging-Function-Addresses or P-Charging-Vector header, the B2BUA should copy them from the receiving side UA to the sending side UA. 6. Security Considerations It is possible for proxies and B2BUAs within a closed network to modify the value of P-Charging-Function-Addresses and P-Charging- Vector or to insert these headers into a request for a dialog, e.g. INVITE request (or other request or response). It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore critical to apply transitive mutual authentication between entities in the closed network, using sips: or other available mechanisms in order to prevent such attacks. 7. IANA Considerations This document defines the SIP extension headers "P-Charging- Function-Addresses" and "P-Charging-Vector" which should be included in the registry of SIP headers defined in SIP [1]. As required by the SIP change process draft-tsvarea-sipchange [4] the SIP extension header name "Charging-Function-Addresses" and "Charging-Vector" should also be registered in association with this extension. 8. Normative References Henrikson Expires - October 2002 [Page 5] Private SIP Extension for Mobile Charging Information April 2002 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session Initiation Protocol, RFC 3261", March 2002. [2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," RFC 2234, Internet Engineering Task Force, November 1997. 9. Non-Normative References [3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia- sipping-3gpp-reqs-03.txt", March 2002. [4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange", March 2002. [5] 3GPP TS 32.200, Version 5, "????" Author's Addresses Eric Henrikson Lucent Technologies 11601 Willows Rd Suite 100 Redmond, WA 98052 US Phone: +1 425 497 2442 EMail: ehenrikson@lucent.com URI: http://www.lucent.com/ Henrikson Expires - October 2002 [Page 6]