偶看新闻定向爆破意外:RFC 4006 - Diameter Credit-Control Applicatio...
来源：百度文库 编辑：偶看新闻 时间：2024/04/28 00:04:07
[Docs] [txt] [pdf] [draft-ietf-aaa-diameter-cc] [Diff1] [Diff2] [IPR]
PROPOSED STANDARD
PROPOSED STANDARD
Network Working Group H. HakalaRequest for Comments: 4006 L. MattilaCategory: Standards Track EricssonJ-P. KoskinenM. SturaJ. LoughneyNokiaAugust 2005Diameter Credit-Control ApplicationStatus of This MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis document specifies a Diameter application that can be used toimplement real-time credit-control for a variety of end user servicessuch as network access, Session Initiation Protocol (SIP) services,messaging services, and download services.Table of Contents1. Introduction................................................. 41.1. Requirements Language................................. 51.2. Terminology........................................... 51.3. Advertising Application Support....................... 72. Architecture Models.......................................... 73. Credit-Control Messages...................................... 93.1. Credit-Control-Request (CCR) Command.................. 93.2. Credit-Control-Answer (CCA) Command................... 114. Credit-Control Application Overview.......................... 114.1. Service-Specific Rating Input and Interoperability.... 135. Session Based Credit-Control................................. 155.1. General Principles.................................... 155.2. First Interrogation................................... 215.3. Intermediate Interrogation............................ 275.4. Final Interrogation................................... 29Hakala, et al. Standards Track [Page 1]
RFC 4006 Diameter Credit-Control Application August 20055.5. Server-Initiated Credit Re-Authorization.............. 305.6. Graceful Service Termination.......................... 325.7. Failure Procedures.................................... 386. One Time Event............................................... 416.1. Service Price Enquiry................................. 426.2. Balance Check......................................... 426.3. Direct Debiting....................................... 436.4. Refund................................................ 446.5. Failure Procedure..................................... 447. Credit-Control Application State Machine..................... 468. Credit-Control AVPs.......................................... 558.1. CC-Correlation-Id AVP................................. 588.2. CC-Request-Number AVP................................. 588.3. CC-Request-Type AVP................................... 588.4. CC-Session-Failover AVP............................... 598.5. CC-Sub-Session-Id AVP................................. 598.6. Check-Balance-Result AVP.............................. 608.7. Cost-Information AVP.................................. 608.8. Unit-Value AVP........................................ 618.9. Exponent AVP.......................................... 618.10. Value-Digits AVP...................................... 618.11. Currency-Code AVP..................................... 628.12. Cost-Unit AVP......................................... 628.13. Credit-Control AVP.................................... 628.14. Credit-Control-Failure-Handling AVP................... 628.15. Direct-Debiting-Failure-Handling AVP.................. 638.16. Multiple-Services-Credit-Control AVP.................. 648.17. Granted-Service-Unit AVP.............................. 658.18. Requested-Service-Unit AVP............................ 668.19. Used-Service-Unit AVP................................. 668.20. Tariff-Time-Change AVP................................ 678.21. CC-Time AVP........................................... 678.22. CC-Money AVP.......................................... 678.23. CC-Total-Octets AVP................................... 688.24. CC-Input-Octets AVP................................... 688.25. CC-Output-Octets AVP.................................. 688.26. CC-Service-Specific-Units AVP......................... 688.27. Tariff-Change-Usage AVP............................... 688.28. Service-Identifier AVP................................ 698.29. Rating-Group AVP...................................... 698.30. G-S-U-Pool-Reference AVP.............................. 698.31. G-S-U-Pool-Identifier AVP............................. 708.32. CC-Unit-Type AVP...................................... 708.33. Validity-Time AVP..................................... 708.34. Final-Unit-Indication AVP............................. 718.35. Final-Unit-Action AVP................................. 728.36. Restriction-Filter-Rule AVP........................... 728.37. Redirect-Server AVP................................... 73Hakala, et al. Standards Track [Page 2]
RFC 4006 Diameter Credit-Control Application August 20058.38. Redirect-Address-Type AVP............................. 738.39. Redirect-Server-Address AVP........................... 748.40. Multiple-Services-Indicator AVP....................... 748.41. Requested-Action AVP.................................. 748.42. Service-Context-Id AVP................................ 758.43. Service-Parameter-Info AVP............................ 768.44. Service-Parameter-Type AVP............................ 768.45. Service-Parameter-Value AVP........................... 778.46. Subscription-Id AVP................................... 778.47. Subscription-Id-Type AVP.............................. 778.48. Subscription-Id-Data AVP.............................. 788.49. User-Equipment-Info AVP............................... 788.50. User-Equipment-Info-Type AVP.......................... 788.50. User-Equipment-Info-Value AVP......................... 799. Result Code AVP Values....................................... 799.1. Transient Failures.................................... 799.2. Permanent Failures.................................... 8010. AVP Occurrence Table......................................... 8010.1. Credit-Control AVP Table.............................. 8110.2. Re-Auth-Request/Answer AVP Table...................... 8211. RADIUS/Diameter Credit-Control Interworking Model............ 8212. IANA Considerations.......................................... 8512.1. Application Identifier................................ 8612.2. Command Codes......................................... 8612.3. AVP Codes............................................. 8612.4. Result-Code AVP Values................................ 8612.5. CC-Request-Type AVP................................... 8612.6. CC-Session-Failover AVP............................... 8612.7. CC-Unit-Type AVP...................................... 8712.8. Check-Balance-Result AVP.............................. 8712.9. Credit-Control AVP.................................... 8712.10. Credit-Control-Failure-Handling AVP................... 8712.11. Direct-Debiting-Failure-Handling AVP.................. 8712.12. Final-Unit-Action AVP................................. 8712.13. Multiple-Services-Indicator AVP....................... 8712.14. Redirect-Address-Type AVP............................. 8812.15. Requested-Action AVP.................................. 8812.16. Subscription-Id-Type AVP.............................. 8812.17. Tariff-Change-Usage AVP............................... 8812.18. User-Equipment-Info-Type AVP.......................... 8813. Credit-Control Application Related Parameters................ 8814. Security Considerations...................................... 8914.1. Direct Connection with Redirects...................... 9015. References................................................... 9115.1. Normative References.................................. 9115.2. Informative References................................ 9216. Acknowledgements............................................. 93Appendix A Credit-Control Sequences.............................. 94Hakala, et al. Standards Track [Page 3]
RFC 4006 Diameter Credit-Control Application August 2005A.1. Flow I................................................ 94A.2. Flow II............................................... 96A.3. Flow III.............................................. 98A.4. Flow IV............................................... 99A.5. Flow V................................................ 100A.6. Flow VI............................................... 102A.7. Flow VII.............................................. 103A.8. Flow VIII............................................. 105A.9. Flow IX............................................... 107Authors' Addresses............................................... 112Full Copyright Statement......................................... 1141. IntroductionThis document specifies a Diameter application that can be used toimplement real-time credit-control for a variety of end user servicessuch as network access, Session Initiation Protocol (SIP) services,messaging services, and download services. It provides a generalsolution to real-time cost and credit-control.The prepaid model has been shown to be very successful, for instance,in GSM networks, where network operators offering prepaid serviceshave experienced a substantial growth of their customer base andrevenues. Prepaid services are now cropping up in many otherwireless and wire line based networks.In next generation wireless networks, additional functionality isrequired beyond that specified in the Diameter base protocol. Forexample, the 3GPP Charging and Billing requirements [3GPPCHARG] statethat an application must be able to rate service information inreal-time. In addition, it is necessary to check that the end user'saccount provides coverage for the requested service prior toinitiation of that service. When an account is exhausted or expired,the user must be denied the ability to compile additional chargeableevents.A mechanism has to be provided to allow the user to be informed ofthe charges to be levied for a requested service. In addition, thereare services such as gaming and advertising that may credit as wellas debit a user account.The other Diameter applications provide service specificauthorization, and they do not provide credit authorization forprepaid users. The credit authorization shall be generic andapplicable to all the service environments required to supportprepaid services.Hakala, et al. Standards Track [Page 4]
RFC 4006 Diameter Credit-Control Application August 2005To fulfill these requirements, it is necessary to facilitate credit-control communication between the network element providing theservice (e.g., Network Access Server, SIP Proxy, and ApplicationServer) and a credit-control server.The scope of this specification is the credit authorization. Servicespecific authorization and authentication is out of the scope.1.1. Requirements LanguageIn this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL","RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted asdescribed in [KEYWORDS].1.2. TerminologyAAAAuthentication, Authorization, and AccountingAA answerAA answer generically refers to a service specific authorization andauthentication answer. AA answer commands are defined in servicespecific authorization applications, e.g., [NASREQ] and [DIAMMIP].AA requestAA request generically refers to a service specific authorization andauthentication request. AA request commands are defined in servicespecific authorization applications e.g., [NASREQ] and [DIAMMIP].Credit-controlCredit-control is a mechanism that directly interacts in real-timewith an account and controls or monitors the charges related to theservice usage. Credit-control is a process of checking whethercredit is available, credit-reservation, deduction of credit from theend user account when service is completed and refunding of reservedcredit that is not used.Diameter Credit-control ServerA Diameter credit-control server acts as a prepaid server, performingreal-time rating and credit-control. It is located in the homedomain and is accessed by service elements or Diameter AAA servers inHakala, et al. Standards Track [Page 5]
RFC 4006 Diameter Credit-Control Application August 2005real-time for purpose of price determination and credit-controlbefore the service event is delivered to the end-user. It may alsointeract with business support systems.Diameter Credit-control ClientA Diameter credit-control client is an entity that interacts with acredit-control server. It monitors the usage of the granted quotaaccording to instructions returned by credit-control server.InterrogationThe Diameter credit-control client uses interrogation to initiate asession based credit-control process. During the credit-controlprocess, it is used to report the used quota and request a new one.An interrogation maps to a request/answer transaction.One-time eventBasically, a request/answer transaction of type event.RatingThe act of determining the cost of the service event.ServiceA type of task performed by a service element for an end user.Service ElementA network element that provides a service to the end users. TheService Element may include the Diameter credit-control client, oranother entity (e.g., RADIUS AAA server) that can act as a Credit-control client on behalf of the Service Element. In the latter case,the interface between the Service Element and the Diameter credit-control client is outside the scope of this specification. Examplesof the Service Elements include Network Access Server (NAS), SIPProxy, and Application Servers such as messaging server, contentserver, and gaming server.Service EventAn event relating to a service provided to the end user.Hakala, et al. Standards Track [Page 6]
RFC 4006 Diameter Credit-Control Application August 2005Session based credit-controlA credit-control process that makes use of several interrogations:the first, a possible intermediate, and the final. The firstinterrogation is used to reserve money from the user's account and toinitiate the process. The intermediate interrogations may be neededto request new quota while the service is being rendered. The finalinterrogation is used to exit the process. The credit-control serveris required to maintain session state for session-based credit-control.1.3. Advertising Application SupportDiameter nodes conforming to this specification MUST advertisesupport by including the value of 4 in the Auth-Application-Id of theCapabilities-Exchange-Request and Capabilities-Exchange-Answercommand [DIAMBASE].2. Architecture ModelsThe current accounting models specified in the Radius Accounting[RFC2866] and Diameter base [DIAMBASE] are not sufficient for real-time credit-control, where credit-worthiness is to be determinedprior to service initiation. Also, the existing Diameterauthorization applications, [NASREQ] and [DIAMMIP], only provideservice authorization, but do not provide credit authorization forprepaid users. In order to support real-time credit-control, a newtype of server is needed in the AAA infrastructure: Diameter credit-control server. The Diameter credit-control server is the entityresponsible for credit authorization for prepaid subscribers.A service element may authenticate and authorize the end user withthe AAA server by using AAA protocols; e.g., RADIUS or a Diameterbase protocol with a possible Diameter application.Accounting protocols such as RADIUS accounting and the Diameter baseaccounting protocol can be used to provide accounting data to theaccounting server after service is initiated, and to provide possibleinterim reports until service completion. However, for real-timecredit-control, these authorization and accounting models are notsufficient.When real-time credit-control is required, the credit-control clientcontacts the credit-control server with information about a possibleservice event. The credit-control process is performed to determinepotential charges and to verify whether the end user's accountbalance is sufficient to cover the cost of the service beingrendered.Hakala, et al. Standards Track [Page 7]
RFC 4006 Diameter Credit-Control Application August 2005Figure 1 illustrates the typical credit-control architecture, whichconsists of a Service Element with an embedded Diameter credit-control client, a Diameter credit-control server, and an AAA server.A Business Support System is usually deployed; it includes at leastthe billing functionality. The credit-control server and AAA serverin this architecture model are logical entities. The realconfiguration can combine them into a single host. The credit-control protocol is the Diameter base protocol with the Diametercredit-control application.When an end user requests services such as SIP or messaging, therequest is typically forwarded to a service element (e.g., SIP Proxy)in the user's home domain. In some cases it might be possible thatthe service element in the visited domain can offer services to theend user; however, a commercial agreement must exist between thevisited domain and the home domain. Network access is an example ofa service offered in the visited domain where the NAS, through an AAAinfrastructure, authenticates and authorizes the user with the user'shome network.Service Element AAA and CC+----------+ +---------+ Protocols+-----------+ +--------+| End |<---->|+-------+|<------------>| AAA | |Business|| User | +->|| CC || | Server |->|Support || | | || Client||<-----+ | | |System |+----------+ | |+-------+| | +-----------+ | || +---------+ | ^ +--------++----------+ | | CC Protocol | ^| End |<--+ | +-----v----+ || User | +------>|Credit- | |+----------+ Credit-Control |Control |--------+Protocol |Server |+----------+Figure 1: Typical credit-control architectureThere can be multiple credit-control servers in the system forredundancy and load balancing. The system can also contain separaterating server(s), and accounts can be located in a centralizeddatabase. To ensure that the end user's account is not debited orcredited multiple times for the same service event, only one place inthe credit-control system should perform duplicate detection. Systeminternal interfaces can exist to relay messages between servers andan account manager. However, the detailed architecture of thecredit-control system and its interfaces are implementation specificand are out of scope of this specification.Hakala, et al. Standards Track [Page 8]
RFC 4006 Diameter Credit-Control Application August 2005Protocol transparent Diameter relays can exist between the credit-control client and credit-control server. Also, Diameter Redirectagents that refer credit-control clients to credit-control serversand allow them to communicate directly can exist. These agentstransparently support the Diameter credit-control application. Thedifferent roles of Diameter Agents are defined in Diameter base[DIAMBASE], section 2.8.If Diameter credit-control proxies exist between the credit-controlclient and the credit-control server, they MUST advertise theDiameter credit-control application support.3. Credit-Control MessagesThis section defines new Diameter message Command-Code values thatMUST be supported by all Diameter implementations that conform tothis specification. The Command Codes are as follows:Command-Name Abbrev. Code Reference-----------------------------------------------------------Credit-Control-Request CCR 272 3.1Credit-Control-Answer CCA 272 3.2Diameter Base [DIAMBASE] defines in the section 3.2 the Command CodeABNF specification. These formats are observed in Credit-Controlmessages.3.1. Credit-Control-Request (CCR) CommandThe Credit-Control-Request message (CCR) is indicated by thecommand-code field being set to 272 and the 'R' bit being set in theCommand Flags field. It is used between the Diameter credit-controlclient and the credit-control server to request credit authorizationfor a given service.The Auth-Application-Id MUST be set to the value 4, indicating theDiameter credit-control application.Hakala, et al. Standards Track [Page 9]
RFC 4006 Diameter Credit-Control Application August 2005Message Format::= < Diameter Header: 272, REQ, PXY >< Session-Id >{ Origin-Host }{ Origin-Realm }{ Destination-Realm }{ Auth-Application-Id }{ Service-Context-Id }{ CC-Request-Type }{ CC-Request-Number }[ Destination-Host ][ User-Name ][ CC-Sub-Session-Id ][ Acct-Multi-Session-Id ][ Origin-State-Id ][ Event-Timestamp ]*[ Subscription-Id ][ Service-Identifier ][ Termination-Cause ][ Requested-Service-Unit ][ Requested-Action ]*[ Used-Service-Unit ][ Multiple-Services-Indicator ]*[ Multiple-Services-Credit-Control ]*[ Service-Parameter-Info ][ CC-Correlation-Id ][ User-Equipment-Info ]*[ Proxy-Info ]*[ Route-Record ]*[ AVP ]Hakala, et al. Standards Track [Page 10]
RFC 4006 Diameter Credit-Control Application August 20053.2. Credit-Control-Answer (CCA) CommandThe Credit-Control-Answer message (CCA) is indicated by the command-code field being set to 272 and the 'R' bit being cleared in theCommand Flags field. It is used between the credit-control serverand the Diameter credit-control client to acknowledge a Credit-Control-Request command.Message Format::= < Diameter Header: 272, PXY >< Session-Id >{ Result-Code }{ Origin-Host }{ Origin-Realm }{ Auth-Application-Id }{ CC-Request-Type }{ CC-Request-Number }[ User-Name ][ CC-Session-Failover ][ CC-Sub-Session-Id ][ Acct-Multi-Session-Id ][ Origin-State-Id ][ Event-Timestamp ][ Granted-Service-Unit ]*[ Multiple-Services-Credit-Control ][ Cost-Information][ Final-Unit-Indication ][ Check-Balance-Result ][ Credit-Control-Failure-Handling ][ Direct-Debiting-Failure-Handling ][ Validity-Time]*[ Redirect-Host][ Redirect-Host-Usage ][ Redirect-Max-Cache-Time ]*[ Proxy-Info ]*[ Route-Record ]*[ Failed-AVP ]*[ AVP ]4. Credit-Control Application OverviewThe credit authorization process takes place before and duringservice delivery to the end user and generally requires the user'sauthentication and authorization before any request is sent to thecredit-control server. The credit-control application defined inthis specification supports two different credit authorizationmodels: credit authorization with money reservation and creditHakala, et al. Standards Track [Page 11]
RFC 4006 Diameter Credit-Control Application August 2005authorization with direct debiting. In both models, the credit-control client requests credit authorization from the credit-controlserver prior to allowing any service to be delivered to the end user.In the first model, the credit-control server rates the request,reserves a suitable amount of money from the user's account, andreturns the corresponding amount of credit resources. Note thatcredit resources may not imply actual monetary credit; creditresources may be granted to the credit control client in the form ofunits (e.g., data volume or time) to be metered.Upon receipt of a successful credit authorization answer with acertain amount of credit resources, the credit-control client allowsservice delivery to the end user and starts monitoring the usage ofthe granted resources. When the credit resources granted to the userhave been consumed or the service has been successfully delivered orterminated, the credit-control client reports back to the server theused amount. The credit-control server deducts the used amount fromthe end user's account; it may perform rating and make a new creditreservation if the service delivery is continuing. This process isaccomplished with session based credit-control that includes thefirst interrogation, possible intermediate interrogations, and thefinal interrogation. For session based credit-control, both thecredit control client and the credit-control server are required tomaintain credit-control session state. Session based credit-controlis described in more detail, with more variations, in section 5.In contrast, credit authorization with direct debiting is a singletransaction process wherein the credit-control server directlydeducts a suitable amount of money from the user's account as soon asthe credit authorization request is received. Upon receipt of asuccessful credit authorization answer, the credit-control clientallows service delivery to the end user. This process isaccomplished with the one-time event. Session state is notmaintained.In a multi-service environment, an end user can issue an additionalservice request (e.g., data service) during an ongoing service (e.g.,voice call) toward the same account. Alternatively, during an activemultimedia session, an additional media type is added to the session,causing a new simultaneous request toward same account.Consequently, this needs to be considered when credit resources aregranted to the services.The credit-control application also supports operations such asservice price enquiry, user's balance check, and refund of credit onthe user's account. These operations are accomplished with the one-time event. Session state is not maintained.Hakala, et al. Standards Track [Page 12]
RFC 4006 Diameter Credit-Control Application August 2005A flexible credit-control application specific failure handling isdefined in which the home service provider can model the credit-control client behavior according to its own credit risk managementpolicy.The Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP are defined to determine what is done if thesending of credit-control messages to the credit-control server hasbeen temporarily prevented. The usage of the Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVPallows flexibility, as failure handling for the credit-controlsession and one time event direct debiting may be different.4.1. Service-Specific Rating Input and InteroperabilityThe Diameter credit-control application defines the framework forcredit-control; it provides generic credit-control mechanismssupporting multiple service applications. The credit-controlapplication, therefore, does not define AVPs that could be used asinput in the rating process. Listing the possible services thatcould use this Diameter application is out of scope for this genericmechanism.It is reasonable to expect that a service level agreement will existbetween providers of the credit-control client and the credit-controlserver covering the charging, services offered, roaming agreements,agreed rating input (i.e., AVPs), and so on.Therefore, it is assumed that a Diameter credit-control server willprovide service only for Diameter credit-control clients that haveagreed beforehand as to the content of credit-control messages.Naturally, it is possible that any arbitrary Diameter credit-controlclient can interchange credit-control messages with any Diametercredit-control server, but with a higher likelihood that unsupportedservices/AVPs could be present in the credit-control message, causingthe server to reject the request with an appropriate result-code.4.1.1. Specifying Rating Input AVPsThere are two ways to provide rating input to the credit-controlserver: either by using AVPs or by including them in the Service-Parameter-Info AVP. The general principles for sending ratingparameters are as follows:1a. The service SHOULD re-use existing AVPs if it can use AVPsdefined in existing Diameter applications (e.g., NASREQ for networkaccess services). Re-use of existing AVPs is strongly recommended in[DIAMBASE].Hakala, et al. Standards Track [Page 13]
RFC 4006 Diameter Credit-Control Application August 2005For AVPs of type Enumerated, the service may require a new value tobe defined. Allocation of new AVP values is done as specified in[DIAMBASE], section 1.2.1b. New AVPs can be defined if the existing AVPs do not providesufficient rating information. In this case, the procedures definedin [DIAMBASE] for creating new AVPs MUST be followed.1c. For services specific only to one vendor's implementation, aVendor-Specific AVP code for Private use can be used. Where aVendor-Specific AVP is implemented by more than one vendor,allocation of global AVPs is encouraged instead; refer to [DIAMBASE].2. The Service-Parameter-Info AVP MAY be used as a container to passlegacy rating information in its original encoded form (e.g., ASN.1BER). This method can be used to avoid unnecessary conversions froman existing data format to an AVP format. In this case, the ratinginput is embedded in the Service-Parameter-Info AVP as defined insection 8.43.New service applications SHOULD favor the use of explicitly definedAVPs as described in items 1a and 1b, to simplify interoperability.4.1.2. Service-Specific DocumentationThe service specific rating input AVPs, the contents of the Service-Parameter-Info AVP or Service-Context-Id AVP (defined in section8.42) are not within the scope of this document. To facilitateinteroperability, it is RECOMMENDED that the rating input and thevalues of the Service-Context-Id be coordinated via an informationalRFC or other permanent and readily available reference. Thespecification of another cooperative standardization body (e.g.,3GPP, OMA, and 3GPP2) SHOULD be used. However, private services maybe deployed that are subject to agreements between providers of thecredit-control server and client. In this case, vendor specific AVPscan be used.This specification, together with the above service specificdocuments, governs the credit-control message. Service specificdocuments define which existing AVPs or new AVPs are used as input tothe rating process (i.e., those that do not define new credit-controlapplications), and thus have to be included in the Credit-Control-Request command by a Diameter credit-control client supporting agiven service as *[AVP]. Should Service-Parameter-Info be used, thenthe service specific document MUST specify the exact content of thisgrouped AVP.Hakala, et al. Standards Track [Page 14]
RFC 4006 Diameter Credit-Control Application August 2005The Service-Context-Id AVP MUST be included at the command level of aCredit-Control Request to identify the service specific document thatapplies to the request. The specific service or rating group therequest relates to is uniquely identified by the combination ofService-Context-Id and Service-Identifier or Rating-Group.4.1.3. Handling of Unsupported/Incorrect Rating InputDiameter credit-control implementations are required to support theMandatory rating AVPs defined in service specific documentation ofthe services they support, according to the 'M' bit rules in[DIAMBASE].If a rating input required for the rating process is incorrect in theCredit-control request, or if the credit-control server does notsupport the requested service context (identified by the Service-Context-Id AVP at command level), the Credit-control answer MUSTcontain the error code DIAMETER_RATING_FAILED. A CCA message withthis error MUST contain one or more Failed-AVP AVPs containing themissing and/or unsupported AVPs that caused the failure. A Diametercredit-control client that receives the error codeDIAMETER_RATING_FAILED in response to a request MUST NOT send similarrequests in the future.4.1.4. RADIUS Vendor-Specific Rating AttributesWhen service specific documents include RADIUS vendor specificattributes that could be used as input in the rating process, therules described in [NASREQ] for formatting the Diameter AVP MUST befollowed.For example, if the AVP code used is the vendor attribute type code,the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST beset to the IANA Vendor identification value. The Diameter AVP datafield contains only the attribute value of the RADIUS attribute.5. Session Based Credit-Control5.1. General PrinciplesFor a session-based credit-control, several interrogations areneeded: the first, intermediate (optional) and the finalinterrogations. This is illustrated in Figures 2 and 3.If the credit-control client performs credit-reservation beforegranting service to the end user, it MUST use several interrogationstoward the credit-control server (i.e., session based credit-Hakala, et al. Standards Track [Page 15]
RFC 4006 Diameter Credit-Control Application August 2005control). In this case, the credit-control server MUST maintain thecredit-control session state.Each credit-control session MUST have a globally unique Session-Id asdefined in [DIAMBASE], which MUST NOT be changed during the lifetimeof a credit-control session.Certain applications require multiple credit-control sub-sessions.These applications would send messages with a constant Session-IdAVP, but with a different CC-Sub-Session-Id AVP. If several creditsub-sessions will be used, all sub-sessions MUST be closed separatelybefore the main session is closed so that units per sub-session maybe reported. The absence of this AVP implies that no sub-sessionsare in use.Note that the service element might send a service specific re-authorization message to the AAA server due to expiration of theauthorization-lifetime during an ongoing credit-control session.However, the service specific re-authorization does not influence thecredit authorization that is ongoing between the credit-controlclient and credit-control server, as credit authorization iscontrolled by the burning rate of the granted quota.If service specific re-authorization fails, the user will bedisconnected, and the credit-control client MUST send a finalinterrogation to the credit-control server.The Diameter credit-control server may seek to control the validitytime of the granted quota and/or the production of intermediateinterrogations. Thus, it MAY include the Validity-Time AVP in theanswer message to the credit-control client. Upon expiration of theValidity-Time, the credit-control client MUST generate a credit-control update request and report the used quota to the credit-control server. It is up to the credit-control server to determinethe value of the Validity-Time to be used for consumption of thegranted service units. If the Validity-Time is used, its valueSHOULD be given as input to set the session supervision timer Tcc(the session supervision timer MAY be set to two times the value ofthe Validity-Time, as defined in section 13). Since credit-controlupdate requests are also produced at the expiry of granted serviceunits and/or for mid-session service events, the omission ofValidity-Time does not mean that intermediate interrogation for thepurpose of credit-control is not performed.Hakala, et al. Standards Track [Page 16]
RFC 4006 Diameter Credit-Control Application August 20055.1.1. Basic Tariff-Time Change SupportThe Diameter credit-control server and client MAY optionally supporta tariff change mechanism. The Diameter credit-control server mayinclude a Tariff-Time-Change AVP in the answer message. Note thatthe granted units should be allocated based on the worst-casescenario in case of forthcoming tariff change, so that the overallreported used units would never exceed the credit reservation.When the Diameter credit-control client reports the used units and atariff change has occurred during the reporting period, the Diametercredit-control client MUST separately itemize the units used beforeand after the tariff change. If the client is unable to distinguishwhether units straddling the tariff change were used before or afterthe tariff change, the credit-control client MUST itemize those unitsin a third category.If a client does not support the tariff change mechanism and itreceives a CCA message carrying the Tariff-Time-Change AVP, it MUSTterminate the credit-control session, giving a reason ofDIAMETER_BAD_ANSWER in the Termination-Cause AVP.For time based services, the quota is continuously consumed at theregular rate of 60 seconds per minute. At the time when creditresources are allocated, the server already knows how many units willbe consumed before the tariff time change and how many units will beconsumed afterward. Similarly, the server can determine the unitsconsumed at the before rate and the units consumed at the rateafterward in the event that the end-user closes the session beforethe consumption of the allotted quota. There is no need foradditional traffic between client and server in the case of tarifftime changes for continuous time based service. Therefore, thetariff change mechanism is not used for such services. For time-based services in which the quota is NOT continuously consumed at aregular rate, the tariff change mechanism described for volume andevent units MAY be used.5.1.2. Credit-Control for Multiple Services within a (sub-)SessionWhen multiple services are used within the same user session and eachservice or group of services is subject to different cost, it isnecessary to perform credit-control for each service independently.Making use of credit-control sub-sessions to achieve independentcredit-control will result in increased signaling load and usage ofresources in both the credit-control client and the credit-controlserver. For instance, during one network access session the end usermay use several http-services subject to different access cost. Thenetwork access specific attributes such as the quality of serviceHakala, et al. Standards Track [Page 17]
RFC 4006 Diameter Credit-Control Application August 2005(QoS) are common to all the services carried within the accessbearer, but the cost of the bearer may vary depending on its content.To support these scenarios optimally, the credit-control applicationenables independent credit-control of multiple services in a singlecredit-control (sub-)session. This is achieved by including theoptional Multiple-Services-Credit-Control AVP in Credit-Control-Request/Answer messages. It is possible to request and allocateresources as a credit pool shared between multiple services. Theservices can be grouped into rating groups in order to achieve evenfurther aggregation of credit allocation. It is also possible torequest and allocate quotas on a per service basis. Where quotas areallocated to a pool by means of the Multiple-Services-Credit-ControlAVP, the quotas remain independent objects that can be re-authorizedindependently at any time. Quotas can also be given independentresult codes, validity times, and Final-Unit-Indications.A Rating-Group gathers a set of services, identified by a Service-Identifier, and subject to the same cost and rating type (e.g.,$0.1/minute). It is assumed that the service element is providedwith Rating-Groups, Service-Identifiers, and their associatedparameters that define what has to be metered by means outside thescope of this specification. (Examples of parameters associated toService-Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiersenable authorization on a per-service based credit as well asitemized reporting of service usage. It is up to the credit-controlserver whether to authorize credit for one or more services or forthe whole rating-group. However, the client SHOULD always reportused units at the finest supported level of granularity. Where quotais allocated to a rating-group, all the services belonging to thatgroup draw from the allotted quota. The following is a graphicalrepresentation of the relationship between service-identifiers,rating-groups, credit pools, and credit-control (sub-)session.DCC (Sub-)Session|+------------+-----------+-------------+--------------- +| | | | |Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z\ / \ / /\ / \ / /\ / Rating-Group 1.......Rating-Group n\ / | |Quota ---------------Quota Quota| / || / |Credit-Pool Credit-PoolHakala, et al. Standards Track [Page 18]
RFC 4006 Diameter Credit-Control Application August 2005If independent credit-control of multiple services is used, thevalidity-time and final-unit-indication SHOULD be present either inthe Multiple-Services-Credit-Control AVP(s) or at command level assingle AVPs. However, the Result-Code AVP MAY be present both on thecommand level and within the Multiple-Services-Credit-Control AVP.If the Result-Code on the command level indicates a value other thanSUCCESS, then the Result-Code on command level takes precedence overany included in the Multiple-Services-Credit-Control AVP.The credit-control client MUST indicate support for independentcredit-control of multiple services within a (sub-)session byincluding the Multiple-Services-Indicator AVP in the firstinterrogation. A credit-control server not supporting this featureMUST treat the Multiple-Services-Indicator AVP and any receivedMultiple-Services-Credit-Control AVPs as invalid AVPs.If the client indicated support for independent credit-control ofmultiple services, a credit-control server that wishes to use thefeature MUST return the granted units within the Multiple-Services-Credit-Control AVP associated to the corresponding service-identifierand/or rating-group.To avoid a situation where several parallel (and typically alsosmall) credit reservations must be made on the same account (i.e.,credit fragmentation), and also to avoid unnecessary load on thecredit-control server, it is possible to provide service units as apool that applies to multiple services or rating groups. This isachieved by providing the service units in the form of a quota for aparticular service or rating group in the Multiple-Services-Credit-Control AVP, and also by including a reference to a credit pool forthat unit type.The reference includes a multiplier derived from the ratingparameter, which translates from service units of a specific type tothe abstract service units in the pool. For instance, if the ratingparameter for service 1 is $1/MB and the rating parameter for service2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2,respectively.If S is the total service units within the pool, M1, M2, ..., Mn arethe multipliers provided for services 1, 2, ..., n, and C1, C2, ...,Cn are the used resources within the session, then the pool credit isexhausted and re-authorization MUST be sought when:C1*M1 + C2*M2 + ... + Cn*Mn >= SHakala, et al. Standards Track [Page 19]
RFC 4006 Diameter Credit-Control Application August 2005The total credit in the pool, S, is calculated from the quotas, whichare currently allocated to the pool as follows:S = Q1*M1 + Q2*M2 + ... + Qn*MnIf services or rating groups are added to or removed from the pool,then the total credit is adjusted appropriately. Note that when thetotal credit is adjusted because services or rating groups areremoved from the pool, the value that need to be removed is theconsumed one (i.e., Cx*Mx).Re-authorizations for an individual service or rating group may besought at any time; for example, if a 'non-pooled' quota is used upor the Validity-Time expires.Where multiple G-S-U-Pool-Reference AVPs (section 8.30) with the sameG-S-U-Pool-Identifier are provided within a Multiple-Services-Credit-Control AVP (section 8.16) along with the Granted-Service-UnitAVP, then these MUST have different CC-Unit-Type values, and they alldraw from the credit pool separately. For instance, if onemultiplier for time (M1t) and one multiplier for volume (M1v) aregiven, then the used resources from the pool is the sum C1t*M1t +C1v*M1v, where C1t is the time unit and C1v is the volume unit.Where service units are provided within a Multiple-Services-Credit-Control AVP without a corresponding G-S-U-Pool-Reference AVP, thenthese are handled independently from any credit pool and from anyother services or rating groups within the session.The credit pool concept is an optimal tool to avoid the over-reservation effect of the basic single quota tariff time changemechanism (the mechanism described in section 5.1.1). Therefore,Diameter credit-control clients and servers implementing theindependent credit-control of multiple services SHOULD leverage thecredit pool concept when supporting the tariff time change. TheDiameter credit-control server SHOULD include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in theanswer message (i.e., two instances of the Multiple-Services-Credit-Control AVP). One of the granted units is allocated to be usedbefore the potential tariff change, while the second granted unitsare for use after a tariff change. Both granted unit quotas MUSTcontain the same Service-Identifier and/or Rating-Group. This dualquota mechanism ensures that the overall reported used units wouldnever exceed the credit reservation. The Diameter credit-controlclient reports both the used units before and after the tariff changein a single instance of the Multiple-Services-Credit-Control AVP.Hakala, et al. Standards Track [Page 20]
RFC 4006 Diameter Credit-Control Application August 2005The failure handling for credit-control sessions is defined insection 5.7 and reflected in the basic credit-control state machinein section 7. Credit-control clients and servers implementing theindependent credit-control of multiple services in a (sub-)sessionfunctionality MUST ensure failure handling and general behavior fullyconsistent with the above mentioned sections, while maintaining theability to handle parallel ongoing credit re-authorization within a(sub-)session. Therefore, it is RECOMMENDED that Diameter credit-control clients maintain a PendingU message queue and restart the Txtimer (section 13) every time a CCR message with the valueUPDATE_REQUEST is sent while they are in PendingU state. Whenanswers to all pending messages are received, the state machine movesto OPEN state, and Tx is stopped. Naturally, the action performedwhen a problem for the session is detected according to section 5.7affects all the ongoing services (e.g., failover to a backup serverif possible affect all the CCR messages with the value UPDATE_REQUESTin the PendingU queue).Since the client may send CCR messages with the value UPDATE_REQUESTwhile in PendingU (i.e., without waiting for an answer to ongoingcredit re-authorization), the time space between these requests maybe very short, and the server may not have received the previousrequest(s) yet. Therefore, in this situation the server may receiveout of sequence requests and SHOULD NOT consider this an errorcondition. A proper answer is to be returned to each of thoserequests.5.2. First InterrogationWhen session based credit-control is required (e.g., theauthentication server indicated a prepaid user), the firstinterrogation MUST be sent before the Diameter credit-control clientallows any service event to the end user. The CC-Request-Type is setto the value INITIAL_REQUEST in the request message.If the Diameter credit-control client knows the cost of the serviceevent (e.g., a content server delivering ringing tones may know theircost) the monetary amount to be charged is included in theRequested-Service-Unit AVP. If the Diameter credit-control clientdoes not know the cost of the service event, the Requested-Service-Unit AVP MAY contain the number of requested service events. Wherethe Multiple-Services-Credit-Control AVP is used, it MUST contain theRequested-Service-Unit AVP to indicate that the quota for theassociated service/rating-group is requested. In the case ofmultiple services, the Service-Identifier AVP or the Rating-Group AVPwithin the Multiple-Services-Credit-Control AVP always indicates theservice concerned. Additional service event information to be ratedHakala, et al. Standards Track [Page 21]
RFC 4006 Diameter Credit-Control Application August 2005MAY be sent as service specific AVPs or MAY be sent within theService-Parameter-Info AVP at command level. The Service-Context-IdAVP indicates the service specific document applicable to therequest.The Event-Timestamp AVP SHOULD be included in the request andcontains the time when the service event is requested in the serviceelement. The Subscription-Id AVP SHOULD be included to identify theend user in the credit-control server. The credit-control client MAYinclude the User-Equipment-Info AVP so that the credit-control serverhas some indication of the type and capabilities of the end useraccess device. How the credit-control server uses this informationis outside the scope of this document.The credit-control server SHOULD rate the service event and make acredit-reservation from the end user's account that covers the costof the service event. If the type of the Requested-Service-Unit AVPis money, no rating is needed, but the corresponding monetary amountis reserved from the end user's account.The credit-control server returns the Granted-Service-Unit AVP in theAnswer message to the Diameter credit-control client. The Granted-Service-Unit AVP contains the amount of service units that theDiameter credit-control client can provide to the end user until anew Credit-Control-Request MUST be sent to the credit-control server.If several unit types are sent in the Answer message, the credit-control client MUST handle each unit type separately. The type ofthe Granted-Service-Unit AVP can be time, volume, service specific,or money, depending on the type of service event. The unit type(s)SHOULD NOT be changed within an ongoing credit-control session.There MUST be a maximum of one instance of the same unit type in oneAnswer message. However, if multiple quotas are conveyed to thecredit-control client in the Multiple-Services-Credit-Control AVPs,it is possible to carry two instances of the same unit typeassociated to a service-identifier/rating-group. This is typicallythe case when a tariff time change is expected and the credit-controlserver wants to make a distinction between the granted quota beforeand after tariff change.If the credit-control server determines that no further control isneeded for the service, it MAY include the result code indicatingthat the credit-control is not applicable (e.g., if the service isfree of charge). This result code at command level implies that thecredit-control session is to be terminated.The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP to indicate that the answer message contains the finalHakala, et al. Standards Track [Page 22]
RFC 4006 Diameter Credit-Control Application August 2005units for the service. After the end user has consumed these units,the Diameter credit-control-client MUST behave as described insection 5.6.This document defines two different approaches to perform the firstinterrogation to be used in different network architectures. Thefirst approach uses credit-control messages after the user'sauthorization and authentication takes place. The second approachuses service specific authorization messages to perform the firstinterrogation during the user's authorization/authentication phase,and credit-control messages for the intermediate and finalinterrogations. If an implementation of the credit-control clientsupports both the methods, determining which method to use SHOULD beconfigurable.In service environments such as the Network Access Server (NAS), itis desired to perform the first interrogation as part of theauthorization/authentication process for the sake of protocolefficiency. Further credit authorizations after the firstinterrogation are performed with credit-control commands defined inthis specification. Implementations of credit-control clientsoperating in the mentioned environments SHOULD support this method.If the credit-control server and AAA server are separate physicalentities, the service element sends the request messages to the AAAserver, which then issues an appropriate request or proxies thereceived request forward to the credit-control server.In other service environments, such as the 3GPP network and some SIPscenarios, there is a substantial decoupling betweenregistration/access to the network and the actual service request(i.e., the authentication/authorization is executed once atregistration/access to the network and is not executed for everyservice event requested by the subscriber). In these environments,it is more appropriate to perform the first interrogation after theuser has been authenticated and authorized. The first, theintermediate, and the final interrogations are executed with credit-control commands defined in this specification.Other IETF standards or standards developed by other standardizationbodies may define the most suitable method in their architectures.5.2.1. First Interrogation after Authorization and AuthenticationThe Diameter credit-control client in the service element may getinformation from the authorization server as to whether credit-control is required, based on its knowledge of the end user. Ifcredit-control is required the credit-control server needs to becontacted prior to initiating service delivery to the end user. TheHakala, et al. Standards Track [Page 23]
RFC 4006 Diameter Credit-Control Application August 2005accounting protocol and the credit-control protocol can be used inparallel. The authorization server may also determine whether theparallel accounting stream is required.The following diagram illustrates the case where both protocols areused in parallel and the service element sends credit-controlmessages directly to the credit-control server. More credit-controlsequence examples are given in Annex A.DiameterEnd User Service Element AAA Server CC Server(CC Client)| Registration | AA request/answer(accounting,cc or both)||<----------------->|<------------------>| || : | | || : | | || Service Request | | ||------------------>| | || | CCR(Initial,Credit-Control AVPs) || +|---------------------------------------->|| CC stream|| | CCA(Granted-Units)|| +|<----------------------------------------|| Service Delivery | | ||<----------------->| ACR(start,Accounting AVPs) || : |------------------->|+ || : | ACA || Accounting stream || |<-------------------|+ || : | | || : | | || | CCR(Update,Used-Units) || |---------------------------------------->|| | | CCA(Granted-Units)|| |<----------------------------------------|| : | | || : | | || End of Service | | ||------------------>| CCR(Termination, Used-Units) || |---------------------------------------->|| | | CCA || |<----------------------------------------|| | ACR(stop) | || |------------------->| || | ACA | || |<-------------------| |Figure 2: Protocol example with first interrogation after user'sauthorization/authenticationHakala, et al. Standards Track [Page 24]
RFC 4006 Diameter Credit-Control Application August 20055.2.2. Authorization Messages for First InterrogationThe Diameter credit-control client in the service element MUSTactively co-operate with the authorization/authentication client inthe construction of the AA request by adding appropriate credit-control AVPs. The credit-control client MUST add the Credit-ControlAVP to indicate credit-control capabilities and MAY add otherrelevant credit-control specific AVPs to the properauthorization/authentication command to perform the firstinterrogation toward the home Diameter AAA server. The Auth-Application-Id is set to the appropriate value, as defined in therelevant service specific authorization/authentication applicationdocument (e.g., [NASREQ], [DIAMMIP]). The home Diameter AAA serverauthenticates/authorizes the subscriber and determines whethercredit-control is required.If credit-control is not required for the subscriber, the homeDiameter AAA server will respond as usual, with an appropriate AAanswer message. If credit-control is required for the subscriber andthe Credit-Control AVP with the value set to CREDIT_AUTHORIZATION waspresent in the authorization request, the home AAA server MUSTcontact the credit-control server to perform the first interrogation.If credit-control is required for the subscriber and the Credit-Control AVP was not present in the authorization request, the homeAAA server MUST send an authorization reject answer message.The Diameter AAA server supporting credit-control is required to sendthe Credit-Control-Request command (CCR) defined in this document tothe credit-control server. The Diameter AAA server populates the CCRbased on service specific AVPs used for input to the rating process,and possibly on credit-control AVPs received in the AA request. Thecredit-control server will reserve money from the user's account,will rate the request and will send a Credit-Control-Answer messageto the home Diameter AAA server. The answer message includes theGranted-Service-Unit AVP(s) and MAY include other credit-controlspecific AVPs, as appropriate. Additionally, the credit-controlserver MAY set the Validity-Time and MAY include the Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP todetermine what to do if the sending of credit-control messages to thecredit-control server has been temporarily prevented.Upon receiving the Credit-Control-Answer message from the credit-control server, the home Diameter AAA server will populate the AAanswer with the received credit-control AVPs and with the appropriateservice attributes according to the authorization/authenticationspecific application (e.g., [NASREQ], [DIAMMIP]). It will thenforward the packet to the credit-control client. If the homeDiameter AAA server receives a credit-control reject message, it willHakala, et al. Standards Track [Page 25]
RFC 4006 Diameter Credit-Control Application August 2005simply generate an appropriate authorization reject message to thecredit-control client, including the credit-control specific errorcode.In this model, the credit-control client sends further credit-controlmessages to the credit-control server via the home Diameter AAAserver. Upon receiving a successful authorization answer messagewith the Granted-Service-Unit AVP(s), the credit-control client willgrant the service to the end user and will generate an intermediatecredit-control request, as required by using credit-control commands.The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1(for how to produce unique value for the CC-Request-Number AVP, seesection 8.2).If service specific re-authorization is performed (i.e.,authorization-lifetime expires), the credit-control client MUST addto the service specific re-authorization request the Credit-ControlAVP with a value set to RE_AUTHORIZATION to indicate that thecredit-control server MUST NOT be contacted. When session basedcredit-control is used for the subscriber, a constant credit-controlmessage stream flows through the home Diameter AAA server. The homeDiameter AAA server can make use of this credit-control message flowto deduce that the user's activity is ongoing; therefore, it isrecommended to set the authorization-lifetime to a reasonably highvalue when credit-control is used for the subscriber.In this scenario, the home Diameter AAA server MUST advertise supportfor the credit-control application to its peers during the capabilityexchange process.Hakala, et al. Standards Track [Page 26]
RFC 4006 Diameter Credit-Control Application August 2005The following diagram illustrates the use ofauthorization/authentication messages to perform the firstinterrogation. The parallel accounting stream is not shown in thefigure.Service Element DiameterEnd User (CC Client) AAA Server CC Server| Service Request | AA Request (CC AVPs) ||------------------>|------------------->| || | | CCR(Initial, CC AVPs)| | |------------------->|| | | CCA(Granted-Units)| | |<-------------------|| | AA Answer(Granted-Units) || Service Delivery |<-------------------| ||<----------------->| | || : | | || : | | || : | | || | | || | CCR(Update,Used-Units) || |------------------->| CCR(Update,Used-Units)| | |------------------->|| | | CCA(Granted-Units)|| | CCA(Granted-Units)|<-------------------|| |<-------------------| || : | | || : | | || End of Service | | ||------------------>| CCR(Termination,Used-Units) || |------------------->| CCR(Term.,Used-Units)| | |------------------->|| | | CCA || | CCA |<-------------------|| |<-------------------| |Figure 3: Protocol example with use of theauthorization messages for the first interrogation5.3. Intermediate InterrogationWhen all the granted service units for one unit type are spent by theend user or the Validity-Time is expired, the Diameter credit-controlclient MUST send a new Credit-Control-Request to the credit-controlserver. In the event that credit-control for multiple services isapplied in one credit-control session (i.e., units associated toService-Identifier(s) or Rating-Group are granted), a new Credit-Control-Request MUST be sent to the credit-control server when theHakala, et al. Standards Track [Page 27]
RFC 4006 Diameter Credit-Control Application August 2005credit reservation has been wholly consumed, or upon expiration ofthe Validity-Time. It is always up to the Diameter credit-controlclient to send a new request well in advance of the expiration of theprevious request in order to avoid interruption in the serviceelement. Even if the granted service units reserved by the credit-control server have not been spent upon expiration of the Validity-Time, the Diameter credit-control client MUST send a new Credit-Control-Request to the credit-control server.There can also be mid-session service events, which might affect therating of the current service events. In this case, a spontaneousupdating (a new Credit-Control-Request) SHOULD be sent includinginformation related to the service event even if all the grantedservice units have not been spent or the Validity-Time has notexpired.When the used units are reported to the credit-control server, thecredit-control client will not have any units in its possessionbefore new granted units are received from the credit-control server.When the new granted units are received, these units apply from thepoint where the measurement of the reported used units stopped.Where independent credit-control of multiple services is supported,this process may be executed for one or more services, a singlerating-group, or a pool within the (sub)session.The CC-Request-Type AVP is set to the value UPDATE_REQUEST in theintermediate request message. The Subscription-Id AVP SHOULD beincluded in the intermediate message to identify the end user in thecredit-control server. The Service-Context-Id AVP indicates theservice specific document applicable to the request.The Requested-Service-Unit AVP MAY contain the new amount ofrequested service units. Where the Multiple-Services-Credit-ControlAVP is used, it MUST contain the Requested-Service-Unit AVP if a newquota is requested for the associated service/rating-group. TheUsed-Service-Unit AVP contains the amount of used service unitsmeasured from the point when the service became active or, if interiminterrogations are used during the session, from the point when theprevious measurement ended. The same unit types used in the previousmessage SHOULD be used. If several unit types were included in theprevious answer message, the used service units for each unit typeMUST be reported.The Event-Timestamp AVP SHOULD be included in the request andcontains the time of the event that triggered the sending of the newCredit-Control-Request.Hakala, et al. Standards Track [Page 28]
RFC 4006 Diameter Credit-Control Application August 2005The credit-control server MUST deduct the used amount from the enduser's account. It MAY rate the new request and make a new credit-reservation from the end user's account that covers the cost of therequested service event.A Credit-Control-Answer message with the CC-Request-Type AVP set tothe value UPDATE_REQUEST MAY include the Cost-Information AVPcontaining the accumulated cost estimation for the session, withouttaking any credit-reservation into account.The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP to indicate that the answer message contains the finalunits for the service. After the end user has consumed these units,the Diameter credit-control-client MUST behave as described insection 5.6.There can be several intermediate interrogations within a session.5.4. Final InterrogationWhen the end user terminates the service session, or when thegraceful service termination described in section 5.6 takes place,the Diameter credit-control client MUST send a final Credit-Control-Request message to the credit-control server. The CC-Request-TypeAVP is set to the value TERMINATION_REQUEST. The Service-Context-IdAVP indicates the service specific document applicable to therequest.The Event-Timestamp AVP SHOULD be included in the request andcontains the time when the session was terminated.The Used-Service-Unit AVP contains the amount of used service unitsmeasured from the point when the service became active or, if interiminterrogations are used during the session, from the point when theprevious measurement ended. If several unit types were included inthe previous answer message, the used service units for each unittype MUST be reported.After final interrogation, the credit-control server MUST refund thereserved credit amount not used to the end user's account and deductthe used monetary amount from the end user's account.A Credit-Control-Answer message with the CC-Request-Type set to thevalue TERMINATION_REQUEST MAY include the Cost-Information AVPcontaining the estimated total cost for the session in question.If the user logs off during an ongoing credit-control session, or ifsome other reason causes the user to become logged off (e.g., final-Hakala, et al. Standards Track [Page 29]
RFC 4006 Diameter Credit-Control Application August 2005unit indication causes user logoff according to local policy), theservice element, according to application specific policy, may send aSession-Termination-Request (STR) to the home Diameter AAA server asusual [DIAMBASE]. Figure 4 illustrates the case when the final-unitindication causes user logoff upon consumption of the final grantedunits and the generation of STR.Service Element AAA Server CC ServerEnd User (CC Client)| Service Delivery | | ||<----------------->| | || : | | || : | | || : | | || | | || | CCR(Update,Used-Units) || |------------------->| CCR(Update,Used-Units)| | |------------------->|| | CCA(Final-Unit, Terminate)| CCA(Final-Unit, Terminate)|<-------------------|| |<-------------------| || : | | || : | | || Disconnect user | | ||<------------------| CCR(Termination,Used-Units) || |------------------->| CCR(Term.,Used-Units)| | |------------------->|| | | CCA || | CCA |<-------------------|| |<-------------------| || | STR | || |------------------->| || | STA | || |<-------------------| |Figure 4: User disconnected due to exhausted account5.5. Server-Initiated Credit Re-AuthorizationThe Diameter credit-control application supports server-initiatedre-authorization. The credit-control server MAY optionally initiatethe credit re-authorization by issuing a Re-Auth-Request (RAR) asdefined in the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in the RAR message is set to 4 to indicate DiameterCredit Control, and the Re-Auth-Request-Type is set toAUTHORIZE_ONLY.Hakala, et al. Standards Track [Page 30]
RFC 4006 Diameter Credit-Control Application August 2005Section 5.1.2 defines the feature to enable credit-control formultiple services within a single (sub-)session where the server canauthorize credit usage at a different level of granularity. Further,the server may provide credit resources to multiple services orrating groups as a pool (see section 5.1.2 for details anddefinitions). Therefore, the server, based on its service logic andits knowledge of the ongoing session, can decide to request creditre-authorization for a whole (sub-)session, a single credit pool, asingle service, or a single rating-group. To request credit re-authorization for a credit pool, the server includes in the RARmessage the G-S-U-Pool-Identifier AVP indicating the affected pool.To request credit re-authorization for a service or a rating-group,the server includes in the RAR message the Service-Identifier AVP orthe Rating-Group AVP, respectively. To request credit re-authorization for all the ongoing services within the (sub-)session,the server includes none of the above mentioned AVPs in the RARmessage.If a credit re-authorization is not already ongoing (i.e., thecredit-control session is in Open state), a credit control clientthat receives an RAR message with Session-Id equal to a currentlyactive credit-control session MUST acknowledge the request by sendingthe Re-Auth-Answer (RAA) message and MUST initiate the credit re-authorization toward the server by sending a Credit-Control-Requestmessage with the CC-Request-Type AVP set to the value UPDATE_REQUEST.The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in theRAA message to indicate that an additional message (i.e., CCR messagewith the value UPDATE_REQUEST) is required to complete the procedure.If a quota was allocated to the service, the credit-control clientMUST report the used quota in the Credit-Control-Request. Note thatthe end user does not need to be prompted for the credit re-authorization, since the credit re-authorization is transparent tothe user (i.e., it takes place exclusively between the credit-controlclient and the credit-control server).Where multiple services in a user's session are supported, theprocedure in the above paragraph will be executed at the granularityrequested by the server in the RAR message.If credit re-authorization is ongoing at the time when the RARmessage is received (i.e., RAR-CCR collision), the credit-controlclient successfully acknowledges the request but does not initiate anew credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS)SHOULD be used in the RAA message to indicate that a credit re-authorization procedure is already ongoing (i.e., the client was inPendingU state when the RAR was received). The credit-control serverSHOULD process the Credit-Control-Request as if it was received inanswer to the server initiated credit re-authorization, and shouldHakala, et al. Standards Track [Page 31]
RFC 4006 Diameter Credit-Control Application August 2005consider the server initiated credit re-authorization processsuccessful upon reception of the Re-Auth-Answer message.When multiple services are supported in a user's session, the servermay request credit re-authorization for a credit pool (or for the(sub-)session) while a credit re-authorization is already ongoing forsome of the services or rating-groups. In this case, the clientacknowledges the server request with an RAA message and MUST send anew Credit-Control-Request message to perform re-authorization forthe remaining services/rating-groups. The Result-Code 2002(DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message toindicate that an additional message (i.e., CCR message with valueUPDATE_REQUEST) is required to complete the procedure. The serverprocesses the received requests and returns an appropriate answer toboth requests.The above-defined procedures are enabled for each of the possiblyactive Diameter credit-control sub-sessions. The server MAY requestre-authorization for an active sub-session by including the CC-Sub-Session-Id AVP in the RAR message in addition to the Session-Id AVP.5.6. Graceful Service TerminationWhen the user's account runs out of money, the user may not beallowed to compile additional chargeable events. However, the homeservice provider may offer some services; for instance, access to aservice portal where it is possible to refill the account, for whichthe user is allowed to benefit for a limited time. The length ofthis time is usually dependent on the home service provider policy.This section defines the optional graceful service terminationfeature that MAY be supported by the credit-control server. Credit-control client implementations MUST support the Final-Unit-Indicationwith at least the teardown of the ongoing service session once thesubscriber has consumed all the final granted units.Where independent credit-control of multiple services in a singlecredit-control (sub-)session is supported, it is possible to use thegraceful service termination for each of the services/rating-groupsindependently. Naturally, the graceful service termination processdefined in the following sub-sections will apply to the specificservice/rating-group as requested by the server.In some service environments (e.g., NAS), the graceful servicetermination may be used to redirect the subscriber to a serviceportal for online balance refill or other services offered by thehome service provider. In this case, the graceful terminationprocess installs a set of packet filters to restrict the user'sHakala, et al. Standards Track [Page 32]
RFC 4006 Diameter Credit-Control Application August 2005access capability only to/from the specified destinations. All theIP packets not matching the filters will be dropped or, possibly,re-directed to the service portal. The user may also be sent anappropriate notification as to why the access has been limited.These actions may be communicated explicitly from the server to theclient or may be configured per-service at the client. Explicitlysignaled redirect or restrict instructions always take precedenceover configured ones.It is also possible use the graceful service termination to connectthe prepaid user to a top-up server that plays an announcement andprompts the user to replenish the account. In this case, thecredit-control server sends only the address of the top-up serverwhere the prepaid user shall be connected after the final grantedunits have been consumed. An example of this is given in Appendix A(Flow VII).The credit-control server MAY initiate the graceful servicetermination by including the Final-Unit-Indication AVP in theCredit-Control-Answer to indicate that the message contains the finalunits for the service.When the credit-control client receives the Final-Unit-Indication AVPin the answer from the server, its behavior depends on the valueindicated in the Final-Unit-Action AVP. The server may request thefollowing actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS.A following figure illustrates the graceful service terminationprocedure described in the following sub-sections.Hakala, et al. Standards Track [Page 33]
RFC 4006 Diameter Credit-Control Application August 2005DiameterEnd User Service Element AAA Server CC Server(CC Client)| Service Delivery | | ||<----------------->| | || |CCR(Update,Used-Units) || |------------------->|CCR(Update,Used-Units)| : | |------------------->|| : | |CCA(Final-Unit,Action)| : | |<-------------------|| |CCA(Final-Unit,Action) || |<-------------------| || | | || : | | || : | | || : | | || /////////////// |CCR(Update,Used-Units) ||/Final Units End/->|------------------->|CCR(Update,Used-Units)|/Action and // | |------------------->||/Restrictions // | | CCA(Validity-Time)||/Start // | CCA(Validity-Time)|<-------------------|| ///////////// |<-------------------| || : | | || : | | || Replenish Account +-------+ ||<-------------------------------------------->|Account| || | | +-------+ || | | RAR || + | RAR |<===================|| | |<===================| || | | RAA | || ///////////// | |===================>| RAA || /If supported / | | CCR(Update) |===================>|| /by CC Server/ | |===================>| CCR(Update) || ///////////// | | |===================>|| | | | CCA(Granted-Unit)|| | | CCA(Granted-Unit)|<===================|| Restrictions ->+ |<===================| || removed | | || : | | || OR | CCR(Update) | || Validity-Time ->|------------------->| CCR(Update) || expires | |------------------->|| | | CCA(Granted-Unit)|| | CCA(Granted-Unit)|<-------------------|| Restrictions ->|<-------------------| || removed | | |Hakala, et al. Standards Track [Page 34]
RFC 4006 Diameter Credit-Control Application August 2005Figure 5: Optional graceful service termination procedure5.6.1. Terminate ActionThe Final-Unit-Indication AVP with Final-Unit-Action TERMINATE doesnot include any other information. When the subscriber has consumedthe final granted units, the service element MUST terminate theservice. This is the default handling applicable whenever thecredit-control client receives an unsupported Final-Unit-Action valueand MUST be supported by all the Diameter credit-control clientimplementations conforming to this specification. A final Credit-Control-Request message to the credit-control server MUST be sent ifthe Final-Unit-Indication AVP indicating action TERMINATE was presentat command level. The CC-Request-Type AVP in the request is set tothe value TERMINATION_REQUEST.5.6.2. Redirect ActionThe Final-Unit-Indication AVP with Final-Unit-Action REDIRECTindicates to the service element supporting this action that, uponconsumption of the final granted units, the user MUST be re-directedto the address specified in the Redirect-Server AVP as follows.The credit-control server sends the Redirect-Server AVP in theCredit-Control-Answer message. In such a case, the service elementMUST redirect or connect the user to the destination specified in theRedirect-Server AVP, if possible. When the end user is redirected(by using protocols others than Diameter) to the specified server orconnected to the top-up server, an additional authorization (andpossibly authentication) may be needed before the subscriber canreplenish the account; however, this is out of the scope of thisspecification.In addition to the Redirect-Server AVP, the credit-control server MAYinclude one or more Restriction-Filter-Rule AVPs or one or moreFilter-Id AVPs in the Credit-Control-Answer message to enable theuser to access other services (for example, zero-rated services). Insuch a case, the access device MUST drop all the packets not matchingthe IP filters specified in the Credit-Control-Answer message and, ifpossible, redirect the user to the destination specified in theRedirect-Server AVP.An entity other than the credit-control server may provision theaccess device with appropriate IP packet filters to be used inconjunction with the Diameter credit-control application. This caseis considered in section 5.6.3.Hakala, et al. Standards Track [Page 35]
RFC 4006 Diameter Credit-Control Application August 2005When the final granted units have been consumed, the credit-controlclient MUST perform an intermediate interrogation. The purpose ofthis interrogation is to indicate to the credit-control server thatthe specified action started and to report the used units. Thecredit-control server MUST deduct the used amount from the end user'saccount but MUST NOT make a new credit reservation. The credit-control client, however, may send intermediate interrogations beforeall the final granted units have been consumed for which rating andmoney reservation may be needed; for instance, upon Validity-Timeexpires or upon mid-session service events that affect the rating ofthe current service. Therefore, the credit-control client MUST NOTinclude any rating related AVP in the request sent once all the finalgranted units have been consumed as an indication to the server thatthe requested final unit action started, rating and money reservationare not required (when the Multiple-Services-Credit-Control AVP isused, the Service-Identifier or Rating-Group AVPs is included toindicate the concerned services). Naturally, the Credit-Control-Answer message does not contain any granted service unit and MUSTinclude the Validity-Time AVP to indicate to the credit-controlclient how long the subscriber is allowed to use network resourcesbefore a new intermediate interrogation is sent to the server.At the expiry of Validity-Time, the credit-control client sends aCredit-Control-Request (UPDATE_REQUEST) as usual. This message doesnot include the Used-Service-Unit AVP, as there is no allotted quotato report. The credit-control server processes the request and MUSTperform the credit reservation. If during this time the subscriberdid not replenish his/her account, whether he/she will bedisconnected or will be granted access to services not controlled bya credit-control server for an unlimited time is dependent on thehome service provider policy (note: the latter option implies thatthe service element should not remove the restriction filters upontermination of the credit-control). The server will return theappropriate Result-Code (see section 9.1) in the Credit-Control-Answer message in order to implement the policy-defined action.Otherwise, new quota will be returned, the service element MUSTremove all the possible restrictions activated by the gracefulservice termination process and continue the credit-control sessionand service session as usual.The credit-control client may not wait until the expiration of theValidity-Time and may send a spontaneous update (a new Credit-Control-Request) if the service element can determine, for instance,that communication between the end user and the top-up server tookplace. An example of this is given in Appendix A (Figure A.8).Hakala, et al. Standards Track [Page 36]
RFC 4006 Diameter Credit-Control Application August 2005Note that the credit-control server may already have initiated theabove-described process for the first interrogation. However, theuser's account might be empty when this first interrogation isperformed. In this case, the subscriber can be offered a chance toreplenish the account and continue the service. The credit-controlclient receives a Credit-Control-Answer or service specificauthorization answer with the Final-Unit-Indication and Validity-TimeAVPs but no Granted-Service-Unit. It immediately starts the gracefulservice termination without sending any message to the server. Anexample of this case is illustrated in Appendix A.5.6.3. Restrict Access ActionA Final-Unit-Indication AVP with the Final-Unit-ActionRESTRICT_ACCESS indicates to the device supporting this action thatthe user's access MUST be restricted according to the IP packetfilters given in the Restriction-Filter-Rule AVP(s) or according tothe IP packet filters identified by the Filter-Id AVP(s). Thecredit-control server SHOULD include either the Restriction-Filter-Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message.An entity other than the credit-control server may provision theaccess device with appropriate IP packet filters to be used inconjunction with the Diameter credit-control application. Such anentity may, for instance, configure the access device with IP flowsto be passed when the Diameter credit-control application indicatesRESTRICT_ACCESS or REDIRECT. The access device passes IP packetsaccording to the filter rules that may have been received in theCredit-Control-Answer message in addition to those that may have beenconfigured by the other entity. However, when the user's accountcannot cover the cost of the requested service, the action taken isthe responsibility of the credit-control server that controls theprepaid subscriber.If another entity working in conjunction with the Diameter credit-control application already provisions the access device with all therequired filter rules for the end user, the credit-control serverpresumably need not send any additional filter. Therefore, it isRECOMMENDED that credit-control server implementations supporting thegraceful service termination be configurable for sending theRestriction-Filter-Rule AVP, the Filter-Id AVP, or none of the above.When the final granted units have been consumed, the credit-controlclient MUST perform an intermediate interrogation. The credit-control client and the credit-control server process thisintermediate interrogation and execute subsequent procedures, asspecified in the previous section for the REDIRECT action.Hakala, et al. Standards Track [Page 37]
RFC 4006 Diameter Credit-Control Application August 2005The credit-control server may initiate the graceful servicetermination with action RESTRICT_ACCESS already for the firstinterrogation, as specified in the previous section for the REDIRECTaction.5.6.4. Usage of the Server-Initiated Credit Re-AuthorizationOnce the subscriber replenishes the account, she presumably expectsall the restrictions placed by the graceful termination procedure tobe removed immediately and unlimited service' access to be resumed.For the best user experience, the credit-control serverimplementation MAY support the server-initiated credit re-authorization (see section 5.5). In such a case, upon the successfulaccount top-up, the credit-control server sends the Re-Auth-Request(RAR) message to solicit the credit re-authorization. The credit-control client initiates the credit re-authorization by sending theCredit-Control-Request message with the CC-Request-Type AVP set tothe value UPDATE_REQUEST. The Used-Service-Unit AVP is not includedin the request, as there is no allotted quota to report. TheRequested-Service-Unit AVP MAY be included in the request. After thecredit-control client successfully receives the Credit-Control-Answerwith new Granted-Service-Unit, all the possible restrictionsactivated for the purpose of the graceful service termination MUST beremoved in the service element. The credit-control session and theservice session continue as usual.5.7. Failure ProceduresThe Credit-Control-Failure-Handling AVP (CCFH), as described in thissection, determines the behavior of the credit-control client infault situations. The CCFH may be received from the Diameter homeAAA server, from the credit-control server, or may be configuredlocally. The CCFH value received from the home AAA server overridesthe locally configured value. The CCFH value received from thecredit-control server in the Credit-Control-Answer message alwaysoverrides any existing value.The authorization server MAY include the Accounting-Realtime-RequiredAVP to determine what to do if the sending of accounting records tothe accounting server has been temporarily prevented, as defined in[DIAMBASE]. It is RECOMMENDED that the client complement thecredit-control failure procedures with backup accounting flow towardan accounting server. By using different combinations ofAccounting-Realtime-Required and Credit-Control-Failure-HandlingAVPs, different safety levels can be built. For example, by choosinga Credit-Control-Failure-Handling AVP equal to CONTINUE for thecredit-control flow and a Accounting-Realtime-Required AVP equal toDELIVER_AND_GRANT for the accounting flow, the service can be grantedHakala, et al. Standards Track [Page 38]
RFC 4006 Diameter Credit-Control Application August 2005to the end user even if the connection to the credit-control serveris down, as long as the accounting server is able to collect theaccounting information and information exchange is taking placebetween the accounting server and credit-control server.As the credit-control application is based on real-time bi-directional communication between the credit-control client and thecredit-control server, the usage of alternative destinations and thebuffering of messages may not be sufficient in the event ofcommunication failures. Because the credit-control server has tomaintain session states, moving the credit-control message stream toa backup server requires a complex context transfer solution.Whether the credit-control message stream is moved to a backupcredit-control server during an ongoing credit-control sessiondepends on the value of the CC-Session-Failover AVP. However,failover may occur at any point in the path between the credit-control client and the credit-control server if a transport failureis detected with a peer, as described in [DIAMBASE]. As aconsequence, the credit-control server might receive duplicatemessages. These duplicates or out of sequence messages can bedetected in the credit-control server based on the credit-controlserver session state machine (section 7), Session-Id AVP, and CC-Request-Number AVP.If a failure occurs during an ongoing credit-control session, thecredit-control client may move the credit-control message stream toan alternative server if the CC-server indicated FAILOVER_SUPPORTEDin the CC-Session-Failover AVP. A secondary credit-control servername, either received from the home Diameter AAA server or configuredlocally, can be used as an address of the backup server. If the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be moved to a backup server.For new credit-control sessions, failover to an alternative credit-control server SHOULD be performed if possible. For instance, if animplementation of the credit-control client can determine primarycredit-control server unavailability, it can establish the newcredit-control sessions with a possibly available secondary credit-control server.The AAA transport profile [AAATRANS] defines the application layerwatchdog algorithm that enables failover from a peer that has failedand is controlled by a watchdog timer (Tw) defined in [AAATRANS].The recommended default initial value for Tw (Twinit) is 30 seconds.Twinit may be set as low as 6 seconds; however, according to[AAATRANS], setting too low a value for Twinit is likely to result inan increased probability of duplicates, as well as an increase inspurious failover and failback attempts. The Diameter base protocolHakala, et al. Standards Track [Page 39]
RFC 4006 Diameter Credit-Control Application August 2005is common to several different types of Diameter AAA applicationsthat may be run in the same service element. Therefore, tuning thetimer Twinit to a lower value in order to satisfy the requirements ofreal-time applications, such as the Diameter credit-controlapplication, will certainly cause the above mentioned problems. Forprepaid services, however, the end user expects an answer from thenetwork in a reasonable time. Thus, the Diameter credit-controlclient will react faster than would the underlying base protocol.Therefore this specification defines the timer Tx that is used by thecredit-control client (as defined in section 13) to supervise thecommunication with the credit-control server. When the timer Txelapses, the credit-control client takes an action to the end useraccording to the Credit-Control-Failure-Handling AVP.When Tx expires, the Diameter credit-control client always terminatesthe service if the Credit-Control-Failure-Handling (CCFH) AVP is setto the value TERMINATE. The credit-control session may be moved toan alternative server only if a protocol error DIAMETER_TOO_BUSY orDIAMETER_UNABLE_TO_DELIVER is received before Tx expires. Therefore,the value TERMINATE is not appropriate if proper failover behavior isdesired.If the Credit-Control-Failure-Handling AVP is set to the valueCONTINUE or RETRY_AND_TERMINATE, the service will be granted to theend user when the timer Tx expires. An answer message with granted-units may arrive later if the base protocol transport failoveroccurred in the path to the credit-control server. (The Twinitdefault value is 3 times more than the Tx recommended value.) Thecredit-control client SHOULD grant the service to the end user, startmonitoring the resource usage, and wait for the possible late answeruntil the timeout of the request (e.g., 120 seconds). If the requestfails and the CC-Session-Failover AVP is set toFAILOVER_NOT_SUPPORTED, the credit-control client terminates orcontinues the service depending on the value set in the CCFH and MUSTfree all the reserved resources for the credit-control session. Ifthe protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY isreceived or the request times out and the CC-Session-Failover AVP isset to FAILOVER_SUPPORTED, the credit-control client MAY send therequest to a backup server, if possible. If the credit-controlclient receives a successful answer from the backup server, itcontinues the credit-control session with such a server. If the re-transmitted request also fails, the credit-control client terminatesor continues the service depending on the value set in the CCFH andMUST free all the reserved resources for the credit-control session.If a communication failure occurs during the graceful servicetermination procedure, the service element SHOULD always terminatethe ongoing service session.Hakala, et al. Standards Track [Page 40]
RFC 4006 Diameter Credit-Control Application August 2005If the credit-control server detects a failure during an ongoingcredit-control session, it will terminate the credit-control sessionand return the reserved units back to the end user's account.The supervision session timer Tcc (as defined in section 13) is usedin the credit-control server to supervise the credit-control session.In order to support failover between credit-control servers,information transfer about the credit-control session and accountstate SHOULD take place between the primary and the secondarycredit-control server. Implementations supporting the credit-controlsession failover MUST also ensure proper detection of duplicate orout of sequence messages. The communication between the servers isregarded as an implementation issue and is outside of the scope ofthis specification.6. One Time EventThe one-time event is used when there is no need to maintain anystate in the Diameter credit-control server; for example, enquiringabout the price of the service. The use of a one-time event impliesthat the user has been authenticated and authorized beforehand.The one time event can be used when the credit-control client wantsto know the cost of the service event or to check the account balancewithout any credit-reservation. It can also be used for refundingservice units on the user's account or for direct debiting withoutany credit-reservation. The one time event is shown in Figure 6.DiameterEnd User Service Element AAA Server CC Server(CC Client)| Service Request | | ||------------------>| | || | CCR(Event) | || |------------------->| CCR(Event) || | |------------------->|| | | CCA(Granted-Units)|| | CCA(Granted-Units)|<-------------------|| Service Delivery |<-------------------| ||<----------------->| | |Figure 6: One time eventIn environments such as the 3GPP architecture, the one time event canbe sent from the service element directly to the credit-controlserver.Hakala, et al. Standards Track [Page 41]
RFC 4006 Diameter Credit-Control Application August 20056.1. Service Price EnquiryThe credit-control client may need to know the price of the serviceevent. Services offered by application service providers whoseprices are not known in the credit-control client might exist. Theend user might also want to get an estimation of the price of aservice event before requesting it.A Diameter credit-control client requesting the cost information MUSTset the CC-Request-Type AVP equal to EVENT_REQUEST, include theRequested-Action AVP set to PRICE_ENQUIRY, and set the requestedservice event information into the Service-Identifier AVP in theCredit-Control-Request message. Additional service event informationmay be sent as service specific AVPs or within the Service-Parameter-Info AVP. The Service-Context-Id AVP indicates the servicespecific document applicable to the request.The credit-control server calculates the cost of the requestedservice event, but it does not perform any account balance check orcredit-reservation from the account.The estimated cost of the requested service event is returned to thecredit-control client in the Cost-Information AVP in the Credit-Control-Answer message.6.2. Balance CheckThe Diameter credit-control client may only have to verify that theend user's account balance covers the cost of a certain servicewithout reserving any units from the account at the time of theinquiry. This method does not guarantee that credit would be leftwhen the Diameter credit-control client requests the debiting of theaccount with a separate request.A Diameter credit-control client requesting the balance check MUSTset the CC-Request-Type AVP equal to EVENT_REQUEST, include aRequested-Action AVP set to CHECK_BALANCE, and include theSubscription-Id AVP in order to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the servicespecific document applicable to the request.The credit-control server makes the balance check, but it does notmake any credit-reservation from the account.The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned tothe credit-control client in the Check-Balance-Result AVP in theCredit-Control-Answer message.Hakala, et al. Standards Track [Page 42]
RFC 4006 Diameter Credit-Control Application August 20056.3. Direct DebitingThere are certain service events for which service execution isalways successful in the service environment. The delay between theservice invocation and the actual service delivery to the end usercan be sufficiently long that the use of the session-based credit-control would lead to unreasonably long credit-control sessions. Inthese cases, the Diameter credit-control client can use the one-timeevent scenario for direct debiting. The Diameter credit-controlclient SHOULD be sure that the requested service event executionwould be successful when this scenario is used.In the Credit-Control-Request message, the CC-Request-Type is set tothe value EVENT_REQUEST and the Requested-Action AVP is set toDIRECT_DEBITING. The Subscription-Id AVP SHOULD be included toidentify the end user in the credit-control server. The Event-Timestamp AVP SHOULD be included in the request and contain the timewhen the service event is requested in the service element. TheService-Context-Id AVP indicates the service specific documentapplicable to the request.The Diameter credit-control client MAY include the monetary amount tobe charged in the Requested-Service-Unit AVP, if it knows the cost ofthe service event. If the Diameter credit-control client does notknow the cost of the service event, the Requested-Service-Unit AVPMAY contain the number of requested service events. The Service-Identifier AVP always indicates the service concerned. Additionalservice event information to be rated MAY be sent as service specificAVPs or within the Service-Parameter-Info AVP.The credit-control server SHOULD rate the service event and deductthe corresponding monetary amount from the end user's account. Ifthe type of the Requested-Service-Unit AVP is money, no rating isneeded, but the corresponding monetary amount is deducted from theend user's account.The credit-control server returns the Granted-Service-Unit AVP in theCredit-Control-Answer message to the Diameter credit-control client.The Granted-Service-Unit AVP contains the amount of service unitsthat the Diameter credit-control client can provide to the end user.The type of the Granted-Service-Unit can be time, volume, servicespecific, or money, depending on the type of service event.If the credit-control server determines that no credit-control isneeded for the service, it can include the result code indicatingthat the credit-control is not applicable (e.g., service is free ofcharge).Hakala, et al. Standards Track [Page 43]
RFC 4006 Diameter Credit-Control Application August 2005For informative purposes, the Credit-Control-Answer message MAY alsoinclude the Cost-Information AVP containing the estimated total costof the requested service.6.4. RefundSome services may refund service units to the end user's account; forexample, gaming services.The credit-control client MUST set CC-Request-Type to the valueEVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in theCredit-Control-Request message. The Subscription-Id AVP SHOULD beincluded to identify the end user in the credit-control server. TheService-Context-Id AVP indicates the service specific documentapplicable to the request.The Diameter credit-control client MAY include the monetary amount tobe refunded in the Requested-Service-Unit AVP. The Service-Identifier AVP always indicates the concerned service. If theDiameter credit-control client does not know the monetary amount tobe refunded, in addition to the Service-Identifier AVP it MAY sendservice specific AVPs or the Service-Parameter-Info AVP containingadditional service event information to be rated.For informative purposes, the Credit-Control-Answer message MAY alsoinclude the Cost-Information AVP containing the estimated monetaryamount of refunded unit.6.5. Failure ProcedureFailover to an alternative credit-control server is allowed for a onetime event, as the server is not maintaining session states. Forinstance, if the credit-control client receives a protocol errorDIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send therequest to an alternative server, if possible. There MAY be protocoltransparent Diameter relays and redirect agents or Diameter credit-control proxies between the credit-control client and credit-controlserver. Failover may occur at any point in the path between thecredit-control client and the credit-control server if a transportfailure is detected with a peer, as described in [DIAMBASE]. Becausethere can be duplicate requests for various reasons, the credit-control server is responsible for real time duplicate detection.Implementation issues for duplicate detection are discussed in[DIAMBASE], Appendix C.When the credit-control client detects a communication failure withthe credit-control server, its behavior depends on the requestedaction. The timer Tx (as defined in section 13) is used in theHakala, et al. Standards Track [Page 44]
RFC 4006 Diameter Credit-Control Application August 2005credit-control client to supervise the communication with thecredit-control server.If the requested action is PRICE_ENQUIRY or CHECK_BALANCE andcommunication failure is detected, the credit-control client SHOULDforward the request messages to an alternative credit-control server,if possible. The secondary credit-control server name, if receivedfrom the home Diameter AAA server, can be used as an address ofbackup server.If the requested action is DIRECT_DEBITING, the Direct-Debiting-Failure-Handling AVP (DDFH) controls the credit-control client'sbehavior. The DDFH may be received from the home Diameter AAA serveror may be locally configured. The credit-control server may alsosend the DDFH in any CCA message to be used for direct debitingevents compiled thereafter. The DDFH value received from the homeDiameter AAA server overrides the locally configured value, and theDDFH value received from the credit-control server in a Credit-Control-Answer message always overrides any existing value.If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control clientSHOULD NOT grant the service if it can determine, eventually after apossible re-transmission attempt to an alternative credit-controlserver, from the result code or error code in the answer message thatunits have not been debited. Otherwise, the credit-control clientSHOULD grant the service to the end user and store the request in thecredit-control application level non-volatile storage. (Note thatre-sending the request at a later time is not a guarantee that theservice will be debited, as the user's account may be empty when theserver successfully processes the request.) The credit-controlclient MUST mark these request messages as possible duplicates bysetting the T-flag in the command header as described in [DIAMBASE],section 3.If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, theservice SHOULD be granted, even if credit-control messages cannot bedelivered and messages are not buffered.If the timer Tx expires, the credit-control client MUST continue theservice and wait for a possible late answer. If the request timesout, the credit-control client re-transmits the request (marked withT-flag) to a backup credit-control server, if possible. If the re-transmitted request also times out, or if a temporary error isreceived in answer, the credit-control client buffers the request ifthe value of the Direct-Debiting-Failure-Handling AVP is set toTERMINATE_OR_BUFFER. If a failed answer is received for theHakala, et al. Standards Track [Page 45]
RFC 4006 Diameter Credit-Control Application August 2005re-transmitted request, the credit-control client frees all theresources reserved for the event message and deletes the requestregardless of the value of the DDFH.The Credit-Control-Request with the requested action REFUND_ACCOUNTshould always be stored in the credit-control application level non-volatile storage in case of temporary failure. The credit-controlclient MUST mark the re-transmitted request message as a possibleduplicate by setting the T-flag in the command header as described in[DIAMBASE], section 3.For stored requests, the implementation may choose to limit thenumber of re-transmission attempts and to define a re-transmissioninterval.Note that only one place in the credit-control system SHOULD beresponsible for duplicate detection. If there is only one credit-control server within the given realm, the credit-control server mayperform duplicate detection. If there is more than one credit-control server in a given realm, only one entity in the credit-control system should be responsible, to ensure that the end user'saccount is not debited or credited multiple times for the sameservice event.7. Credit-Control Application State MachineThis section defines the credit-control application state machine.The first four state machines are to be observed by credit-controlclients. The first one describes the session-based credit-controlwhen the first interrogation is executed as part of theauthorization/authentication process. The second describes thesession-based credit-control when the first interrogation is executedafter the authorization/authentication process. The requirements asto what state machines have to be supported are discussed in section5.2.The third state machine describes the session-based credit-controlfor the intermediate and final interrogations. The fourth onedescribes the event-based credit-control. These latter statemachines are to be observed by all implementations that conform tothis specification.The fifth state machine describes the credit-control session from acredit-control server perspective.Hakala, et al. Standards Track [Page 46]
RFC 4006 Diameter Credit-Control Application August 2005Any event not listed in the state machines MUST be considered anerror condition, and a corresponding answer, if applicable, MUST bereturned to the originator of the message.In the state table, the event 'Failure to send' means that theDiameter credit-control client is unable to communicate with thedesired destination or, if failover procedure is supported, with apossibly defined alternative destination (e.g., the request times outand the answer message is not received). This could be due to thepeer being down, or due to a physical link failure in the path to orfrom the credit-control server.The event 'Temporary error' means that the Diameter credit-controlclient received a protocol error notification (DIAMETER_TOO_BUSY,DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in theResult-Code AVP of the Credit-Control-Answer command. The aboveprotocol error notification may ultimately be received in answer tothe re-transmitted request to a defined alternative destination, iffailover is supported.The event 'Failed answer' means that the Diameter credit-controlclient received non-transient failure (permanent failure)notification in the Credit-Control-Answer command. The abovepermanent failure notification may ultimately be received in answerto the re-transmitted request to a defined alternative destination,if failover is supported.The action 'store request' means that a request is stored in thecredit-control application level non-volatile storage.The event 'Not successfully processed' means that the credit-controlserver could not process the message; e.g., due to an unknown enduser, account being empty, or errors defined in [DIAMBASE].The event 'User service terminated' can be triggered by variousreasons, e.g., normal user termination, network failure, and ASR(Abort-Session-Request). The Termination-Cause AVP containsinformation about the termination reason, as specified in [DIAMBASE].The Tx timer, which is used to control the waiting time in thecredit-control client in the Pending state, is stopped upon exit ofthe Pending state. The stopping of the Tx timer is omitted in thestate machine when the new state is Idle, as moving to Idle stateimplies the clearing of the session and all the variables associatedto it.Hakala, et al. Standards Track [Page 47]
RFC 4006 Diameter Credit-Control Application August 2005The states PendingI, PendingU, PendingT, PendingE, and PendingB standfor pending states to wait for an answer to a credit-control requestrelated to Initial, Update, Termination, Event, or Buffered request,respectively.The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handlingand Direct-Debiting-Failure-Handling, respectively.In the following state machine table, the failover to a secondaryserver upon 'Temporary error' or 'Failure to send' is not explicitlydescribed. Moving an ongoing credit-control message stream to analternative server is, however, possible if the CC-Session-FailoverAVP is set to FAILOVER_SUPPORTED, as described in section 5.7.Re-sending a credit-control event to an alternative server issupported as described in section 6.5.CLIENT, SESSION BASED for the first interrogation with AA requestState Event Action New State---------------------------------------------------------------Idle Client or device requests Send PendingIaccess/service AA requestwith addedCC AVPs,start TxPendingI Successful AA req. Grant Openanswer received service toend user,stop TxPendingI Tx expired Disconnect Idleuser/devPendingI Failed AA answer received Disconnect Idleuser/devPendingI AA answer Grant Idlereceived with result code serviceequal to CREDIT_CONTROL_ to end userNOT_APPLICABLEPendingI User service terminated Queue PendingIterminationeventHakala, et al. Standards Track [Page 48]
RFC 4006 Diameter Credit-Control Application August 2005PendingI Change in rating condition Queue PendingIchangedratingconditioneventCLIENT, SESSION BASED for the first interrogation with CCRState Event Action New State----------------------------------------------------------------Idle Client or device requests Send PendingIaccess/service CC initialreq.,start TxPendingI Successful CC initial Stop Tx Openanswer receivedPendingI Failure to send, or Grant Idletemporary error and service toCCFH equal to CONTINUE end userPendingI Failure to send, or Terminate Idletemporary error and end user'sCCFH equal to TERMINATE serviceor to RETRY_AND_TERMINATEPendingI Tx expired and CCFH Terminate Idleequal to TERMINATE end user'sservicePendingI Tx expired and CCFH equal Grant PendingIto CONTINUE or to service toRETRY_AND_TERMINATE end userPendingI CC initial answer Terminate Idlereceived with result code end user'sEND_USER_SERVICE_DENIED or serviceUSER_UNKNOWNPendingI CC initial answer Grant Idlereceived with result code serviceequal to CREDIT_CONTROL_ to end userNOT_APPLICABLEHakala, et al. Standards Track [Page 49]
RFC 4006 Diameter Credit-Control Application August 2005PendingI Failed CC initial answer Grant Idlereceived and CCFH equal to service toCONTINUE end userPendingI Failed CC initial answer Terminate Idlereceived and CCFH equal end user'sto TERMINATE or to serviceRETRY_AND_TERMINATEPendingI User service terminated Queue PendingIterminationeventPendingI Change in rating condition Queue PendingIchangedratingconditioneventCLIENT, SESSION BASED for intermediate and final interrogationsState Event Action New State----------------------------------------------------------------Open Granted unit elapses Send PendingUand no final unit CC updateindication received req.,start TxOpen Granted unit elapses Terminate PendingTand final unit action end user'sequal to TERMINATE service, sendreceived CC terminationreq.Open Change in rating condition Send PendingUin queue CC updatereq.,Start TxOpen Service terminated in queue Send PendingTCC terminationreq.Open Change in rating condition Send PendingUor Validity-Time elapses CC updatereq.,Start TxHakala, et al. Standards Track [Page 50]
RFC 4006 Diameter Credit-Control Application August 2005Open User service terminated Send PendingTCC terminationreq.Open RAR received Send RAA PendingUfollowed byCC update req.,start TxPendingU Successful CC update Stop Tx Openanswer receivedPendingU Failure to send, or Grant Idletemporary error and service toCCFH equal to CONTINUE end userPendingU Failure to send, or Terminate Idletemporary error and end user'sCCFH equal to TERMINATE serviceor to RETRY_AND_TERMINATEPendingU Tx expired and CCFH Terminate Idleequal to TERMINATE end user'sservicePendingU Tx expired and CCFH equal Grant PendingUto CONTINUE or to service toRETRY_AND_TERMINATE end userPendingU CC update answer Terminate Idlereceived with result code end user'sEND_USER_SERVICE_DENIED servicePendingU CC update answer Grant Idlereceived with result code serviceequal to CREDIT_CONTROL_ to end userNOT_APPLICABLEPendingU Failed CC update Grant Idleanswer received and service toCCFH equal to CONTINUE end userPendingU Failed CC update Terminate Idleanswer received and CCFH end user'sequal to TERMINATE or serviceto RETRY_AND_TERMINATEHakala, et al. Standards Track [Page 51]
RFC 4006 Diameter Credit-Control Application August 2005PendingU User service terminated Queue PendingUterminationeventPendingU Change in rating Queue PendingUcondition changedratingconditioneventPendingU RAR received Send RAA PendingUPendingT Successful CC Idletermination answer receivedPendingT Failure to send, temporary Idleerror, or failed answerPendingT Change in rating condition PendingTCLIENT, EVENT BASEDState Event Action New State----------------------------------------------------------------Idle Client or device requests Send PendingEa one-time service CC eventreq.,Start TxIdle Request in storage Send PendingBstoredrequestPendingE Successful CC event Grant Idleanswer received service toend userPendingE Failure to send, temporary Indicate Idleerror, failed CC event serviceanswer received, or errorTx expired; requestedaction CHECK_BALANCE orPRICE_ENQUIRYPendingE CC event answer Terminate Idlereceived with result code end user'sEND_USER_SERVICE_DENIED or serviceUSER_UNKNOWN and Tx runningHakala, et al. Standards Track [Page 52]
RFC 4006 Diameter Credit-Control Application August 2005PendingE CC event answer Grant Idlereceived with result code serviceCREDIT_CONTROL_NOT_APPLICABLE; to endrequested action userDIRECT_DEBITINGPendingE Failure to send, temporary Grant Idleerror, or failed CC event serviceanswer received; requested to endaction DIRECT_DEBITING; userDDFH equal to CONTINUEPendingE Failed CC event Terminate Idleanswer received or temporary end user'serror; requested action serviceDIRECT_DEBITING;DDFH equal toTERMINATE_OR_BUFFER andTx runningPendingE Tx expired; requested Grant PendingEaction DIRECT_DEBITING serviceto enduserPendingE Failure to send; requested Store Idleaction DIRECT_DEBITING; request withDDFH equal to T-flagTERMINATE_OR_BUFFERPendingE Temporary error; requested Store Idleaction DIRECT_DEBITING; requestDDFH equal toTERMINATE_OR_BUFFER;Tx expiredPendingE Failed answer or answer Idlereceived with result codeEND_USER_SERVICE DENIED orUSER_UNKNOWN; requested actionDIRECT_DEBITING; Tx expiredPendingE Failed CC event answer Indicate Idlereceived; requested serviceaction REFUND_ACCOUNT error anddelete requestHakala, et al. Standards Track [Page 53]
RFC 4006 Diameter Credit-Control Application August 2005PendingE Failure to send or Store IdleTx expired; requested requestaction REFUND_ACCOUNT with T-flagPendingE Temporary error, Store Idleand requested action requestREFUND_ACCOUNTPendingB Successful CC answer Delete Idlereceived requestPendingB Failed CC answer Delete Idlereceived requestPendingB Failure to send or Idletemporary errorSERVER, SESSION AND EVENT BASEDState Event Action New State----------------------------------------------------------------Idle CC initial request Send Openreceived and successfully CC initialprocessed answer,reserve units,start TccIdle CC initial request Send Idlereceived but not CC initialsuccessfully processed answer withResult-Code!= SUCCESSIdle CC event request Send Idlereceived and successfully CC eventprocessed answerIdle CC event request Send Idlereceived but not CC eventsuccessfully processed answer withResult-Code!= SUCCESSHakala, et al. Standards Track [Page 54]
RFC 4006 Diameter Credit-Control Application August 2005Open CC update request Send CC Openreceived and successfully update answer,processed debit usedunits,reservenew units,restart TccOpen CC update request Send Idlereceived but not CC updatesuccessfully processed answer withResult-Code!= SUCCESS,debit usedunitsOpen CC termination request Send Idlereceived and successfully CC termin.processed answer,Stop Tcc,debit usedunitsOpen CC termination request Send Idlereceived but not CC termin.successfully processed answer withResult-Code!= SUCCESS,debit usedunitsOpen Session supervision timer Tcc Release Idleexpired reservedunits8. Credit-Control AVPsThis section defines the credit-control AVPs that are specific toDiameter credit-control application and that MAY be included in theDiameter credit-control messages.The AVPs defined in this section MAY also be included inauthorization commands defined in authorization-specificapplications, such as [NASREQ] and [DIAMMIP], if the firstinterrogation is performed as part of theauthorization/authentication process, as described in section 5.2.Hakala, et al. Standards Track [Page 55]
RFC 4006 Diameter Credit-Control Application August 2005The Diameter AVP rules are defined in the Diameter Base [DIAMBASE],section 4. These AVP rules are observed in AVPs defined in thissection.The following table describes the Diameter AVPs defined in thecredit-control application, their AVP Code values, types, possibleflag values, and whether the AVP MAY be encrypted. The Diameter base[DIAMBASE] specifies the AVP Flag rules for AVPs in section 4.5.+--------------------+| AVP Flag rules ||----+-----+----+----|----+AVP Section | | |SHLD|MUST| |Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr|-----------------------------------------|----+-----+----+----|----|CC-Correlation-Id 411 8.1 OctetString| | P,M | | V | Y |CC-Input-Octets 412 8.24 Unsigned64 | M | P | | V | Y |CC-Money 413 8.22 Grouped | M | P | | V | Y |CC-Output-Octets 414 8.25 Unsigned64 | M | P | | V | Y |CC-Request-Number 415 8.2 Unsigned32 | M | P | | V | Y |CC-Request-Type 416 8.3 Enumerated | M | P | | V | Y |CC-Service- 417 8.26 Unsigned64 | M | P | | V | Y |Specific-Units | | | | | |CC-Session- 418 8.4 Enumerated | M | P | | V | Y |Failover | | | | | |CC-Sub-Session-Id 419 8.5 Unsigned64 | M | P | | V | Y |CC-Time 420 8.21 Unsigned32 | M | P | | V | Y |CC-Total-Octets 421 8.23 Unsigned64 | M | P | | V | Y |CC-Unit-Type 454 8.32 Enumerated | M | P | | V | Y |Check-Balance- 422 8.6 Enumerated | M | P | | V | Y |Result | | | | | |Cost-Information 423 8.7 Grouped | M | P | | V | Y |Cost-Unit 424 8.12 UTF8String | M | P | | V | Y |Credit-Control 426 8.13 Enumerated | M | P | | V | Y |Credit-Control- 427 8.14 Enumerated | M | P | | V | Y |Failure-Handling | | | | | |Currency-Code 425 8.11 Unsigned32 | M | P | | V | Y |Direct-Debiting- 428 8.15 Enumerated | M | P | | V | Y |Failure-Handling | | | | | |Exponent 429 8.9 Integer32 | M | P | | V | Y |Final-Unit-Action 449 8.35 Enumerated | M | P | | V | Y |Final-Unit- 430 8.34 Grouped | M | P | | V | Y |Indication | | | | | |Granted-Service- 431 8.17 Grouped | M | P | | V | Y |Unit | | | | | |G-S-U-Pool- 453 8.31 Unsigned32 | M | P | | V | Y |Identifier | | | | | |Hakala, et al. Standards Track [Page 56]
RFC 4006 Diameter Credit-Control Application August 2005G-S-U-Pool- 457 8.30 Grouped | M | P | | V | Y |Reference | | | | | |Multiple-Services 456 8.16 Grouped | M | P | | V | Y |-Credit-Control | | | | | |Multiple-Services 455 8.40 Enumerated | M | P | | V | Y |-Indicator | | | | | |Rating-Group 432 8.29 Unsigned32 | M | P | | V | Y |Redirect-Address 433 8.38 Enumerated | M | P | | V | Y |-Type | | | | | |Redirect-Server 434 8.37 Grouped | M | P | | V | Y |Redirect-Server 435 8.39 UTF8String | M | P | | V | Y |-Address | | | | | |Requested-Action 436 8.41 Enumerated | M | P | | V | Y |Requested-Service 437 8.18 Grouped | M | P | | V | Y |-Unit | | | | | |Restriction 438 8.36 IPFiltrRule| M | P | | V | Y |-Filter-Rule | | | | | |Service-Context 461 8.42 UTF8String | M | P | | V | Y |-Id | | | | | |Service- 439 8.28 Unsigned32 | M | P | | V | Y |Identifier | | | | | |Service-Parameter 440 8.43 Grouped | | P,M | | V | Y |-Info | | | | | |Service- 441 8.44 Unsigned32 | | P,M | | V | Y |Parameter-Type | | | | | |Service- 442 8.45 OctetString| | P,M | | V | Y |Parameter-Value | | | | | |Subscription-Id 443 8.46 Grouped | M | P | | V | Y |Subscription-Id 444 8.48 UTF8String | M | P | | V | Y |-Data | | | | | |Subscription-Id 450 8.47 Enumerated | M | P | | V | Y |-Type | | | | | |Tariff-Change 452 8.27 Enumerated | M | P | | V | Y |-Usage | | | | | |Tariff-Time 451 8.20 Time | M | P | | V | Y |-Change | | | | | |Unit-Value 445 8.8 Grouped | M | P | | V | Y |Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y |User-Equipment 458 8.49 Grouped | | P,M | | V | Y |-Info | | | | | |User-Equipment 459 8.50 Enumerated | | P,M | | V | Y |-Info-Type | | | | | |User-Equipment 460 8.51 OctetString| | P,M | | V | Y |-Info-Value | | | | | |Value-Digits 447 8.10 Integer64 | M | P | | V | Y |Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y |Hakala, et al. Standards Track [Page 57]
RFC 4006 Diameter Credit-Control Application August 20058.1. CC-Correlation-Id AVPThe CC-Correlation-Id AVP (AVP Code 411) is of type OctetString andcontains information to correlate credit-control requests generatedfor different components of the service; e.g., transport and servicelevel. The one who allocates the Service-Context-Id (i.e., uniqueidentifier of a service specific document) is also responsible fordefining the content and encoding of the CC-Correlation-Id AVP.8.2. CC-Request-Number AVPThe CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 andidentifies this request within one session. As Session-Id AVPs areglobally unique, the combination of Session-Id and CC-Request-NumberAVPs is also globally unique and can be used in matching credit-control messages with confirmations. An easy way to produce uniquenumbers is to set the value to 0 for a credit-control request of typeINITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for thefirst UPDATE_REQUEST, to 2 for the second, and so on until the valuefor TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST.8.3. CC-Request-Type AVPThe CC-Request-Type AVP (AVP Code 416) is of type Enumerated andcontains the reason for sending the credit-control request message.It MUST be present in all Credit-Control-Request messages. Thefollowing values are defined for the CC-Request-Type AVP:INITIAL_REQUEST 1An Initial request is used to initiate a credit-control session,and contains credit control information that is relevant to theinitiation.UPDATE_REQUEST 2An Update request contains credit-control information for anexisting credit-control session. Update credit-control requestsSHOULD be sent every time a credit-control re-authorization isneeded at the expiry of the allocated quota or validity time.Further, additional service-specific events MAY trigger aspontaneous Update request.TERMINATION_REQUEST 3A Termination request is sent to terminate a credit-controlsession and contains credit-control information relevant to theexisting session.Hakala, et al. Standards Track [Page 58]
RFC 4006 Diameter Credit-Control Application August 2005EVENT_REQUEST 4An Event request is used when there is no need to maintain anycredit-control session state in the credit-control server. Thisrequest contains all information relevant to the service, and isthe only request of the service. The reason for the Event requestis further detailed in the Requested-Action AVP. The Requested-Action AVP MUST be included in the Credit-Control-Request messagewhen CC-Request-Type is set to EVENT_REQUEST.8.4. CC-Session-Failover AVPThe CC-Session-Failover AVP (AVP Code 418) is type of Enumerated andcontains information as to whether moving the credit-control messagestream to a backup server during an ongoing credit-control session issupported. In communication failures, the credit-control messagestreams can be moved to an alternative destination if the credit-control server supports failover to an alternative server. Thesecondary credit-control server name, if received from the homeDiameter AAA server, can be used as an address of the backup server.An implementation is not required to support moving a credit-controlmessage stream to an alternative server, as this also requires movinginformation related to the credit-control session to backup server.The following values are defined for the CC-Session-Failover AVP:FAILOVER_NOT_SUPPORTED 0When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED,the credit-control message stream MUST NOT to be moved to analternative destination in the case of communication failure.This is the default behavior if the AVP isn't included in thereply from the authorization or credit-control server.FAILOVER_SUPPORTED 1When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, thecredit-control message stream SHOULD be moved to an alternativedestination in the case of communication failure. Moving thecredit-control message stream to a backup server MAY require thatinformation related to the credit-control session should also beforwarded to alternative server.8.5. CC-Sub-Session-Id AVPThe CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 andcontains the credit-control sub-session identifier. The combinationof the Session-Id and this AVP MUST be unique per sub-session, andHakala, et al. Standards Track [Page 59]
RFC 4006 Diameter Credit-Control Application August 2005the value of this AVP MUST be monotonically increased by one for allnew sub-sessions. The absence of this AVP implies that no sub-sessions are in use.8.6. Check-Balance-Result AVPThe Check Balance Result AVP (AVP Code 422) is of type Enumerated andcontains the result of the balance check. This AVP is applicableonly when the Requested-Action AVP indicates CHECK_BALANCE in theCredit-Control-Request command.The following values are defined for the Check-Balance-Result AVP.ENOUGH_CREDIT 0There is enough credit in the account to cover the requestedservice.NO_CREDIT 1There isn't enough credit in the account to cover the requestedservice.8.7. Cost-Information AVPThe Cost-Information AVP (AVP Code 423) is of type Grouped, and it isused to return the cost information of a service, which the credit-control client can transfer transparently to the end user. Theincluded Unit-Value AVP contains the cost estimate (always type ofmoney) of the service, in the case of price enquiry, or theaccumulated cost estimation, in the case of credit-control session.The Currency-Code specifies in which currency the cost was given.The Cost-Unit specifies the unit when the service cost is a cost perunit (e.g., cost for the service is $1 per minute).When the Requested-Action AVP with value PRICE_ENQUIRY is included inthe Credit-Control-Request command, the Cost-Information AVP sent inthe succeeding Credit-Control-Answer command contains the costestimation of the requested service, without any reservation beingmade.The Cost-Information AVP included in the Credit-Control-Answercommand with the CC-Request-Type set to UPDATE_REQUEST contains theaccumulated cost estimation for the session, without taking anycredit reservation into account.Hakala, et al. Standards Track [Page 60]
RFC 4006 Diameter Credit-Control Application August 2005The Cost-Information AVP included in the Credit-Control-Answercommand with the CC-Request-Type set to EVENT_REQUEST orTERMINATION_REQUEST contains the estimated total cost for therequested service.It is defined as follows (per the grouped-avp-def ofRFC 3588 [DIAMBASE]):Cost-Information ::= < AVP Header: 423 >{ Unit-Value }{ Currency-Code }[ Cost-Unit ]8.8. Unit-Value AVPUnit-Value AVP is of type Grouped (AVP Code 445) and specifies theunits as decimal value. The Unit-Value is a value with an exponent;i.e., Unit-Value = Value-Digits AVP * 10^Exponent. Thisrepresentation avoids unwanted rounding off. For example, the valueof 2,3 is represented as Value-Digits = 23 and Exponent = -1. Theabsence of the exponent part MUST be interpreted as an exponent equalto zero.It is defined as follows (per the grouped-avp-def ofRFC 3588 [DIAMBASE]):Unit-Value ::= < AVP Header: 445 >{ Value-Digits }[ Exponent ]8.9. Exponent AVPExponent AVP is of type Integer32 (AVP Code 429) and contains theexponent value to be applied for the Value-Digit AVP within theUnit-Value AVP.8.10. Value-Digits AVPThe Value-Digits AVP is of type Integer64 (AVP Code 447) and containsthe significant digits of the number. If decimal values are neededto present the units, the scaling MUST be indicated with the relatedExponent AVP. For example, for the monetary amount $ 0.05 the valueof Value-Digits AVP MUST be set to 5, and the scaling MUST beindicated with the Exponent AVP set to -2.Hakala, et al. Standards Track [Page 61]RFC 4006 Diameter Credit-Control Application August 20058.11. Currency-Code AVPThe Currency-Code AVP (AVP Code 425) is of type Unsigned32 andcontains a currency code that specifies in which currency the valuesof AVPs containing monetary units were given. It is specified byusing the numeric values defined in the ISO 4217 standard [ISO4217].8.12. Cost-Unit AVPThe Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it isused to display a human readable string to the end user. Itspecifies the applicable unit to the Cost-Information when theservice cost is a cost per unit (e.g., cost of the service is $1 perminute). The Cost-Unit can be minutes, hours, days, kilobytes,megabytes, etc.8.13. Credit-Control AVPThe Credit-Control AVP (AVP Code 426) is of type Enumerated and MUSTbe included in AA requests when the service element has credit-control capabilities.CREDIT_AUTHORIZATION 0If the home Diameter AAA server determines that the user hasprepaid subscription, this value indicates that the credit-controlserver MUST be contacted to perform the first interrogation. Thevalue of the Credit-Control AVP MUST always be set to 0 in an AArequest sent to perform the first interrogation and to initiate anew credit-control session.RE_AUTHORIZATION 1This value indicates to the Diameter AAA server that a credit-control session is ongoing for the subscriber and that thecredit-control server MUST not be contacted. The Credit-ControlAVP set to the value of 1 is to be used only when the firstinterrogation has been successfully performed and the credit-control session is ongoing (i.e., re-authorization triggered byAuthorization-Lifetime). This value MUST NOT be used in an AArequest sent to perform the first interrogation.8.14. Credit-Control-Failure-Handling AVPThe Credit-Control-Failure-Handling AVP (AVP Code 427) is of typeEnumerated. The credit-control client uses information in this AVPto decide what to do if sending credit-control messages to thecredit-control server has been, for instance, temporarily preventeddue to a network problem. Depending on the service logic, thecredit-control server can order the client to terminate the serviceHakala, et al. Standards Track [Page 62]
RFC 4006 Diameter Credit-Control Application August 2005immediately when there is a reason to believe that the service cannotbe charged, or to try failover to an alternative server, if possible.Then the server could either terminate or grant the service, shouldthe alternative connection also fail.TERMINATE 0When the Credit-Control-Failure-Handling AVP is set to TERMINATE,the service MUST only be granted for as long as there is aconnection to the credit-control server. If the credit-controlclient does not receive any Credit-Control-Answer message withinthe Tx timer (as defined in section 13), the credit-controlrequest is regarded as failed, and the end user's service sessionis terminated.This is the default behavior if the AVP isn't included in thereply from the authorization or credit-control server.CONTINUE 1When the Credit-Control-Failure-Handling AVP is set to CONTINUE,the credit-control client SHOULD re-send the request to analternative server in the case of transport or temporary failures,provided that a failover procedure is supported in the credit-control server and the credit-control client, and that analternative server is available. Otherwise, the service SHOULD begranted, even if credit-control messages can't be delivered.RETRY_AND_TERMINATE 2When the Credit-Control-Failure-Handling AVP is set toRETRY_AND_TERMINATE, the credit-control client SHOULD re-send therequest to an alternative server in the case of transport ortemporary failures, provided that a failover procedure issupported in the credit-control server and the credit-controlclient, and that an alternative server is available. Otherwise,the service SHOULD not be granted when the credit-control messagescan't be delivered.8.15. Direct-Debiting-Failure-Handling AVPThe Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of typeEnumerated. The credit-control client uses information in this AVPto decide what to do if sending credit-control messages (Requested-Action AVP set to DIRECT_DEBITING) to the credit-control server hasbeen, for instance, temporarily prevented due to a network problem.TERMINATE_OR_BUFFER 0When the Direct-Debiting-Failure-Handling AVP is set toTERMINATE_OR_BUFFER, the service MUST be granted for as long asthere is a connection to the credit-control server. If theHakala, et al. Standards Track [Page 63]
RFC 4006 Diameter Credit-Control Application August 2005credit-control client does not receive any Credit-Control-Answermessage within the Tx timer (as defined in section 13) thecredit-control request is regarded as failed. The client SHOULDterminate the service if it can determine from the failed answerthat units have not been debited. Otherwise the credit-controlclient SHOULD grant the service, store the request in applicationlevel non-volatile storage, and try to re-send the request. Theserequests MUST be marked as possible duplicates by setting the T-flag in the command header as described in [DIAMBASE] section 3.This is the default behavior if the AVP isn't included in thereply from the authorization server.CONTINUE 1When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE,the service SHOULD be granted, even if credit-control messagescan't be delivered, and the request should be deleted.8.16. Multiple-Services-Credit-Control AVPMultiple-Services-Credit-Control AVP (AVP Code 456) is of typeGrouped and contains the AVPs related to the independent credit-control of multiple services feature. Note that each instance ofthis AVP carries units related to one or more services or related toa single rating group.The Service-Identifier and the Rating-Group AVPs are used toassociate the granted units to a given service or rating group. Ifboth the Service-Identifier and the Rating-Group AVPs are included,the target of the service units is always the service(s) indicated bythe value of the Service-Identifier AVP(s). If only the Rating-Group-Id AVP is present, the Multiple-Services-Credit-Control AVPrelates to all the services that belong to the specified ratinggroup.The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U-Pool-Identifier identifying a credit pool within which the units ofthe specified type are considered pooled. If a G-S-U-Pool-ReferenceAVP is present, then actual service units of the specified type MUSTalso be present. For example, if the G-S-U-Pool-Reference AVPspecifies Unit-Type TIME, then the CC-Time AVP MUST be present.The Requested-Service-Unit AVP MAY contain the amount of requestedservice units or the requested monetary value. It MUST be present inthe initial interrogation and within the intermediate interrogationsin which new quota is requested. If the credit-control client doesnot include the Requested-Service-Unit AVP in a request command,because for instance, it has determined that the end-user terminatedHakala, et al. Standards Track [Page 64]
RFC 4006 Diameter Credit-Control Application August 2005the service, the server MUST debit the used amount from the user'saccount but MUST NOT return a new quota in the corresponding answer.The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY bepresent in an answer command as defined in sections 5.1.2 and 5.6 forthe graceful service termination.When both the Tariff-Time-Change and Tariff-Change-Usage AVPs arepresent, the server MUST include two separate instances of theMultiple-Services-Credit-Control AVP with the Granted-Service-UnitAVP associated to the same service-identifier and/or rating-group.Where the two quotas are associated to the same pool or to differentpools, the credit pooling mechanism defined in section 5.1.2 applies.The Tariff-Change-Usage AVP MUST NOT be included in request commandsto report used units before, and after tariff time change the Used-Service-Unit AVP MUST be used.A server not implementing the independent credit-control of multipleservices functionality MUST treat the Multiple-Services-Credit-Control AVP as an invalid AVP.The Multiple-Services-Control AVP is defined as follows (per thegrouped-avp-def of RFC 3588 [DIAMBASE]):Multiple-Services-Credit-Control ::= < AVP Header: 456 >[ Granted-Service-Unit ][ Requested-Service-Unit ]*[ Used-Service-Unit ][ Tariff-Change-Usage ]*[ Service-Identifier ][ Rating-Group ]*[ G-S-U-Pool-Reference ][ Validity-Time ][ Result-Code ][ Final-Unit-Indication ]*[ AVP ]8.17. Granted-Service-Unit AVPGranted-Service-Unit AVP (AVP Code 431) is of type Grouped andcontains the amount of units that the Diameter credit-control clientcan provide to the end user until the service must be released or thenew Credit-Control-Request must be sent. A client is not required toimplement all the unit types, and it must treat unknown orunsupported unit types in the answer message as an incorrect CCAanswer. In this case, the client MUST terminate the credit-controlsession and indicate in the Termination-Cause AVP reasonDIAMETER_BAD_ANSWER.Hakala, et al. Standards Track [Page 65]
RFC 4006 Diameter Credit-Control Application August 2005The Granted-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):Granted-Service-Unit ::= < AVP Header: 431 >[ Tariff-Time-Change ][ CC-Time ][ CC-Money ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ]8.18. Requested-Service-Unit AVPThe Requested-Service-Unit AVP (AVP Code 437) is of type Grouped andcontains the amount of requested units specified by the Diametercredit-control client. A server is not required to implement all theunit types, and it must treat unknown or unsupported unit types asinvalid AVPs.The Requested-Service-Unit AVP is defined as follows (per thegrouped-avp-def of RFC 3588 [DIAMBASE]):Requested-Service-Unit ::= < AVP Header: 437 >[ CC-Time ][ CC-Money ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ]8.19. Used-Service-Unit AVPThe Used-Service-Unit AVP is of type Grouped (AVP Code 446) andcontains the amount of used units measured from the point when theservice became active or, if interim interrogations are used duringthe session, from the point when the previous measurement ended.Hakala, et al. Standards Track [Page 66]
RFC 4006 Diameter Credit-Control Application August 2005The Used-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):Used-Service-Unit ::= < AVP Header: 446 >[ Tariff-Change-Usage ][ CC-Time ][ CC-Money ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ]8.20. Tariff-Time-Change AVPThe Tariff-Time-Change AVP (AVP Code 451) is of type Time. It issent from the server to the client and includes the time in secondssince January 1, 1900, 00:00 UTC, when the tariff of the service willbe changed.The tariff change mechanism is optional for the client and server,and it is not used for time-based services defined in section 5. Ifa client does not support the tariff time change mechanism, it MUSTtreat Tariff-Time-Change AVP in the answer message as an incorrectCCA answer. In this case, the client terminates the credit-controlsession and indicates in the Termination-Cause AVP reasonDIAMETER_BAD_ANSWER.Omission of this AVP means that no tariff change is to be reported.8.21. CC-Time AVPThe CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicatesthe length of the requested, granted, or used time in seconds.8.22. CC-Money AVPThe CC-Money AVP (AVP Code 413) is of type Grouped and specifies themonetary amount in the given currency. The Currency-Code AVP SHOULDbe included. It is defined as follows (per the grouped-avp-def ofRFC 3588 [DIAMBASE]):CC-Money ::= < AVP Header: 413 >{ Unit-Value }[ Currency-Code ]Hakala, et al. Standards Track [Page 67]RFC 4006 Diameter Credit-Control Application August 20058.23. CC-Total-Octets AVPThe CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 andcontains the total number of requested, granted, or used octetsregardless of the direction (sent or received).8.24. CC-Input-Octets AVPThe CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 andcontains the number of requested, granted, or used octets that canbe/have been received from the end user.8.25. CC-Output-Octets AVPThe CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 andcontains the number of requested, granted, or used octets that canbe/have been sent to the end user.8.26. CC-Service-Specific-Units AVPThe CC-Service-Specific-Units AVP (AVP Code 417) is of typeUnsigned64 and specifies the number of service-specific units (e.g.,number of events, points) given in a selected service. The service-specific units always refer to the service identified in theService-Identifier AVP (or Rating-Group AVP when the Multiple-Services-Credit-Control AVP is used).8.27. Tariff-Change-Usage AVPThe Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated anddefines whether units are used before or after a tariff change, orwhether the units straddled a tariff change during the reportingperiod. Omission of this AVP means that no tariff change hasoccurred.In addition, when present in answer messages as part of theMultiple-Services-Credit-Control AVP, this AVP defines whether unitsare allocated to be used before or after a tariff change event.When the Tariff-Time-Change AVP is present, omission of this AVP inanswer messages means that the single quota mechanism applies.Tariff-Change-Usage can be one of the following:UNIT_BEFORE_TARIFF_CHANGE 0When present in the Multiple-Services-Credit-Control AVP, thisvalue indicates the amount of the units allocated for use before atariff change occurs.Hakala, et al. Standards Track [Page 68]
RFC 4006 Diameter Credit-Control Application August 2005When present in the Used-Service-Unit AVP, this value indicatesthe amount of resource units used before a tariff change hadoccurred.UNIT_AFTER_TARIFF_CHANGE 1When present in the Multiple-Services-Credit-Control AVP, thisvalue indicates the amount of the units allocated for use after atariff change occurs.When present in the Used-Service-Unit AVP, this value indicatesthe amount of resource units used after tariff change hadoccurred.UNIT_INDETERMINATE 2The used unit contains the amount of units that straddle thetariff change (e.g., the metering process reports to the credit-control client in blocks of n octets, and one block straddled thetariff change). This value is to be used only in the Used-Service-Unit AVP.8.28. Service-Identifier AVPThe Service-Identifier AVP is of type Unsigned32 (AVP Code 439) andcontains the identifier of a service. The specific service therequest relates to is uniquely identified by the combination ofService-Context-Id and Service-Identifier AVPs.A usage example of this AVP is illustrated in Appendix A (Flow IX).8.29. Rating-Group AVPThe Rating-Group AVP is of type Unsigned32 (AVP Code 432) andcontains the identifier of a rating group. All the services subjectto the same rating type are part of the same rating group. Thespecific rating group the request relates to is uniquely identifiedby the combination of Service-Context-Id and Rating-Group AVPs.A usage example of this AVP is illustrated in Appendix A (Flow IX).8.30. G-S-U-Pool-Reference AVPThe G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. Itis used in the Credit-Control-Answer message, and associates theGranted-Service-Unit AVP within which it appears with a credit poolwithin the session.The G-S-U-Pool-Identifier AVP specifies the credit pool from whichcredit is drawn for this unit type.Hakala, et al. Standards Track [Page 69]
RFC 4006 Diameter Credit-Control Application August 2005The CC-Unit-Type AVP specifies the type of units for which credit ispooled.The Unit-Value AVP specifies the multiplier, which converts betweenservice units of type CC-Unit-Type and abstract service units withinthe credit pool (and thus to service units of any other service orrating group associated with the same pool).The G-S-U-Pool-Reference AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):G-S-U-Pool-Reference ::= < AVP Header: 457 >{ G-S-U-Pool-Identifier }{ CC-Unit-Type }{ Unit-Value }8.31. G-S-U-Pool-Identifier AVPThe G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32and identifies a credit pool within the session.8.32. CC-Unit-Type AVPThe CC-Unit-Type AVP (AVP Code 454) is of type Enumerated andspecifies the type of units considered to be pooled into a creditpool.The following values are defined for the CC-Unit-Type AVP:TIME 0MONEY 1TOTAL-OCTETS 2INPUT-OCTETS 3OUTPUT-OCTETS 4SERVICE-SPECIFIC-UNITS 58.33. Validity-Time AVPThe Validity-Time AVP is of type Unsigned32 (AVP Code 448). It issent from the credit-control server to the credit-control client.The AVP contains the validity time of the granted service units. Themeasurement of the Validity-Time is started upon receipt of theCredit-Control-Answer Message containing this AVP. If the grantedservice units have not been consumed within the validity timespecified in this AVP, the credit-control client MUST send a Credit-Control-Request message to the server, with CC-Request-Type set toUPDATE_REQUEST. The value field of the Validity-Time AVP is given inseconds.Hakala, et al. Standards Track [Page 70]RFC 4006 Diameter Credit-Control Application August 2005The Validity-Time AVP is also used for the graceful servicetermination (see section 5.6) to indicate to the credit-controlclient how long the subscriber is allowed to use network resourcesafter the specified action (i.e., REDIRECT or RESTRICT_ACCESS)started. When the Validity-Time elapses, a new intermediateinterrogation is sent to the server.8.34. Final-Unit-Indication AVPThe Final-Unit-Indication AVP (AVP Code 430) is of type Grouped andindicates that the Granted-Service-Unit AVP in the Credit-Control-Answer, or in the AA answer, contains the final units for theservice. After these units have expired, the Diameter credit-controlclient is responsible for executing the action indicated in theFinal-Unit-Action AVP (see section 5.6).If more than one unit type is received in the Credit-Control-Answer,the unit type that first expired SHOULD cause the credit-controlclient to execute the specified action.In the first interrogation, the Final-Unit-Indication AVP withFinal-Unit-Action REDIRECT or RESTRICT_ACCESS can also be presentwith no Granted-Service-Unit AVP in the Credit-Control-Answer or inthe AA answer. This indicates to the Diameter credit-control clientto execute the specified action immediately. If the home serviceprovider policy is to terminate the service, naturally, the serverSHOULD return the appropriate transient failure (see section 9.1) inorder to implement the policy-defined action.The Final-Unit-Action AVP defines the behavior of the service elementwhen the user's account cannot cover the cost of the service and MUSTalways be present if the Final-Unit-Indication AVP is included in acommand.If the Final-Unit-Action AVP is set to TERMINATE, no other AVPs MUSTbe present.If the Final-Unit-Action AVP is set to REDIRECT at least theRedirect-Server AVP MUST be present. The Restriction-Filter-Rule AVPor the Filter-Id AVP MAY be present in the Credit-Control-Answermessage if the user is also allowed to access other services that arenot accessible through the address given in the Redirect-Server AVP.If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either theRestriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.Hakala, et al. Standards Track [Page 71]
RFC 4006 Diameter Credit-Control Application August 2005The Filter-Id AVP is defined in [NASREQ]. The Filter-Id AVP can beused to reference an IP filter list installed in the access device bymeans other than the Diameter credit-control application, e.g.,locally configured or configured by another entity.The Final-Unit-Indication AVP is defined as follows (per thegrouped-avp-def of RFC 3588 [DIAMBASE]):Final-Unit-Indication ::= < AVP Header: 430 >{ Final-Unit-Action }*[ Restriction-Filter-Rule ]*[ Filter-Id ][ Redirect-Server ]8.35. Final-Unit-Action AVPThe Final-Unit-Action AVP (AVP Code 449) is of type Enumerated andindicates to the credit-control client the action to be taken whenthe user's account cannot cover the service cost.The Final-Unit-Action can be one of the following:TERMINATE 0The credit-control client MUST terminate the service session.This is the default handling, applicable whenever the credit-control client receives an unsupported Final-Unit-Action value,and it MUST be supported by all the Diameter credit-control clientimplementations conforming to this specification.REDIRECT 1The service element MUST redirect the user to the addressspecified in the Redirect-Server-Address AVP. The redirect actionis defined in section 5.6.2.RESTRICT_ACCESS 2The access device MUST restrict the user access according to theIP packet filters defined in the Restriction-Filter-Rule AVP oraccording to the IP packet filters identified by the Filter-IdAVP. All the packets not matching the filters MUST be dropped(see section 5.6.3).8.36. Restriction-Filter-Rule AVPThe Restriction-Filter-Rule AVP (AVP Code 438) is of typeIPFilterRule and provides filter rules corresponding to services thatare to remain accessible even if there are no more service unitsgranted. The access device has to configure the specified filterHakala, et al. Standards Track [Page 72] RFC 4006 Diameter Credit-Control Application August 2005rules for the subscriber and MUST drop all the packets not matchingthese filters. Zero, one, or more such AVPs MAY be present in aCredit-Control-Answer message or in an AA answer message.8.37. Redirect-Server AVPThe Redirect-Server AVP (AVP Code 434) is of type Grouped andcontains the address information of the redirect server (e.g., HTTPredirect server, SIP Server) with which the end user is to beconnected when the account cannot cover the service cost. It MUST bepresent when the Final-Unit-Action AVP is set to REDIRECT.It is defined as follows (per the grouped-avp-def of RFC 3588[DIAMBASE]):Redirect-Server ::= < AVP Header: 434 >{ Redirect-Address-Type }{ Redirect-Server-Address }8.38. Redirect-Address-Type AVPThe Redirect-Address-Type AVP (AVP Code 433) is of type Enumeratedand defines the address type of the address given in the Redirect-Server-Address AVP.The address type can be one of the following:IPv4 Address 0The address type is in the form of "dotted-decimal" IPv4 address,as defined in [IPv4].IPv6 Address 1The address type is in the form of IPv6 address, as defined in[IPv6Addr]. The address is a text representation of the addressin either the preferred or alternate text form [IPv6Addr].Conformant implementations MUST support the preferred form andSHOULD support the alternate text form for IPv6 addresses.URL 2The address type is in the form of Uniform Resource Locator, asdefined in [URL].SIP URI 3The address type is in the form of SIP Uniform ResourceIdentifier, as defined in [SIP].Hakala, et al. Standards Track [Page 73]RFC 4006 Diameter Credit-Control Application August 20058.39. Redirect-Server-Address AVPThe Redirect-Server-Address AVP (AVP Code 435) is of type UTF8Stringand defines the address of the redirect server (e.g., HTTP redirectserver, SIP Server) with which the end user is to be connected whenthe account cannot cover the service cost.8.40. Multiple-Services-Indicator AVPThe Multiple-Services-Indicator AVP (AVP Code 455) is of typeEnumerated and indicates whether the Diameter credit-control clientis capable of handling multiple services independently within a(sub-) session. The absence of this AVP means that independentcredit-control of multiple services is not supported.A server not implementing the independent credit-control of multipleservices MUST treat the Multiple-Services-Indicator AVP as an invalidAVP.The following values are defined for the Multiple-Services-IndicatorAVP:MULTIPLE_SERVICES_NOT_SUPPORTED 0Client does not support independent credit-control of multipleservices within a (sub-)session.MULTIPLE_SERVICES_SUPPORTED 1Client supports independent credit-control of multiple serviceswithin a (sub-)session.8.41. Requested-Action AVPThe Requested-Action AVP (AVP Code 436) is of type Enumerated andcontains the requested action being sent by Credit-Control-Requestcommand where the CC-Request-Type is set to EVENT_REQUEST. Thefollowing values are defined for the Requested-Action AVP:DIRECT_DEBITING 0This indicates a request to decrease the end user's accountaccording to information specified in the Requested-Service-UnitAVP and/or Service-Identifier AVP (additional rating informationmay be included in service-specific AVPs or in the Service-Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-Control-Answer command contains the debited units.Hakala, et al. Standards Track [Page 74]
RFC 4006 Diameter Credit-Control Application August 2005REFUND_ACCOUNT 1This indicates a request to increase the end user's accountaccording to information specified in the Requested-Service-UnitAVP and/or Service-Identifier AVP (additional rating informationmay be included in service-specific AVPs or in the Service-Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-Control-Answer command contains the refunded units.CHECK_BALANCE 2This indicates a balance check request. In this case, thechecking of the account balance is done without any creditreservation from the account. The Check-Balance-Result AVP in theCredit-Control-Answer command contains the result of the balancecheck.PRICE_ENQUIRY 3This indicates a price enquiry request. In this case, neitherchecking of the account balance nor reservation from the accountwill be done; only the price of the service will be returned inthe Cost-Information AVP in the Credit-Control-Answer Command.8.42. Service-Context-Id AVPThe Service-Context-Id AVP is of type UTF8String (AVP Code 461) andcontains a unique identifier of the Diameter credit-control servicespecific document that applies to the request (as defined in section4.1.2). This is an identifier allocated by the service provider, bythe service element manufacturer, or by a standardization body, andMUST uniquely identify a given Diameter credit-control servicespecific document. The format of the Service-Context-Id is:"service-context" "@" "domain"service-context = TokenThe Token is an arbitrary string of characters and digits.'domain' represents the entity that allocated the Service-Context-Id.It can be ietf.org, 3gpp.org, etc., if the identifier is allocated bya standardization body, or it can be the FQDN of the service provider(e.g., provider.example.com) or of the vendor (e.g.,vendor.example.com) if the identifier is allocated by a privateentity.This AVP SHOULD be placed as close to the Diameter header aspossible.Hakala, et al. Standards Track [Page 75]
RFC 4006 Diameter Credit-Control Application August 2005Service-specific documents that are for private use only (i.e., toone provider's own use, where no interoperability is deemed useful)may define private identifiers without need of coordination.However, when interoperability is wanted, coordination of theidentifiers via, for example, publication of an informational RFC isRECOMMENDED in order to make Service-Context-Id globally available.8.43. Service-Parameter-Info AVPThe Service-Parameter-Info AVP (AVP Code 440) is of type Grouped andcontains service-specific information used for price calculation orrating. The Service-Parameter-Type AVP defines the service parametertype, and the Service-Parameter-Value AVP contains the parametervalue. The actual contents of these AVPs are not within the scope ofthis document and SHOULD be defined in another Diameter application,in standards written by other standardization bodies, or in service-specific documentation.In the case of an unknown service request (e.g., unknown Service-Parameter-Type), the corresponding answer message MUST contain theerror code DIAMETER_RATING_FAILED. A Credit-Control-Answer messagewith this error MUST contain one or more Failed-AVP AVPs containingthe Service-Parameter-Info AVPs that caused the failure.It is defined as follows (per the grouped-avp-def of RFC 3588[DIAMBASE]):Service-Parameter-Info ::= < AVP Header: 440 >{ Service-Parameter-Type }{ Service-Parameter-Value }8.44. Service-Parameter-Type AVPThe Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441)and defines the type of the service event specific parameter (e.g.,it can be the end-user location or service name). The differentparameters and their types are service specific, and the meanings ofthese parameters are not defined in this document. Whoever allocatesthe Service-Context-Id (i.e., unique identifier of a service-specificdocument) is also responsible for assigning Service-Parameter-Typevalues for the service and ensuring their uniqueness within the givenservice. The Service-Parameter-Value AVP contains the valueassociated with the service parameter type.Hakala, et al. Standards Track [Page 76] RFC 4006 Diameter Credit-Control Application August 20058.45. Service-Parameter-Value AVPThe Service-Parameter-Value AVP is of type OctetString (AVP Code 442)and contains the value of the service parameter type.8.46. Subscription-Id AVPThe Subscription-Id AVP (AVP Code 443) is used to identify the enduser's subscription and is of type Grouped. The Subscription-Id AVPincludes a Subscription-Id-Data AVP that holds the identifier and aSubscription-Id-Type AVP that defines the identifier type.It is defined as follows (per the grouped-avp-def of RFC 3588[DIAMBASE]):Subscription-Id ::= < AVP Header: 443 >{ Subscription-Id-Type }{ Subscription-Id-Data }8.47. Subscription-Id-Type AVPThe Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated,and it is used to determine which type of identifier is carried bythe Subscription-Id AVP.This specification defines the following subscription identifiers.However, new Subscription-Id-Type values can be assigned by an IANAdesignated expert, as defined in section 12. A server MUST implementall the Subscription-Id-Types required to perform creditauthorization for the services it supports, including possible futurevalues. Unknown or unsupported Subscription-Id-Types MUST be treatedaccording to the 'M' flag rule, as defined in [DIAMBASE].END_USER_E164 0The identifier is in international E.164 format (e.g., MSISDN),according to the ITU-T E.164 numbering plan defined in [E164] and[CE164].END_USER_IMSI 1The identifier is in international IMSI format, according to theITU-T E.212 numbering plan as defined in [E212] and [CE212].END_USER_SIP_URI 2The identifier is in the form of a SIP URI, as defined in [SIP].END_USER_NAI 3The identifier is in the form of a Network Access Identifier, asdefined in [NAI].Hakala, et al. Standards Track [Page 77] RFC 4006 Diameter Credit-Control Application August 2005END_USER_PRIVATE 4The Identifier is a credit-control server private identifier.8.48. Subscription-Id-Data AVPThe Subscription-Id-Data AVP (AVP Code 444) is used to identify theend user and is of type UTF8String. The Subscription-Id-Type AVPdefines which type of identifier is used.8.49. User-Equipment-Info AVPThe User-Equipment-Info AVP (AVP Code 458) is of type Grouped andallows the credit-control client to indicate the identity andcapability of the terminal the subscriber is using for the connectionto network.It is defined as follows (per the grouped-avp-def of RFC 3588[DIAMBASE]):User-Equipment-Info ::= < AVP Header: 458 >{ User-Equipment-Info-Type }{ User-Equipment-Info-Value }8.50. User-Equipment-Info-Type AVPThe User-Equipment-Info-Type AVP is of type Enumerated (AVP Code459) and defines the type of user equipment information contained inthe User-Equipment-Info-Value AVP.This specification defines the following user equipment types.However, new User-Equipment-Info-Type values can be assigned by anIANA designated expert, as defined in section 12.IMEISV 0The identifier contains the International Mobile EquipmentIdentifier and Software Version in the international IMEISV formataccording to 3GPP TS 23.003 [3GPPIMEI].MAC 1The 48-bit MAC address is formatted as described in [RAD802.1X].EUI64 2The 64-bit identifier used to identify hardware instance of theproduct, as defined in [EUI64].Hakala, et al. Standards Track [Page 78]RFC 4006 Diameter Credit-Control Application August 2005MODIFIED_EUI64 3There are a number of types of terminals that have identifiersother than IMEI, IEEE 802 MACs, or EUI-64. These identifiers canbe converted to modified EUI-64 format as described in [IPv6Addr]or by using some other methods referred to in the service-specificdocumentation.8.51. User-Equipment-Info-Value AVPThe User-Equipment-Info-Value AVP (AVP Code 460) is of typeOctetString. The User-Equipment-Info-Type AVP defines which type ofidentifier is used.9. Result Code AVP ValuesThis section defines new Result-Code AVP [DIAMBASE] values that mustbe supported by all Diameter implementations that conform to thisspecification.The Credit-Control-Answer message includes the Result-Code AVP, whichmay indicate that an error was present in the Credit-Control-Requestmessage. A rejected Credit-Control-Request message SHOULD cause theuser's session to be terminated.9.1. Transient FailuresErrors that fall within the transient failures category are used toinform a peer that the request could not be satisfied at the time itwas received, but that the request MAY be able to be satisfied in thefuture.DIAMETER_END_USER_SERVICE_DENIED 4010The credit-control server denies the service request due toservice restrictions. If the CCR contained used-service-units,they are deducted, if possible.DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011The credit-control server determines that the service can begranted to the end user but that no further credit-control isneeded for the service (e.g., service is free of charge).DIAMETER_CREDIT_LIMIT_REACHED 4012The credit-control server denies the service request because theend user's account could not cover the requested service. If theCCR contained used-service-units they are deducted, if possible.Hakala, et al. Standards Track [Page 79]
RFC 4006 Diameter Credit-Control Application August 20059.2. Permanent FailuresErrors that fall within the permanent failure category are used toinform the peer that the request failed and should not be attemptedagain.DIAMETER_USER_UNKNOWN 5030The specified end user is unknown in the credit-control server.DIAMETER_RATING_FAILED 5031This error code is used to inform the credit-control client thatthe credit-control server cannot rate the service request due toinsufficient rating input, an incorrect AVP combination, or an AVPor an AVP value that is not recognized or supported in the rating.The Failed-AVP AVP MUST be included and contain a copy of theentire AVP(s) that could not be processed successfully or anexample of the missing AVP complete with the Vendor-Id ifapplicable. The value field of the missing AVP should be ofcorrect minimum length and contain zeros.10. AVP Occurrence TableThe following table presents the AVPs defined in this document andspecifies in which Diameter messages they MAY or MAY NOT be present.Note that AVPs that can only be present within a Grouped AVP are notrepresented in this table.The table uses the following symbols:0 The AVP MUST NOT be present in the message.0+ Zero or more instances of the AVP MAY be present in themessage.0-1 Zero or one instance of the AVP MAY be present in themessage. It is considered an error if there is morethan one instance of the AVP.1 One instance of the AVP MUST be present in the message.1+ At least one instance of the AVP MUST be present in themessage.Hakala, et al. Standards Track [Page 80]
RFC 4006 Diameter Credit-Control Application August 200510.1. Credit-Control AVP TableThe table in this section is used to represent which credit-controlapplications specific AVPs defined in this document are to be presentin the credit-control messages.+-----------+| Command || Code ||-----+-----+Attribute Name | CCR | CCA |------------------------------|-----+-----+Acct-Multi-Session-Id | 0-1 | 0-1 |Auth-Application-Id | 1 | 1 |CC-Correlation-Id | 0-1 | 0 |CC-Session-Failover | 0 | 0-1 |CC-Request-Number | 1 | 1 |CC-Request-Type | 1 | 1 |CC-Sub-Session-Id | 0-1 | 0-1 |Check-Balance-Result | 0 | 0-1 |Cost-Information | 0 | 0-1 |Credit-Control-Failure- | 0 | 0-1 |Handling | | |Destination-Host | 0-1 | 0 |Destination-Realm | 1 | 0 |Direct-Debiting-Failure- | 0 | 0-1 |Handling | | |Event-Timestamp | 0-1 | 0-1 |Failed-AVP | 0 | 0+ |Final-Unit-Indication | 0 | 0-1 |Granted-Service-Unit | 0 | 0-1 |Multiple-Services-Credit- | 0+ | 0+ |Control | | |Multiple-Services-Indicator | 0-1 | 0 |Origin-Host | 1 | 1 |Origin-Realm | 1 | 1 |Origin-State-Id | 0-1 | 0-1 |Proxy-Info | 0+ | 0+ |Redirect-Host | 0 | 0+ |Redirect-Host-Usage | 0 | 0-1 |Redirect-Max-Cache-Time | 0 | 0-1 |Requested-Action | 0-1 | 0 |Requested-Service-Unit | 0-1 | 0 |Route-Record | 0+ | 0+ |Result-Code | 0 | 1 |Service-Context-Id | 1 | 0 |Service-Identifier | 0-1 | 0 |Service-Parameter-Info | 0+ | 0 |Hakala, et al. Standards Track [Page 81]
RFC 4006 Diameter Credit-Control Application August 2005Session-Id | 1 | 1 |Subscription-Id | 0+ | 0 |Termination-Cause | 0-1 | 0 |User-Equipment-Info | 0-1 | 0 |Used-Service-Unit | 0+ | 0 |User-Name | 0-1 | 0-1 |Validity-Time | 0 | 0-1 |------------------------------|-----+-----+10.2. Re-Auth-Request/Answer AVP TableThis section defines AVPs that are specific to the Diameter credit-control application and that MAY be included in the Diameter Re-Auth-Request/Answer (RAR/RAA) message [DIAMBASE].Re-Auth-Request/Answer command MAY include the following additionalAVPs:+---------------+| Command Code ||-------+-------+Attribute Name | RAR | RAA |------------------------------+-------+-------+CC-Sub-Session-Id | 0-1 | 0-1 |G-S-U-Pool-Identifier | 0-1 | 0-1 |Service-Identifier | 0-1 | 0-1 |Rating-Group | 0-1 | 0-1 |------------------------------+-------+-------+11. RADIUS/Diameter Credit-Control Interworking ModelThis section defines the basic principles for the Diameter credit-control/RADIUS prepaid inter-working model; that is, a messagetranslation between a RADIUS based prepaid solution and a Diametercredit-control application. A complete description of the protocoltranslations between RADIUS and the Diameter credit-controlapplication is beyond the scope of this specification and SHOULD beaddressed in another appropriate document, such as the RADIUS prepaidspecification.The Diameter credit-control architecture may have a Translation Agentcapable of translation between RADIUS prepaid and Diameter credit-control protocols. An AAA server (usually the home AAA server) mayact as a Translation Agent and as a Diameter credit-control clientfor service elements that use credit-control mechanisms other thanDiameter credit control for instance, RADIUS prepaid. In this case,the home AAA server contacts the Diameter credit-control server aspart of the authorization process. The interworking architecture isHakala, et al. Standards Track [Page 82]
RFC 4006 Diameter Credit-Control Application August 2005illustrated in Figure 7, and interworking flow in Figure 8. In aroaming situation the service element (e.g., the NAS) may be locatedin the visited network, and a visited AAA server is usuallycontacted. The visited AAA server connects then to the home AAAserver.RADIUS Prepaid+--------+ +---------+ protocol +------------+ +--------+| End |<----->| Service |<---------->| Home AAA | |Business|| User | | Element | | Server | |Support |+--------+ +-->| | |+----------+|->|System || +---------+ ||CC Client || | || |+----------+| | |+--------+ | +------^-----+ +----^---+| End |<--+ Credit-Control | || User | Protocol | |+--------+ +-------V--------+ ||Credit-Control |----+| Server |+----------------+Figure 7: Credit-control architecture with service elementcontaining translation agent, translating RADIUSprepaid to Diameter credit-control protocolWhen the AAA server acting as a Translation Agent receives an initialRADIUS Access-Request message from service element (e.g., NASaccess), it performs regular authentication and authorization. Ifthe RADIUS Access-Request message indicates that the service elementis capable of credit-control, and if the home AAA server finds thatthe subscriber is a prepaid subscriber, then a Diameter credit-control request SHOULD be sent toward the credit-control server toperform credit authorization and to establish a credit-controlsession. After the Diameter credit-control server checks the enduser's account balance, rates the service, and reserves credit fromthe end user's account, the reserved quota is returned to the homeAAA server in the Diameter Credit-Control-Answer. Then the home AAAserver sends the reserved quota to the service element in the RADIUSAccess-Accept.At the expiry of the allocated quota, the service element sends a newRADIUS Access-Request containing the units used this far to the homeAAA server. The home AAA server shall map a RADIUS Access-Requestcontaining the reported units to the Diameter credit-control serverin a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diametercredit-control server debits the used units from the end user'saccount and allocates a new quota that is returned to the home AAAserver in the Diameter Credit-Control-Answer. The quota isHakala, et al. Standards Track [Page 83]
RFC 4006 Diameter Credit-Control Application August 2005transferred to the service element in the RADIUS Access-Accept. Whenthe end user terminates the service, or when the entire quota hasbeen used, the service element sends a RADIUS Access-Request. Todebit the used units from the end user's account and to stop thecredit-control session, the home AAA server sends a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server.The Diameter credit-control server acknowledges the sessiontermination by sending a Diameter Credit-Control-Answer to the homeAAA server. The RADIUS Access-Accept is sent to the NAS.Hakala, et al. Standards Track [Page 84]
RFC 4006 Diameter Credit-Control Application August 2005A following diagram illustrates a RADIUS prepaid - Diameter credit-control interworking sequence.Service Element Translation Agent(e.g., NAS) (CC Client) CC Server| Access-Request | ||----------------------->| || | CCR (initial) || |----------------------->|| | CCA (Granted-Units) || |<-----------------------|| Access-Accept | || (Granted-Units) | ||<-----------------------| |: : :| Access-Request | || (Used-Units) | ||----------------------->| || | CCR (update, || | Used-Units) || |----------------------->|| | CCA (Granted-Units) || |<-----------------------|| Access-Accept | || (Granted-Units) | ||<-----------------------| |: : :| Access-Request | ||----------------------->| || | CCR (terminate, || | Used-Units) || |----------------------->|| | CCA || |<-----------------------|| Access-Accept | ||<-----------------------| || | |Figure 8: Message flow example with RADIUS prepaid -Diameter credit-control interworking12. IANA ConsiderationsThis section contains the namespaces that have either been created inthis specification, or the values assigned to existing namespacesmanaged by IANA.Hakala, et al. Standards Track [Page 85]
RFC 4006 Diameter Credit-Control Application August 2005In the subsections below, when we speak about review by a DesignatedExpert, please note that the designated expert will be assigned bythe IESG. Initially, such Expert discussions take place on the AAAWG mailing list.12.1. Application IdentifierThis specification assigns the value 4, 'Diameter Credit Control', tothe Application Identifier namespace defined in [DIAMBASE]. Seesection 1.3 for more information.12.2. Command CodesThis specification uses the value 272 from the Command code namespacedefined in [DIAMBASE] for the Credit-Control-Request (CCR) andCredit-Control-Answer (CCA) commands.12.3. AVP CodesThis specification assigns the values 411 - 461 from the AVP codenamespace defined in [DIAMBASE]. See section 8 for the assignment ofthe namespace in this specification.12.4. Result-Code AVP ValuesThis specification assigns the values 4010, 4011, 4012, 5030, 5031from the Result-Code AVP value namespace defined in [DIAMBASE]. Seesection 9 for the assignment of the namespace in this specification.12.5. CC-Request-Type AVPAs defined in section 8.3, the CC-Request-Type AVP includesEnumerated type values 1 - 4. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.6. CC-Session-Failover AVPAs defined in section 8.4, the CC-Failover-Supported AVP includesEnumerated type values 0 - 1. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].Hakala, et al. Standards Track [Page 86]
RFC 4006 Diameter Credit-Control Application August 200512.7. CC-Unit-Type AVPAs defined in section 8.32, the CC-Unit-Type AVP includes Enumeratedtype values 0 - 5. IANA has created and is maintaining a namespacefor this AVP. All remaining values are available for assignment by aDesignated Expert [IANA].12.8. Check-Balance-Result AVPAs defined in section 8.6, the Check-Balance-Result AVP includesEnumerated type values 0 - 1. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.9. Credit-Control AVPAs defined in section 8.13, the Credit-Control AVP includesEnumerated type values 0 - 1. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.10. Credit-Control-Failure-Handling AVPAs defined in section 8.14, the Credit-Control-Failure-Handling AVPincludes Enumerated type values 0 - 2. IANA has created and ismaintaining a namespace for this AVP. All remaining values areavailable for assignment by a Designated Expert [IANA].12.11. Direct-Debiting-Failure-Handling AVPAs defined in section 8.15, the Direct-Debiting-Failure-Handling AVPincludes Enumerated type values 0 - 1. IANA has created and ismaintaining a namespace for this AVP. All remaining values areavailable for assignment by a Designated Expert [IANA].12.12. Final-Unit-Action AVPAs defined in section 8.35, the Final-Unit-Action AVP includesEnumerated type values 0 - 2. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.13. Multiple-Services-Indicator AVPAs defined in section 8.40, the Multiple-Services-Indicator AVPincludes Enumerated type values 0 - 1. IANA has created and ismaintaining a namespace for this AVP. All remaining values areavailable for assignment by a Designated Expert [IANA].Hakala, et al. Standards Track [Page 87]
RFC 4006 Diameter Credit-Control Application August 200512.14. Redirect-Address-Type AVPAs defined in section 8.38, the Redirect-Address-Type AVP includesEnumerated type values 0 - 3. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.15. Requested-Action AVPAs defined in section 8.41, the Requested-Action AVP includesEnumerated type values 0 - 3. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.16. Subscription-Id-Type AVPAs defined in section 8.47, the Subscription-Id-Type AVP includesEnumerated type values 0 - 4. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.17. Tariff-Change-Usage AVPAs defined in section 8.27, the Tariff-Change-Usage AVP includesEnumerated type values 0 - 2. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].12.18. User-Equipment-Info-Type AVPAs defined in section 8.50, the User-Equipment-Info-Type AVP includesEnumerated type values 0 - 3. IANA has created and is maintaining anamespace for this AVP. All remaining values are available forassignment by a Designated Expert [IANA].13. Credit-Control Application Related ParametersTx timerWhen real-time credit-control is required, the credit-controlclient contacts the credit-control server before and while theservice is provided to an end user. Due to the real-time natureof the application, the communication delays SHOULD be minimized;e.g., to avoid an overly long service setup time experienced bythe end user. The Tx timer is introduced to control the waitingtime in the client in the Pending state. When the Tx timerelapses, the credit-control client takes an action to the end useraccording to the value of the Credit-Control-Failure-Handling AVPHakala, et al. Standards Track [Page 88]
RFC 4006 Diameter Credit-Control Application August 2005or Direct-Debiting-Failure-Handling AVP. The recommended value is10 seconds.Tcc timerThe Tcc timer supervises an ongoing credit-control session in thecredit-control server. It is RECOMMENDED to use the Validity-Timeas input to set the Tcc timer value. In case of transientfailures in the network, the Diameter credit-control server mightchange to Idle state. To avoid this, the Tcc timer MAY be set sothat Tcc equals to 2 x Validity-Time.Credit-Control-Failure-Handling and Direct-Debiting-Failure-HandlingClient implementations may offer the possibility of locallyconfiguring these AVPs. In such a case their value and behavioris defined in section 5.7 for the Credit-Control-Failure-Handlingand in section 6.5 for the Direct-Debiting-Failure-Handling.14. Security ConsiderationsThe Diameter base protocol [DIAMBASE] requires that each Diameterimplementation use underlying security; i.e., IPsec or TLS. Thesemechanisms are believed to provide sufficient protection under thenormal Internet threat model; that is, assuming that the authorizednodes engaging in the protocol have not been compromised, but thatthe attacker has complete control over the communication channelsbetween them. This includes eavesdropping, message modification,insertion, and man-in-the-middle and replay attacks. Note also thatthis application includes a mechanism for application layer replayprotection by means of the Session-Id from [DIAMBASE] and CC-Request-Number, which is specified in this document. The Diametercredit-control application is often used within one domain, and theremay be a single hop between the peers. In these environments, theuse of TLS or IPsec is sufficient. The details of TLS and IPsecrelated security considerations are discussed in the [DIAMBASE].Because this application handles monetary transactions (directly orindirectly), it increases the interest for various security attacks.Therefore, all parties communicating with each other MUST beauthenticated, including, for instance, TLS client-sideauthentication. In addition, authorization of the client SHOULD beemphasized; i.e., that the client is allowed to perform credit-control for a certain user. The specific means of authorization areoutside of the scope of this specification but can be, for instance,manual configuration.Hakala, et al. Standards Track [Page 89]
RFC 4006 Diameter Credit-Control Application August 2005Another kind of threat is malicious modification, injection, ordeletion of AVPs or complete credit-control messages. The credit-control messages contain sensitive billing related information (suchas subscription Id, granted units, used units, cost information)whose malicious modification can have financial consequences.Sometimes simply delaying the credit-control messages can causedisturbances in the credit-control client or server.Even without any modification to the messages, an adversary caninvite a security threat by eavesdropping, as the transactionscontain private information about the user. Also, by monitoring thecredit-control messages one can collect information about thecredit-control server's billing models and business relationships.When third-party relays or proxy are involved, the hop-by-hopsecurity does not necessarily provide sufficient protection forDiameter user session. In some cases, it may be inappropriate tosend Diameter messages, such as CCR and CCA, containing sensitiveAVPs via untrusted Diameter proxy agents, as there are no assurancesthat third-party proxies will not modify the credit-control commandsor AVP values.14.1. Direct Connection with RedirectsA Diameter credit-control agent cannot always know whether agentsbetween it and the end user's Diameter credit-control server arereliable. In this case, the Diameter credit-control agent doesn'thave a routing entry in its Diameter Routing Table (defined in[DIAMBASE], section 2.7) for the realm of the credit-control serverin the end user's home domain. The Diameter credit-control agent canhave a default route configured to a local Redirect agent, and itredirects the CCR message to the redirect agent. The local Redirectagent then returns a redirect notification (Result-code 3006,DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well asDiameter credit-control server(s) information (Redirect-Host AVP) andinformation (Redirect-Host-Usage AVP) about how the routing entryresulting from the Redirect-Host is to be used. The Diametercredit-control agent then forwards the CCR message directly to one ofthe hosts identified by the CCA message from the redirect agent. Ifthe value of the Redirect-Host-Usage AVP is unequal to zero, allfollowing messages are sent to the host specified in the Redirect-Host AVP until the time specified by the Redirect-Max-Cache-Time AVPis expired.There are some authorization issues even with redirects. There maybe attacks toward nodes that have been properly authorized, but thatabuse their authorization or have been compromised. These issues arediscussed more widely in [DIAMEAP], section 8.Hakala, et al. Standards Track [Page 90]
RFC 4006 Diameter Credit-Control Application August 200515. References15.1. Normative References[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.Arkko, "Diameter Base Protocol", RFC 3588, September2003.[3GPPCHARG] 3rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects, Serviceaspects; Charging and Billing, (release 5), 3GPP TS22.115 v. 5.2.1, 2002-03.[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,A., Peterson, J., Sparks, R., Handley, M., and E.Schooler, "SIP: Session Initiation Protocol", RFC 3261,June 2002.[NAI] Aboba, B. and M. Beadles, "The Network AccessIdentifier", RFC 2486, January 1999.[E164] Recommendation E.164/I.331 (05/97): The InternationalPublic Telecommunication Numbering Plan. 1997.[CE164] Complement to ITU-T Recommendation E.164 (05/1997):"Listof ITU-T Recommendation E.164 assigned country codes",June 2000.[E212] Recommendation E.212 (11/98): The internationalidentification plan for mobile terminals and mobileusers. 1998.[CE212] Complement to ITU-T Recommendation E.212 (11/1997):" Listof mobile country or geographical area codes", February1999.[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 2434,October 1998.[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,September 1981.[IPv6Addr] Hinden, R. and S. Deering, "Internet Protocol Version 6(IPv6) Addressing Architecture", RFC 3513, April 2003.[KEYWORDS] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.Hakala, et al. Standards Track [Page 91]
RFC 4006 Diameter Credit-Control Application August 2005[ISO4217] Codes for the representation of currencies and funds,International Standard ISO 4217,2001[NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,"Diameter Network Access Server Application", RFC 4005,August 2005.[AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization andAccounting (AAA) Transport Profile", RFC 3539, June 2003.[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "UniformResource Locators (URL)", RFC 1738, December 1994.[RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.Roese, "IEEE 802.1X Remote Authentication Dial In UserService (RADIUS) Usage Guidelines", RFC 3580, September2003.[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)Registration Authority",http://standards.ieee.org/regauth/oui/tutorials/EUI64.html March 1997.[3GPPIMEI] 3rd Generation Partnership Project; TechnicalSpecification Group Core Network, Numbering, addressingand identification, (release 5), 3GPP TS 23.003 v. 5.8.0,2003-1215.2. Informative References[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.[DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., andP. McCann, "Diameter Mobile IPv4 Application", RFC 4004,August 2005.[DIAMEAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter ExtensibleAuthentication Protocol (EAP) Application", Work inProgress.[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.Camarillo, "Best Current Practices for Third Party CallControl (3pcc) in the Session Initiation Protocol (SIP)",BCP 85, RFC 3725, April 2004.Hakala, et al. Standards Track [Page 92]
RFC 4006 Diameter Credit-Control Application August 200516. AcknowledgementsThe authors would like to thank Bernard Aboba, Jari Arkko, RobertEkblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior,Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe,Christopher Richards, Juha Vallinen, and Mark Watson for theircomments and suggestions.Hakala, et al. Standards Track [Page 93]
RFC 4006 Diameter Credit-Control Application August 2005Appendix A. Credit-Control SequencesA.1. Flow INASEnd User (CC Client) AAA Server CC Server|(1)User Logon |(2)AA Request (CC AVPs) ||------------------>|------------------->| || | |(3)CCR(initial, CC AVPs)| | |------------------->|| | | (4)CCA(Granted-Units)| | |<-------------------|| |(5)AA Answer(Granted-Units) ||(6)Access granted |<-------------------| ||<----------------->| | || | | |: : : :| |(7)CCR(update,Used-Units) || |------------------->|(8)CCR || | | (update,Used-Units)| | |------------------->|| | |(9)CCA(Granted-Units)| |(10)CCA(Granted-Units)<------------------|| |<-------------------| |: : : :| (Auth. lifetime expires) | || |(11) AAR (CC AVP) | || |------------------->| || | (12) AAA | || |<-------------------| |: : : :: : : :|(13) User logoff | | ||------------------>|(14)CCR(term.,Used-Units) || |------------------->|(15)CCR || | | (term.,Used-Units)| | |------------------->|| | | (16)CCA || | (17)CCA |<-------------------|| |<-------------------| || |(18)STR | || |------------------->| || | (19)STA | || |<-------------------| |Figure A.1: Flow IHakala, et al. Standards Track [Page 94]
RFC 4006 Diameter Credit-Control Application August 2005A credit-control flow for Network Access Services prepaid is shown inFigure A.1. The Diameter [NASREQ] is implemented in the NetworkAccess Server (NAS). The focus of this flow is in the creditauthorization.The user logs on to the network (1). The Diameter NAS sends aDiameter AA-Request (AAR) to the home Diameter AAA server. Thecredit-control client populates the AAR with the Credit-Control AVPset to CREDIT_AUTHORIZATION, and service-specific AVPs are included,as usual [NASREQ]. The home Diameter AAA server performs service-specific Authentication and Authorization, as usual. The homeDiameter AAA server determines that the user is a prepaid user andnotices from the Credit-Control AVP that the NAS has credit-controlcapabilities. It sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-controlserver to perform credit authorization (3) and to establish acredit-control session. (The home Diameter AAA server may forwardservice-specific AVPs received from the NAS as input for the ratingprocess.) The Diameter credit-control server checks the end user'saccount balance, rates the service, and reserves credit from the enduser's account. The reserved quota is returned to the home DiameterAAA server in the Diameter Credit-Control-Answer (4). The homeDiameter AAA server sends the reserved quota to the NAS in theDiameter AA-Answer (AAA). Upon successful AAA, the NAS starts thecredit-control session and starts monitoring the granted units (5).The NAS grants access to the end user (6). At the expiry of theallocated quota, the NAS sends a Diameter Credit-Control-Request withCC-Request-Type set to UPDATE_REQUEST to the Home Diameter AAA server(7). This message contains the units used thus far. The homeDiameter AAA server forwards the CCR to the Diameter credit-controlserver (8). The Diameter credit-control server debits the used unitsfrom the end user's account and allocates a new quota that isreturned to the home Diameter AAA server in the Diameter Credit-Control-Answer (9). The message is forwarded to the NAS (10).During the ongoing credit-control session, the authorization lifetimeexpires, and the authorization/authentication client in the NASperforms service specific re-authorization to the home Diameter AAAserver, as usual. The credit-control client populates the AAR withthe Credit-Control AVP set to RE_AUTHORIZATION, indicating that thecredit-control server shall not be contacted, as the creditauthorization is controlled by the burning rate of the granted units(11). The home Diameter AAA server performs service-specific re-authorization as usual and returns the AA-Answer to the NAS (12).The end user logs off from the network (13). To debit the used unitsfrom the end user's account and to stop the credit-control session,the NAS sends a Diameter Credit-Control-Request with CC-Request-Typeset to TERMINATION_REQUEST to the home Diameter AAA server (14). Thehome Diameter AAA server forwards the CCR to the credit-controlHakala, et al. Standards Track [Page 95]
RFC 4006 Diameter Credit-Control Application August 2005server (15). The Diameter credit-control server acknowledges thesession termination by sending a Diameter Credit-Control-Answer tothe home Diameter AAA server (16). The home Diameter AAA serverforwards the answer to the NAS (17). STR/STA takes place between theNAS and home Diameter AAA server, as usual (18-19).A.2. Flow IISIP Proxy/Registrar AAAA (CC Client) Server B CC Server|(i) REGISTER | | | ||------------->|(ii) | | || |------------->| | || |authentication & | || |authorization | | || |<-------------| | ||(iii)200 OK | | ||<-------------| | |: : : :|(1) INVITE | :|------------->|| |(2) CCR (Initial, SIP specific AVP) || |------------------------------------------->|| |(3) CCA (Granted-Units) || |<-------------------------------------------|| |(4) INVITE | || |---------------------------->| |: : : :| |(5) CCR (update, Used-Units) || |------------------------------------------->|| |(6) CCA (Granted-Units) || |<-------------------------------------------|: : : :|(7) BYE | | ||------------->| | || |(8) BYE | || |---------------------------->| || |(9) CCR (termination, Used-Units) || |------------------------------------------->|| |(10) CCA () || |<-------------------------------------------|| | | |Figure A.2: Flow IIHakala, et al. Standards Track [Page 96]
RFC 4006 Diameter Credit-Control Application August 2005This is an example of Diameter credit-control for SIP sessions.Although the flow focuses on illustrating the usage of credit-controlmessages, the SIP signaling is inaccurate, and the diagram is not byany means an attempt to define a service provider's SIP network.However, for the sake of this example, some assumptions are madebelow.Typically, prepaid services based, for example, on time usage for SIPsession require an entity in the service provider network tointercept all the requests within the SIP dialog in order to detectevents, such as session establishment and session release, that areessential to perform credit-control operations with the credit-control server. Therefore, in this example, it is assumed that theSIP Proxy adds a Record-Route header in the initial SIP INVITE tomake sure that all the future requests in the created dialog traversethrough it (for the definitions of 'Record-Route' and 'dialog' pleaserefer to [SIP]). Finally, the degree of credit-control measuring ofthe media by the proxy depends on the business model design used insetting up the end system and proxies in the SIP network.The end user (SIP User Agent A) sends REGISTER with credentials (i).The SIP Proxy sends a request to the home AAA server to performMultimedia authentication and authorization by using, for instance,Diameter Multimedia application (ii). The home AAA server checksthat the credentials are correct and checks the user profile.Eventually, 200 OK response (iii) is sent to the UA. Note that theAuthentication and Authorization is valid for the registrationvalidity period duration (i.e., until re-registration is performed).Several SIP sessions may be established without re-authorization.UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit-Control-Request (INITIAL_REQUEST) to the Diameter credit-controlserver (2). The Credit-Control-Request contains information obtainedfrom the SIP signaling describing the requested service (e.g.,calling party, called party, Session Description Protocolattributes). The Diameter credit-control server checks the enduser's account balance, rates the service, and reserves credit fromthe end user's account. The reserved quota is returned to the SIPProxy in the Diameter Credit-Control-Answer (3). The SIP Proxyforwards the SIP INVITE to UA B (4). B's phone rings, and B answers.The media flows between them, and the SIP Proxy starts measuring thequota. At the expiry of the allocated quota, the SIP Proxy sends aDiameter Credit-Control-Request (UPDATE_REQUEST) to the Diametercredit-control server (5). This message contains the units used thusfar. The Diameter credit-control server debits the used units fromthe end user's account and allocates new credit that is returned tothe SIP Proxy in the Diameter Credit-Control-Answer (6). The enduser terminates the service by sending a BYE (7). The SIP ProxyHakala, et al. Standards Track [Page 97]
RFC 4006 Diameter Credit-Control Application August 2005forwards the BYE message to UA B (8) and sends a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server(9). The Diameter credit-control server acknowledges the sessiontermination by sending a Diameter Credit-Control-Answer to the SIPProxy (10).A.3. Flow IIIMMS ServerA (CC Client) B CC Server|(1) Send MMS | | ||--------------->| | || |(2) CCR (event, DIRECT_DEBITING,|| | MMS specific AVP) || |-------------------------------->|| |(3) CCA (Granted-Units) || |<--------------------------------||(4) Send MMS Ack| | ||<---------------| | || |(5) Notify MMS | || |--------------->| |: : : :| |(6) Retrieve MMS| || |<---------------| || |(7) Retrieve MMS| || | Ack | || |--------------->| || | | |Figure A.3: Flow IIIA credit-control flow for Multimedia Messaging Services is shown inFigure A.3. The sender is charged as soon as the messaging serversuccessfully stores the message.The end user A sends a Multimedia Message (MMS) to the MMS server(1). The MMS server stores the message and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING)to the Diameter credit-control server (2). The Credit-Control-Request contains information about the MMS message (e.g., size,recipient address, image coding type). The Diameter credit-controlserver checks the end user's account balance, rates the service, anddebits the service from the end user's account. The granted quota isreturned to the MMS server in the Diameter Credit-Control-Answer (3).The MMS server acknowledges the successful reception of the MMSmessage (4). The MMS Server notifies the recipient about the new MMS(5), and end user B retrieves the message from the MMS message store(6),(7).Hakala, et al. Standards Track [Page 98]
RFC 4006 Diameter Credit-Control Application August 2005A.4. Flow IVMMS ServerContent Server (CC Client) B CC Server|(1) Send MMS | | ||--------------->| | || |(2) CCR (event, CHECK_BALANCE, || | MMS specific AVP) || |-------------------------------->|| |(3) CCA (ENOUGH_CREDIT) || |<--------------------------------||(4) Send MMS Ack| | ||<---------------| | || |(5) Notify MMS | || |--------------->| |: : : :| |(6) Retrieve MMS| || |<---------------| || |(7) CCR (event, DIRECT_DEBITING,|| | MMS specific AVP) || |-------------------------------->|| |(8) CCA (Granted-Units) || |<--------------------------------|| |(9) Retrieve MMS| || | Ack | || |--------------->| || | | |Figure A.4: Flow IVThis is an example of Diameter credit-control for direct debitingusing the Multimedia Messaging Service environment. Although theflow focuses on illustrating the usage of credit-control messages,the MMS signaling is inaccurate, and the diagram is not by any meansan attempt to define any service provider's MMS configuration orbilling model.A credit-control flow for Multimedia Messaging Service is shown inFigure A.4. The recipient is charged at the message delivery.A content server sends a Multimedia Message (MMS) to the MMS server(1) that stores the message. The message recipient will be chargedfor the MMS message in this case. As there can be a substantiallylong time between the receipt of the message at the MMS server andthe actual retrieval of the message, the MMS server does notestablish any credit-control session to the Diameter credit-controlserver but performs first only a balance check (without any creditreservation) by sending a Diameter Credit-Control-RequestHakala, et al. Standards Track [Page 99]
RFC 4006 Diameter Credit-Control Application August 2005(EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify thatend user B can cover the cost for the MMS (2). The Diameter credit-control server checks the end user's account balance and returns theanswer to the MMS server in the Diameter Credit-Control-Answer (3).The MMS server acknowledges the successful reception of the MMSmessage (4). The MMS server notifies the recipient of the new MMS(5), and after some time end user B retrieves the message from theMMS message store (6). The MMS server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action:DIRECT_DEBITING) to the Diameter credit-control server (7). TheCredit-Control-Request contains information about the MMS message(e.g., size, recipient address, coding type). The Diameter credit-control server checks the end user's account balance, rates theservice, and debits the service from the end user's account. Thegranted quota is returned to the MMS server in the Diameter Credit-Control-Request (8). The MMS is transferred to end user B (9).Note that the transfer of the MMS message can take an extended timeand can fail, in which case a recovery action is needed. The MMSserver should return the already debited units to the user's accountby using the REFUND action described in section 6.4.A.5. Flow VSIP ControllerA (CC Client) B CC Server|(1)INVITE B(SDP)| | ||--------------->| | || |(2) CCR (event, PRICE_ENQUIRY, || | SIP specific AVPs) || |-------------------------------->|| |(3) CCA (Cost-Information) || |<--------------------------------|| (4)MESSAGE(URL)| | ||<---------------| | ||(5)HTTP GET | | ||--------------->| | ||(6)HTTP POST | | ||--------------->|(7)INVITE(SDP) | || |--------------->| || | (8)200 OK | || (9)200 OK |<---------------| ||<---------------| | |Figure A.5: Flow VHakala, et al. Standards Track [Page 100]
RFC 4006 Diameter Credit-Control Application August 2005This is an example of Diameter credit-control for SIP sessions.Although the flow focuses on illustrating the usage of credit-controlmessages, the SIP signaling is inaccurate, and the diagram is not byany means an attempt to define a service provider's SIP network.Figure A.5 is an example of Advice of Charge (AoC) service for SIPcall. User A can be either a postpaid or prepaid subscriber usingthe AoC service. It is assumed that the SIP controller also has HTTPcapabilities and delivers an interactive AoC web page with, forinstance, the cost information, the details of the call derived fromthe SDP, and a button to accept/not accept the charges. (There maybe many other ways to deliver AoC information; however, this flowfocuses on the use of the credit-control messages.) The user hasbeen authenticated and authorized prior to initiating the call andsubscribed to AoC service.UA A sends an INVITE with SDP to B (1). The SIP controllerdetermines that the user is subscribed to AoC service and sends aDiameter Credit-Control-Request (EVENT_REQUEST with Requested-Action:PRICE_ENQUIRY) to the Diameter credit-control server (2). TheCredit-Control-Request contains SIP specific AVPs derived from theSIP signaling, describing the requested service (e.g., calling party,called party, Session Description Protocol attributes). The Diametercredit-control server determines the cost of the service and returnsthe Credit-Control-Answer including the Cost-Information AVP (3).The SIP controller manufactures the AoC web page with informationreceived in SIP signaling and with the cost information received fromthe credit-control server. Then it sends a SIP MESSAGE that containsa URL pointing to the AoC information web page (4). At the receiptof the SIP MESSAGE, A's UA automatically invokes the web browser thatretrieves the AoC information (5). The user clicks on a properbutton and accepts the charges (6). The SIP controller continues thesession and sends the INVITE to the B party, which accepts the call(7,8,9).Hakala, et al. Standards Track [Page 101]
RFC 4006 Diameter Credit-Control Application August 2005A.6. Flow VIGaming ServerEnd User (CC Client) CC Server| (1)Service Delivery | ||<---------------------->| |: : :: : :| |(2)CCR(event,REFUND,Requested-| |Service-Unit,Service-Parameter-Info)| |----------------------->|| | (3)CCA(Cost-Information)| |<-----------------------|| (4)Notification | ||<-----------------------| |Figure A.6: Flow VIFigure A.6 illustrates a credit-control flow for the REFUND case. Itis assumed that there is a trusted relationship and secure connectionbetween the Gaming server and the Diameter credit-control server.The end user may be a prepaid subscriber or a postpaid subscriber.While the end user is playing the game (1), she enters a new levelthat entitles her to a bonus. The Gaming server sends a DiameterCredit-Control-Request (EVENT_REQUEST with Requested-Action:REFUND_ACCOUNT) to the Diameter credit-control server (2). TheCredit-Control-Request Request contains the Requested-Service-UnitAVP with the CC-Service-Specific-Units containing the number ofpoints the user just won. The Service-Parameter-Info AVP is alsoincluded in the request and specifies the service event to be rated(e.g., Tetris Bonus). From information received, the Diametercredit-control server determines the amount to be credited, refundsthe user's account, and returns the Credit-Control-Answer, includingthe Cost-Information AVP (3). The Cost-Information indicates thecredited amount. At the first opportunity, the Gaming servernotifies the end user of the credited amount (4).Hakala, et al. Standards Track [Page 102]
RFC 4006 Diameter Credit-Control Application August 2005A.7. Flow VIISIP Controller Top-UpA (CC Client) Server B CC Server| | | | || | (1) CCR(Update,Used-Unit) | || |------------------------------------------>|| | (2) CCA(Final-Unit, Redirect)|| |<------------------------------------------|: : : : :: : : : :| | (3) CCR(Update, Used-Units)| || |------------------------------------------>|| | (3a)INVITE("hold") | || |--------------------------->| || | | (4) CCA(Validity-Time)|| |<------------------------------------------|| (5)INVITE | (6)INVITE | | ||<--------------|------------->| | || (7)RTP | | ||..............................| | || | (8)BYE | | || |<-------------| | || | (9)CCR(Update) | || |------------------------------------------>|| | (10)CCA(Granted-Unit) || |<------------------------------------------|| (12)INVITE | (11)INVITE | ||<--------------|--------------------------->| |Figure A.7: Flow VIIFigure A.7 is an example of the graceful service termination for aSIP call. It is assumed that the call is set up so that thecontroller is in the call as a B2BUA (Back to Back User Agent)performing third-party call control (3PCC). Note that the SIPsignaling is inaccurate, as the focus of this flow is in the gracefulservice termination and credit-control authorization. The bestpractice for 3PCC is defined in [RFC3725].The call is ongoing between users A and B; user A has a prepaidsubscription. At the expiry of the allocated quota, the SIPcontroller sends a Diameter Credit-Control-Request (UPDATE_REQUEST)to the Diameter credit-control server (1). This message contains theunits used thus far. The Diameter credit-control server debits theused units from the end user's account and allocates the final quotareturned to the SIP controller in the Diameter Credit-Control-Answer(2). This message contains the Final-Unit-Indication AVP with theHakala, et al. Standards Track [Page 103]RFC 4006 Diameter Credit-Control Application August 2005Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set toSIP URI, and the Redirect-Server-Address set to the Top-up servername (e.g., sip:sip-topup-server@domain.com). At the expiry of thefinal allocated quota, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-controlserver (3) and places the called party on "hold" by sending an INVITEwith the appropriate connection address in the SDP (3a). TheCredit-Control-Request message contains the units used thus far. TheDiameter credit-control server debits the used units from the enduser's account but does not make any credit reservation. TheCredit-Control-Answer message, which contains the Validity-Time tosupervise the graceful service termination, is returned to the SIPcontroller (4). The SIP controller establishes a SIP session betweenthe prepaid user and the Top-up server (5, 6). The Top-up serverplays an announcement and prompts the user to enter a credit cardnumber and the amount of money to be used to replenish the account(7). The Top-up server validates the credit card number andreplenishes the user's account (using some means outside the scope ofthis specification) and releases the SIP session (8). The SIPcontroller can now assume that communication between the prepaid userand the Top-up server took place. It sends a spontaneous Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-controlserver to check whether the account has been replenished (9). TheDiameter credit-control server reserves credit from the end user'saccount and returns the reserved quota to the SIP controller in theCredit-Control-Answer (10). At this point, the SIP controller re-connects the caller and the called party (11,12).Hakala, et al. Standards Track [Page 104]
RFC 4006 Diameter Credit-Control Application August 2005A.8. Flow VIIINAS Top-up CCEnd-User (CC Client) AAA Server Server Server|(1)User Logon |(2)AA Request (CC AVPs) | ||------------------>|------------------->| | || | |(3)CCR(initial, CC AVPs)| | |------------------->|| | |(4)CCA(Final-Unit, || | | Validity-Time)|| | |<-------------------|| |(5)AA Answer(Final-Unit,Validity-Time) ||(6)Limited Access |<-------------------| | || granted | | | ||<----------------->| | | || | | | || (7)TCP/HTTP | (8)TCP/HTTP | ||<----------------->|<----------------------------->| || (9) Replenish account | ||<------------------------------------------------->| || | | (10)RAR || |<-------------------|<-------------------|| | (11) RAA | || |------------------->|------------------->|| |(12)CCR(update) | || |------------------->|(13)CCR(Update) || | |------------------->|| | |(14)CCA(Granted-Units)| |(15)CCA(Granted-Units)<------------------|| |<-------------------| |Figure A.8: Flow VIIIFigure A.8 is an example of the graceful service terminationinitiated when the first interrogation takes place because the user'saccount is empty. In this example, the credit-control serversupports the server-initiated credit re-authorization. The Diameter[NASREQ] is implemented in the Network Access Server (NAS).The user logs on to the network (1). The Diameter NAS sends aDiameter AA-Request to the home Diameter AAA server. The credit-control client populates the AAR with the Credit-Control AVP set toCREDIT_AUTHORIZATION, and service specific AVPs are included, asusual [NASREQ]. The home Diameter AAA server performs servicespecific Authentication and Authorization, as usual. The homeDiameter AAA server determines that the user has a prepaidsubscription and notices from the Credit-Control AVP that the NAS hascredit-control capabilities. It sends a Diameter Credit-Control-Hakala, et al. Standards Track [Page 105]
什么是RFC?
有关RFC的请教
请求评议RFC
什么是RFC 954?
什么是RFC 954?
如何得到RFC
“6mm outer diameter”是什么意思？
什么是弗雷特直径(Feret Diameter)?
哪里有Diameter 测试工具
什么是rfc文档？有什么用？
什么是IETF？什么是RFC？他们是什么关系？
RFC文档中IP加速算法是什么
RFC文档是怎么进行排版的？
什么是RFC? 它的作用是什么？
求 RFC浏览器破解补丁或注册码!
机械中的tolerance diameter怎么译呀？什么意思？
服装英语中tube diameter是指什么？
Orifice diameter effects on diesel fuel jet flame structure
0.7 diameter for 3/8 length怎么翻译?
有最常用的RFC中文定义吗？
802.3ah OAM相关的rfc和MIB定义
谁知道比较全的RFC文档资源站啊?
Error 500--Internal Server Error From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
哪个网站可以打包下载至今为止所有的RFC呀？