summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8506.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8506.txt')
-rw-r--r--doc/rfc/rfc8506.txt7283
1 files changed, 7283 insertions, 0 deletions
diff --git a/doc/rfc/rfc8506.txt b/doc/rfc/rfc8506.txt
new file mode 100644
index 0000000..674d6b3
--- /dev/null
+++ b/doc/rfc/rfc8506.txt
@@ -0,0 +1,7283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Bertz, Ed.
+Request for Comments: 8506 Sprint
+Obsoletes: 4006 D. Dolson, Ed.
+Category: Standards Track Y. Lifshitz, Ed.
+ISSN: 2070-1721 Sandvine
+ March 2019
+
+
+ Diameter Credit-Control Application
+
+Abstract
+
+ This document specifies a Diameter application that can be used to
+ implement real-time credit-control for a variety of end-user services
+ such as network access, Session Initiation Protocol (SIP) services,
+ messaging services, and download services. The Diameter Credit-
+ Control application as defined in this document obsoletes RFC 4006,
+ and it must be supported by all new Diameter Credit-Control
+ application implementations.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8506.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 1]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+Copyright Notice
+
+ Copyright (c) 2019 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 2]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+Table of Contents
+
+ 1. Introduction ....................................................6
+ 1.1. Requirements Language ......................................7
+ 1.2. Terminology ................................................7
+ 1.3. Advertising Application Support ............................9
+ 2. Architecture Models .............................................9
+ 3. Credit-Control Messages ........................................11
+ 3.1. Credit-Control-Request (CCR) Command ......................11
+ 3.2. Credit-Control-Answer (CCA) Command .......................12
+ 4. Credit-Control Application Overview ............................13
+ 4.1. Service-Specific Rating Input and Interoperability ........14
+ 4.1.1. Specifying Rating Input AVPs .......................15
+ 4.1.2. Service-Specific Documentation .....................16
+ 4.1.3. Handling of Unsupported/Incorrect Rating Input .....16
+ 4.1.4. RADIUS Vendor-Specific Rating Attributes ...........17
+ 5. Session-Based Credit-Control ...................................17
+ 5.1. General Principles ........................................17
+ 5.1.1. Basic Support for Tariff Time Change ...............18
+ 5.1.2. Credit-Control for Multiple Services within
+ a (Sub-)Session ....................................19
+ 5.2. First Interrogation .......................................23
+ 5.2.1. First Interrogation after Authorization and
+ Authentication .....................................25
+ 5.2.2. First Interrogation Included with
+ Authorization Messages .............................27
+ 5.3. Intermediate Interrogation ................................29
+ 5.4. Final Interrogation .......................................31
+ 5.5. Server-Initiated Credit Re-authorization ..................32
+ 5.6. Graceful Service Termination ..............................34
+ 5.6.1. Terminate Action ...................................37
+ 5.6.2. Redirect Action ....................................38
+ 5.6.3. Restrict Access Action .............................40
+ 5.6.4. Usage of the Server-Initiated Credit
+ Re-authorization ...................................41
+ 5.7. Failure Procedures ........................................41
+ 6. One-Time Event .................................................44
+ 6.1. Service Price Inquiry .....................................45
+ 6.2. Balance Checks ............................................46
+ 6.3. Direct Debiting ...........................................46
+ 6.4. Refunds ...................................................47
+ 6.5. Failure Procedure .........................................48
+ 7. Credit-Control Application State Machines ......................50
+ 8. Credit-Control AVPs ............................................59
+ 8.1. CC-Correlation-Id AVP .....................................61
+ 8.2. CC-Request-Number AVP .....................................62
+ 8.3. CC-Request-Type AVP .......................................62
+ 8.4. CC-Session-Failover AVP ...................................63
+
+
+
+Bertz, et al. Standards Track [Page 3]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ 8.5. CC-Sub-Session-Id AVP .....................................64
+ 8.6. Check-Balance-Result AVP ..................................64
+ 8.7. Cost-Information AVP ......................................64
+ 8.8. Unit-Value AVP ............................................65
+ 8.9. Exponent AVP ..............................................65
+ 8.10. Value-Digits AVP .........................................66
+ 8.11. Currency-Code AVP ........................................66
+ 8.12. Cost-Unit AVP ............................................66
+ 8.13. Credit-Control AVP .......................................66
+ 8.14. Credit-Control-Failure-Handling AVP (CCFH) ...............67
+ 8.15. Direct-Debiting-Failure-Handling AVP (DDFH) ..............68
+ 8.16. Multiple-Services-Credit-Control AVP .....................68
+ 8.17. Granted-Service-Unit AVP .................................70
+ 8.18. Requested-Service-Unit AVP ...............................71
+ 8.19. Used-Service-Unit AVP ....................................71
+ 8.20. Tariff-Time-Change AVP ...................................72
+ 8.21. CC-Time AVP ..............................................72
+ 8.22. CC-Money AVP .............................................72
+ 8.23. CC-Total-Octets AVP ......................................72
+ 8.24. CC-Input-Octets AVP ......................................72
+ 8.25. CC-Output-Octets AVP .....................................73
+ 8.26. CC-Service-Specific-Units AVP ............................73
+ 8.27. Tariff-Change-Usage AVP ..................................73
+ 8.28. Service-Identifier AVP ...................................74
+ 8.29. Rating-Group AVP .........................................74
+ 8.30. G-S-U-Pool-Reference AVP .................................74
+ 8.31. G-S-U-Pool-Identifier AVP ................................75
+ 8.32. CC-Unit-Type AVP .........................................75
+ 8.33. Validity-Time AVP ........................................75
+ 8.34. Final-Unit-Indication AVP ................................76
+ 8.35. Final-Unit-Action AVP ....................................77
+ 8.36. Restriction-Filter-Rule AVP ..............................78
+ 8.37. Redirect-Server AVP ......................................78
+ 8.38. Redirect-Address-Type AVP ................................79
+ 8.39. Redirect-Server-Address AVP ..............................79
+ 8.40. Multiple-Services-Indicator AVP ..........................80
+ 8.41. Requested-Action AVP .....................................80
+ 8.42. Service-Context-Id AVP ...................................81
+ 8.43. Service-Parameter-Info AVP ...............................82
+ 8.44. Service-Parameter-Type AVP ...............................82
+ 8.45. Service-Parameter-Value AVP ..............................83
+ 8.46. Subscription-Id AVP ......................................83
+ 8.47. Subscription-Id-Type AVP .................................83
+ 8.48. Subscription-Id-Data AVP .................................84
+ 8.49. User-Equipment-Info AVP ..................................84
+ 8.50. User-Equipment-Info-Type AVP .............................84
+ 8.51. User-Equipment-Info-Value AVP ............................85
+ 8.52. User-Equipment-Info-Extension AVP ........................85
+
+
+
+Bertz, et al. Standards Track [Page 4]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ 8.53. User-Equipment-Info-IMEISV AVP ...........................86
+ 8.54. User-Equipment-Info-MAC AVP ..............................86
+ 8.55. User-Equipment-Info-EUI64 AVP ............................86
+ 8.56. User-Equipment-Info-ModifiedEUI64 AVP ....................86
+ 8.57. User-Equipment-Info-IMEI AVP .............................86
+ 8.58. Subscription-Id-Extension AVP ............................87
+ 8.59. Subscription-Id-E164 AVP .................................87
+ 8.60. Subscription-Id-IMSI AVP .................................87
+ 8.61. Subscription-Id-SIP-URI AVP ..............................88
+ 8.62. Subscription-Id-NAI AVP ..................................88
+ 8.63. Subscription-Id-Private AVP ..............................88
+ 8.64. Redirect-Server-Extension AVP ............................88
+ 8.65. Redirect-Address-IPAddress AVP ...........................89
+ 8.66. Redirect-Address-URL AVP .................................89
+ 8.67. Redirect-Address-SIP-URI AVP .............................89
+ 8.68. QoS-Final-Unit-Indication AVP ............................89
+ 9. Result-Code AVP Values .........................................91
+ 9.1. Transient Failures ........................................91
+ 9.2. Permanent Failures ........................................92
+ 10. AVP Occurrence Table ..........................................92
+ 10.1. Credit-Control AVP Table .................................93
+ 10.2. Re-Auth-Request/Re-Auth-Answer AVP Table .................94
+ 11. RADIUS/Diameter Credit-Control Interworking Model .............94
+ 12. IANA Considerations ...........................................97
+ 12.1. Application Identifier ...................................97
+ 12.2. Command Codes ............................................97
+ 12.3. AVP Codes ................................................97
+ 12.4. Result-Code AVP Values ...................................98
+ 12.5. CC-Request-Type AVP ......................................98
+ 12.6. CC-Session-Failover AVP ..................................98
+ 12.7. CC-Unit-Type AVP .........................................99
+ 12.8. Check-Balance-Result AVP .................................99
+ 12.9. Credit-Control AVP .......................................99
+ 12.10. Credit-Control-Failure-Handling AVP .....................99
+ 12.11. Direct-Debiting-Failure-Handling AVP ....................99
+ 12.12. Final-Unit-Action AVP ...................................99
+ 12.13. Multiple-Services-Indicator AVP ........................100
+ 12.14. Redirect-Address-Type AVP ..............................100
+ 12.15. Requested-Action AVP ...................................100
+ 12.16. Subscription-Id-Type AVP ...............................100
+ 12.17. Tariff-Change-Usage AVP ................................100
+ 12.18. User-Equipment-Info-Type AVP ...........................100
+ 13. Parameters Related to the Credit-Control Application .........101
+ 14. Security Considerations ......................................101
+ 14.1. Direct Connection with Redirects ........................102
+ 14.2. Application-Level Redirects .............................103
+
+
+
+
+
+Bertz, et al. Standards Track [Page 5]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ 15. Privacy Considerations .......................................104
+ 15.1. Privacy-Sensitive AVPs ..................................104
+ 15.2. Data Minimization .......................................106
+ 15.3. Diameter Agents .........................................107
+ 16. References ...................................................107
+ 16.1. Normative References ....................................107
+ 16.2. Informative References ..................................110
+ Appendix A. Credit-Control Sequences .............................111
+ A.1. Flow I ....................................................111
+ A.2. Flow II ...................................................113
+ A.3. Flow III ..................................................116
+ A.4. Flow IV ...................................................117
+ A.5. Flow V ....................................................119
+ A.6. Flow VI ...................................................120
+ A.7. Flow VII ..................................................121
+ A.8. Flow VIII .................................................123
+ A.9. Flow IX ...................................................124
+ Acknowledgements .................................................130
+ Authors' Addresses ...............................................130
+
+1. Introduction
+
+ This document specifies a Diameter application that can be used to
+ implement real-time credit-control for a variety of end-user services
+ such as network access, Session Initiation Protocol (SIP) services,
+ messaging services, and download services. ("Credit-control" is
+ sometimes abbreviated as "CC" in figures and tables throughout this
+ document.) The Diameter Credit-Control application as defined in
+ this document obsoletes [RFC4006], and it must be supported by all
+ new Diameter Credit-Control application implementations. This
+ document provides a general solution 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
+ services have experienced a substantial growth of their customer base
+ and revenues. Prepaid services are now cropping up in many other
+ wireless and wire-line-based networks.
+
+ In mobile networks, additional functionality is required beyond that
+ specified in the Diameter base protocol [RFC6733]. For example, the
+ 3GPP charging and billing requirements document [TGPPCHARG] states
+ that an application must be able to rate service information in
+ real time. In addition, it is necessary to check that the end user's
+ account provides coverage for the requested service prior to
+ initiation of that service. When an account is exhausted or expired,
+ the user must be denied the ability to compile additional chargeable
+ events.
+
+
+
+Bertz, et al. Standards Track [Page 6]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ A mechanism has to be provided to allow the user to be informed of
+ the charges to be levied for a requested service. In addition, there
+ are services such as gaming and advertising that may credit as well
+ as debit a user account.
+
+ The other Diameter applications provide service-specific
+ authorization, and they do not provide credit authorization for
+ prepaid users. The credit authorization shall be generic and
+ applicable to all the service environments required to support
+ prepaid services.
+
+ To fulfill these requirements, it is necessary to facilitate
+ credit-control communication between the network element providing
+ the service (e.g., Network Access Server (NAS), SIP Proxy,
+ Application Server) and a credit-control server.
+
+ The scope of this specification is credit authorization. Service-
+ specific authorization and authentication are out of scope.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+1.2. Terminology
+
+ AAA: Authentication, Authorization, and Accounting.
+
+ AA-Answer: "AA-Answer" generically refers to a service-specific
+ authorization and authentication answer. AA-Answer commands are
+ defined in service-specific authorization applications, e.g.,
+ [RFC7155] [RFC4004].
+
+ AA-Request: "AA-Request" generically refers to a service-specific
+ authorization and authentication request. AA-Request commands are
+ defined in service-specific authorization applications, e.g.,
+ [RFC7155] [RFC4004].
+
+ Credit-control: "Credit-control" is a mechanism that directly
+ interacts in real time with an account and controls or monitors
+ the charges related to service usage. Credit-control is a
+ process of (1) checking whether or not credit is available,
+ (2) credit reservation, (3) deduction of credit from the end-user
+ account when service is completed, and (4) refunding of reserved
+ credit that is not used.
+
+
+
+Bertz, et al. Standards Track [Page 7]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Diameter Credit-Control server: A Diameter Credit-Control server
+ acts as a prepaid server, performing real-time rating and
+ credit-control. It is located in the home domain and is accessed
+ by Service Elements or Diameter AAA servers in real time, for the
+ purpose of price determination and credit-control before the
+ service event is delivered to the end user. It may also interact
+ with Business Support Systems.
+
+ Diameter Credit-Control client: A Diameter Credit-Control client is
+ an entity that interacts with a credit-control server. It
+ monitors the usage of the granted quota according to instructions
+ returned by the credit-control server.
+
+ Interrogation: The Diameter Credit-Control client uses interrogation
+ to initiate a session-based credit-control process. During the
+ credit-control process, it is used to report the used quota and
+ request a new one. An interrogation maps to a request/answer
+ transaction.
+
+ One-time event: A charging transaction session comprising a single
+ request and single response.
+
+ Rating: The act of determining the cost of the service event.
+
+ Service: A type of task performed by a Service Element for an
+ end user.
+
+ Service Element: A network element that provides a service to the
+ end users. The Service Element may include the Diameter
+ Credit-Control client or another entity (e.g., a 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. Examples of Service Elements
+ include NASs, SIP Proxies, and Application Servers such as
+ messaging servers, content servers, and gaming servers.
+
+ Service event: An event relating to a service provided to the
+ end user.
+
+ Session-based credit-control: A credit-control process that makes
+ use of several interrogations: the first, a possible intermediate,
+ and the final. The first interrogation is used to reserve money
+ from the user's account and to initiate the process. Intermediate
+ interrogations (if any) may be needed to request a new quota while
+ the service is being rendered. The final interrogation is used to
+ exit the process. The credit-control server is required to
+ maintain session state for session-based credit-control.
+
+
+
+Bertz, et al. Standards Track [Page 8]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+1.3. Advertising Application Support
+
+ Diameter nodes conforming to this specification MUST advertise
+ support by including the value of 4 in the Auth-Application-Id of the
+ Capabilities-Exchange-Request and Capabilities-Exchange-Answer
+ commands [RFC6733].
+
+2. Architecture Models
+
+ The current accounting models specified in the RADIUS accounting and
+ Diameter base specifications [RFC2866] [RFC6733] are not sufficient
+ for real-time credit-control, where creditworthiness is to be
+ determined prior to service initiation. Also, the existing Diameter
+ authorization applications [RFC7155] [RFC4004] only provide service
+ authorization; they do not provide credit authorization for prepaid
+ users. In order to support real-time credit-control, a new type of
+ server is needed in the AAA infrastructure: the Diameter
+ Credit-Control server. The Diameter Credit-Control server is the
+ entity responsible for credit authorization for prepaid subscribers.
+
+ A Service Element may authenticate and authorize the end user with
+ the AAA server by using AAA protocols, e.g., RADIUS or the Diameter
+ base protocol (possibly extended via a Diameter application).
+
+ Accounting protocols such as RADIUS accounting and the Diameter base
+ accounting protocol can be used to provide accounting data to the
+ accounting server after service is initiated and to provide possible
+ interim reports until service completion. However, for real-time
+ credit-control, these authorization and accounting models are not
+ sufficient.
+
+ When real-time credit-control is required, the credit-control client
+ contacts the credit-control server with information about a possible
+ service event. The credit-control process is performed to determine
+ potential charges and to verify whether the end user's account
+ balance is sufficient to cover the cost of the service being
+ rendered.
+
+ Figure 1 illustrates the typical credit-control architecture, which
+ consists of a Service Element with an embedded Diameter
+ Credit-Control client, a Diameter Credit-Control server, and a AAA
+ server. A Business Support System is usually deployed; at a minimum,
+ it includes billing functionality. The credit-control server and AAA
+ server in this architecture model are logical entities. The real
+ configuration can combine them into a single host. The
+ credit-control protocol is the Diameter base protocol [RFC6733] with
+ the Diameter Credit-Control application.
+
+
+
+
+Bertz, et al. Standards Track [Page 9]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ When an end user requests services such as SIP or messaging, the
+ request is typically forwarded to a Service Element (e.g., a SIP
+ Proxy) in the user's home realm as defined in [RFC6733]. In some
+ cases, it might be possible that the Service Element in the local
+ realm [RFC6733] can offer services to the end user; however, a
+ commercial agreement must exist between the local realm and the home
+ realm. Network access is an example of a service offered in the
+ local realm where the NAS, through a AAA infrastructure,
+ authenticates and authorizes the user with the user's home 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 Architecture
+
+ There can be multiple credit-control servers in the system for
+ redundancy and load balancing. The system can also contain separate
+ rating server(s), and accounts can be located in a centralized
+ database. To ensure that the end user's account is not debited or
+ credited multiple times for the same service event, only one entity
+ in the credit-control system should perform duplicate detection.
+ System-internal interfaces can exist to relay messages between
+ servers and an account manager. However, the detailed architecture
+ of the credit-control system and its interfaces is implementation
+ specific and is out of scope for this specification.
+
+ Protocol-transparent Diameter relays can exist between the
+ credit-control client and credit-control server. Also, Diameter
+ redirect agents that refer credit-control clients to credit-control
+ servers and allow them to communicate directly can exist. These
+ agents transparently support the Diameter Credit-Control application.
+ The different roles of Diameter agents are defined in Diameter base
+ [RFC6733], Section 2.8.
+
+ If Diameter Credit-Control proxies exist between the credit-control
+ client and the credit-control server, they MUST advertise support for
+ the Diameter Credit-Control application.
+
+
+
+Bertz, et al. Standards Track [Page 10]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+3. Credit-Control Messages
+
+ This section defines new Diameter message Command Code values that
+ MUST be supported by all Diameter implementations that conform to
+ this specification. The Command Codes are as follows:
+
+ +------------------------+---------+------+-------------+
+ | Command Name | Abbrev. | Code | Reference |
+ +------------------------+---------+------+-------------+
+ | Credit-Control-Request | CCR | 272 | Section 3.1 |
+ | Credit-Control-Answer | CCA | 272 | Section 3.2 |
+ +------------------------+---------+------+-------------+
+
+ Table 1: Credit-Control Commands
+
+ Section 3.2 of [RFC6733] (Diameter base) defines the Command Code
+ Format specification. These formats are observed in credit-control
+ messages.
+
+3.1. Credit-Control-Request (CCR) Command
+
+ The Credit-Control-Request message (CCR) is indicated by the Command
+ Code field being set to 272 and the 'R' bit being set in the Command
+ Flags field. It is used between the Diameter Credit-Control client
+ and the credit-control server to request credit authorization for a
+ given service.
+
+ The Auth-Application-Id MUST be set to the value 4, indicating the
+ Diameter Credit-Control application.
+
+ The CCR is extensible via the inclusion of one or more
+ Attribute-Value Pairs (AVPs).
+
+ Message Format:
+
+ <Credit-Control-Request> ::= < 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 ]
+
+
+
+Bertz, et al. Standards Track [Page 11]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ [ Origin-State-Id ]
+ [ Event-Timestamp ]
+ *[ Subscription-Id ]
+ *[ Subscription-Id-Extension ]
+ [ 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 ]
+ [ User-Equipment-Info-Extension ]
+ *[ Proxy-Info ]
+ *[ Route-Record ]
+ *[ AVP ]
+
+3.2. Credit-Control-Answer (CCA) Command
+
+ The Credit-Control-Answer message (CCA) is indicated by the Command
+ Code field being set to 272 and the 'R' bit being cleared in the
+ Command Flags field. It is used between the credit-control server
+ and the Diameter Credit-Control client to acknowledge a
+ Credit-Control-Request command.
+
+ Message Format:
+
+ <Credit-Control-Answer> ::= < 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 ]
+ [ QoS-Final-Unit-Indication ]
+
+
+
+Bertz, et al. Standards Track [Page 12]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ [ 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 Overview
+
+ The credit authorization process takes place before and during
+ service delivery to the end user and generally requires the user's
+ authentication and authorization before any requests are sent to the
+ credit-control server. The credit-control application defined in
+ this specification supports two different credit authorization
+ models: credit authorization with money reservation and credit
+ authorization with direct debiting. In both models, the
+ credit-control client requests credit authorization from the
+ credit-control server prior to allowing any services 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, and
+ returns the amount of credit reserved. Note that credit resources
+ may not imply actual monetary credit; credit resources may be granted
+ to the credit-control client in the form of units (e.g., data volume
+ or time) to be metered.
+
+ Upon receipt of a successful credit authorization answer with a
+ certain amount of credit resources, the credit-control client allows
+ service delivery to the end user and starts monitoring the usage of
+ the granted resources. When the credit resources granted to the user
+ have been consumed or the service has been successfully delivered or
+ terminated, the credit-control client reports back to the server the
+ used amount. The credit-control server deducts the used amount from
+ the end user's account; it may perform rating and make a new credit
+ reservation if the service delivery is continuing. This process is
+ accomplished with session-based credit-control that includes the
+ first interrogation, possible intermediate interrogations, and the
+ final interrogation. For session-based credit-control, both the
+ credit-control client and the credit-control server are required to
+ maintain credit-control session state. Session-based credit-control
+ is described in more detail, with more variations, in Section 5.
+
+
+
+
+Bertz, et al. Standards Track [Page 13]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ In contrast, credit authorization with direct debiting is a
+ single-transaction process wherein the credit-control server directly
+ deducts a suitable amount of money from the user's account as soon as
+ the credit authorization request is received. Upon receipt of a
+ successful credit authorization answer, the credit-control client
+ allows service delivery to the end user. This process is
+ accomplished with the one-time event. Session state is not
+ maintained.
+
+ In a multi-service environment, an end user can issue an additional
+ service request (e.g., data service) during an ongoing service (e.g.,
+ voice call) toward the same account. Alternatively, during an active
+ multimedia session, an additional media type is added to the session,
+ causing a new simultaneous request toward the same account.
+ Consequently, this needs to be considered when credit resources are
+ granted to the services.
+
+ The credit-control application also supports operations such as
+ service price inquiries, user's balance checks, and refunds of credit
+ on the user's account. These operations are accomplished with the
+ one-time event. Session state is not maintained.
+
+ Flexible failure handling, specific to the credit-control
+ application, is defined in the application. This allows the service
+ provider to control the credit-control client's behavior according to
+ its own risk management policy.
+
+ The Credit-Control-Failure-Handling AVP (also referred to as the
+ CCFH) and the Direct-Debiting-Failure-Handling AVP (also referred to
+ as the DDFH) are defined to determine what is done if the sending of
+ credit-control messages to the credit-control server has been
+ temporarily prevented. The usage of the CCFH and the DDFH allows
+ flexibility, as failure handling for the credit-control session and
+ one-time event direct debiting may be different.
+
+4.1. Service-Specific Rating Input and Interoperability
+
+ The Diameter Credit-Control application defines the framework for
+ credit-control; it provides generic credit-control mechanisms
+ supporting multiple service applications. The credit-control
+ application therefore does not define AVPs that could be used as
+ input in the rating process. Listing the possible services that
+ could use this Diameter application is out of scope for this generic
+ mechanism.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 14]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ It is reasonable to expect that a service level agreement will exist
+ between providers of the credit-control client and the credit-control
+ server covering the charging, services offered, roaming agreements,
+ agreed-upon rating input (i.e., AVPs), and so on.
+
+ Therefore, it is assumed that a Diameter Credit-Control server will
+ provide service only for Diameter Credit-Control clients that have
+ agreed beforehand as to the content of credit-control messages.
+ Naturally, it is possible that any arbitrary Diameter Credit-Control
+ client can interchange credit-control messages with any Diameter
+ Credit-Control server, but with a higher likelihood that unsupported
+ services/AVPs could be present in the credit-control message, causing
+ the server to reject the request with an appropriate Result-Code.
+
+4.1.1. Specifying Rating Input AVPs
+
+ There are two ways to provide rating input to the credit-control
+ server: by either using AVPs or including the rating input in the
+ Service-Parameter-Info AVP. The general principles for sending
+ rating parameters are as follows:
+
+ 1. Using AVPs:
+
+ A. The service SHOULD reuse existing AVPs if it can use AVPs
+ defined in existing Diameter applications (e.g., [RFC7155]
+ for network access services). [RFC6733] strongly recommends
+ the reuse of existing AVPs.
+
+ For AVPs of type Enumerated, the service may require a new
+ value to be defined. Allocation of new AVP values is done as
+ specified in [RFC6733], Section 1.3.
+
+ B. New AVPs can be defined if the existing AVPs do not provide
+ sufficient rating information. In this case, the procedures
+ defined in [RFC6733] for creating new AVPs MUST be followed.
+
+ C. For services specific only to one vendor's implementation, a
+ vendor-specific AVP code for private use can be used. Where
+ a vendor-specific AVP is implemented by more than one vendor,
+ allocation of global AVPs is encouraged instead; refer to
+ [RFC6733].
+
+ 2. The Service-Parameter-Info AVP MAY be used as a container to pass
+ legacy rating information in its original encoded form (e.g.,
+ ASN.1 BER). This method can be used to avoid unnecessary
+ conversions from an existing data format to an AVP format. In
+ this case, the rating input is embedded in the Service-Parameter-
+ Info AVP as defined in Section 8.43.
+
+
+
+Bertz, et al. Standards Track [Page 15]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ New service applications SHOULD favor the use of explicitly defined
+ AVPs as described in items 1a and 1b, to simplify interoperability.
+
+4.1.2. Service-Specific Documentation
+
+ The service-specific rating input AVPs, and the contents of the
+ Service-Parameter-Info AVP or Service-Context-Id AVP (defined in
+ Section 8.42), are not within the scope of this document. To
+ facilitate interoperability, it is RECOMMENDED that the rating input
+ and the values of the Service-Context-Id be coordinated via an
+ informational RFC or other permanent and readily available reference
+ (preferably that of another cooperative standardization body, e.g.,
+ 3GPP, the Open Mobile Alliance (OMA), or 3GPP2). However, private
+ services may be deployed that are subject to agreements between
+ providers of the credit-control server and client. In this case,
+ vendor-specific AVPs can be used.
+
+ This specification, together with the above-mentioned service-
+ specific documents, governs the credit-control message. Service-
+ specific documents (i.e., those documents that do not define new
+ credit-control applications) define which existing AVPs or new AVPs
+ are used as input to the rating process; thus, the AVPs in question
+ have to be included in the Credit-Control-Request command by a
+ Diameter Credit-Control client supporting a given service as
+ "* [AVP]". Should the Service-Parameter-Info AVP be used, the
+ service-specific document MUST specify the exact content of this
+ Grouped AVP.
+
+ The Service-Context-Id AVP MUST be included at the command level of a
+ Credit-Control-Request to identify the service-specific document that
+ applies to the request. The specific service or rating-group the
+ request relates to is uniquely identified by the combination of
+ Service-Context-Id and Service-Identifier or rating-group.
+
+4.1.3. Handling of Unsupported/Incorrect Rating Input
+
+ Diameter Credit-Control implementations are required to support
+ mandatory rating-related AVPs defined in service-specific documents
+ for the services they support, according to the 'M' bit rules in
+ [RFC6733].
+
+ If a rating input required for the rating process is incorrect in
+ the Credit-Control-Request or if the credit-control server does not
+ support the requested service context (identified by the
+ Service-Context-Id AVP at the command level), the
+ Credit-Control-Answer MUST contain the error code
+ DIAMETER_RATING_FAILED. A CCA message with this error MUST contain
+ one or more Failed-AVP AVPs containing the missing and/or unsupported
+
+
+
+Bertz, et al. Standards Track [Page 16]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ AVPs that caused the failure. A Diameter Credit-Control client that
+ receives the error code DIAMETER_RATING_FAILED in response to a
+ request MUST NOT send similar requests in the future.
+
+4.1.4. RADIUS Vendor-Specific Rating Attributes
+
+ When service-specific documents include RADIUS vendor-specific
+ attributes that could be used as input in the rating process, the
+ rules described in [RFC7155] for formatting the Diameter AVP MUST be
+ followed.
+
+ 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 be
+ set to the IANA Vendor identification value. The Diameter AVP Data
+ field contains only the attribute value of the RADIUS attribute.
+
+5. Session-Based Credit-Control
+
+5.1. General Principles
+
+ For session-based credit-control, several interrogations are needed:
+ the first, the intermediate (optional), and the final. This is
+ illustrated in Figures 3 and 4 (Sections 5.2.1 and 5.2.2).
+
+ If the credit-control client performs credit reservation before
+ granting service to the end user, it MUST use several interrogations
+ toward the credit-control server (i.e., session-based
+ credit-control). In this case, the credit-control server MUST
+ maintain the credit-control session state.
+
+ Each credit-control session MUST have a globally unique Session-Id as
+ defined in [RFC6733]; this Session-Id MUST NOT be changed during the
+ lifetime of a credit-control session.
+
+ Certain applications require multiple credit-control sub-sessions.
+ These applications would send messages with a constant Session-Id AVP
+ but with a different CC-Sub-Session-Id AVP. If several credit
+ sub-sessions will be used, all sub-sessions MUST be closed separately
+ before the main session is closed so that units per sub-session may
+ be reported. The absence of the CC-Sub-Session-Id AVP implies that
+ no sub-sessions are in use.
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 17]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Note that the Service Element might send a service-specific
+ re-authorization message to the AAA server due to expiration of the
+ authorization lifetime during an ongoing credit-control session.
+ However, the service-specific re-authorization does not influence the
+ credit authorization that is ongoing between the credit-control
+ client and credit-control server, as credit authorization is
+ controlled by the burning rate of the granted quota.
+
+ If service-specific re-authorization fails, the user will be
+ disconnected, and the credit-control client MUST send a final
+ interrogation to the credit-control server.
+
+ The Diameter Credit-Control server may seek to control the validity
+ time of the granted quota and/or the production of intermediate
+ interrogations. Thus, it MAY include the Validity-Time AVP in the
+ Answer message to the credit-control client. Upon expiration of the
+ Validity-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
+ determine the value of the Validity-Time to be used for consumption
+ of the granted service unit(s) (G-S-U). If the Validity-Time is
+ used, its value SHOULD be given as input to set the session
+ supervision timer Tcc (the session supervision timer MAY be set to
+ two times the value of the Validity-Time, as defined in Section 13).
+ Since credit-control update requests are also produced at the expiry
+ of granted service units and/or for mid-session service events, the
+ omission of Validity-Time does not mean that intermediate
+ interrogation for the purpose of credit-control is not performed.
+
+5.1.1. Basic Support for Tariff Time Change
+
+ The Diameter Credit-Control server and client MAY optionally support
+ a tariff change mechanism. The Diameter Credit-Control server may
+ include a Tariff-Time-Change AVP in the Answer message. Note that
+ the granted units should be allocated based on the worst-case
+ scenario, so that the overall reported used units would never exceed
+ the credit reservation. For example, in the case of a forthcoming
+ tariff change, in which the new rate is higher, the allocation should
+ be given so it does not exceed the credit, assuming that all of it is
+ used after the tariff changed.
+
+ When the Diameter Credit-Control client reports the used units and a
+ tariff change has occurred during the reporting period, the Diameter
+ Credit-Control client MUST separately itemize the units used before
+ and after the tariff change. If the client is unable to distinguish
+ whether units straddling the tariff change were used before or after
+ the tariff change, the credit-control client MUST itemize those units
+ in a third category.
+
+
+
+Bertz, et al. Standards Track [Page 18]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ If a client does not support the tariff change mechanism and it
+ receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
+ terminate the credit-control session, giving a reason of
+ DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
+
+ For time-based services, the quota is consumed at the rate of the
+ passage of real time (ignoring leap seconds). That is, precisely
+ 1 second of quota is consumed per second of real time. At the time
+ when credit resources are allocated, the server already knows how
+ many units will be consumed before the tariff time change and how
+ many units will be consumed afterward. Similarly, the server can
+ determine the units consumed at the "before" rate and the units
+ consumed at the "afterward" rate in the event that the end user
+ closes the session before the consumption of the allotted quota.
+ There is no need for additional traffic between the client and server
+ in the case of tariff time changes for continuous time-based service.
+ Therefore, the tariff change mechanism is not used for such services.
+ For time-based services in which the quota is NOT continuously
+ consumed at a regular rate, the tariff change mechanism described for
+ volume and event units MAY be used.
+
+5.1.2. Credit-Control for Multiple Services within a (Sub-)Session
+
+ When multiple services are used within the same user session and each
+ service or group of services is subject to different cost, it is
+ necessary to perform credit-control for each service independently.
+ Making use of credit-control sub-sessions to achieve independent
+ credit-control will result in increased signaling load and usage of
+ resources in both the credit-control client and the credit-control
+ server. For instance, during one network access session, the
+ end user may use several HTTP-based services that could be charged
+ with different costs. The network-access-specific attributes, such
+ as Quality of Service (QoS), are common to all the services carried
+ within the access bearer, but the cost of the bearer may vary,
+ depending on its content.
+
+ To support these scenarios optimally, the credit-control application
+ enables independent credit-control of multiple services in a single
+ credit-control (sub-)session. This is achieved by including the
+ optional Multiple-Services-Credit-Control AVP in Credit-Control-
+ Request/Credit-Control-Answer messages. It is possible to request
+ and allocate resources as a credit pool shared between multiple
+ services. The services can be grouped into rating-groups in order to
+ achieve even further aggregation of credit allocation. It is also
+ possible to request and allocate quotas on a per-service basis.
+ Where quotas are allocated to a pool by means of the Multiple-
+ Services-Credit-Control AVP, the quotas remain independent objects
+
+
+
+
+Bertz, et al. Standards Track [Page 19]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ that can be re-authorized independently at any time. Quotas can also
+ be given independent result codes, validity times, and Final-Unit-
+ Indication AVP values or QoS-Final-Unit-Indication AVP values.
+
+ 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 provided
+ with rating-groups, service-identifiers, and their associated
+ parameters that define what has to be metered by means outside the
+ scope of this specification. (Examples of parameters associated to
+ service-identifiers are IP 5-tuples and HTTP URLs.) Service-
+ identifiers enable authorization on a per-service-based credit as
+ well as itemized reporting of service usage. It is up to the
+ credit-control server whether to authorize credit for one or more
+ services or for the whole rating-group. However, the client SHOULD
+ always report used units at the finest supported level of
+ granularity. Where a quota is allocated to a rating-group, all the
+ services belonging to that group draw from the allotted quota.
+ Figure 2 provides a graphical representation of the relationship
+ between service-identifiers, rating-groups, credit pools, and
+ credit-control (sub-)sessions.
+
+ Diameter Credit-Control (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 Pool
+
+ Figure 2: Multiple-Service (Sub-)Session Example
+
+ If independent credit-control of multiple services is used, the
+ Validity-Time AVP, and the Final-Unit-Indication AVP or
+ QoS-Final-Unit-Indication AVP, SHOULD be present either in the
+ Multiple-Services-Credit-Control AVP(s) or at the command level as
+ single AVPs. However, the Result-Code AVP MAY be present both at the
+ command level and within the Multiple-Services-Credit-Control AVP.
+ If the Result-Code AVP at the command level indicates a value other
+ than SUCCESS, then the Result-Code AVP at the command level takes
+ precedence over any other AVPs included in the Multiple-Services-
+ Credit-Control AVP.
+
+
+
+Bertz, et al. Standards Track [Page 20]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The credit-control client MUST indicate support for independent
+ credit-control of multiple services within a (sub-)session by
+ including the Multiple-Services-Indicator AVP in the first
+ interrogation. A credit-control server not supporting this feature
+ MUST treat the Multiple-Services-Indicator AVP and any received
+ Multiple-Services-Credit-Control AVPs as invalid AVPs.
+
+ If the client indicated support for independent credit-control of
+ multiple services, a credit-control server that wishes to use the
+ feature MUST return the granted units within the Multiple-Services-
+ Credit-Control AVP associated to the corresponding service-identifier
+ and/or rating-group.
+
+ To avoid a situation where several parallel (and typically also
+ small) credit reservations must be made on the same account (i.e.,
+ credit fragmentation), and also to avoid unnecessary load on the
+ credit-control server, it is possible to provide service units as a
+ pool that applies to multiple services or rating-groups. This is
+ achieved by providing the service units in the form of a quota for a
+ particular service or rating-group in the Multiple-Services-Credit-
+ Control AVP, and also by including a reference to a credit pool for
+ that unit type.
+
+ The reference includes a multiplier derived from the rating
+ parameter, which translates from service units of a specific type to
+ the abstract service units in the pool. For instance, if the rating
+ parameter for service 1 is $1/MB and the rating parameter for
+ service 2 is $0.5/MB, the multipliers could be 10 and 5 for
+ services 1 and 2, respectively.
+
+ If (1) S is the total service units within the pool, (2) M1, M2, ...,
+ Mn are the multipliers provided for services 1, 2, ..., n, and
+ (3) C1, C2, ..., Cn are the used resources within the session, then
+ the pool's credit is exhausted and re-authorization MUST be sought
+ when:
+
+ C1*M1 + C2*M2 + ... + Cn*Mn >= S
+
+ The total credit in the pool, S, is calculated from the quotas, which
+ are currently allocated to the pool as follows:
+
+ S = Q1*M1 + Q2*M2 + ... + Qn*Mn
+
+ If services or rating-groups are added to or removed from the pool,
+ then the total credit is adjusted appropriately. Note that when the
+ total credit is adjusted because services or rating-groups are
+ removed from the pool, the value that needs to be removed is the
+ consumed one (i.e., Cx*Mx).
+
+
+
+Bertz, et al. Standards Track [Page 21]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Re-authorizations for an individual service or rating-group may be
+ sought at any time -- for example, if a "non-pooled" quota is used up
+ or the Validity-Time expires.
+
+ Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same
+ G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit-
+ Control AVP (Section 8.16) along with the Granted-Service-Unit AVP,
+ these AVPs MUST have different CC-Unit-Type values, and they all draw
+ from the credit pool separately. For instance, if one multiplier for
+ time (M1t) and one multiplier for volume (M1v) are given, then the
+ used resources from the pool yield the sum of 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, these
+ units are handled independently from any credit pools and from any
+ other 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 change
+ mechanism (Section 5.1.1). Therefore, Diameter Credit-Control
+ clients and servers implementing the independent credit-control of
+ multiple services SHOULD leverage the credit pool concept when
+ supporting the tariff time change. The Diameter Credit-Control
+ server SHOULD include both the Tariff-Time-Change AVP and the
+ Tariff-Change-Usage AVP in two quota allocations in the Answer
+ message (i.e., two instances of the Multiple-Services-Credit-Control
+ AVP). One of the grants is allocated to be used before the potential
+ tariff change, while the second grant is for use after a tariff
+ change. Both granted unit quotas MUST contain the same Service-
+ Identifier and/or rating-group. This dual-quota mechanism ensures
+ that the overall reported used units would never exceed the credit
+ reservation. The Diameter Credit-Control client reports the used
+ units both before and after the tariff change in a single instance of
+ the Multiple-Services-Credit-Control AVP.
+
+ Failure handling for credit-control sessions is defined in
+ Section 5.7 and reflected in the basic credit-control state machines
+ defined in Section 7. Credit-control clients and servers
+ implementing the functionality of independent credit-control of
+ multiple services in a (sub-)session MUST ensure failure handling and
+ general behavior fully consistent with Sections 5.7 and 7 while
+ maintaining the ability 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 (Section 7) and restart the Tx timer (Section 13) every
+ time a CCR message with the value UPDATE_REQUEST is sent while they
+ are in PendingU state. When answers to all pending messages are
+
+
+
+Bertz, et al. Standards Track [Page 22]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ received, the state machine moves to Open state, and the Tx timer is
+ stopped. Naturally, when a problem is detected and acted upon per
+ Section 5.7, all of the ongoing services are affected (e.g., failover
+ to a backup server affects all of the CCR messages in the PendingU
+ queue).
+
+ Since the client may send CCR messages with the value UPDATE_REQUEST
+ while in PendingU state (i.e., without waiting for an answer to
+ ongoing credit re-authorization), the time space between these
+ requests may be very short, and the server may not have received the
+ previous request(s) yet. Therefore, in this situation the server may
+ receive out-of-sequence requests and SHOULD NOT consider this an
+ error condition. A proper answer is to be returned to each of those
+ requests.
+
+5.2. First Interrogation
+
+ When session-based credit-control is required (e.g., the
+ authentication server indicated a prepaid user), the first
+ interrogation MUST be sent before the Diameter Credit-Control client
+ allows any service events for the end user. The CC-Request-Type AVP
+ is set to the value INITIAL_REQUEST in the request message.
+
+ If the Diameter Credit-Control client knows the cost of the service
+ event (e.g., a content server delivering ringing tones may know their
+ cost) the monetary amount to be charged is included in the Requested-
+ Service-Unit AVP. If the Diameter Credit-Control client does not
+ know the cost of the service event, the Requested-Service-Unit AVP
+ MAY contain the number of requested service events. Where the
+ Multiple-Services-Credit-Control AVP is used, it MUST contain the
+ Requested-Service-Unit AVP to indicate that the quota for the
+ associated service/rating-group is requested. In the case of
+ multiple services, the Service-Identifier AVP or the Rating-Group AVP
+ within the Multiple-Services-Credit-Control AVP always indicates the
+ service concerned. Additional service event information to be rated
+ MAY be sent as service-specific AVPs or MAY be sent within the
+ Service-Parameter-Info AVP at the command level. The
+ Service-Context-Id AVP indicates the service-specific document
+ applicable to the request.
+
+ The Event-Timestamp AVP SHOULD be included in the request and
+ contains the time when the service event is requested in the Service
+ Element. The Subscription-Id AVP or the Subscription-Id-Extension
+ AVP SHOULD be included to identify the end user in the credit-control
+ server. The credit-control client MAY include the User-Equipment-
+ Info AVP or User-Equipment-Info-Extension AVP so that the
+
+
+
+
+
+Bertz, et al. Standards Track [Page 23]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ credit-control server has some indication of the type and
+ capabilities of the end-user access device. How the credit-control
+ server uses this information is outside the scope of this document.
+
+ The credit-control server SHOULD rate the service event and make a
+ credit reservation from the end user's account that covers the cost
+ of the service event. If the type of the Requested-Service-Unit AVP
+ is "money", no rating is needed, but the corresponding monetary
+ amount is reserved from the end user's account.
+
+ The credit-control server returns the Granted-Service-Unit AVP in the
+ Answer message to the Diameter Credit-Control client. The Granted-
+ Service-Unit AVP contains the amount of service units that the
+ Diameter Credit-Control client can provide to the end user until a
+ new 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 of the 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 one
+ Answer message. However, if multiple quotas are conveyed to the
+ credit-control client in the Multiple-Services-Credit-Control AVPs,
+ it is possible to carry two instances of the same unit type
+ associated to a service-identifier/rating-group. This is typically
+ the case when a tariff time change is expected and the credit-control
+ server wants to make a distinction between the granted quota before
+ the tariff change and the granted quota after the tariff change.
+
+ If the credit-control server determines that no further control is
+ needed for the service, it MAY include the result code indicating
+ that the credit-control is not applicable (e.g., if the service is
+ free of charge). This result code, at the command level, implies
+ that the credit-control session is to be terminated.
+
+ The Credit-Control-Answer message MAY also include the Final-Unit-
+ Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that
+ the Answer message contains the final units for the service. After
+ the end user has consumed these units, the Diameter Credit-Control
+ client MUST behave as described in Section 5.6.
+
+ This document defines two different approaches for performing the
+ first interrogation to be used in different network architectures.
+ The first approach uses credit-control messages after the user's
+ authorization and authentication take place. The second approach
+ uses (1) service-specific authorization messages to perform the first
+
+
+
+Bertz, et al. Standards Track [Page 24]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ interrogation during the user's authorization/authentication phase
+ and (2) credit-control messages for the intermediate and final
+ interrogations. If an implementation of the credit-control client
+ supports both methods, determining which method to use SHOULD be
+ configurable.
+
+ In service environments such as NAS environments, it is desired to
+ perform the first interrogation as part of the authorization/
+ authentication process for the sake of protocol efficiency. Further
+ credit authorizations after the first interrogation are performed
+ with credit-control commands defined in this specification.
+ Implementations of credit-control clients operating in the
+ environments mentioned in this document SHOULD support this method.
+ If the credit-control server and AAA server are separate physical
+ entities, the Service Element sends the request messages to the AAA
+ server, which then issues an appropriate request or proxies the
+ received request forward to the credit-control server.
+
+ In other service environments, such as the 3GPP network and some SIP
+ scenarios, there is a substantial decoupling between registration/
+ access to the network and the actual service request (i.e., the
+ authentication/authorization is executed once during registration/
+ access to the network and is not executed for every service event
+ requested by the subscriber). In these environments, it is more
+ appropriate to perform the first interrogation after the user has
+ been authenticated and authorized. The first, intermediate, and
+ final interrogations are executed with credit-control commands
+ defined in this specification.
+
+ Other IETF standards or standards developed by other standardization
+ bodies may define the most suitable method in their architectures.
+
+5.2.1. First Interrogation after Authorization and Authentication
+
+ The Diameter Credit-Control client in the Service Element may get
+ information from the authorization server as to whether
+ credit-control is required, based on its knowledge of the end user.
+ If credit-control is required, the credit-control server needs to be
+ contacted prior to initiating service delivery to the end user. The
+ accounting protocol and the credit-control protocol can be used in
+ parallel. The authorization server may also determine whether the
+ parallel accounting stream is required.
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 25]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Figure 3 illustrates the case where both protocols are used in
+ parallel and the Service Element sends credit-control messages
+ directly to the credit-control server. More credit-control sequence
+ examples are given in Appendix A.
+
+ Diameter
+ End 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 | |
+ | |<-------------------| |
+
+ ACR: Accounting-Request
+ ACA: Accounting-Answer
+
+ Figure 3: Protocol Example with First Interrogation
+ after User's Authorization/Authentication
+
+
+
+
+
+Bertz, et al. Standards Track [Page 26]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+5.2.2. First Interrogation Included with Authorization Messages
+
+ The Diameter Credit-Control client in the Service Element MUST
+ actively co-operate with the authorization/authentication client in
+ the construction of the AA-Request by adding appropriate
+ Credit-Control AVPs. The credit-control client MUST add the
+ Credit-Control AVP to indicate credit-control capabilities and MAY
+ add other relevant credit-control-specific AVPs to the proper
+ authorization/authentication command to perform the first
+ interrogation toward the home Diameter AAA server. The
+ Auth-Application-Id is set to the appropriate value, as defined in
+ service-specific authorization/authentication application document
+ (e.g., [RFC7155] [RFC4004]). The home Diameter AAA server
+ authenticates/authorizes the subscriber and determines whether
+ credit-control is required.
+
+ If credit-control is not required for the subscriber, the home
+ Diameter AAA server will respond as usual, with an appropriate
+ AA-Answer message. If credit-control is required for the subscriber
+ and the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION
+ was present in the authorization request, the home AAA server MUST
+ contact 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
+ home AAA server MUST send an authorization reject Answer message.
+
+ The Diameter AAA server supporting credit-control is required to send
+ the Credit-Control-Request command (CCR) defined in this document to
+ the credit-control server. The Diameter AAA server populates the CCR
+ based on service-specific AVPs used for input to the rating process,
+ and possibly on Credit-Control AVPs received in the AA-Request. The
+ credit-control server will reserve money from the user's account,
+ will rate the request, and will send a Credit-Control-Answer message
+ to the home Diameter AAA server. The Answer message includes the
+ Granted-Service-Unit AVP(s) and MAY include other credit-control-
+ specific AVPs, as appropriate. Additionally, the credit-control
+ server MAY set the Validity-Time and MAY include the CCFH and the
+ DDFH to determine what to do if the sending of credit-control
+ messages to the credit-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
+ AA-Answer with the received Credit-Control AVPs and with the
+ appropriate service attributes according to the authorization/
+ authentication-specific application (e.g., [RFC7155] [RFC4004]). It
+ will then forward the packet to the credit-control client. If the
+ home Diameter AAA server receives a credit-control reject message, it
+
+
+
+
+Bertz, et al. Standards Track [Page 27]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ will simply generate an appropriate authorization reject message to
+ the credit-control client, including the credit-control-specific
+ error code.
+
+ In this model, the credit-control client sends further credit-control
+ messages to the credit-control server via the home Diameter AAA
+ server. Upon receiving a successful authorization Answer message
+ with the Granted-Service-Unit AVP(s), the credit-control client will
+ grant the service to the end user and will generate an intermediate
+ Credit-Control-Request, if required, by using credit-control
+ commands. The CC-Request-Number of the first UPDATE_REQUEST MUST be
+ set to 1 (for details regarding how to produce a unique value for the
+ CC-Request-Number AVP, see Section 8.2).
+
+ If service-specific re-authorization is performed (i.e., the
+ authorization lifetime expires), the credit-control client MUST add
+ to the service-specific re-authorization request the Credit-Control
+ AVP with a value set to RE_AUTHORIZATION to indicate that the
+ credit-control server MUST NOT be contacted. When session-based
+ credit-control is used for the subscriber, a constant credit-control
+ message stream flows through the home Diameter AAA server. The home
+ Diameter AAA server can make use of this credit-control message flow
+ to deduce that the user's activity is ongoing; therefore, it is
+ recommended to set the authorization lifetime to a reasonably high
+ value when credit-control is used for the subscriber.
+
+ In this scenario, the home Diameter AAA server MUST advertise support
+ for the credit-control application to its peers during the capability
+ exchange process.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 28]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Figure 4 illustrates the use of authorization/authentication messages
+ to perform the first interrogation. The parallel accounting stream
+ is not shown in the figure.
+
+ Diameter
+ Service Element AAA Server CC Server
+ End User (CC Client)
+ | 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 4: Protocol Example with Use of Authorization Messages
+ for the First Interrogation
+
+5.3. Intermediate Interrogation
+
+ When all the granted service units for one unit type are spent by the
+ end user or the Validity-Time has expired, the Diameter
+ Credit-Control client MUST send a new Credit-Control-Request to the
+ credit-control server. In the event that credit-control for multiple
+ services is applied in one credit-control session (i.e., units
+ associated to Service-Identifier(s) or the rating-group are granted),
+ a new Credit-Control-Request MUST be sent to the credit-control
+
+
+
+Bertz, et al. Standards Track [Page 29]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ server when the credit reservation has been wholly consumed or upon
+ expiration of the Validity-Time. It is always up to the Diameter
+ Credit-Control client to send a new request well in advance of the
+ expiration of the previous request in order to avoid interruption in
+ the Service Element. 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 the
+ rating of the current service events. In this case, a spontaneous
+ update (a new Credit-Control-Request) SHOULD be sent, including
+ information related to the service event, even if all the granted
+ service units have not been spent or the Validity-Time has not
+ expired.
+
+ When the used units are reported to the credit-control server, the
+ credit-control client will not have any units in its possession
+ before new granted units are received from the credit-control server.
+ When the new granted units are received, these units apply from the
+ point 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 single
+ rating-group, or a pool within the (sub-)session.
+
+ The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the
+ intermediate request message. The Subscription-Id AVP or
+ Subscription-Id-Extension AVP SHOULD be included in the intermediate
+ message to identify the end user in the credit-control server. The
+ Service-Context-Id AVP indicates the service-specific document
+ applicable to the request.
+
+ The Requested-Service-Unit AVP MAY contain the new amount of
+ requested service units. Where the Multiple-Services-Credit-Control
+ AVP is used, it MUST contain the Requested-Service-Unit AVP if a new
+ quota is requested for the associated service/rating-group. The
+ Used-Service-Unit AVP contains the amount of used service units
+ measured from the point when the service became active or, if interim
+ interrogations are used during the session, from the point when the
+ previous measurement ended. The same unit types used in the previous
+ message SHOULD be used. If several unit types were included in the
+ previous Answer message, the used service units for each unit type
+ MUST be reported.
+
+ The Event-Timestamp AVP SHOULD be included in the request and
+ contains the time of the event that triggered the sending of the new
+ Credit-Control-Request.
+
+
+
+
+Bertz, et al. Standards Track [Page 30]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The credit-control server MUST deduct the used amount from the
+ end user'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 the requested service event.
+
+ A Credit-Control-Answer message with the CC-Request-Type AVP set to
+ the value UPDATE_REQUEST MAY include the Cost-Information AVP
+ containing the accumulated cost estimation for the session, without
+ taking any credit reservations into account.
+
+ The Credit-Control-Answer message MAY also include the Final-Unit-
+ Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that
+ the Answer message contains the final units for the service. After
+ the end user has consumed these units, the Diameter Credit-Control
+ client MUST behave as described in Section 5.6.
+
+ There can be several intermediate interrogations within a session.
+
+5.4. Final Interrogation
+
+ When the end user terminates the service session or when graceful
+ 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-Type
+ AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id
+ AVP indicates the service-specific document applicable to the
+ request.
+
+ The Event-Timestamp AVP SHOULD be included in the request and
+ contains the time when the session was terminated.
+
+ The Used-Service-Unit AVP contains the amount of used service units
+ measured from the point when the service became active or, if interim
+ interrogations are used during the session, from the point when the
+ previous measurement ended. If several unit types were included in
+ the previous Answer message, the used service units for each unit
+ type MUST be reported.
+
+ After final interrogation, the credit-control server MUST refund the
+ reserved credit amount not used to the end user's account and deduct
+ the used monetary amount from the end user's account.
+
+ A Credit-Control-Answer message with the CC-Request-Type AVP set to
+ the value TERMINATION_REQUEST MAY include the Cost-Information AVP
+ containing the estimated total cost for the session in question.
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 31]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ If the user logs off during an ongoing credit-control session or if
+ the user becomes logged off for some other reason (e.g., a final-unit
+ indication causes user logoff according to local policy), the Service
+ Element, according to application-specific policy, may send a
+ Session-Termination-Request (STR) to the home Diameter AAA server as
+ usual [RFC6733]. Figure 5 illustrates the case when the final-unit
+ indication causes user logoff upon consumption of the final granted
+ units and the generation of an STR.
+
+ The Diameter AAA server responds with a Session-Termination-Answer
+ (STA).
+
+ Service Element AAA Server CC Server
+ End 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 5: User Disconnected Due to Exhausted Account
+
+5.5. Server-Initiated Credit Re-authorization
+
+ The Diameter Credit-Control application supports server-initiated
+ re-authorization. The credit-control server MAY optionally initiate
+ the credit re-authorization by issuing a Re-Auth-Request (RAR) as
+ defined in the Diameter base protocol [RFC6733]. The
+
+
+
+Bertz, et al. Standards Track [Page 32]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Auth-Application-Id in the RAR message is set to 4 to indicate
+ "Diameter Credit Control", and the Re-Auth-Request-Type is set to
+ AUTHORIZE_ONLY.
+
+ Section 5.1.2 defines the feature to enable credit-control for
+ multiple services within a single (sub-)session where the server can
+ authorize credit usage at a different level of granularity. Further,
+ the server may provide credit resources to multiple services or
+ rating-groups as a pool (see Section 5.1.2 for details and
+ definitions). Therefore, the server, based on its service logic and
+ its knowledge of the ongoing session, can decide to request credit
+ re-authorization for a whole (sub-)session, a single credit pool, a
+ single service, or a single rating-group. To request credit
+ re-authorization for a credit pool, the server includes in the RAR
+ message 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 or
+ the 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 RAR message.
+
+ If a credit re-authorization is not already ongoing (i.e., the
+ credit-control session is in Open state), a credit-control client
+ that receives an RAR message with Session-Id equal to a currently
+ active credit-control session MUST acknowledge the request by sending
+ the Re-Auth-Answer (RAA) message and MUST initiate the credit
+ re-authorization toward the server by sending a Credit-Control-
+ Request message with the CC-Request-Type AVP set to the value
+ UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS)
+ SHOULD be used in the RAA message to indicate that an additional
+ message (i.e., a CCR message with the value UPDATE_REQUEST) is
+ required to complete the procedure. If a quota was allocated to the
+ service, the credit-control client MUST report the used quota in the
+ Credit-Control-Request. Note that the end user does not need to be
+ prompted for the credit re-authorization, since the credit
+ re-authorization is transparent to the user (i.e., it takes place
+ exclusively between the credit-control client and the credit-control
+ server).
+
+ Where multiple services in a user's session are supported, the
+ procedure in the above paragraph will be executed at the granularity
+ requested by the server in the RAR message.
+
+ If credit re-authorization is ongoing at the time when the RAR
+ message is received (i.e., an RAR-CCR collision), the credit-control
+ client successfully acknowledges the request but does not initiate a
+ new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS)
+
+
+
+Bertz, et al. Standards Track [Page 33]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ SHOULD be used in the RAA message to indicate that a credit
+ re-authorization procedure is already ongoing (i.e., the client was
+ in PendingU state when the RAR was received). The credit-control
+ server SHOULD process the Credit-Control-Request as if it was
+ received in answer to the server-initiated credit re-authorization
+ and should consider the server-initiated credit re-authorization
+ process successful upon reception of the RAA message.
+
+ When multiple services are supported in a user's session, the server
+ may request credit re-authorization for a credit pool (or for the
+ (sub-)session) while a credit re-authorization is already ongoing for
+ some of the services or rating-groups. In this case, the client
+ acknowledges the server request with an RAA message and MUST send a
+ new Credit-Control-Request message to perform re-authorization for
+ the remaining services/rating-groups. The Result-Code 2002
+ (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to
+ indicate that an additional message (i.e., a CCR message with the
+ value UPDATE_REQUEST) is required to complete the procedure. The
+ server processes the received requests and returns an appropriate
+ answer to both requests.
+
+ The above-defined procedures are enabled for each of the possibly
+ active Diameter Credit-Control sub-sessions. The server MAY request
+ re-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 Termination
+
+ When the user's account runs out of money, the user may not be
+ allowed to compile additional chargeable events. However, the home
+ service provider may offer some services -- for instance, access to a
+ service portal where it is possible to refill the account -- from
+ which the user is allowed to benefit for a limited time. The length
+ of this time is usually dependent on the home service provider
+ policy.
+
+ This section defines the optional graceful service termination
+ feature. This feature MAY be supported by the credit-control server.
+ Credit-control client implementations MUST support the Final-Unit-
+ Indication AVP or QoS-Final-Unit-Indication AVP with at least the
+ teardown of the ongoing service session once the subscriber has
+ consumed all the final granted units.
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 34]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Where independent credit-control of multiple services in a single
+ credit-control (sub-)session is supported, it is possible to use
+ graceful service termination for each of the services/rating-groups
+ independently. Naturally, the graceful service termination process
+ defined in the following subsections will apply to the specific
+ service/rating-group as requested by the server.
+
+ In some service environments (e.g., NAS), graceful service
+ termination may be used to redirect the subscriber to a service
+ portal for online balance refill or other services offered by the
+ home service provider. In this case, the graceful service
+ termination process installs a set of packet filters to restrict the
+ user's access capability only to/from the specified destinations.
+ All the IP packets not matching the filters will be dropped or,
+ possibly, redirected to the service portal. The user may also be
+ sent an appropriate notification as to why the access has been
+ limited. These actions may be communicated explicitly from the
+ server to the client or may be configured "per service" at the
+ client. Explicitly signaled redirection or restriction instructions
+ always take precedence over configured ones.
+
+ It is also possible to use graceful service termination to connect
+ the prepaid user to a top-up server that plays an announcement and
+ prompts the user to replenish the account. In this case, the
+ credit-control server sends only the address of the top-up server
+ where the prepaid user shall be connected after the final granted
+ units have been consumed. An example of this case is given in
+ Appendix A.7.
+
+ The credit-control server MAY initiate graceful service termination
+ by including the Final-Unit-Indication AVP or the
+ QoS-Final-Unit-Indication AVP in the Credit-Control-Answer to
+ indicate that the message contains the final units for the service.
+
+ When the credit-control client receives the Final-Unit-Indication AVP
+ or the QoS-Final-Unit-Indication AVP in the answer from the server,
+ its behavior depends on the value indicated in the Final-Unit-Action
+ AVP. The server may request the following actions: TERMINATE,
+ REDIRECT, or RESTRICT_ACCESS.
+
+ Figure 6 illustrates the graceful service termination procedure
+ described in the following subsections.
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 35]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Diameter
+ End 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-Units)|
+ | | | CCA(Granted-Units)|<====================|
+ | Restrictions ->+ |<====================| |
+ | removed | | |
+ | : | | |
+ | OR | CCR(Update) | |
+ | Validity-Time ->|-------------------->| CCR(Update) |
+ | expires | |-------------------->|
+ | | | CCA(Granted-Units)|
+ | | CCA(Granted-Units)|<--------------------|
+ | Restrictions ->|<--------------------| |
+ | removed | | |
+
+ Figure 6: Optional Graceful Service Termination Procedure
+
+
+
+Bertz, et al. Standards Track [Page 36]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ In addition, the credit-control server MAY reply with the Final-Unit-
+ Indication AVP or QoS-Final-Unit-Indication AVP holding a Granted-
+ Service-Unit (G-S-U) with a zero grant, indicating that the service
+ SHOULD be terminated immediately, and no further reporting is
+ required. Figure 7 illustrates a graceful service termination
+ procedure that applies immediately after receiving a zero grant.
+
+ Diameter
+ End User Service Element AAA Server CC Server
+ (CC Client)
+ | Service Delivery | | |
+ |<----------------->| | |
+ | |CCR(Update, Used-Units) |
+ | |--------------------->|CCR(Update, Used-Units)
+ | : | |-------------------->|
+ | : | |CCA(Final-Unit, Action,
+ | : | | Zero G-S-U)
+ | : | |<--------------------|
+ | |CCA(Final-Unit, Action, |
+ | | Zero G-S-U) |
+ | |<---------------------| |
+ | /////////////// | | |
+ |/Action and // | | |
+ |/Restrictions // | | |
+ |/Start // | | |
+ | ///////////// | | |
+ | : | | |
+ | : | | |
+
+ Figure 7: Optional Immediate Graceful Service Termination Procedure
+
+5.6.1. Terminate Action
+
+ The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP
+ with Final-Unit-Action set to TERMINATE does not include any other
+ information. When the subscriber has consumed the final granted
+ units, the Service Element MUST terminate the service. This is the
+ default handling applicable whenever the credit-control client
+ receives an unsupported Final-Unit-Action value and MUST be supported
+ by all the Diameter Credit-Control client implementations conforming
+ to this specification. A final Credit-Control-Request message to the
+ credit-control server MUST be sent if the Final-Unit-Indication AVP
+ or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was
+ present at the command level. The CC-Request-Type AVP in the request
+ is set to the value TERMINATION_REQUEST.
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 37]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+5.6.2. Redirect Action
+
+ The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP
+ with Final-Unit-Action set to REDIRECT indicates to the Service
+ Element supporting this action that, upon consumption of the final
+ granted units, the user MUST be redirected to the address specified
+ in the Redirect-Server AVP or Redirect-Server-Extension AVP as
+ follows.
+
+ The credit-control server sends the Redirect-Server AVP or Redirect-
+ Server-Extension AVP in the Credit-Control-Answer message. In such a
+ case, the Service Element MUST redirect or connect the user to the
+ destination specified in the Redirect-Server AVP or Redirect-Server-
+ Extension AVP, if possible. When the end user is redirected (by
+ using protocols other than Diameter) to the specified server or
+ connected to the top-up server, an additional authorization (and
+ possibly authentication) may be needed before the subscriber can
+ replenish the account; however, this scenario is out of scope for
+ this specification.
+
+ In addition to the Redirect-Server AVP or Redirect-Server-Extension
+ AVP, the credit-control server MAY include one or more Restriction-
+ Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more
+ Filter-Id AVPs in the Credit-Control-Answer message to enable the
+ user to access other services (for example, zero-rated services). In
+ such a case, the access device MUST treat all packets according to
+ the Restriction-Filter-Rule AVPs, Filter-Rule AVPs, and the rules
+ referred to by the Filter-Id AVP. After treatment is applied
+ according to these rules, all traffic that has not been dropped or
+ already forwarded MUST be redirected to the destination specified in
+ the Redirect-Server AVP or Redirect-Server-Extension AVP.
+
+ An entity other than the credit-control server may provision the
+ access device with appropriate IP packet filters to be used in
+ conjunction with the Diameter Credit-Control application. This case
+ is considered in Section 5.6.3.
+
+ When the final granted units have been consumed, the credit-control
+ client MUST perform an intermediate interrogation. The purpose of
+ this interrogation is to indicate to the credit-control server that
+ the specified action started and to report the used units. The
+ credit-control server MUST deduct the used amount from the end user's
+ account but MUST NOT make a new credit reservation. The
+ credit-control client, however, may send intermediate interrogations
+ before all the final granted units have been consumed for which
+ rating and money reservation may be needed -- for instance, upon
+ Validity-Time expiration or upon mid-session service events that
+ affect the rating of the current service. Therefore, the
+
+
+
+Bertz, et al. Standards Track [Page 38]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ credit-control client MUST NOT include any rating-related AVPs in the
+ request sent once all the final granted units have been consumed, as
+ an indication to the server that (1) the requested final unit action
+ started and (2) rating and money reservation are not required (when
+ the Multiple-Services-Credit-Control AVP is used, the Service-
+ Identifier AVP or the Rating-Group AVP is included to indicate the
+ services concerned). Naturally, the Credit-Control-Answer message
+ does not contain any granted service units and MUST include the
+ Validity-Time AVP to indicate to the credit-control client how long
+ the subscriber is allowed to use network resources before a new
+ intermediate interrogation is sent to the server.
+
+ At the expiry of Validity-Time, the credit-control client sends a
+ Credit-Control-Request (UPDATE_REQUEST) as usual. This message does
+ not include the Used-Service-Unit AVP, as there is no allotted quota
+ to report. The credit-control server processes the request and MUST
+ perform the credit reservation. If during this time the subscriber
+ did not replenish their account, whether they will be disconnected or
+ will be granted access to services not controlled by a credit-control
+ server for an unlimited time is dependent on the home service
+ provider policy. (Note: The latter option implies that the Service
+ Element should not remove the restriction filters upon termination of
+ the credit-control.) The server will return the appropriate
+ Result-Code (see Section 9.1) in the Credit-Control-Answer message in
+ order to implement the policy-defined action. Otherwise, a new quota
+ will be returned, and the Service Element MUST remove all the
+ possible restrictions activated by the graceful service termination
+ process and continue the credit-control session and service session
+ as usual.
+
+ The credit-control client may not wait until the expiration of the
+ Validity-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 took place. An example of this case is given in Appendix A.8
+ (Figure 18).
+
+ Note that the credit-control server may already have initiated the
+ above-described process for the first interrogation. However, the
+ user's account might be empty when this first interrogation is
+ performed. In this case, the subscriber can be offered a chance to
+ replenish the account and continue the service. When the
+ credit-control client receives (at either the session level or a
+ service-specific level) a Final-Unit-Indication AVP or QoS-Final-
+ Unit-Indication AVP, together with Validity-Time AVPs, but without a
+ Granted-Service-Unit AVP, it immediately starts the graceful service
+ termination process without sending any messages to the server. An
+ example of this case is illustrated in Appendix A.8 (Figure 18).
+
+
+
+Bertz, et al. Standards Track [Page 39]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+5.6.3. Restrict Access Action
+
+ A Final-Unit-Indication AVP with Final-Unit-Action set to
+ RESTRICT_ACCESS indicates to the device supporting this action that,
+ upon consumption of the final granted units, the user's access MUST
+ be restricted according to the IP packet filters given in the
+ Restriction-Filter-Rule AVP(s) or according to the IP packet filters
+ identified by the Filter-Id AVP(s). The credit-control server SHOULD
+ include either the Restriction-Filter-Rule AVP or the Filter-Id AVP
+ in the Final-Unit-Indication group AVP of the Credit-Control-Answer
+ message.
+
+ A QoS-Final-Unit-Indication AVP with Final-Unit-Action set to
+ RESTRICT_ACCESS indicates to the device supporting this action that,
+ upon consumption of the final granted units, the actions specified in
+ Filter-Rule AVP(s) MUST restrict the traffic according to the
+ classifiers in the Filter-Rule AVP(s). If one or more Filter-Id AVPs
+ are provided in the Credit-Control-Answer message, the credit-control
+ client MUST restrict the traffic according to the IP packet filters
+ identified by the Filter-Id AVP(s). The credit-control server SHOULD
+ include either the Filter-Rule AVP or the Filter-Id AVP in the
+ QoS-Final-Unit-Indication group AVP of the Credit-Control-Answer
+ message.
+
+ If both the Final-Unit-Indication AVP and the QoS-Final-Unit-
+ Indication AVP exist in the Credit-Control-Answer message, a
+ credit-control client that supports the QoS-Final-Unit-Indication AVP
+ SHOULD follow the directives included in the QoS-Final-Unit-
+ Indication AVP and SHOULD ignore the Final-Unit-Indication AVP.
+
+ An entity other than the credit-control server may provision the
+ access device with appropriate IP packet filters to be used in
+ conjunction with the Diameter Credit-Control application. Such an
+ entity may, for instance, configure the access device with IP flows
+ to be passed when the Diameter Credit-Control application indicates
+ RESTRICT_ACCESS or REDIRECT. The access device passes IP packets
+ according to the filter rules that may have been received in the
+ Credit-Control-Answer message, in addition to those rules that may
+ have been configured by the other entity. However, when the user's
+ account cannot cover the cost of the requested service, the action
+ taken is the responsibility of the credit-control server that
+ controls the prepaid subscriber.
+
+ If another entity working in conjunction with the Diameter
+ Credit-Control application already provisions the access device with
+ all the required filter rules for the end user, the credit-control
+ server presumably need not send any additional filters. Therefore,
+ it is RECOMMENDED that credit-control server implementations
+
+
+
+Bertz, et al. Standards Track [Page 40]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ supporting graceful service termination be configurable for sending
+ the Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id
+ AVP, or none of the above.
+
+ When the final granted units have been consumed, the credit-control
+ client MUST perform an intermediate interrogation. The
+ credit-control client and the credit-control server process this
+ intermediate interrogation and execute subsequent procedures, as
+ specified in Section 5.6.2.
+
+ The credit-control server may initiate graceful service termination
+ when replying with the action RESTRICT_ACCESS for the first
+ interrogation. This is similar to the behavior specified in
+ Section 5.6.2.
+
+5.6.4. Usage of the Server-Initiated Credit Re-authorization
+
+ Once the subscriber replenishes the account, they presumably expect
+ all the restrictions applied by the graceful service termination
+ procedure to be removed immediately and unlimited service access to
+ be resumed. For the best user experience, the credit-control server
+ implementation MAY support the server-initiated credit
+ re-authorization (see Section 5.5). In such a case, upon the
+ successful account 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 the Credit-Control-Request message with the CC-Request-Type
+ AVP set to the value UPDATE_REQUEST. The Used-Service-Unit AVP is
+ not included in the request, as there is no allotted quota to report.
+ The Requested-Service-Unit AVP MAY be included in the request. After
+ the credit-control client successfully receives the Credit-Control-
+ Answer with a new Granted-Service-Unit AVP, all the possible
+ restrictions activated for the purpose of graceful service
+ termination MUST be removed in the Service Element. The
+ credit-control session and the service session continue as usual.
+
+5.7. Failure Procedures
+
+ The CCFH, as described in this section, determines the behavior of
+ the credit-control client in fault situations. The CCFH may be
+ (1) received from the Diameter home AAA server, (2) received from the
+ credit-control server, or (3) configured locally. The CCFH value
+ received from the home AAA server overrides the locally configured
+ value. The CCFH value received from the credit-control server in the
+ Credit-Control-Answer message always overrides any existing values.
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 41]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The authorization server MAY include the Accounting-Realtime-Required
+ AVP to determine what to do if the sending of accounting records to
+ the accounting server has been temporarily prevented, as defined in
+ [RFC6733]. It is RECOMMENDED that the client complement the
+ credit-control failure procedures with a backup accounting flow
+ toward an accounting server. By using different combinations of the
+ Accounting-Realtime-Required AVP and the CCFH, different safety
+ levels can be built. For example, by choosing a CCFH equal to
+ CONTINUE for the credit-control flow and an Accounting-Realtime-
+ Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the
+ service can be granted to the end user even if the connection to the
+ credit-control server is down, as long as the accounting server is
+ able to collect the accounting information and information exchange
+ is taking place between the accounting server and credit-control
+ server.
+
+ As the credit-control application is based on real-time bidirectional
+ communication between the credit-control client and the
+ credit-control server, the usage of alternative destinations and the
+ buffering of messages may not be sufficient in the event of
+ communication failures. Because the credit-control server has to
+ maintain session states, moving the credit-control message stream to
+ a backup server requires a complex context transfer solution.
+ Whether the credit-control message stream is moved to a backup
+ credit-control server during an ongoing credit-control session
+ depends 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
+ failure is detected with a peer, as described in [RFC6733]. As a
+ consequence, the credit-control server might receive duplicate
+ messages. These duplicate or out-of-sequence messages can be
+ detected in the credit-control server based on the credit-control
+ server session state machine (Section 7), Session-Id AVP, and
+ CC-Request-Number AVP.
+
+ If a failure occurs during an ongoing credit-control session, the
+ credit-control client may move the credit-control message stream to
+ an alternative server if the credit-control server indicated
+ FAILOVER_SUPPORTED in the CC-Session-Failover AVP. A secondary
+ credit-control server name, either received from the home Diameter
+ AAA server or configured locally, 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.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 42]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ For new credit-control sessions, failover to an alternative
+ credit-control server SHOULD be performed, if possible. For
+ instance, if an implementation of the credit-control client can
+ determine primary credit-control server unavailability, it can
+ establish the new credit-control sessions with a possibly available
+ secondary credit-control server.
+
+ The AAA transport profile [RFC3539] defines an application-layer
+ watchdog algorithm that enables failover from a peer that has failed
+ and is controlled by a watchdog timer (Tw) (defined in [RFC3539]).
+ The recommended default initial value for Tw (Twinit) is 30 seconds.
+ Twinit may be set as low as 6 seconds; however, according to
+ [RFC3539], setting too low a value for Twinit is likely to result in
+ an increased probability of duplicates, as well as an increase in
+ spurious failover and failback attempts. The Diameter base protocol
+ [RFC6733] is common to several different types of Diameter AAA
+ applications that may be run in the same Service Element. Therefore,
+ tuning the timer for Twinit to a lower value in order to satisfy the
+ requirements of real-time applications, such as the Diameter
+ Credit-Control application, will certainly cause the above-mentioned
+ problems. For prepaid services, however, the end user expects an
+ answer from the network in a reasonable time. Thus, the Diameter
+ Credit-Control client will react more quickly than would the
+ underlying base protocol. Therefore, this specification defines the
+ Tx timer (as defined in Section 13), which is used by the
+ credit-control client to supervise communication with the
+ credit-control server. When the Tx timer elapses, the credit-control
+ client takes action for the end user according to the CCFH.
+
+ When the Tx timer expires, the Diameter Credit-Control client always
+ terminates the service if the CCFH is set to the value TERMINATE.
+ The credit-control session may be moved to an alternative server only
+ if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER
+ is received before the Tx timer expires. Therefore, the value
+ TERMINATE is not appropriate if proper failover behavior is desired.
+
+ If the CCFH is set to the value CONTINUE or RETRY_AND_TERMINATE, the
+ service will be granted to the end user when the Tx timer expires.
+ An Answer message with granted units may arrive later if the base
+ protocol transport failover occurred in the path to the
+ credit-control server. (The Twinit default value is 3 times more
+ than the recommended Tx timeout value.) The credit-control client
+ SHOULD grant the service to the end user, start monitoring resource
+ usage, and wait for the possible late answer until the timeout of the
+ request (e.g., 120 seconds). If the request fails and the
+ CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the
+
+
+
+
+
+Bertz, et al. Standards Track [Page 43]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ credit-control client terminates or continues the service --
+ depending on the value set in the CCFH -- and MUST free all the
+ reserved resources for the credit-control session. If the protocol
+ error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or
+ the request times out and the CC-Session-Failover AVP is set to
+ FAILOVER_SUPPORTED, the credit-control client MAY send the request to
+ a backup server, if possible. If the credit-control client receives
+ a successful answer from the backup server, it continues the
+ credit-control session with such a server. If the retransmitted
+ request also fails, the credit-control client terminates or continues
+ the service -- depending on the value set in the CCFH -- and MUST
+ free all the reserved resources for the credit-control session.
+
+ If a communication failure occurs during the graceful service
+ termination procedure, the Service Element SHOULD always terminate
+ the ongoing service session.
+
+ If the credit-control server detects a failure during an ongoing
+ credit-control session, it will terminate the credit-control session
+ and return the reserved units back to the end user's account.
+
+ The supervision session timer Tcc (as defined in Section 13) is used
+ in 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 account
+ state SHOULD take place between the primary and secondary
+ credit-control servers. Implementations supporting credit-control
+ session failover MUST also ensure proper detection of duplicate or
+ out-of-sequence messages. Communication between the servers is
+ regarded as an implementation issue and is outside the scope of this
+ specification.
+
+6. One-Time Event
+
+ The one-time event is used when there is no need to maintain any
+ state in the Diameter Credit-Control server -- for example, inquiring
+ about the price of the service. The use of a one-time event implies
+ that the user has been authenticated and authorized beforehand.
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 44]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The one-time event can be used when the credit-control client wants
+ to know the cost of the service event or to check the account balance
+ without any credit reservations. It can also be used for refunding
+ service units on the user's account or for direct debiting without
+ any credit reservations. The one-time event is shown in Figure 8.
+
+ Diameter
+ End User Service Element AAA Server CC Server
+ (CC Client)
+ | Service Request | | |
+ |------------------>| | |
+ | | CCR(Event) | |
+ | |------------------->| CCR(Event) |
+ | | |------------------->|
+ | | | CCA(Granted-Units)|
+ | | CCA(Granted-Units)|<-------------------|
+ | Service Delivery |<-------------------| |
+ |<----------------->| | |
+
+ Figure 8: One-Time Event
+
+ In environments such as the 3GPP architecture, the one-time event can
+ be sent from the Service Element directly to the credit-control
+ server.
+
+6.1. Service Price Inquiry
+
+ The credit-control client may need to know the price of the service
+ event. Services offered by application service providers whose
+ prices are not known in the credit-control client might exist. The
+ end user might also want to get an estimate of the price of a service
+ event before requesting it.
+
+ A Diameter Credit-Control client requesting the cost information MUST
+ set the CC-Request-Type AVP equal to EVENT_REQUEST, include the
+ Requested-Action AVP set to PRICE_ENQUIRY, and set the requested
+ service event information in the Service-Identifier AVP in the
+ Credit-Control-Request message. Additional service event information
+ may be sent as service-specific AVPs or within the Service-Parameter-
+ Info AVP. The Service-Context-Id AVP indicates the service-specific
+ document applicable to the request.
+
+ The credit-control server calculates the cost of the requested
+ service event, but it does not perform any account-balance checks or
+ credit reservations from the account.
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 45]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The estimated cost of the requested service event is returned to the
+ credit-control client in the Cost-Information AVP in the
+ Credit-Control-Answer message.
+
+6.2. Balance Checks
+
+ The Diameter Credit-Control client may only have to verify that the
+ end user's account balance covers the cost of a certain service
+ without reserving any units from the account at the time of the
+ inquiry. This method does not guarantee that credit would be left
+ when the Diameter Credit-Control client requests the debiting of the
+ account with a separate request.
+
+ A Diameter Credit-Control client requesting a balance check MUST set
+ the CC-Request-Type AVP equal to EVENT_REQUEST, include a Requested-
+ Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP
+ or Subscription-Id-Extension AVP in order to identify the end user in
+ the credit-control server. The Service-Context-Id AVP indicates the
+ service-specific document applicable to the request.
+
+ The credit-control server makes the balance check, but it does not
+ make any credit reservations from the account.
+
+ The result of the balance check (ENOUGH_CREDIT/NO_CREDIT) is returned
+ to the credit-control client in the Check-Balance-Result AVP in the
+ Credit-Control-Answer message.
+
+6.3. Direct Debiting
+
+ There are certain service events for which service execution is
+ always successful in the service environment. The delay between the
+ service invocation and the actual service delivery to the end user
+ can be sufficiently long that the use of session-based credit-control
+ would lead to unreasonably long credit-control sessions. In these
+ cases, the Diameter Credit-Control client can use the one-time event
+ scenario for direct debiting. The Diameter Credit-Control client
+ SHOULD be sure that the requested service event execution would be
+ successful when this scenario is used.
+
+ In the Credit-Control-Request message, the CC-Request-Type AVP is set
+ to the value EVENT_REQUEST and the Requested-Action AVP is set to
+ DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id-
+ Extension AVP SHOULD be included to identify the end user in the
+ credit-control server. The Event-Timestamp AVP SHOULD be included in
+ the request and contain the time when the service event is requested
+ in the Service Element. The Service-Context-Id AVP indicates the
+ service-specific document applicable to the request.
+
+
+
+
+Bertz, et al. Standards Track [Page 46]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ If it knows the cost of the service event, the Diameter
+ Credit-Control client MAY include in the Requested-Service-Unit AVP
+ the monetary amount to be charged. If the Diameter Credit-Control
+ client does not know the cost of the service event, the Requested-
+ Service-Unit AVP MAY contain the number of requested service events.
+ The Service-Identifier AVP always indicates the service concerned.
+ Additional service event information to be rated MAY be sent as
+ service-specific AVPs or within the Service-Parameter-Info AVP.
+
+ The credit-control server SHOULD rate the service event and deduct
+ the corresponding monetary amount from the end user's account. If
+ the type of the Requested-Service-Unit AVP is "money", no rating is
+ needed, but the corresponding monetary amount is deducted from the
+ end user's account.
+
+ The credit-control server returns the Granted-Service-Unit AVP in the
+ Credit-Control-Answer message to the Diameter Credit-Control client.
+ The Granted-Service-Unit AVP contains the amount of service units
+ that the Diameter Credit-Control client can provide to the end user.
+ The type of the Granted-Service-Unit can be time, volume, service-
+ specific, or money, depending on the type of service event.
+
+ If the credit-control server determines that no credit-control is
+ needed for the service, it can include the result code indicating
+ that the credit-control is not applicable (e.g., the service is free
+ of charge).
+
+ For informative purposes, the Credit-Control-Answer message MAY also
+ include the Cost-Information AVP containing the estimated total cost
+ of the requested service.
+
+6.4. Refunds
+
+ Some services may refund service units to the end user's account --
+ for example, gaming services.
+
+ The credit-control client MUST set the CC-Request-Type AVP to the
+ value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in
+ the Credit-Control-Request message. The Subscription-Id AVP or
+ Subscription-Id-Extension AVP SHOULD be included to identify the
+ end user in the credit-control server. The Service-Context-Id AVP
+ indicates the service-specific document applicable to the request.
+
+ The Diameter Credit-Control client MAY include the monetary amount to
+ be refunded in the Requested-Service-Unit AVP. The Service-
+ Identifier AVP always indicates the service concerned. If the
+ Diameter Credit-Control client does not know the monetary amount to
+
+
+
+
+Bertz, et al. Standards Track [Page 47]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ be refunded, in addition to the Service-Identifier AVP it MAY send
+ service-specific AVPs or the Service-Parameter-Info AVP containing
+ additional service event information to be rated.
+
+ For informative purposes, the Credit-Control-Answer message MAY also
+ include the Cost-Information AVP containing the estimated monetary
+ amount of refunded units.
+
+6.5. Failure Procedure
+
+ Failover to an alternative credit-control server is allowed for a
+ one-time event, as the server is not maintaining session states. For
+ instance, if the credit-control client receives a protocol error
+ DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can resend the
+ request to an alternative server, if possible. There MAY be
+ protocol-transparent Diameter relays and redirect agents or Diameter
+ Credit-Control proxies between the credit-control client and
+ credit-control server. Failover may occur at any point in the path
+ between the credit-control client and the credit-control server if a
+ transport failure is detected with a peer, as described in [RFC6733].
+ Because there 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 [RFC6733], Appendix C.
+
+ When the credit-control client detects a communication failure with
+ the credit-control server, its behavior depends on the requested
+ action. The Tx timer (as defined in Section 13) is used in the
+ credit-control client to supervise communication with the
+ credit-control server.
+
+ If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and a
+ communication failure is detected, the credit-control client SHOULD
+ forward the request messages to an alternative credit-control server,
+ if possible. The secondary credit-control server name, if received
+ from the home Diameter AAA server, can be used as an address of the
+ backup server.
+
+ If the requested action is DIRECT_DEBITING, the DDFH controls the
+ credit-control client's behavior. The DDFH may be received from the
+ home Diameter AAA server or may be locally configured. The
+ credit-control server may also send the DDFH in any CCA messages to
+ be used for direct-debiting events compiled thereafter. The DDFH
+ value received from the home Diameter AAA server overrides the
+ locally configured value, and the DDFH value received from the
+ credit-control server in a Credit-Control-Answer message always
+ overrides any existing values.
+
+
+
+
+Bertz, et al. Standards Track [Page 48]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client
+ SHOULD NOT grant the service if, after a possible retransmission
+ attempt to an alternative credit-control server, the credit-control
+ client can eventually determine from the result code or error code in
+ the Answer message that units have not been debited. Otherwise, the
+ credit-control client SHOULD grant the service to the end user and
+ store the request in credit-control application-level non-volatile
+ storage. (Note that resending the request at a later time is not a
+ guarantee that the service will be debited, as the user's account may
+ be empty when the server successfully processes the request.) The
+ credit-control client MUST mark these request messages as possible
+ duplicates by setting the T flag in the command header as described
+ in [RFC6733], Section 3.
+
+ If the DDFH is set to CONTINUE, the service SHOULD be granted, even
+ if credit-control messages cannot be delivered and messages are not
+ buffered.
+
+ If the Tx timer expires, the credit-control client MUST continue the
+ service and wait for a possible late answer. If the request
+ times out, the credit-control client retransmits the request (marked
+ with the T flag) to a backup credit-control server, if possible. If
+ the retransmitted request also times out or if a temporary error is
+ received in answer, the credit-control client buffers the request if
+ the value of the DDFH is set to TERMINATE_OR_BUFFER. If a failed
+ answer is received for the retransmitted request, the credit-control
+ client frees all the resources reserved for the event message and
+ deletes the request regardless of the value of the DDFH.
+
+ The Credit-Control-Request with the requested action REFUND_ACCOUNT
+ should always be stored in credit-control application-level
+ non-volatile storage in case a temporary failure occurs. The
+ credit-control client MUST mark the retransmitted request message as
+ a possible duplicate by setting the T flag in the command header as
+ described in [RFC6733], Section 3.
+
+ For stored requests, the implementation may choose to limit the
+ number of retransmission attempts and to define a retransmission
+ interval.
+
+ Note that only one entity in the credit-control system SHOULD be
+ responsible for duplicate detection. If there is only one
+ credit-control server within the given realm, the credit-control
+ server may perform 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's account is not debited or credited multiple times for the
+ same service event.
+
+
+
+Bertz, et al. Standards Track [Page 49]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+7. Credit-Control Application State Machines
+
+ This section defines five credit-control application state machines.
+ The first four state machines are to be observed by credit-control
+ clients.
+
+ The first state machine describes session-based credit-control where
+ the first interrogation is executed as part of the authorization/
+ authentication process. The second state machine describes
+ session-based credit-control where the first interrogation is
+ executed after the authorization/authentication process. The
+ requirements regarding what has to be supported for these two state
+ machines are discussed in Section 5.2.
+
+ The third state machine describes session-based credit-control for
+ the intermediate and final interrogations. The fourth state machine
+ describes event-based credit-control. These two state machines are
+ to be observed by all implementations that conform to this
+ specification.
+
+ The fifth state machine describes the credit-control session from a
+ credit-control server's perspective.
+
+ Any event not listed in the state machines MUST be considered an
+ error condition, and a corresponding answer, if applicable, MUST be
+ returned to the originator of the message.
+
+ In Tables 3, 4, and 5, the event "failure to send" means that the
+ Diameter Credit-Control client is unable to communicate with the
+ desired destination or, if a failover procedure is supported, with a
+ possibly defined alternative destination (e.g., the request times out
+ and the Answer message is not received). This could be due to
+ (1) the peer being down or (2) a physical link failure in the path to
+ or from the credit-control server.
+
+ The event "temporary error" means that the Diameter Credit-Control
+ client received a protocol error notification (DIAMETER_TOO_BUSY,
+ DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the
+ Result-Code AVP of the Credit-Control-Answer command. This type of
+ notification may ultimately be received in answer to the
+ retransmitted request to a defined alternative destination, if
+ failover is supported.
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 50]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The event "failed answer" means that the Diameter Credit-Control
+ client received a non-transient failure (permanent failure)
+ notification in the Credit-Control-Answer command. This type of
+ notification may ultimately be received in answer to the
+ retransmitted request to a defined alternative destination, if
+ failover is supported.
+
+ The action "store request" means that a request is stored in
+ credit-control application-level non-volatile storage.
+
+ The event "not successfully processed" means that the credit-control
+ server could not process the message, e.g., due to an unknown
+ end user, an account being empty, or errors defined in [RFC6733].
+
+ The event "user service terminated" can be triggered for various
+ reasons, e.g., normal user termination, network failure, and ASR
+ (Abort-Session-Request). The Termination-Cause AVP contains
+ information about the reason for termination, as specified in
+ [RFC6733].
+
+ The Tx timer, which is used to control the waiting time in the
+ credit-control client in the Pending state, is stopped upon exit of
+ the Pending state. The stopping of the Tx timer is omitted in the
+ state machine when the new state is Idle, as moving to Idle state
+ implies the clearing of the session and all the variables associated
+ to it.
+
+ The states PendingI, PendingU, PendingT, PendingE, and PendingB stand
+ for pending states to wait for an answer to a credit-control request
+ related to Initial, Update, Termination, Event, or Buffered request,
+ respectively.
+
+ In Table 2, failover to a secondary server upon "temporary error" or
+ "failure to send" is not explicitly described. However, moving an
+ ongoing credit-control message stream to an alternative server is
+ possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED,
+ as described in Section 5.7.
+
+ Resending a credit-control event to an alternative server is
+ supported as described in Section 6.5.
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 51]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ +----------+-------------------------------+-------------+----------+
+ | State | Event | Action | New |
+ | | | | State |
+ +----------+-------------------------------+-------------+----------+
+ | Idle | Client or device requests | Send | PendingI |
+ | | access/service | AA-Request | |
+ | | | with added | |
+ | | | CC AVPs, | |
+ | | | start Tx | |
+ | | | timer | |
+ | | | | |
+ | PendingI | Successful answer to | Grant | Open |
+ | | AA-Request received | service to | |
+ | | | end user, | |
+ | | | stop Tx | |
+ | | | timer | |
+ | | | | |
+ | PendingI | Tx timer expired | Disconnect | Idle |
+ | | | user/dev | |
+ | | | | |
+ | PendingI | Failed AA-Answer received | Disconnect | Idle |
+ | | | user/dev | |
+ | | | | |
+ | PendingI | AA-Answer received with | Grant | Idle |
+ | | Result-Code equal to | service to | |
+ | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
+ | | | | |
+ | PendingI | User service terminated | Queue | PendingI |
+ | | | termination | |
+ | | | event | |
+ | | | | |
+ | PendingI | Change in rating condition | Queue | PendingI |
+ | | | changed | |
+ | | | rating | |
+ | | | condition | |
+ | | | event | |
+ +----------+-------------------------------+-------------+----------+
+
+ Table 2: Session-Based Client State Machine for the
+ First Interrogation with AA-Request
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 52]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ +----------+-------------------------------+-------------+----------+
+ | State | Event | Action | New |
+ | | | | State |
+ +----------+-------------------------------+-------------+----------+
+ | Idle | Client or device requests | Send CC | PendingI |
+ | | access/service | initial | |
+ | | | req., start | |
+ | | | Tx timer | |
+ | | | | |
+ | PendingI | Successful CC initial answer | Stop Tx | Open |
+ | | received | timer | |
+ | | | | |
+ | PendingI | Failure to send, or temporary | Grant | Idle |
+ | | error and CCFH equal to | service to | |
+ | | CONTINUE | end user | |
+ | | | | |
+ | PendingI | Failure to send, or temporary | Terminate | Idle |
+ | | error and CCFH equal to | end user's | |
+ | | TERMINATE or to | service | |
+ | | RETRY_AND_TERMINATE | | |
+ | | | | |
+ | PendingI | Tx timer expired and CCFH | Terminate | Idle |
+ | | equal to TERMINATE | end user's | |
+ | | | service | |
+ | | | | |
+ | PendingI | Tx timer expired and CCFH | Grant | PendingI |
+ | | equal to CONTINUE or to | service to | |
+ | | RETRY_AND_TERMINATE | end user | |
+ | | | | |
+ | PendingI | CC initial answer received | Terminate | Idle |
+ | | with Result-Code equal to | end user's | |
+ | | END_USER_SERVICE_DENIED or to | service | |
+ | | USER_UNKNOWN | | |
+ | | | | |
+ | PendingI | CC initial answer received | Grant | Idle |
+ | | with Result-Code equal to | service to | |
+ | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
+ | | | | |
+ | PendingI | Failed CC initial answer | Grant | Idle |
+ | | received and CCFH equal to | service to | |
+ | | CONTINUE | end user | |
+ | | | | |
+ | PendingI | Failed CC initial answer | Terminate | Idle |
+ | | received and CCFH equal to | end user's | |
+ | | TERMINATE or to | service | |
+ | | RETRY_AND_TERMINATE | | |
+ | | | | |
+
+
+
+
+Bertz, et al. Standards Track [Page 53]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ | PendingI | User service terminated | Queue | PendingI |
+ | | | termination | |
+ | | | event | |
+ | | | | |
+ | PendingI | Change in rating condition | Queue | PendingI |
+ | | | changed | |
+ | | | rating | |
+ | | | condition | |
+ | | | event | |
+ +----------+-------------------------------+-------------+----------+
+
+ Table 3: Session-Based Client State Machine for the
+ First Interrogation with CCR
+
+
+ +----------+-------------------------------+-------------+----------+
+ | State | Event | Action | New |
+ | | | | State |
+ +----------+-------------------------------+-------------+----------+
+ | Open | Granted unit elapses and no | Send CC | PendingU |
+ | | final-unit indication | update | |
+ | | received | req., start | |
+ | | | Tx timer | |
+ | | | | |
+ | Open | Granted unit elapses and | Terminate | PendingT |
+ | | final unit action equal to | end user's | |
+ | | TERMINATE received | service, | |
+ | | | send CC | |
+ | | | termination | |
+ | | | req. | |
+ | | | | |
+ | Open | Change in rating condition in | Send CC | PendingU |
+ | | queue | update | |
+ | | | req., start | |
+ | | | Tx timer | |
+ | | | | |
+ | Open | Service terminated in queue | Send CC | PendingT |
+ | | | termination | |
+ | | | req. | |
+ | | | | |
+ | Open | Change in rating condition or | Send CC | PendingU |
+ | | Validity-Time elapses | update | |
+ | | | req., start | |
+ | | | Tx timer | |
+ | | | | |
+ | Open | User service terminated | Send CC | PendingT |
+ | | | termination | |
+ | | | req. | |
+
+
+
+Bertz, et al. Standards Track [Page 54]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ | | | | |
+ | Open | RAR received | Send RAA | PendingU |
+ | | | followed by | |
+ | | | CC update | |
+ | | | req., start | |
+ | | | Tx timer | |
+ | | | | |
+ | PendingU | Successful CC update answer | Stop Tx | Open |
+ | | received | timer | |
+ | | | | |
+ | PendingU | Failure to send, or temporary | Grant | Idle |
+ | | error and CCFH equal to | service to | |
+ | | CONTINUE | end user | |
+ | | | | |
+ | PendingU | Failure to send, or temporary | Terminate | Idle |
+ | | error and CCFH equal to | end user's | |
+ | | TERMINATE or to | service | |
+ | | RETRY_AND_TERMINATE | | |
+ | | | | |
+ | PendingU | Tx timer expired and CCFH | Terminate | Idle |
+ | | equal to TERMINATE | end user's | |
+ | | | service | |
+ | | | | |
+ | PendingU | Tx timer expired and CCFH | Grant | PendingU |
+ | | equal to CONTINUE or to | service to | |
+ | | RETRY_AND_TERMINATE | end user | |
+ | | | | |
+ | PendingU | CC update answer received | Terminate | Idle |
+ | | with Result-Code equal to | end user's | |
+ | | END_USER_SERVICE_DENIED | service | |
+ | | | | |
+ | PendingU | CC update answer received | Grant | Idle |
+ | | with Result-Code equal to | service to | |
+ | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
+ | | | | |
+ | PendingU | Failed CC update answer | Grant | Idle |
+ | | received and CCFH equal to | service to | |
+ | | CONTINUE | end user | |
+ | | | | |
+ | PendingU | Failed CC update answer | Terminate | Idle |
+ | | received and CCFH equal to | end user's | |
+ | | TERMINATE or to | service | |
+ | | RETRY_AND_TERMINATE | | |
+ | | | | |
+ | PendingU | User service terminated | Queue | PendingU |
+ | | | termination | |
+ | | | event | |
+ | | | | |
+
+
+
+Bertz, et al. Standards Track [Page 55]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ | PendingU | Change in rating condition | Queue | PendingU |
+ | | | changed | |
+ | | | rating | |
+ | | | condition | |
+ | | | event | |
+ | | | | |
+ | PendingU | RAR received | Send RAA | PendingU |
+ | | | | |
+ | PendingT | Successful CC termination | | Idle |
+ | | answer received | | |
+ | | | | |
+ | PendingT | Failure to send, temporary | | Idle |
+ | | error, or failed answer | | |
+ | | | | |
+ | PendingT | Change in rating condition | | PendingT |
+ +----------+-------------------------------+-------------+----------+
+
+ Table 4: Session-Based Client State Machine for Intermediate and
+ Final Interrogations
+
+
+ +----------+--------------------------------+------------+----------+
+ | State | Event | Action | New |
+ | | | | State |
+ +----------+--------------------------------+------------+----------+
+ | Idle | Client or device requests a | Send CC | PendingE |
+ | | one-time service | event | |
+ | | | req., | |
+ | | | start Tx | |
+ | | | timer | |
+ | | | | |
+ | Idle | Request in storage | Send | PendingB |
+ | | | stored | |
+ | | | request | |
+ | | | | |
+ | PendingE | Successful CC event answer | Grant | Idle |
+ | | received | service to | |
+ | | | end user | |
+ | | | | |
+ | PendingE | Failure to send, temporary | Indicate | Idle |
+ | | error, failed CC event answer | service | |
+ | | received, or Tx timer expired; | error | |
+ | | requested action CHECK_BALANCE | | |
+ | | or PRICE_ENQUIRY | | |
+ | | | | |
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 56]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ | PendingE | CC event answer received with | Terminate | Idle |
+ | | Result-Code equal to | end user's | |
+ | | END_USER_SERVICE_DENIED or to | service | |
+ | | USER_UNKNOWN and Tx timer | | |
+ | | running | | |
+ | | | | |
+ | PendingE | CC event answer received with | Grant | Idle |
+ | | Result-Code equal to | service to | |
+ | | CREDIT_CONTROL_NOT_APPLICABLE; | end user | |
+ | | requested action | | |
+ | | DIRECT_DEBITING | | |
+ | | | | |
+ | PendingE | Failure to send, temporary | Grant | Idle |
+ | | error, or failed CC event | service to | |
+ | | answer received; requested | end user | |
+ | | action DIRECT_DEBITING; DDFH | | |
+ | | equal to CONTINUE | | |
+ | | | | |
+ | PendingE | Failed CC event answer | Terminate | Idle |
+ | | received or temporary error; | end user's | |
+ | | requested action | service | |
+ | | DIRECT_DEBITING; DDFH equal to | | |
+ | | TERMINATE_OR_BUFFER and Tx | | |
+ | | timer running | | |
+ | | | | |
+ | PendingE | Tx timer expired; requested | Grant | PendingE |
+ | | action DIRECT_DEBITING | service to | |
+ | | | end user | |
+ | | | | |
+ | PendingE | Failure to send; requested | Store | Idle |
+ | | action DIRECT_DEBITING; DDFH | request | |
+ | | equal to TERMINATE_OR_BUFFER | with | |
+ | | | T flag | |
+ | | | | |
+ | PendingE | Temporary error; requested | Store | Idle |
+ | | action DIRECT_DEBITING; DDFH | request | |
+ | | equal to TERMINATE_OR_BUFFER; | | |
+ | | Tx timer expired | | |
+ | | | | |
+ | PendingE | Failed answer or answer | | Idle |
+ | | received with Result-Code | | |
+ | | equal to END_USER_SERVICE | | |
+ | | DENIED or to USER_UNKNOWN; | | |
+ | | requested action | | |
+ | | DIRECT_DEBITING; Tx timer | | |
+ | | expired | | |
+ | | | | |
+
+
+
+
+Bertz, et al. Standards Track [Page 57]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ | PendingE | Failed CC event answer | Indicate | Idle |
+ | | received; requested action | service | |
+ | | REFUND_ACCOUNT | error and | |
+ | | | delete | |
+ | | | request | |
+ | | | | |
+ | PendingE | Failure to send or Tx timer | Store | Idle |
+ | | expired; requested action | request | |
+ | | REFUND_ACCOUNT | with | |
+ | | | T flag | |
+ | | | | |
+ | PendingE | Temporary error; requested | Store | Idle |
+ | | action REFUND_ACCOUNT | request | |
+ | | | | |
+ | PendingB | Successful CC answer received | Delete | Idle |
+ | | | request | |
+ | | | | |
+ | PendingB | Failed CC answer received | Delete | Idle |
+ | | | request | |
+ | | | | |
+ | PendingB | Failure to send or temporary | | Idle |
+ | | error | | |
+ +----------+--------------------------------+------------+----------+
+
+ Table 5: One-Time Event Client State Machine
+
+
+ +-------+------------------------+--------------------------+-------+
+ | State | Event | Action | New |
+ | | | | State |
+ +-------+------------------------+--------------------------+-------+
+ | Idle | CC initial request | Send CC initial answer, | Open |
+ | | received and | reserve units, start Tcc | |
+ | | successfully processed | | |
+ | | | | |
+ | Idle | CC initial request | Send CC initial answer | Idle |
+ | | received but not | with Result-Code != | |
+ | | successfully processed | SUCCESS | |
+ | | | | |
+ | Idle | CC event request | Send CC event answer | Idle |
+ | | received and | | |
+ | | successfully processed | | |
+ | | | | |
+ | Idle | CC event request | Send CC event answer | Idle |
+ | | received but not | with Result-Code != | |
+ | | successfully processed | SUCCESS | |
+ | | | | |
+
+
+
+
+Bertz, et al. Standards Track [Page 58]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ | Open | CC update request | Send CC update answer, | Open |
+ | | received and | debit used units, | |
+ | | successfully processed | reserve new units, | |
+ | | | restart Tcc | |
+ | | | | |
+ | Open | CC update request | Send CC update answer | Idle |
+ | | received but not | with Result-Code != | |
+ | | successfully processed | SUCCESS, debit used | |
+ | | | units | |
+ | | | | |
+ | Open | CC termination request | Send CC termin. answer, | Idle |
+ | | received and | stop Tcc, debit used | |
+ | | successfully processed | units | |
+ | | | | |
+ | Open | CC termination request | Send CC termin. answer | Idle |
+ | | received but not | with Result-Code != | |
+ | | successfully processed | SUCCESS, debit used | |
+ | | | units | |
+ | | | | |
+ | Open | Session supervision | Release reserved units | Idle |
+ | | timer Tcc expired | | |
+ +-------+------------------------+--------------------------+-------+
+
+ Table 6: Session-Based and Event-Based Server State Machine
+
+8. Credit-Control AVPs
+
+ This section defines the Credit-Control AVPs that are specific to the
+ Diameter Credit-Control application and that MAY be included in the
+ Diameter Credit-Control messages.
+
+ The AVPs defined in this section MAY also be included in
+ authorization commands defined in authorization-specific
+ applications, such as [RFC7155] and [RFC4004], if the first
+ interrogation is performed as part of the authorization/
+ authentication process, as described in Section 5.2.
+
+ The Diameter AVP rules are defined in [RFC6733], Section 4. These
+ AVP rules are observed in AVPs defined in this section.
+
+ The following table describes the Diameter AVPs defined in the
+ credit-control application, their AVP Code values, types, and
+ possible flag values. The AVP Flag rules ('M', 'V') are explained in
+ [RFC6733], Section 4.1.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 59]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ +---------------+
+ |AVP Flag Rules |
+ Defined |----+-----+----|
+ AVP in | | |MUST|
+ Attribute Name Code Section Data Type |MUST| MAY |NOT |
+ ----------------------------------------------------|----+-----+----|
+ CC-Correlation-Id 411 8.1 OctetString | | M | V |
+ CC-Input-Octets 412 8.24 Unsigned64 | M | | V |
+ CC-Money 413 8.22 Grouped | M | | V |
+ CC-Output-Octets 414 8.25 Unsigned64 | M | | V |
+ CC-Request-Number 415 8.2 Unsigned32 | M | | V |
+ CC-Request-Type 416 8.3 Enumerated | M | | V |
+ CC-Service-Specific- 417 8.26 Unsigned64 | M | | V |
+ Units | | | |
+ CC-Session-Failover 418 8.4 Enumerated | M | | V |
+ CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V |
+ CC-Time 420 8.21 Unsigned32 | M | | V |
+ CC-Total-Octets 421 8.23 Unsigned64 | M | | V |
+ CC-Unit-Type 454 8.32 Enumerated | M | | V |
+ Check-Balance-Result 422 8.6 Enumerated | M | | V |
+ Cost-Information 423 8.7 Grouped | M | | V |
+ Cost-Unit 424 8.12 UTF8String | M | | V |
+ Credit-Control 426 8.13 Enumerated | M | | V |
+ Credit-Control- 427 8.14 Enumerated | M | | V |
+ Failure-Handling | | | |
+ Currency-Code 425 8.11 Unsigned32 | M | | V |
+ Direct-Debiting- 428 8.15 Enumerated | M | | V |
+ Failure-Handling | | | |
+ Exponent 429 8.9 Integer32 | M | | V |
+ Final-Unit-Action 449 8.35 Enumerated | M | | V |
+ Final-Unit-Indication 430 8.34 Grouped | M | | V |
+ QoS-Final-Unit-Indication 669 8.68 Grouped | | M | V |
+ Granted-Service-Unit 431 8.17 Grouped | M | | V |
+ G-S-U-Pool-Identifier 453 8.31 Unsigned32 | M | | V |
+ G-S-U-Pool-Reference 457 8.30 Grouped | M | | V |
+ Multiple-Services- 456 8.16 Grouped | M | | V |
+ Credit-Control | | | |
+ Multiple-Services- 455 8.40 Enumerated | M | | V |
+ Indicator | | | |
+ Rating-Group 432 8.29 Unsigned32 | M | | V |
+ Redirect-Address-Type 433 8.38 Enumerated | M | | V |
+ Redirect-Server 434 8.37 Grouped | M | | V |
+ Redirect-Server-Address 435 8.39 UTF8String | M | | V |
+ Redirect-Server-Extension 665 8.64 Grouped | | M | V |
+ Redirect-Address- 666 8.65 Address | | M | V |
+ IPAddress | | | |
+ Redirect-Address-URL 667 8.66 UTF8String | | M | V |
+ Redirect-Address-SIP-URI 668 8.67 UTF8String | | M | V |
+
+
+
+Bertz, et al. Standards Track [Page 60]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Requested-Action 436 8.41 Enumerated | M | | V |
+ Requested-Service-Unit 437 8.18 Grouped | M | | V |
+ Restriction-Filter-Rule 438 8.36 IPFilterRule| M | | V |
+ Service-Context-Id 461 8.42 UTF8String | M | | V |
+ Service-Identifier 439 8.28 Unsigned32 | M | | V |
+ Service-Parameter-Info 440 8.43 Grouped | | M | V |
+ Service-Parameter-Type 441 8.44 Unsigned32 | | M | V |
+ Service-Parameter-Value 442 8.45 OctetString | | M | V |
+ Subscription-Id 443 8.46 Grouped | M | | V |
+ Subscription-Id-Data 444 8.48 UTF8String | M | | V |
+ Subscription-Id-Type 450 8.47 Enumerated | M | | V |
+ Subscription-Id-Extension 659 8.58 Grouped | | M | V |
+ Subscription-Id-E164 660 8.59 UTF8String | | M | V |
+ Subscription-Id-IMSI 661 8.60 UTF8String | | M | V |
+ Subscription-Id-SIP-URI 662 8.61 UTF8String | | M | V |
+ Subscription-Id-NAI 663 8.62 UTF8String | | M | V |
+ Subscription-Id-Private 664 8.63 UTF8String | | M | V |
+ Tariff-Change-Usage 452 8.27 Enumerated | M | | V |
+ Tariff-Time-Change 451 8.20 Time | M | | V |
+ Unit-Value 445 8.8 Grouped | M | | V |
+ Used-Service-Unit 446 8.19 Grouped | M | | V |
+ User-Equipment-Info 458 8.49 Grouped | | M | V |
+ User-Equipment-Info-Type 459 8.50 Enumerated | | M | V |
+ User-Equipment-Info-Value 460 8.51 OctetString | | M | V |
+ User-Equipment-Info- 653 8.52 Grouped | | M | V |
+ Extension | | | |
+ User-Equipment-Info- 654 8.53 OctetString | | M | V |
+ IMEISV | | | |
+ User-Equipment-Info-MAC 655 8.54 OctetString | | M | V |
+ User-Equipment-Info-EUI64 656 8.55 OctetString | | M | V |
+ User-Equipment-Info- 657 8.56 OctetString | | M | V |
+ ModifiedEUI64 | | | |
+ User-Equipment-Info-IMEI 658 8.57 OctetString | | M | V |
+ Value-Digits 447 8.10 Integer64 | M | | V |
+ Validity-Time 448 8.33 Unsigned32 | M | | V |
+
+8.1. CC-Correlation-Id AVP
+
+ The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and
+ contains information to correlate credit-control requests generated
+ for different components of the service, e.g., transport and service
+ level. Whoever allocates the Service-Context-Id (i.e., a unique
+ identifier of a service-specific document) is also responsible for
+ defining the content and encoding of the CC-Correlation-Id AVP.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 61]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.2. CC-Request-Number AVP
+
+ The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and
+ identifies this request within one session. As Session-Id AVPs are
+ globally unique, the combination of the Session-Id AVP and the
+ CC-Request-Number AVP is also globally unique and can be used in
+ matching credit-control messages with confirmations. An easy way to
+ produce unique numbers is to set the value of the CC-Request-Number
+ AVP to 0 for a credit-control request with a CC-Request-Type AVP of
+ INITIAL_REQUEST (the initial request in a session). The value of the
+ CC-Request-Number AVP should be set to 1 for the first
+ UPDATE_REQUEST, to 2 for the second, and so on until the value for
+ TERMINATION_REQUEST is one more than the value for the last
+ UPDATE_REQUEST. In the case of event charging (when the CC-Request-
+ Type AVP has the value EVENT_REQUEST), the CC-Request-Number AVP
+ should be set to 0 for a credit-control request.
+
+8.3. CC-Request-Type AVP
+
+ The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and
+ contains the reason for sending the Credit-Control-Request message.
+ It MUST be present in all Credit-Control-Request messages. The
+ following values are defined for the CC-Request-Type AVP (the value
+ of 0 (zero) is reserved):
+
+ INITIAL_REQUEST 1
+
+ This request is used to initiate a credit-control session. It
+ contains credit-control information that is relevant to the
+ initiation.
+
+ UPDATE_REQUEST 2
+
+ This request contains credit-control information for an existing
+ credit-control session. Credit-control requests of this type SHOULD
+ be sent every time a credit-control re-authorization is needed at the
+ expiry of the allocated quota or validity time. Further, additional
+ service-specific events MAY trigger a spontaneous UPDATE_REQUEST.
+
+ TERMINATION_REQUEST 3
+
+ This request is sent to terminate a credit-control session. It
+ contains credit-control information relevant to the existing session.
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 62]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ EVENT_REQUEST 4
+
+ This request is used when there is no need to maintain any
+ credit-control session state in the credit-control server. It
+ contains all information relevant to the service and is the only
+ request of the service. The reason for this request is further
+ detailed in the Requested-Action AVP. The Requested-Action AVP MUST
+ be included in the Credit-Control-Request message when CC-Request-
+ Type is set to EVENT_REQUEST.
+
+8.4. CC-Session-Failover AVP
+
+ The CC-Session-Failover AVP (AVP Code 418) is of type Enumerated and
+ contains information as to whether moving the credit-control message
+ stream to a backup server during an ongoing credit-control session is
+ supported. In the case of communication failures, the credit-control
+ message streams can be moved to an alternative destination if the
+ credit-control server supports failover to an alternative server.
+ The secondary credit-control server name, if received from the home
+ Diameter AAA server, can be used as an address of the backup server.
+ An implementation is not required to support moving a credit-control
+ message stream to an alternative server, as this also requires moving
+ information related to the credit-control session to the backup
+ server.
+
+ The following values are defined for the CC-Session-Failover AVP:
+
+ FAILOVER_NOT_SUPPORTED 0
+
+ When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED,
+ the credit-control message stream MUST NOT be moved to an alternative
+ destination in the case of a communication failure. This is the
+ default behavior if the AVP isn't included in the reply from the
+ authorization or credit-control server.
+
+ FAILOVER_SUPPORTED 1
+
+ When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the
+ credit-control message stream SHOULD be moved to an alternative
+ destination in the case of a communication failure. Moving the
+ credit-control message stream to a backup server MAY require that
+ information related to the credit-control session should also be
+ forwarded to an alternative server.
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 63]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.5. CC-Sub-Session-Id AVP
+
+ The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and
+ contains the credit-control sub-session identifier. The combination
+ of the Session-Id AVP and this AVP MUST be unique per sub-session,
+ and the value of this AVP MUST be monotonically increased by one for
+ all new sub-sessions. The absence of this AVP implies that no
+ sub-sessions are in use.
+
+8.6. Check-Balance-Result AVP
+
+ The Check-Balance-Result AVP (AVP Code 422) is of type Enumerated and
+ contains the result of the balance check. This AVP is applicable
+ only when the Requested-Action AVP indicates CHECK_BALANCE in the
+ Credit-Control-Request command. The following values are defined for
+ the Check-Balance-Result AVP:
+
+ ENOUGH_CREDIT 0
+
+ There is enough credit in the account to cover the requested service.
+
+ NO_CREDIT 1
+
+ There isn't enough credit in the account to cover the requested
+ service.
+
+8.7. Cost-Information AVP
+
+ The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is
+ used to return the cost information of a service, which the
+ credit-control client can transfer transparently to the end user.
+ The included Unit-Value AVP contains the cost estimate (always of
+ type "money") of the service in the case of price inquiries, or the
+ accumulated cost estimation in the case of a credit-control session.
+
+ The Currency-Code AVP specifies in which currency the cost was given.
+ The Cost-Unit AVP specifies the unit when the service cost is a cost
+ per unit (e.g., cost for the service is $1 per minute).
+
+ When the Requested-Action AVP with the value PRICE_ENQUIRY is
+ included in the Credit-Control-Request command, the Cost-Information
+ AVP sent in the succeeding Credit-Control-Answer command contains the
+ cost estimation for the requested service, without any reservations
+ being made.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 64]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The Cost-Information AVP included in the Credit-Control-Answer
+ command with the CC-Request-Type set to UPDATE_REQUEST contains the
+ accumulated cost estimation for the session, without taking any
+ credit reservations into account.
+
+ The Cost-Information AVP included in the Credit-Control-Answer
+ command with the CC-Request-Type set to EVENT_REQUEST or
+ TERMINATION_REQUEST contains the estimated total cost for the
+ requested service.
+
+ The Cost-Information AVP is defined as follows (per grouped-avp-def
+ as defined in [RFC6733]):
+
+ Cost-Information ::= < AVP Header: 423 >
+ { Unit-Value }
+ { Currency-Code }
+ [ Cost-Unit ]
+
+8.8. Unit-Value AVP
+
+ The Unit-Value AVP is of type Grouped (AVP Code 445) and specifies
+ the cost as a floating-point value. The Unit-Value is a significand
+ with an exponent; i.e., Unit-Value = Value-Digits AVP * 10^Exponent.
+ This representation avoids unwanted rounding off. For example, the
+ value of 2,3 is represented as Value-Digits = 23 and Exponent = -1.
+ The absence of the exponent part MUST be interpreted as an exponent
+ equal to zero.
+
+ The Unit-Value AVP is defined as follows (per grouped-avp-def as
+ defined in [RFC6733]):
+
+ Unit-Value ::= < AVP Header: 445 >
+ { Value-Digits }
+ [ Exponent ]
+
+8.9. Exponent AVP
+
+ The Exponent AVP is of type Integer32 (AVP Code 429) and contains the
+ exponent value to be applied for the Value-Digits AVP within the
+ Unit-Value AVP.
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 65]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.10. Value-Digits AVP
+
+ The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains
+ the significant digits of the number. If decimal values are needed
+ to present the units, the scaling MUST be indicated with the related
+ Exponent AVP. For example, for the monetary amount $0.05, the value
+ of the Value-Digits AVP MUST be set to 5, and the scaling MUST be
+ indicated with the Exponent AVP set to -2.
+
+8.11. Currency-Code AVP
+
+ The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and
+ contains a currency code that specifies in which currency the values
+ of AVPs containing monetary units were given. It is specified by
+ using the numeric values defined in the ISO 4217 standard [ISO4217].
+
+8.12. Cost-Unit AVP
+
+ The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is
+ used to display a human-readable string to the end user. It
+ specifies the applicable unit to the Cost-Information AVP when the
+ service cost is a cost per unit (e.g., cost of the service is $1 per
+ minute). The Cost-Unit setting can be minutes, hours, days,
+ kilobytes, megabytes, etc.
+
+8.13. Credit-Control AVP
+
+ The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST
+ be included in AA-Request messages when the Service Element has
+ credit-control capabilities. The following values are defined for
+ the Credit-Control AVP:
+
+ CREDIT_AUTHORIZATION 0
+
+ If the home Diameter AAA server determines that the user has a
+ prepaid subscription, this value indicates that the credit-control
+ server MUST be contacted to perform the first interrogation. The
+ value of the Credit-Control AVP MUST always be set to 0 in an
+ AA-Request sent to perform the first interrogation and to initiate a
+ new credit-control session.
+
+ RE_AUTHORIZATION 1
+
+ This value indicates to the Diameter AAA server that a credit-control
+ session is ongoing for the subscriber and that the credit-control
+ server MUST NOT be contacted. The Credit-Control AVP set to the
+ value of 1 is to be used only when the first interrogation has been
+ successfully performed and the credit-control session is ongoing
+
+
+
+Bertz, et al. Standards Track [Page 66]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ (i.e., re-authorization triggered by authorization lifetime). This
+ value MUST NOT be used in an AA-Request sent to perform the first
+ interrogation.
+
+8.14. Credit-Control-Failure-Handling AVP (CCFH)
+
+ The CCFH (AVP Code 427) is of type Enumerated. The credit-control
+ client uses information in this AVP to decide what to do if sending
+ credit-control messages to the credit-control server has been, for
+ instance, temporarily prevented due to a network problem. Depending
+ on the service logic, the credit-control server can order the client
+ to terminate the service immediately when there is a reason to
+ believe that the service cannot be charged, or to try failover to an
+ alternative server, if possible. The server could then either
+ terminate or grant the service, should the alternative connection
+ also fail.
+
+ The following values are defined for the CCFH:
+
+ TERMINATE 0
+
+ When the CCFH is set to TERMINATE, the service MUST only be granted
+ for as long as there is a connection to the credit-control server.
+ If the credit-control client does not receive any Credit-Control-
+ Answer messages before the Tx timer (as defined in Section 13)
+ expires, the credit-control request is regarded as failed, and the
+ end user's service session is terminated.
+
+ This is the default behavior if the AVP isn't included in the reply
+ from the authorization or credit-control server.
+
+ CONTINUE 1
+
+ When the CCFH is set to CONTINUE, the credit-control client SHOULD
+ resend the request to an alternative server in the case of transport
+ or temporary failures, provided that (1) a failover procedure is
+ supported in the credit-control server and the credit-control client
+ and (2) an alternative server is available. Otherwise, the service
+ SHOULD be granted, even if credit-control messages can't be
+ delivered.
+
+ RETRY_AND_TERMINATE 2
+
+ When the CCFH is set to RETRY_AND_TERMINATE, the credit-control
+ client SHOULD resend the request to an alternative server in the case
+ of transport or temporary failures, provided that (1) a failover
+ procedure is supported in the credit-control server and the
+ credit-control client and (2) an alternative server is available.
+
+
+
+Bertz, et al. Standards Track [Page 67]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Otherwise, the service SHOULD NOT be granted when the credit-control
+ messages can't be delivered.
+
+8.15. Direct-Debiting-Failure-Handling AVP (DDFH)
+
+ The DDFH (AVP Code 428) is of type Enumerated. The credit-control
+ client uses information in this AVP to decide what to do if sending
+ credit-control messages (Requested-Action AVP set to DIRECT_DEBITING)
+ to the credit-control server has been, for instance, temporarily
+ prevented due to a network problem.
+
+ The following values are defined for the DDFH:
+
+ TERMINATE_OR_BUFFER 0
+
+ When the DDFH is set to TERMINATE_OR_BUFFER, the service MUST be
+ granted for as long as there is a connection to the credit-control
+ server. If the credit-control client does not receive any
+ Credit-Control-Answer messages before the Tx timer (as defined in
+ Section 13) expires, the credit-control request is regarded as
+ failed. The client SHOULD terminate the service if it can determine
+ from the failed answer that units have not been debited. Otherwise,
+ the credit-control client SHOULD grant the service, store the request
+ in application-level non-volatile storage, and try to resend the
+ request. These requests MUST be marked as possible duplicates by
+ setting the T flag in the command header as described in [RFC6733],
+ Section 3. This is the default behavior if the AVP isn't included in
+ the reply from the authorization server.
+
+ CONTINUE 1
+
+ When the DDFH is set to CONTINUE, the service SHOULD be granted, even
+ if credit-control messages can't be delivered, and the request should
+ be deleted.
+
+8.16. Multiple-Services-Credit-Control AVP
+
+ The Multiple-Services-Credit-Control AVP (AVP Code 456) is of type
+ Grouped and contains the AVPs related to the independent
+ credit-control of multiple services. Note that each instance of this
+ AVP carries units related to one or more services or related to a
+ single rating-group.
+
+ The Service-Identifier AVP and the Rating-Group AVP are used to
+ associate the granted units to a given service or rating-group. If
+ both the Service-Identifier AVP and the Rating-Group AVP are
+ included, the target of the service units is always the service(s)
+ indicated by the value of the Service-Identifier AVP(s). If only the
+
+
+
+Bertz, et al. Standards Track [Page 68]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Rating-Group AVP is present, the Multiple-Services-Credit-Control AVP
+ relates to all the services that belong to the specified
+ rating-group.
+
+ 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 of the specified type are considered pooled. If a G-S-U-Pool-
+ Reference AVP is present, then actual service units of the specified
+ type MUST also be present. For example, if the G-S-U-Pool-Reference
+ AVP specifies a CC-Unit-Type value of TIME (Section 8.32), then the
+ CC-Time AVP MUST be present.
+
+ The Requested-Service-Unit AVP MAY contain the amount of requested
+ service units or the requested monetary value. It MUST be present in
+ the initial interrogation and within the intermediate interrogations
+ in which a new quota is requested. If the credit-control client does
+ not include the Requested-Service-Unit AVP in a request command --
+ because, for instance, it has determined that the end user terminated
+ the service -- the server MUST debit the used amount from the user's
+ account but MUST NOT return a new quota in the corresponding answer.
+ The Validity-Time, Result-Code, and Final-Unit-Indication or
+ QoS-Final-Unit-Indication AVPs MAY be present in a Credit-Control-
+ Answer command as defined in Sections 5.1.2 and 5.6 for graceful
+ service termination.
+
+ When both the Tariff-Time-Change AVP and the Tariff-Change-Usage AVP
+ are present, the server MUST include two separate instances of the
+ Multiple-Services-Credit-Control AVP with the Granted-Service-Unit
+ AVP associated to the same service-identifier and/or rating-group.
+ Where the two quotas are associated to the same pool or to different
+ pools, the credit-pooling mechanism defined in Section 5.1.2 applies.
+ When the client is reporting used units before and after the tariff
+ time change, it MUST use the Tariff-Change-Usage AVP inside the
+ Used-Service-Unit AVP.
+
+ A server not implementing the independent credit-control of multiple
+ services MUST treat the Multiple-Services-Credit-Control AVP as an
+ invalid AVP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 69]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The Multiple-Services-Credit-Control AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ 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 ]
+ [ QoS-Final-Unit-Indication ]
+ *[ AVP ]
+
+8.17. Granted-Service-Unit AVP
+
+ The Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and
+ contains the amount of units that the Diameter Credit-Control client
+ can provide to the end user until the service must be released or the
+ new Credit-Control-Request must be sent. A client is not required to
+ implement all the unit types, and it must treat unknown or
+ unsupported unit types in the Answer message as an incorrect CCA. In
+ this case, the client MUST terminate the credit-control session and
+ indicate the reason as DIAMETER_BAD_ANSWER in the Termination-Cause
+ AVP.
+
+ The Granted-Service-Unit AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ 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 ]
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 70]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.18. Requested-Service-Unit AVP
+
+ The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and
+ contains the amount of requested units specified by the Diameter
+ Credit-Control client. A server is not required to implement all the
+ unit types, and it must treat unknown or unsupported unit types as
+ invalid AVPs.
+
+ The Requested-Service-Unit AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ 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 AVP
+
+ The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and
+ contains the amount of used units measured from the point when the
+ service became active or, if interim interrogations are used during
+ the session, from the point when the previous measurement ended.
+ Note: The value reported in a Used-Service-Unit AVP is not
+ necessarily related to the grant provided in a Granted-Service-Unit
+ AVP, e.g., the value in this AVP may exceed the value in the grant.
+
+ The Used-Service-Unit AVP is defined as follows (per grouped-avp-def
+ as defined in [RFC6733]):
+
+ 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 ]
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 71]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.20. Tariff-Time-Change AVP
+
+ The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is
+ sent from the server to the client and includes the time in seconds
+ since January 1, 1900, 00:00 UTC, when the tariff of the service will
+ be changed.
+
+ The tariff change mechanism is optional for the client and server,
+ and it is not used for time-based services (Section 5). If a client
+ does not support the tariff time change mechanism, it MUST treat the
+ Tariff-Time-Change AVP in the Answer message as an incorrect CCA. In
+ this case, the client terminates the credit-control session and
+ indicates the reason as DIAMETER_BAD_ANSWER in the Termination-Cause
+ AVP.
+
+ Omission of this AVP means that no tariff change is to be reported.
+
+8.21. CC-Time AVP
+
+ The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates
+ the length of the requested, granted, or used time in seconds.
+
+8.22. CC-Money AVP
+
+ The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the
+ monetary amount in the given currency. The Currency-Code AVP SHOULD
+ be included. The CC-Money AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ CC-Money ::= < AVP Header: 413 >
+ { Unit-Value }
+ [ Currency-Code ]
+
+8.23. CC-Total-Octets AVP
+
+ The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and
+ contains the total number of requested, granted, or used octets
+ regardless of the direction (sent or received).
+
+8.24. CC-Input-Octets AVP
+
+ The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and
+ contains the number of requested, granted, or used octets that
+ can be / have been received from the end user.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 72]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.25. CC-Output-Octets AVP
+
+ The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and
+ contains the number of requested, granted, or used octets that
+ can be / have been sent to the end user.
+
+8.26. CC-Service-Specific-Units AVP
+
+ The CC-Service-Specific-Units AVP (AVP Code 417) is of type
+ Unsigned64 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 the Service-
+ Identifier AVP (or Rating-Group AVP when the Multiple-Services-
+ Credit-Control AVP is used).
+
+8.27. Tariff-Change-Usage AVP
+
+ The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and
+ defines whether units are used before or after a tariff change, or
+ whether the units straddled a tariff change during the reporting
+ period. Omission of this AVP means that no tariff change has
+ occurred.
+
+ In addition, when present in Answer messages as part of the Multiple-
+ Services-Credit-Control AVP, this AVP defines whether units are
+ allocated to be used before or after a tariff change event.
+
+ When the Tariff-Time-Change AVP is present, omission of this AVP in
+ Answer messages means that the single-quota mechanism applies.
+
+ Tariff-Change-Usage can be set to one of the following values:
+
+ UNIT_BEFORE_TARIFF_CHANGE 0
+
+ When present in the Multiple-Services-Credit-Control AVP, this value
+ indicates the amount of units allocated for use before a tariff
+ change occurs.
+
+ When present in the Used-Service-Unit AVP, this value indicates the
+ amount of resource units used before a tariff change had occurred.
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 73]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ UNIT_AFTER_TARIFF_CHANGE 1
+
+ When present in the Multiple-Services-Credit-Control AVP, this value
+ indicates the amount of units allocated for use after a tariff change
+ occurs.
+
+ When present in the Used-Service-Unit AVP, this value indicates the
+ amount of resource units used after a tariff change had occurred.
+
+ UNIT_INDETERMINATE 2
+
+ This value is to be used only in the Used-Service-Unit AVP and
+ indicates the amount of resource units that straddle the tariff
+ change (e.g., the metering process reports to the credit-control
+ client in blocks of n octets, and one block straddled the tariff
+ change).
+
+8.28. Service-Identifier AVP
+
+ The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and
+ contains the identifier of a service. The specific service the
+ request relates to is uniquely identified by the combination of the
+ Service-Context-Id AVP and the Service-Identifier AVP.
+
+ A usage example of this AVP is illustrated in Appendix A.9.
+
+8.29. Rating-Group AVP
+
+ The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and
+ contains the identifier of a rating-group. All the services subject
+ to the same rating type are part of the same rating-group. The
+ specific rating-group the request relates to is uniquely identified
+ by the combination of the Service-Context-Id AVP and the Rating-Group
+ AVP.
+
+ A usage example of this AVP is illustrated in Appendix A.9.
+
+8.30. G-S-U-Pool-Reference AVP
+
+ The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It
+ is used in the Credit-Control-Answer message and associates the
+ Granted-Service-Unit AVP within which it appears with a credit pool
+ within the session.
+
+ The G-S-U-Pool-Identifier AVP specifies the credit pool from which
+ credit is drawn for this unit type.
+
+
+
+
+
+Bertz, et al. Standards Track [Page 74]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The CC-Unit-Type AVP specifies the type of units for which credit is
+ pooled.
+
+ The Unit-Value AVP specifies the multiplier, which converts between
+ service units of type CC-Unit-Type and abstract service units within
+ the credit pool (and thus to service units of any other services or
+ rating-groups associated with the same pool).
+
+ The G-S-U-Pool-Reference AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ 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 AVP
+
+ The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32
+ and identifies a credit pool within the session.
+
+8.32. CC-Unit-Type AVP
+
+ The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and
+ specifies the type of units considered to be pooled into a
+ credit pool.
+
+ The following values are defined for the CC-Unit-Type AVP:
+
+ TIME 0
+ MONEY 1
+ TOTAL-OCTETS 2
+ INPUT-OCTETS 3
+ OUTPUT-OCTETS 4
+ SERVICE-SPECIFIC-UNITS 5
+
+8.33. Validity-Time AVP
+
+ The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is
+ sent from the credit-control server to the credit-control client.
+ The Validity-Time AVP contains the validity time of the granted
+ service units. The measurement of the Validity-Time is started upon
+ receipt of the Credit-Control-Answer message containing this AVP. If
+ the granted service units have not been consumed within the validity
+ time specified in this AVP, the credit-control client MUST send a
+ Credit-Control-Request message to the server, with CC-Request-Type
+ set to UPDATE_REQUEST. The value field of the Validity-Time AVP is
+ given in seconds.
+
+
+
+Bertz, et al. Standards Track [Page 75]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The Validity-Time AVP is also used for graceful service termination
+ (see Section 5.6) to indicate to the credit-control client how long
+ the subscriber is allowed to use network resources after the
+ specified action (i.e., REDIRECT or RESTRICT_ACCESS) started. When
+ the Validity-Time elapses, a new intermediate interrogation is sent
+ to the server.
+
+8.34. Final-Unit-Indication AVP
+
+ The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and
+ indicates that the Granted-Service-Unit AVP in the Credit-Control-
+ Answer or in the AA-Answer contains the final units for the service.
+ After these units have expired, the Diameter Credit-Control client is
+ responsible for executing the action indicated in the Final-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-control
+ client to execute the specified action.
+
+ In the first interrogation, the Final-Unit-Indication AVP with
+ Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS can also be
+ present with no Granted-Service-Unit AVP in the Credit-Control-Answer
+ or in the AA-Answer. This indicates to the Diameter Credit-Control
+ client that the client is to execute the specified action
+ immediately. If the home service provider policy is to terminate the
+ service, naturally, the server SHOULD return the appropriate
+ transient failure (see Section 9.1) in order to implement the policy-
+ defined action.
+
+ The Final-Unit-Action AVP defines the behavior of the Service Element
+ when the user's account cannot cover the cost of the service and MUST
+ always be present if the Final-Unit-Indication AVP is included in a
+ command.
+
+ If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit-
+ Indication group AVP MUST NOT contain any other AVPs.
+
+ If the Final-Unit-Action AVP is set to REDIRECT, the Redirect-Server
+ AVP or the Redirect-Server-Extension AVP (at least one) MUST be
+ present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be
+ present in the Credit-Control-Answer message if the user is also
+ allowed to access other services that are not accessible through the
+ address given in the Redirect-Server AVP.
+
+ If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
+ Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
+
+
+
+
+Bertz, et al. Standards Track [Page 76]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be
+ used to reference an IP filter list installed in the access device by
+ means other than the Diameter Credit-Control application, e.g.,
+ locally configured or configured by another entity.
+
+ If the Final-Unit-Action AVP is set to REDIRECT and the type of
+ server is not one of the enumerations in the Redirect-Address-Type
+ AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together
+ with the Redirect-Server-Extension AVP instead of the Final-Unit-
+ Indication AVP.
+
+ If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
+ and the classification of the restricted traffic cannot be expressed
+ using an IPFilterRule, or if actions (e.g., QoS) other than just
+ allowing traffic need to be enforced, then the QoS-Final-Unit-
+ Indication AVP SHOULD be used instead of the Final-Unit-Indication
+ AVP. However, if the credit-control server wants to preserve
+ backward compatibility with credit-control clients that support only
+ [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with
+ the Filter-Id AVP.
+
+ The Final-Unit-Indication AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ Final-Unit-Indication ::= < AVP Header: 430 >
+ { Final-Unit-Action }
+ *[ Restriction-Filter-Rule ]
+ *[ Filter-Id ]
+ [ Redirect-Server ]
+
+8.35. Final-Unit-Action AVP
+
+ The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and
+ indicates to the credit-control client the action to be taken when
+ the user's account cannot cover the service cost.
+
+ Final-Unit-Action can be set to one of the following values:
+
+ TERMINATE 0
+
+ The 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 client
+ implementations conforming to this specification.
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 77]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ REDIRECT 1
+
+ The Service Element MUST redirect the user to the address specified
+ in the Redirect-Server-Address AVP or one of the AVPs included in the
+ Redirect-Server-Extension AVP. The redirect action is defined in
+ Section 5.6.2.
+
+ RESTRICT_ACCESS 2
+
+ The access device MUST restrict the user's access according to the
+ filter AVPs contained in the applied Grouped AVP: according to IP
+ packet filters defined in the Restriction-Filter-Rule AVP, according
+ to the packet classifier filters defined in the Filter-Rule AVP, or
+ according to the packet filters identified by the Filter-Id AVP. All
+ of the packets not matching any restriction filters (see
+ Section 5.6.3) MUST be dropped.
+
+8.36. Restriction-Filter-Rule AVP
+
+ The Restriction-Filter-Rule AVP (AVP Code 438) is of type
+ IPFilterRule and provides filter rules corresponding to services that
+ are to remain accessible even if there are no more service units
+ granted. The access device has to configure the specified filter
+ rules for the subscriber and MUST drop all the packets not matching
+ these filters. Zero, one, or more such AVPs MAY be present in a
+ Credit-Control-Answer message or in an AA-Answer message.
+
+8.37. Redirect-Server AVP
+
+ The Redirect-Server AVP (AVP Code 434) is of type Grouped and
+ contains the address information of the redirect server (e.g., HTTP
+ redirect server, SIP Server) with which the end user is to be
+ connected when the account cannot cover the service cost. It MUST be
+ present when the Final-Unit-Action AVP is set to REDIRECT.
+
+ The Redirect-Server AVP is defined as follows (per grouped-avp-def as
+ defined in [RFC6733]):
+
+ Redirect-Server ::= < AVP Header: 434 >
+ { Redirect-Address-Type }
+ { Redirect-Server-Address }
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 78]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.38. Redirect-Address-Type AVP
+
+ The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated
+ and defines the address type of the address given in the Redirect-
+ Server-Address AVP.
+
+ Redirect-Address-Type can be set to one of the following values:
+
+ IPv4 Address 0
+
+ The address type is in the form of a "dotted-decimal" IPv4 address,
+ as defined in [RFC791].
+
+ IPv6 Address 1
+
+ The address type is in the form of an IPv6 address, as defined in
+ [RFC4291]. The address MUST conform to the textual representation of
+ the address according to [RFC5952].
+
+ Because [RFC5952] is more restrictive than the "RFC 3513" format
+ required by [RFC4006], some legacy implementations may not be
+ compliant with the new requirements. Accordingly, implementations
+ receiving this AVP MAY be liberal in the textual IPv6 representations
+ that are accepted, without raising an error.
+
+ URL 2
+
+ The address type is in the form of a Uniform Resource Locator, as
+ defined in [RFC3986].
+
+ SIP URI 3
+
+ The address type is in the form of a SIP Uniform Resource Identifier,
+ as defined in [RFC3261].
+
+8.39. Redirect-Server-Address AVP
+
+ The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String
+ and defines the address of the redirect server (e.g., HTTP redirect
+ server, SIP Server) with which the end user is to be connected when
+ the account cannot cover the service cost.
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 79]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.40. Multiple-Services-Indicator AVP
+
+ The Multiple-Services-Indicator AVP (AVP Code 455) is of type
+ Enumerated and indicates whether the Diameter Credit-Control client
+ is capable of handling multiple services independently within a
+ (sub-)session. The absence of this AVP means that independent
+ credit-control of multiple services is not supported.
+
+ A server not implementing the independent credit-control of multiple
+ services MUST treat the Multiple-Services-Indicator AVP as an
+ invalid AVP.
+
+ The following values are defined for the Multiple-Services-Indicator
+ AVP:
+
+ MULTIPLE_SERVICES_NOT_SUPPORTED 0
+
+ The client does not support independent credit-control of multiple
+ services within a (sub-)session.
+
+ MULTIPLE_SERVICES_SUPPORTED 1
+
+ The client supports independent credit-control of multiple services
+ within a (sub-)session.
+
+8.41. Requested-Action AVP
+
+ The Requested-Action AVP (AVP Code 436) is of type Enumerated and
+ contains the requested action being sent in a Credit-Control-Request
+ command where the CC-Request-Type is set to EVENT_REQUEST. The
+ following values are defined for the Requested-Action AVP:
+
+ DIRECT_DEBITING 0
+
+ This indicates a request to decrease the end user's account according
+ to information specified in the Requested-Service-Unit AVP and/or
+ Service-Identifier AVP (additional rating information may 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.
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 80]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ REFUND_ACCOUNT 1
+
+ This indicates a request to increase the end user's account according
+ to information specified in the Requested-Service-Unit AVP and/or
+ Service-Identifier AVP (additional rating information may 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 2
+
+ This indicates a balance-check request. In this case, the checking
+ of the account balance is done without any credit reservations from
+ the account. The Check-Balance-Result AVP in the Credit-Control-
+ Answer command contains the result of the balance check.
+
+ PRICE_ENQUIRY 3
+
+ This indicates a price-inquiry request. In this case, neither
+ checking of the account balance nor reservation from the account will
+ be done; only the price of the service will be returned in the
+ Cost-Information AVP in the Credit-Control-Answer command.
+
+8.42. Service-Context-Id AVP
+
+ The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and
+ contains a unique identifier of the Diameter Credit-Control service-
+ specific document (as defined in Section 4.1.2) that applies to the
+ request. This is an identifier allocated by the service provider,
+ the Service Element manufacturer, or a standardization body, and MUST
+ uniquely identify a given Diameter Credit-Control service-specific
+ document. The format of the Service-Context-Id is:
+
+ "service-context" "@" "domain"
+
+ service-context = Token
+
+ The 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 by
+ a standardization body, or it can be the Fully Qualified Domain Name
+ (FQDN) of the service provider (e.g., provider.example.com) or the
+ vendor (e.g., vendor.example.com) if the identifier is allocated by a
+ private entity.
+
+ This AVP SHOULD be placed as close to the Diameter header as
+ possible.
+
+
+
+Bertz, et al. Standards Track [Page 81]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Service-specific documents that are for private use only (i.e., for
+ one provider's own use, where no interoperability is deemed useful)
+ may define private identifiers without a need for coordination.
+ However, when interoperability is desired, coordination of the
+ identifiers via, for example, publication of an informational RFC is
+ RECOMMENDED in order to make the Service-Context-Id AVP globally
+ available.
+
+8.43. Service-Parameter-Info AVP
+
+ The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and
+ contains service-specific information used for price calculation or
+ rating. The Service-Parameter-Type AVP defines the service parameter
+ type, and the Service-Parameter-Value AVP contains the parameter
+ value. The actual contents of these AVPs are not within the scope of
+ this 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 the
+ error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message
+ with this error MUST contain one or more Failed-AVP AVPs containing
+ the Service-Parameter-Info AVPs that caused the failure.
+
+ The Service-Parameter-Info AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ Service-Parameter-Info ::= < AVP Header: 440 >
+ { Service-Parameter-Type }
+ { Service-Parameter-Value }
+
+8.44. Service-Parameter-Type AVP
+
+ The 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 different
+ parameters and their types are service specific, and the meanings of
+ these parameters are not defined in this document. Whoever allocates
+ the Service-Context-Id (i.e., a unique identifier of a service-
+ specific document) is also responsible for assigning Service-
+ Parameter-Type values for the service and ensuring their uniqueness
+ within the given service. The Service-Parameter-Value AVP contains
+ the value associated with the service parameter type.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 82]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.45. Service-Parameter-Value AVP
+
+ The Service-Parameter-Value AVP is of type OctetString (AVP Code 442)
+ and contains the value of the service parameter type.
+
+8.46. Subscription-Id AVP
+
+ The Subscription-Id AVP (AVP Code 443) is used to identify the
+ end user's subscription and is of type Grouped. The Subscription-Id
+ AVP includes a Subscription-Id-Data AVP that holds the identifier and
+ a Subscription-Id-Type AVP that defines the identifier type.
+
+ The Subscription-Id AVP is defined as follows (per grouped-avp-def as
+ defined in [RFC6733]):
+
+ Subscription-Id ::= < AVP Header: 443 >
+ { Subscription-Id-Type }
+ { Subscription-Id-Data }
+
+8.47. Subscription-Id-Type AVP
+
+ The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated,
+ and it is used to determine which type of identifier is carried by
+ the Subscription-Id AVP.
+
+ This specification defines the following subscription identifiers.
+ However, new Subscription-Id-Type values can be assigned by IANA as
+ defined in Section 12. A server MUST implement all the Subscription-
+ Id-Type values required to perform credit authorization for the
+ services it supports, including possible future values. Unknown or
+ unsupported Subscription-Id-Type values MUST be treated according to
+ the 'M' flag rule, as defined in [RFC6733].
+
+ END_USER_E164 0
+
+ The 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 1
+
+ The identifier is in IMSI format, according to the ITU-T E.212
+ identification plan as defined in [E212] and [CE212].
+
+ END_USER_SIP_URI 2
+
+ The identifier is in the form of a SIP URI, as defined in [RFC3261].
+
+
+
+
+Bertz, et al. Standards Track [Page 83]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ END_USER_NAI 3
+
+ The identifier is in the form of a Network Access Identifier, as
+ defined in [RFC7542].
+
+ END_USER_PRIVATE 4
+
+ The identifier is a credit-control server private identifier.
+
+8.48. Subscription-Id-Data AVP
+
+ The Subscription-Id-Data AVP (AVP Code 444) is used to identify the
+ end user and is of type UTF8String. The Subscription-Id-Type AVP
+ defines which type of identifier is used.
+
+8.49. User-Equipment-Info AVP
+
+ The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and
+ allows the credit-control client to indicate the identity and
+ capability of the terminal the subscriber is using for the connection
+ to the network.
+
+ The User-Equipment-Info AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ User-Equipment-Info ::= < AVP Header: 458 >
+ { User-Equipment-Info-Type }
+ { User-Equipment-Info-Value }
+
+8.50. User-Equipment-Info-Type AVP
+
+ The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459)
+ and defines the type of user equipment information contained in the
+ User-Equipment-Info-Value AVP.
+
+ This specification defines the following user equipment types.
+ However, new User-Equipment-Info-Type values can be assigned by IANA
+ as defined in Section 12.
+
+ IMEISV 0
+
+ The identifier contains the International Mobile Equipment Identifier
+ and Software Version (IMEISV) in the IMEISV format according to 3GPP
+ TS 23.003 [TGPPIMEI].
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 84]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ MAC 1
+
+ The 48-bit Media Access Control (MAC) address is formatted as
+ described in Section 3.21 of [RFC3580].
+
+ EUI64 2
+
+ The 64-bit identifier used to identify the hardware instance of the
+ product, as defined in [EUI64].
+
+ MODIFIED_EUI64 3
+
+ There are a number of types of terminals that have identifiers other
+ than the International Mobile Equipment Identifier (IMEI), IEEE 802
+ MACs, or EUI-64. These identifiers can be converted to modified
+ EUI-64 format as described in [RFC4291] or by using some other
+ methods referred to in the service-specific documentation.
+
+8.51. User-Equipment-Info-Value AVP
+
+ The User-Equipment-Info-Value AVP (AVP Code 460) is of type
+ OctetString. The User-Equipment-Info-Type AVP defines which type of
+ identifier is used.
+
+8.52. User-Equipment-Info-Extension AVP
+
+ The User-Equipment-Info-Extension AVP (AVP Code 653) is of type
+ Grouped and allows the credit-control client to indicate the identity
+ and capability of the terminal the subscriber is using for the
+ connection to the network. If the type of the equipment is one of
+ the enumerated User-Equipment-Info-Type AVP values, then the
+ credit-control client SHOULD send the information in the
+ User-Equipment-Info AVP, in addition to or instead of the
+ User-Equipment-Info-Extension AVP. This is done in order to preserve
+ backward compatibility with credit-control servers that support only
+ [RFC4006]. Exactly one AVP MUST be included inside the
+ User-Equipment-Info-Extension AVP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 85]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The User-Equipment-Info-Extension AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ User-Equipment-Info-Extension ::= < AVP Header: 653 >
+ [ User-Equipment-Info-IMEISV ]
+ [ User-Equipment-Info-MAC ]
+ [ User-Equipment-Info-EUI64 ]
+ [ User-Equipment-Info-ModifiedEUI64 ]
+ [ User-Equipment-Info-IMEI ]
+ [ AVP ]
+
+8.53. User-Equipment-Info-IMEISV AVP
+
+ The User-Equipment-Info-IMEISV AVP (AVP Code 654) is of type
+ OctetString. The User-Equipment-Info-IMEISV AVP contains the
+ International Mobile Equipment Identifier and Software Version in the
+ IMEISV format according to 3GPP TS 23.003 [TGPPIMEI].
+
+8.54. User-Equipment-Info-MAC AVP
+
+ The User-Equipment-Info-MAC AVP (AVP Code 655) is of type
+ OctetString. The User-Equipment-Info-MAC AVP contains the 48-bit MAC
+ address; the MAC address is formatted as described in Section 4.1.7.8
+ of [RFC5777].
+
+8.55. User-Equipment-Info-EUI64 AVP
+
+ The User-Equipment-Info-EUI64 AVP (AVP Code 656) is of type
+ OctetString. The User-Equipment-Info-EUI64 AVP contains the 64-bit
+ identifier used to identify the hardware instance of the product, as
+ defined in [EUI64].
+
+8.56. User-Equipment-Info-ModifiedEUI64 AVP
+
+ The User-Equipment-Info-ModifiedEUI64 AVP (AVP Code 657) is of type
+ OctetString. There are a number of types of terminals that have
+ identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These
+ identifiers can be converted to modified EUI-64 format as described
+ in [RFC4291] or by using some other methods referred to in the
+ service-specific documentation. The User-Equipment-Info-
+ ModifiedEUI64 AVP contains such identifiers.
+
+8.57. User-Equipment-Info-IMEI AVP
+
+ The User-Equipment-Info-IMEI AVP (AVP Code 658) is of type
+ OctetString. The User-Equipment-Info-IMEI AVP contains the
+ International Mobile Equipment Identifier in the IMEI format
+ according to 3GPP TS 23.003 [TGPPIMEI].
+
+
+
+Bertz, et al. Standards Track [Page 86]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.58. Subscription-Id-Extension AVP
+
+ The Subscription-Id-Extension AVP (AVP Code 659) is used to identify
+ the end user's subscription and is of type Grouped. The
+ Subscription-Id-Extension group AVP MUST include an AVP holding the
+ subscription identifier. The type of this included AVP indicates the
+ type of the subscription identifier. For each of the enumerated
+ values of the Subscription-Id-Type AVP, there is a corresponding
+ sub-AVP for use within the Subscription-Id-Extension group AVP. If a
+ new identifier type is required, a corresponding new sub-AVP SHOULD
+ be defined for use within the Subscription-Id-Extension group AVP.
+
+ If full backward compatibility with [RFC4006] is required, then the
+ Subscription-Id AVP MUST be used to indicate identifier types
+ enumerated in the Subscription-Id-Type AVP, whereas the Subscription-
+ Id-Extension AVP MUST be used only for newly defined identifier
+ types. If full backward compatibility with [RFC4006] is not
+ required, then the Subscription-Id-Extension AVP MAY be used to carry
+ the existing identifier types. In this case, the Subscription-Id-
+ Extension AVP MAY be sent together with the Subscription-Id AVP.
+
+ Exactly one sub-AVP MUST be included inside the Subscription-Id-
+ Extension AVP.
+
+ The Subscription-Id-Extension AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ Subscription-Id-Extension ::= < AVP Header: 659 >
+ [ Subscription-Id-E164 ]
+ [ Subscription-Id-IMSI ]
+ [ Subscription-Id-SIP-URI ]
+ [ Subscription-Id-NAI ]
+ [ Subscription-Id-Private ]
+ [ AVP ]
+
+8.59. Subscription-Id-E164 AVP
+
+ The Subscription-Id-E164 AVP (AVP Code 660) is of type UTF8String.
+ The Subscription-Id-E164 AVP contains the international E.164 format
+ (e.g., MSISDN), according to the ITU-T E.164 numbering plan defined
+ in [E164] and [CE164].
+
+8.60. Subscription-Id-IMSI AVP
+
+ The Subscription-Id-IMSI AVP (AVP Code 661) is of type UTF8String.
+ The Subscription-Id-IMSI AVP contains the IMSI format, according to
+ the ITU-T E.212 identification plan as defined in [E212] and [CE212].
+
+
+
+
+Bertz, et al. Standards Track [Page 87]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.61. Subscription-Id-SIP-URI AVP
+
+ The Subscription-Id-SIP-URI AVP (AVP Code 662) is of type UTF8String.
+ The Subscription-Id-SIP-URI AVP contains the identifier in the form
+ of a SIP URI, as defined in [RFC3261].
+
+8.62. Subscription-Id-NAI AVP
+
+ The Subscription-Id-NAI AVP (AVP Code 663) is of type UTF8String.
+ The Subscription-Id-NAI AVP contains the identifier in the form of a
+ Network Access Identifier, as defined in [RFC7542].
+
+8.63. Subscription-Id-Private AVP
+
+ The Subscription-Id-Private AVP (AVP Code 664) is of type UTF8String.
+ The Subscription-Id-Private AVP contains a credit-control server
+ private identifier.
+
+8.64. Redirect-Server-Extension AVP
+
+ The Redirect-Server-Extension AVP (AVP Code 665) is of type Grouped
+ and contains the address information of the redirect server (e.g.,
+ HTTP redirect server, SIP Server) with which the end user is to be
+ connected when the account cannot cover the service cost. It MUST be
+ present inside the QoS-Final-Unit-Indication AVP when the Final-Unit-
+ Action AVP is set to REDIRECT. If the type of the redirect server is
+ one of the enumerated values of the Redirect-Address-Type AVP, then
+ the credit-control server SHOULD send the information in the
+ Redirect-Server AVP, in addition to or instead of the Redirect-
+ Server-Extension AVP. This is done in order to preserve backward
+ compatibility with credit-control clients that support only
+ [RFC4006]. Exactly one AVP MUST be included inside the Redirect-
+ Server-Extension AVP.
+
+ The Redirect-Server-Extension AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ Redirect-Server-Extension ::= < AVP Header: 665 >
+ [ Redirect-Address-IPAddress ]
+ [ Redirect-Address-URL ]
+ [ Redirect-Address-SIP-URI ]
+ [ AVP ]
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 88]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+8.65. Redirect-Address-IPAddress AVP
+
+ The Redirect-Address-IPAddress AVP (AVP Code 666) is of type Address
+ and defines the IPv4 or IPv6 address of the redirect server with
+ which the end user is to be connected when the account cannot cover
+ the service cost.
+
+ When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6
+ format [RFC4291] MAY be used to indicate an IPv4 address.
+
+ The interpretation of Redirect-Address-IPAddress by the Diameter
+ Credit-Control client is a matter of local policy.
+
+8.66. Redirect-Address-URL AVP
+
+ The Redirect-Address-URL AVP (AVP Code 667) is of type UTF8String and
+ defines the address of the redirect server with which the end user is
+ to be connected when the account cannot cover the service cost. The
+ address type is in the form of a Uniform Resource Locator, as defined
+ in [RFC3986]. Note that individual URL schemes may restrict the
+ contents of the UTF8String.
+
+8.67. Redirect-Address-SIP-URI AVP
+
+ The Redirect-Address-SIP-URI AVP (AVP Code 668) is of type UTF8String
+ and defines the address of the redirect server with which the end
+ user is to be connected when the account cannot cover the service
+ cost. The address type is in the form of a SIP Uniform Resource
+ Identifier, as defined in [RFC3261].
+
+8.68. QoS-Final-Unit-Indication AVP
+
+ The QoS-Final-Unit-Indication AVP (AVP Code 669) is of type Grouped
+ and indicates that the Granted-Service-Unit AVP in the
+ Credit-Control-Answer or in the AA-Answer contains the final units
+ for the service. After these units have expired, the Diameter
+ Credit-Control client is responsible for executing the action
+ indicated in the Final-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-control
+ client to execute the specified action.
+
+ In the first interrogation, the QoS-Final-Unit-Indication AVP with
+ Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS can also be
+ present with no Granted-Service-Unit AVP in the Credit-Control-Answer
+ or in the AA-Answer. This indicates to the Diameter Credit-Control
+ client that the client is to execute the specified action
+
+
+
+Bertz, et al. Standards Track [Page 89]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ immediately. If the home service provider policy is to terminate the
+ service, naturally, the server SHOULD return the appropriate
+ transient failure (see Section 9.1) in order to implement the
+ policy-defined action.
+
+ The Final-Unit-Action AVP defines the behavior of the Service Element
+ when the user's account cannot cover the cost of the service and MUST
+ always be present if the QoS-Final-Unit-Indication AVP is included in
+ a command.
+
+ If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit-
+ Indication group AVP MUST NOT contain any other AVPs.
+
+ If the Final-Unit-Action AVP is set to REDIRECT, then the Redirect-
+ Server-Extension AVP MUST be present. The Filter-Rule AVP or the
+ Filter-Id AVP MAY be present in the Credit-Control-Answer message if
+ the user is also allowed to access other services that are not
+ accessible through the address given in the Redirect-Server-Extension
+ AVP or if access to these services needs to be limited in some way
+ (e.g., QoS).
+
+ If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
+ Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
+
+ The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can
+ be used to define a specific combination of a condition and an
+ action. If used only with traffic conditions, it should define which
+ traffic should be allowed when no more service units are granted.
+ However, if QoS or treatment information exists in the AVP, these
+ actions should be executed, e.g., limiting the allowed traffic with
+ certain QoS information. When multiple Filter-Rule AVPs exist,
+ precedence should be determined as defined in [RFC5777].
+
+ The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be
+ used to reference an IP filter list installed in the access device by
+ means other than the Diameter Credit-Control application, e.g.,
+ locally configured or configured by another entity.
+
+ If the Final-Unit-Action AVP is (1) set to TERMINATE, (2) set to
+ RESTRICT_ACCESS and the action required is to allow only traffic that
+ could be classified using an IPFilterRule, or (3) set to REDIRECT
+ using a type that is one of the types in the Redirect-Address-Type
+ AVP, then the credit-control server SHOULD send the information in
+ the Final-Unit-Indication AVP, in addition to or instead of the
+ QoS-Final-Unit-Indication AVP. This is done in order to preserve
+ backward compatibility with credit-control clients that support only
+ [RFC4006].
+
+
+
+
+Bertz, et al. Standards Track [Page 90]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The QoS-Final-Unit-Indication AVP is defined as follows (per
+ grouped-avp-def as defined in [RFC6733]):
+
+ QoS-Final-Unit-Indication ::= < AVP Header: 669 >
+ { Final-Unit-Action }
+ *[ Filter-Rule ]
+ *[ Filter-Id ]
+ [ Redirect-Server-Extension ]
+ *[ AVP ]
+
+9. Result-Code AVP Values
+
+ This section defines new Result-Code AVP [RFC6733] values that must
+ be supported by all Diameter implementations that conform to this
+ specification.
+
+ The Credit-Control-Answer message includes the Result-Code AVP, which
+ may indicate that an error was present in the Credit-Control-Request
+ message. A rejected Credit-Control-Request message SHOULD cause the
+ user's session to be terminated.
+
+9.1. Transient Failures
+
+ Errors that fall within the category of transient failures are used
+ to inform the peer that the request could not be satisfied at the
+ time it was received but that the request MAY be able to be satisfied
+ in the future.
+
+ DIAMETER_END_USER_SERVICE_DENIED 4010
+
+ The credit-control server denies the service request due to service
+ restrictions. If the CCR contained used service units, they are
+ deducted, if possible.
+
+ DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011
+
+ The credit-control server determines that the service can be granted
+ to the end user but that no further credit-control is needed for the
+ service (e.g., the service is free of charge).
+
+ DIAMETER_CREDIT_LIMIT_REACHED 4012
+
+ The credit-control server denies the service request because the
+ end user's account could not cover the requested service. If the CCR
+ contained used service units, they are deducted, if possible.
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 91]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+9.2. Permanent Failures
+
+ Errors that fall within the category of permanent failures are used
+ to inform the peer that the request failed and should not be
+ attempted again.
+
+ DIAMETER_USER_UNKNOWN 5030
+
+ The specified end user is unknown in the credit-control server.
+
+ DIAMETER_RATING_FAILED 5031
+
+ This error code is used to inform the credit-control client that the
+ credit-control server cannot rate the service request due to
+ insufficient rating input, an incorrect AVP combination, or an AVP or
+ AVP value that is not recognized or supported in the rating. The
+ Failed-AVP AVP MUST be included and contain (1) a copy of the entire
+ AVP or AVPs that could not be processed successfully or (2) an
+ example of the missing AVP, complete with the Vendor-Id if
+ applicable. The value field of the missing AVP should be of correct
+ minimum length and contain zeros.
+
+10. AVP Occurrence Table
+
+ The table in Section 10.1 presents the AVPs defined in this document
+ and specifies in which Diameter messages they MAY or MUST NOT be
+ present. Note that AVPs that can only be present within a Grouped
+ AVP are not represented in the 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 the
+ message.
+ 0-1 Zero or one instance of the AVP MAY be present in the
+ message. It is considered an error if there is more
+ than one instance of the AVP.
+ 1 One instance of the AVP MUST be present in the message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 92]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+10.1. Credit-Control AVP Table
+
+ The table in this section is used to represent which credit-control
+ application-specific AVPs defined in this document are to be present
+ in 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-Handling | 0 | 0-1 |
+ Destination-Host | 0-1 | 0 |
+ Destination-Realm | 1 | 0 |
+ Direct-Debiting-Failure-Handling | 0 | 0-1 |
+ Event-Timestamp | 0-1 | 0-1 |
+ Failed-AVP | 0 | 0+ |
+ Final-Unit-Indication | 0 | 0-1 |
+ QoS-Final-Unit-Indication | 0 | 0-1 |
+ Granted-Service-Unit | 0 | 0-1 |
+ Multiple-Services-Credit-Control | 0+ | 0+ |
+ 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 |
+ Session-Id | 1 | 1 |
+ Subscription-Id | 0+ | 0 |
+
+
+
+Bertz, et al. Standards Track [Page 93]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Subscription-Id-Extension | 0+ | 0 |
+ Termination-Cause | 0-1 | 0 |
+ User-Equipment-Info | 0-1 | 0 |
+ User-Equipment-Info-Extension | 0-1 | 0 |
+ Used-Service-Unit | 0+ | 0 |
+ User-Name | 0-1 | 0-1 |
+ Validity-Time | 0 | 0-1 |
+ ----------------------------------|-----+-----+
+
+10.2. Re-Auth-Request/Re-Auth-Answer AVP Table
+
+ This section defines AVPs that are specific to the Diameter
+ Credit-Control application and that MAY be included in the Diameter
+ Re-Auth-Request/Re-Auth-Answer (RAR/RAA) message [RFC6733].
+
+ The RAR/RAA command MAY include the following additional AVPs:
+
+ +---------------+
+ | 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 Model
+
+ This section defines the basic principles for the Diameter
+ Credit-Control / RADIUS prepaid interworking model -- that is, a
+ message translation between a RADIUS-based prepaid solution and a
+ Diameter Credit-Control application. A complete description of the
+ protocol translations between RADIUS and the Diameter Credit-Control
+ application is beyond the scope of this specification and SHOULD be
+ addressed in another appropriate document.
+
+ The Diameter Credit-Control architecture may have a Translation Agent
+ capable of translation between RADIUS prepaid and Diameter
+ Credit-Control protocols. A AAA server (usually the home AAA server)
+ may act as a Translation Agent and as a Diameter Credit-Control
+ client for Service Elements that use credit-control mechanisms other
+ than Diameter Credit-Control -- for instance, RADIUS prepaid. In
+ this case, the home AAA server contacts the Diameter Credit-Control
+ server as part of the authorization process. The interworking
+ architecture is illustrated in Figure 9, and an interworking flow is
+ illustrated in Figure 10. In a roaming situation, the Service
+
+
+
+Bertz, et al. Standards Track [Page 94]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Element (e.g., the NAS) may be located in the visited network, and a
+ visited AAA server is usually contacted. The visited AAA server then
+ connects to the home AAA server.
+
+ 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 9: Credit-Control Architecture with Service Element
+ Containing Translation Agent, Translating RADIUS Prepaid
+ to Diameter Credit-Control Protocol
+
+ When the AAA server acting as a Translation Agent receives an initial
+ RADIUS Access-Request message from a Service Element (e.g., NAS
+ access), it performs regular authentication and authorization. If
+ the RADIUS Access-Request message indicates that the Service Element
+ is capable of credit-control and if the home AAA server finds that
+ the subscriber is a prepaid subscriber, then a Diameter
+ Credit-Control-Request SHOULD be sent toward the credit-control
+ server to perform credit authorization and to establish a
+ credit-control session. After the Diameter Credit-Control server
+ checks the end user's account balance, rates the service, and
+ reserves credit from the end user's account, the reserved quota is
+ returned to the home AAA server in the Diameter Credit-Control-
+ Answer. The home AAA server then sends the reserved quota to the
+ Service Element in the RADIUS Access-Accept.
+
+ At the expiry of the allocated quota, the Service Element sends a new
+ RADIUS Access-Request containing the units used thus far to the home
+ AAA server. The home AAA server shall map a RADIUS Access-Request
+ containing the reported units to the Diameter Credit-Control server
+ in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter
+ Credit-Control server debits the used units from the end user's
+ account and allocates a new quota that is returned to the home AAA
+ server in the Diameter Credit-Control-Answer. The quota is
+ transferred to the Service Element in the RADIUS Access-Accept. When
+ the end user terminates the service or when the entire quota has been
+
+
+
+Bertz, et al. Standards Track [Page 95]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ used, the Service Element sends a RADIUS Access-Request. To debit
+ the used units from the end user's account and to stop the
+ credit-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 session
+ termination by sending a Diameter Credit-Control-Answer to the home
+ AAA server. The RADIUS Access-Accept is sent to the NAS.
+
+ Figure 10 illustrates a Diameter Credit-Control / RADIUS prepaid
+ 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 10: Message Flow Example with Diameter
+ Credit-Control / RADIUS Prepaid Interworking
+
+
+
+Bertz, et al. Standards Track [Page 96]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+12. IANA Considerations
+
+ This document uses several registries that were originally created in
+ [RFC4006] or the values assigned to existing namespaces managed by
+ IANA. IANA has updated these registries to reference this document.
+ The registries and their allocation policies are specified below.
+
+12.1. Application Identifier
+
+ This specification assigns the value 4, "Diameter Credit Control", to
+ the "Application IDs" namespace defined in [RFC6733]. See
+ Section 1.3 for more information.
+
+12.2. Command Codes
+
+ This specification uses the value 272 from the "Command Codes"
+ namespace defined in [RFC6733] for the Credit-Control-Request (CCR)
+ and Credit-Control-Answer (CCA) commands.
+
+12.3. AVP Codes
+
+ See Section 8 for the assignments in this specification.
+
+ This document describes new AVP codes beyond those described in
+ [RFC4006]. IANA has allocated codes for the AVPs listed in Table 7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 97]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ +-----------------------------------+------+--------------+
+ | Attribute Name | Code | Defined in |
+ +-----------------------------------+------+--------------+
+ | User-Equipment-Info-Extension | 653 | Section 8.52 |
+ | User-Equipment-Info-IMEISV | 654 | Section 8.53 |
+ | User-Equipment-Info-MAC | 655 | Section 8.54 |
+ | User-Equipment-Info-EUI64 | 656 | Section 8.55 |
+ | User-Equipment-Info-ModifiedEUI64 | 657 | Section 8.56 |
+ | User-Equipment-Info-IMEI | 658 | Section 8.57 |
+ | Subscription-Id-Extension | 659 | Section 8.58 |
+ | Subscription-Id-E164 | 660 | Section 8.59 |
+ | Subscription-Id-IMSI | 661 | Section 8.60 |
+ | Subscription-Id-SIP-URI | 662 | Section 8.61 |
+ | Subscription-Id-NAI | 663 | Section 8.62 |
+ | Subscription-Id-Private | 664 | Section 8.63 |
+ | Redirect-Server-Extension | 665 | Section 8.64 |
+ | Redirect-Address-IPAddress | 666 | Section 8.65 |
+ | Redirect-Address-URL | 667 | Section 8.66 |
+ | Redirect-Address-SIP-URI | 668 | Section 8.67 |
+ | QoS-Final-Unit-Indication | 669 | Section 8.68 |
+ +-----------------------------------+------+--------------+
+
+ Table 7: Requested AVP Assignments
+
+12.4. Result-Code AVP Values
+
+ This specification assigns the values 4010, 4011, and 4012 in the
+ "Result-Code AVP Values (code 268) - Transient Failures" namespace
+ and values 5030 and 5031 in the "Result-Code AVP Values (code 268) -
+ Permanent Failure" namespace, both of which were defined by
+ [RFC6733]. See Section 9 for the assignments in this specification.
+
+12.5. CC-Request-Type AVP
+
+ As defined in Section 8.3, the CC-Request-Type AVP includes
+ Enumerated type values 1-4. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+12.6. CC-Session-Failover AVP
+
+ As defined in Section 8.4, the CC-Session-Failover AVP includes
+ Enumerated type values 0-1. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+
+
+
+Bertz, et al. Standards Track [Page 98]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+12.7. CC-Unit-Type AVP
+
+ As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated
+ type values 0-5. IANA has created and is maintaining a namespace for
+ this AVP. The definition of new values is subject to the
+ Specification Required policy [RFC8126] and conditions for enumerated
+ values described in [RFC7423], Section 5.6.
+
+12.8. Check-Balance-Result AVP
+
+ As defined in Section 8.6, the Check-Balance-Result AVP includes
+ Enumerated type values 0-1. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+12.9. Credit-Control AVP
+
+ As defined in Section 8.13, the Credit-Control AVP includes
+ Enumerated type values 0-1. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+12.10. Credit-Control-Failure-Handling AVP
+
+ As defined in Section 8.14, the Credit-Control-Failure-Handling AVP
+ includes Enumerated type values 0-2. IANA has created and is
+ maintaining a namespace for this AVP. The definition of new values
+ is subject to the Specification Required policy [RFC8126] and
+ conditions for enumerated values described in [RFC7423], Section 5.6.
+
+12.11. Direct-Debiting-Failure-Handling AVP
+
+ As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP
+ includes Enumerated type values 0-1. IANA has created and is
+ maintaining a namespace for this AVP. The definition of new values
+ is subject to the Specification Required policy [RFC8126] and
+ conditions for enumerated values described in [RFC7423], Section 5.6.
+
+12.12. Final-Unit-Action AVP
+
+ As defined in Section 8.35, the Final-Unit-Action AVP includes
+ Enumerated type values 0-2. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+
+
+
+Bertz, et al. Standards Track [Page 99]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+12.13. Multiple-Services-Indicator AVP
+
+ As defined in Section 8.40, the Multiple-Services-Indicator AVP
+ includes Enumerated type values 0-1. IANA has created and is
+ maintaining a namespace for this AVP. The definition of new values
+ is subject to the Specification Required policy [RFC8126] and
+ conditions for enumerated values described in [RFC7423], Section 5.6.
+
+12.14. Redirect-Address-Type AVP
+
+ As defined in Section 8.38, the Redirect-Address-Type AVP includes
+ Enumerated type values 0-3. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+12.15. Requested-Action AVP
+
+ As defined in Section 8.41, the Requested-Action AVP includes
+ Enumerated type values 0-3. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+12.16. Subscription-Id-Type AVP
+
+ As defined in Section 8.47, the Subscription-Id-Type AVP includes
+ Enumerated type values 0-4. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+12.17. Tariff-Change-Usage AVP
+
+ As defined in Section 8.27, the Tariff-Change-Usage AVP includes
+ Enumerated type values 0-2. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+12.18. User-Equipment-Info-Type AVP
+
+ As defined in Section 8.50, the User-Equipment-Info-Type AVP includes
+ Enumerated type values 0-3. IANA has created and is maintaining a
+ namespace for this AVP. The definition of new values is subject to
+ the Specification Required policy [RFC8126] and conditions for
+ enumerated values described in [RFC7423], Section 5.6.
+
+
+
+
+Bertz, et al. Standards Track [Page 100]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+13. Parameters Related to the Credit-Control Application
+
+ Tx timer
+
+ When real-time credit-control is required, the credit-control
+ client contacts the credit-control server before and while the
+ service is provided to an end user. Due to the real-time nature
+ of the application, communication delays SHOULD be minimized,
+ e.g., to avoid an overly long service setup time experienced by
+ the end user. The Tx timer is introduced to control the waiting
+ time in the client in the Pending state. When the Tx timer
+ elapses, the credit-control client takes action for the end user
+ according to the value of the CCFH or the DDFH. The recommended
+ value is 10 seconds.
+
+ Tcc timer
+
+ The Tcc timer supervises an ongoing credit-control session in the
+ credit-control server. It is RECOMMENDED to use the Validity-Time
+ as input to set the Tcc timer value. In the case of transient
+ failures in the network, the Diameter Credit-Control server might
+ change to Idle state. To avoid this, the Tcc timer MAY be set so
+ that Tcc is equal to 2 x Validity-Time.
+
+ Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling
+
+ Client implementations may offer the possibility of locally
+ configuring these AVPs. In such a case, their values and behavior
+ are defined in Sections 5.7 and 6.5, respectively.
+
+14. Security Considerations
+
+ Security considerations regarding the Diameter protocol itself are
+ discussed in [RFC6733]. The use of this application of Diameter MUST
+ take into consideration the security issues and requirements of the
+ base protocol.
+
+ This application includes a mechanism for application-layer replay
+ protection by means of (1) the Session-Id AVP as specified in
+ [RFC6733] and (2) the CC-Request-Number AVP, which is specified in
+ this document. The Diameter Credit-Control application is often used
+ within one domain, and there may be a single hop between the peers.
+ In these environments, the use of TLS/TCP, DTLS/SCTP (Datagram
+ Transport Layer Security / Stream Control Transmission Protocol), or
+ IPsec is sufficient. The details of security considerations related
+ to TLS/TCP, DTLS/SCTP, and IPsec are discussed in [RFC6733].
+
+
+
+
+
+Bertz, et al. Standards Track [Page 101]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Because this application handles monetary transactions (directly or
+ indirectly), it increases interest in various security attacks.
+ Therefore, all parties communicating with each other MUST be
+ authenticated, including, for instance, TLS client-side
+ authentication. In addition, authorization of the client SHOULD be
+ emphasized, i.e., that the client is allowed to perform
+ credit-control for a certain user. The specific means of
+ authorization are outside the scope of this specification but can be,
+ for instance, manual configuration.
+
+ Another kind of threat is malicious modification, injection, or
+ deletion of AVPs or complete credit-control messages. The
+ credit-control messages contain sensitive billing-related information
+ (such as subscription identifiers, granted units, used units, or cost
+ information) whose malicious modification can have financial
+ consequences. Sometimes simply delaying the credit-control messages
+ can cause disturbances in the credit-control client or server.
+
+ Even without any modifications to the messages, an adversary that can
+ eavesdrop on transactions can obtain privacy-sensitive information.
+ Also, by monitoring the credit-control messages, one can collect
+ information about the credit-control server's billing models and
+ business relationships.
+
+ When third-party relays or proxies are involved, hop-by-hop security
+ does not necessarily provide sufficient protection for Diameter user
+ sessions. In some cases, it may be inappropriate to send Diameter
+ messages, such as CCR messages and CCA messages, containing sensitive
+ AVPs via untrusted Diameter proxy agents, as there are no assurances
+ that third-party proxies will not modify the credit-control commands
+ or AVP values.
+
+14.1. Direct Connection with Redirects
+
+ A Diameter Credit-Control agent cannot always know whether agents
+ between it and the end user's Diameter Credit-Control server are
+ reliable. In this case, the Diameter Credit-Control agent doesn't
+ have a routing entry in its Diameter routing table (defined in
+ [RFC6733], Section 2.7) for the realm of the credit-control server in
+ the end user's home realm. The Diameter Credit-Control agent can
+ have a default route configured to a local redirect agent, and it
+ redirects the CCR message to the redirect agent. The local redirect
+ agent then returns a redirect notification (Result-Code 3006,
+ DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as
+ information about the Diameter Credit-Control server(s) (Redirect-
+ Host AVP) and information about how the routing entry resulting from
+ the Redirect-Host is to be used (Redirect-Host-Usage AVP). The
+ Diameter Credit-Control agent then forwards the CCR message directly
+
+
+
+Bertz, et al. Standards Track [Page 102]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ to one of the hosts identified by the CCA message from the redirect
+ agent. If the value of the Redirect-Host-Usage AVP does not equal
+ zero, all subsequent messages are sent to the host specified in the
+ Redirect-Host AVP until the time specified by the Redirect-Max-Cache-
+ Time AVP has expired.
+
+ Even with redirects, there are some authorization issues. There may
+ be attacks toward nodes that have been properly authorized but that
+ abuse their authorization or have been compromised. These issues are
+ discussed more widely in [RFC4072], Section 8.
+
+14.2. Application-Level Redirects
+
+ This document includes a redirection feature (Section 5.6.2) whereby
+ the service provider can redirect (in an application-specific way)
+ the end user to an alternate location when their credits have
+ expired. This technique is useful in that it allows the user to
+ return to normal service quickly, but it also exposes additional
+ risks and attack surface. In particular, this redirection can
+ potentially occur at an arbitrary point in a user's session,
+ potentially without any additional contextual confirmation available
+ to the user that the redirection is driven by the network. This lack
+ of confirmation matters because, in many application protocols, the
+ communication peer is also capable of inducing redirection. When the
+ peer is an attacker, the redirection can be to an attacker-controlled
+ site. In particular, such sites may be "phishing" sites designed to
+ appear similar to legitimate payment sites in an attempt to obtain
+ users' payment information for fraudulent purposes. When users
+ become accustomed to such redirections, they may have difficulty
+ distinguishing such attacks from legitimate redirections.
+
+ Because of the potentially harmful consequences of arbitrary
+ redirection by an attacker (such as to phishing sites), it is
+ important for service providers to be aware of that risk and ensure
+ that their users are aware of it as well. Service providers should
+ follow industry best practices for the specific application-layer
+ protocol to reduce the chances that such attacks could be mistaken
+ for legitimate redirections. The details of such a practice are out
+ of scope for this document.
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 103]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+15. Privacy Considerations
+
+ As the Diameter protocol, and especially the credit-control
+ application, deal with subscribers and their actions, extra care
+ should be taken regarding the privacy of the subscribers. Per
+ terminology used in [RFC6973], both the credit-control client and the
+ credit-control server are intermediary entities, wherein the
+ subscribers' privacy may be compromised even if no security issues
+ exist, and only authorized entities have access to the privacy-
+ sensitive information.
+
+15.1. Privacy-Sensitive AVPs
+
+ The privacy-sensitive AVPs listed in this section MUST NOT be sent
+ across non-trusted networks or Diameter agents without end-to-end
+ authentication and confidentiality protection, as described in
+ [RFC6733], Section 13.3.
+
+ The following AVPs contain privacy-sensitive information at different
+ levels:
+
+ 1. CC-Correlation-Id AVP: may contain privacy-sensitive
+ information, as the service provider may encode personal
+ information that helps it correlate different subscriptions and
+ access technologies.
+
+ 2. Check-Balance-Result AVP: contains information on the balance
+ status of the subscriber.
+
+ 3. Currency-Code AVP: contains information on the subscriber's
+ locale.
+
+ 4. Cost-Unit AVP: contains privacy-sensitive information for the
+ Cost-Information AVP, in human-readable format.
+
+ 5. Service-Identifier AVP: may contain privacy-sensitive
+ information about the subscriber's Internet activity.
+
+ 6. Rating-Group AVP: may contain privacy-sensitive information
+ about the subscriber's Internet activity.
+
+ 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule
+ may be used to infer services used by the subscriber.
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 104]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ 8. Redirect-Server-Address AVP: the service provider might embed
+ personal information on the subscriber in the URL/URI (e.g., to
+ create a personalized message). However, the service provider
+ may instead anonymize the subscriber's identity in the URL/URI
+ and let the redirect server query the information directly.
+ Such anonymized information must not allow personal information
+ or the subscriber's identity to be easily guessed. Furthermore,
+ the service provider should treat the URL/URI schema itself as
+ confidential and make sure it cannot be inferred (1) from
+ observation of the traffic or (2) due to its trivial structure.
+ A trivial structure could allow an adversary to query/modify
+ personal information even without knowing the subscriber's
+ identity. Similar AVPs are Redirect-Address-URL and Redirect-
+ Address-SIP-URI.
+
+ 9. Service-Context-Id AVP: depending on how the service provider
+ uses it, it may contain privacy-sensitive information about the
+ service (e.g., in a 3GPP network Service-Context-Id AVP, it has
+ a different value for packet switching, SMS, Multimedia Messages
+ (MMSs), etc.).
+
+ 10. Service-Parameter-Info AVP: depending on how the service
+ provider uses it, it may contain privacy-sensitive information
+ about the subscriber (e.g., location).
+
+ 11. Subscription-Id-Data AVP: contains the identity of the
+ subscriber. Similar AVPs are Subscription-Id-E164,
+ Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id-
+ NAI, and Subscription-Id-Private.
+
+ 12. User-Equipment-Info-Value AVP: contains the identity of the
+ device of the subscriber. Similar AVPs are User-Equipment-Info-
+ IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64,
+ User-Equipment-Info-ModifiedEUI64, and User-Equipment-Info-IMEI.
+
+ 13. QoS-Final-Unit-Indication AVP: Grouped AVP that may contain
+ privacy-sensitive information in its sub-AVPs (e.g.,
+ IPFilterRule, redirect address).
+
+ Note that some AVPs that are used in this document are defined in
+ [RFC6733] and may contain privacy-sensitive information. These AVPs
+ are not listed above.
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 105]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+15.2. Data Minimization
+
+ Due to the nature of the credit-control application, some personal
+ data and identity information must be stored in both the
+ credit-control client and the credit-control server. However, this
+ could be minimized by following these guidelines:
+
+ 1. Data stored in the credit-control client does not need to persist
+ across sessions. All data could be deleted once the session ends
+ and could be reconstructed once a new session is initialized.
+ Note that while the credit-control server is usually owned by the
+ service provider with which the subscriber already has some
+ direct legal or business relationship (where the privacy level
+ could be agreed upon), this is not always true for a
+ credit-control client that may be owned by a third party.
+
+ 2. Some information about the subscriber has to be stored in
+ persistent storage in the credit-control server (e.g., identity,
+ balance); however, per-transaction information does not have to
+ be stored in persistent storage, and per-session information may
+ be deleted from persistent storage once the session ends.
+
+ 3. In some cases, per-transaction information has to be stored on
+ the credit-control server, client, or both, for regulatory,
+ auditability, or debugging reasons. However, this could be
+ minimized by following these guidelines:
+
+ A. Data retention does not need to exceed the required duration.
+
+ B. Transaction information could be aggregated in some cases
+ (e.g., prefer information per session over information per
+ rating-group; prefer hourly byte summary over per-transaction
+ byte counts).
+
+ C. If not strictly needed, information that is more sensitive
+ (e.g., location, equipment type) could be filtered out of
+ such logs. This information is often used to make rating
+ decisions, and in this case, the rating decisions should be
+ logged instead of the data used to make them.
+
+ D. Due to the reasons explained in the first guideline, the
+ credit-control server, rather than the credit-control client,
+ would be the preferred location for storing such transaction
+ information.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 106]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+15.3. Diameter Agents
+
+ Diameter agents, as described in [RFC6733], may be owned by
+ third parties. If end-to-end security is supported between the
+ credit-control client and the credit-control server, the operator can
+ use it to encrypt privacy-sensitive AVPs (as listed in Section 15.1)
+ and prevent such information from leaking into the agent.
+
+ In some cases, the Diameter agent needs access to privacy-sensitive
+ AVPs, in order to make correct routing decisions or even to modify
+ the content of these AVPs. For example, a proxy agent may need to
+ look at the Subscription-Id-IMSI AVP, in order to extract the mobile
+ country and network codes of the user and use them to look up the
+ destination to which the request should be routed (see Section 2.8.2
+ in [RFC6733]). In such a case, the credit-control client and
+ credit-control server may use a mechanism that anonymizes the
+ identity of the subscriber, as well as a mechanism to encrypt other
+ AVPs not used by the agent.
+
+16. References
+
+16.1. Normative References
+
+ [CE164] International Telecommunication Union, "COMPLEMENT TO
+ ITU-T RECOMMENDATION E.164 (11/2010): LIST OF ITU-T
+ RECOMMENDATION E.164 ASSIGNED COUNTRY CODES",
+ November 2011, <https://www.itu.int/dms_pub/itu-t/opb/sp/
+ T-SP-E.164D-11-2011-PDF-E.pdf>.
+
+ [CE212] International Telecommunication Union, "COMPLEMENT TO
+ RECOMMENDATION ITU-T E.212 (09/2016): LIST OF MOBILE
+ COUNTRY OR GEOGRAPHICAL AREA CODES", February 2017,
+ <https://www.itu.int/dms_pub/itu-t/opb/sp/
+ T-SP-E.212A-2017-PDF-E.pdf>.
+
+ [E164] International Telecommunication Union, "The international
+ public telecommunication numbering plan", ITU-T
+ Recommendation E.164, November 2010,
+ <https://www.itu.int/rec/T-REC-E.164/>.
+
+ [E212] International Telecommunication Union, "The international
+ identification plan for public networks and
+ subscriptions", ITU-T Recommendation E.212,
+ September 2016, <https://www.itu.int/rec/T-REC-E.212/en>.
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 107]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ [EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier
+ (EUI), Organizationally Unique Identifier (OUI), and
+ Company ID (CID)", August 2017,
+ <https://standards.ieee.org/content/dam/
+ ieee-standards/standards/web/documents/tutorials/eui.pdf>.
+
+ [ISO4217] ISO, "Codes for the representation of currencies",
+ ISO 4217:2015, 2015, <https://www.iso.org/
+ iso-4217-currency-codes.html>.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ DOI 10.17487/RFC0791, September 1981,
+ <https://www.rfc-editor.org/info/rfc791>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ DOI 10.17487/RFC3261, June 2002,
+ <https://www.rfc-editor.org/info/rfc3261>.
+
+ [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
+ Accounting (AAA) Transport Profile", RFC 3539,
+ DOI 10.17487/RFC3539, June 2003,
+ <https://www.rfc-editor.org/info/rfc3539>.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <https://www.rfc-editor.org/info/rfc3986>.
+
+ [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and
+ J. Loughney, "Diameter Credit-Control Application",
+ RFC 4006, DOI 10.17487/RFC4006, August 2005,
+ <https://www.rfc-editor.org/info/rfc4006>.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, DOI 10.17487/RFC4291,
+ February 2006, <https://www.rfc-editor.org/info/rfc4291>.
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 108]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
+ Ed., and A. Lior, "Traffic Classification and Quality of
+ Service (QoS) Attributes for Diameter", RFC 5777,
+ DOI 10.17487/RFC5777, February 2010,
+ <https://www.rfc-editor.org/info/rfc5777>.
+
+ [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+ Address Text Representation", RFC 5952,
+ DOI 10.17487/RFC5952, August 2010,
+ <https://www.rfc-editor.org/info/rfc5952>.
+
+ [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
+ Ed., "Diameter Base Protocol", RFC 6733,
+ DOI 10.17487/RFC6733, October 2012,
+ <https://www.rfc-editor.org/info/rfc6733>.
+
+ [RFC7155] Zorn, G., Ed., "Diameter Network Access Server
+ Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
+ <https://www.rfc-editor.org/info/rfc7155>.
+
+ [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter
+ Applications Design Guidelines", BCP 193, RFC 7423,
+ DOI 10.17487/RFC7423, November 2014,
+ <https://www.rfc-editor.org/info/rfc7423>.
+
+ [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
+ DOI 10.17487/RFC7542, May 2015,
+ <https://www.rfc-editor.org/info/rfc7542>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+ [TGPPIMEI] 3rd Generation Partnership Project, Technical
+ Specification Group Core Network, "Numbering, addressing
+ and identification (release 15)", 3GPP TS 23.003
+ version 15.6.0, December 2018.
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 109]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+16.2. Informative References
+
+ [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
+ DOI 10.17487/RFC2866, June 2000,
+ <https://www.rfc-editor.org/info/rfc2866>.
+
+ [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
+ "IEEE 802.1X Remote Authentication Dial In User Service
+ (RADIUS) Usage Guidelines", RFC 3580,
+ DOI 10.17487/RFC3580, September 2003,
+ <https://www.rfc-editor.org/info/rfc3580>.
+
+ [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and
+ G. Camarillo, "Best Current Practices for Third Party Call
+ Control (3pcc) in the Session Initiation Protocol (SIP)",
+ BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
+ <https://www.rfc-editor.org/info/rfc3725>.
+
+ [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed.,
+ and P. McCann, "Diameter Mobile IPv4 Application",
+ RFC 4004, DOI 10.17487/RFC4004, August 2005,
+ <https://www.rfc-editor.org/info/rfc4004>.
+
+ [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
+ Extensible Authentication Protocol (EAP) Application",
+ RFC 4072, DOI 10.17487/RFC4072, August 2005,
+ <https://www.rfc-editor.org/info/rfc4072>.
+
+ [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+ Morris, J., Hansen, M., and R. Smith, "Privacy
+ Considerations for Internet Protocols", RFC 6973,
+ DOI 10.17487/RFC6973, July 2013,
+ <https://www.rfc-editor.org/info/rfc6973>.
+
+ [TGPPCHARG]
+ 3rd Generation Partnership Project, Technical
+ Specification Group Services and System Aspects, "Service
+ aspects; Charging and Billing", 3GPP TS 22.115
+ version 15.5.0, September 2018.
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 110]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+Appendix A. Credit-Control Sequences
+
+A.1. Flow I
+
+ A credit-control flow for Network Access Services prepaid is shown in
+ Figure 11. The Diameter protocol application is implemented in the
+ Network Access Server (NAS) per [RFC7155]. The focus of this flow is
+ on credit authorization.
+
+ NAS
+ End 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 | |
+ | |<--------------------| |
+ : : : :
+ : : : :
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 111]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ |(13)User logoff | | |
+ |------------------>|(14)CCR(Term., Used-Units) |
+ | |-------------------->|(15)CCR |
+ | | | (Term., Used-Units)
+ | | |-------------------->|
+ | | | (16)CCA |
+ | | (17)CCA |<--------------------|
+ | |<--------------------| |
+ | |(18)STR | |
+ | |-------------------->| |
+ | | (19)STA | |
+ | |<--------------------| |
+
+ Figure 11: Flow I
+
+ The user logs on to the network (1). The Diameter NAS sends a
+ Diameter AA-Request (AAR) to the home Diameter AAA server (2). The
+ credit-control client populates the AAR with the Credit-Control AVP
+ set to CREDIT_AUTHORIZATION, and service-specific AVPs are included,
+ as usual [RFC7155]. The home Diameter AAA server performs service-
+ specific authentication and authorization, as usual. The home
+ Diameter AAA server determines that the user is a prepaid user and
+ notices from the Credit-Control AVP that the NAS has credit-control
+ capabilities. It sends a Diameter Credit-Control-Request with
+ CC-Request-Type set to INITIAL_REQUEST to the Diameter Credit-Control
+ server to perform credit authorization (3) and to establish a
+ credit-control session. (The home Diameter AAA server may forward
+ service-specific AVPs received from the NAS as input for the rating
+ process.) The Diameter Credit-Control server checks the end user's
+ account balance, rates the service, and reserves credit from the
+ end user's account. The reserved quota is returned to the home
+ Diameter AAA server in the Diameter Credit-Control-Answer (4). The
+ home Diameter AAA server sends the reserved quota to the NAS in the
+ Diameter AA-Answer (AAA). Upon receiving the AA-Answer, the NAS
+ starts the credit-control session and starts monitoring the granted
+ units (5). The NAS grants access to the end user (6). At the expiry
+ of the allocated quota, the NAS sends a Diameter Credit-Control-
+ Request with CC-Request-Type set to UPDATE_REQUEST to the home
+ Diameter AAA server (7). This message contains the units used thus
+ far. The home Diameter AAA server forwards the CCR to the Diameter
+ Credit-Control server (8). The Diameter Credit-Control server debits
+ the used units from the end user's account and allocates a new quota
+ that is returned 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 lifetime
+ expires, and the authorization/authentication client in the NAS
+ performs service-specific re-authorization to the home Diameter AAA
+ server, as usual. The credit-control client populates the AAR with
+
+
+
+Bertz, et al. Standards Track [Page 112]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ the Credit-Control AVP set to RE_AUTHORIZATION, indicating that the
+ credit-control server shall not be contacted, as the credit
+ authorization 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 units
+ from the end user's account and to stop the credit-control session,
+ the NAS sends a Diameter Credit-Control-Request with CC-Request-Type
+ set to TERMINATION_REQUEST to the home Diameter AAA server (14). The
+ home Diameter AAA server forwards the CCR to the credit-control
+ server (15). The Diameter Credit-Control server acknowledges the
+ session termination by sending a Diameter Credit-Control-Answer to
+ the home Diameter AAA server (16). The home Diameter AAA server
+ forwards the answer to the NAS (17). The STR/STA takes place between
+ the NAS and home Diameter AAA server, as usual (18), (19).
+
+A.2. Flow II
+
+ Figure 12 provides an example of Diameter Credit-Control for SIP
+ sessions. Although the flow focuses on illustrating the usage of
+ credit-control messages, the SIP signaling is inaccurate, and the
+ diagram is not by any means an attempt to define a service provider's
+ SIP network. However, for the sake of this example, some assumptions
+ are made below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 113]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ SIP Proxy/Registrar AAA
+ A (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 12: Flow II
+
+ Typically, prepaid services based, for example, on time usage for SIP
+ sessions require an entity in the service provider network to
+ intercept all the requests within the SIP dialog in order to detect
+ events, such as session establishment and session release, that are
+ essential for performing credit-control operations with the
+ credit-control server. Therefore, in this example, it is assumed
+ that the SIP Proxy adds a Record-Route header in the initial SIP
+ INVITE to make sure that all the future requests in the created
+ dialog traverse through it (for the definitions of "Record-Route" and
+ "dialog", please refer to [RFC3261]). Finally, the degree of
+
+
+
+
+Bertz, et al. Standards Track [Page 114]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ credit-control measuring of the media by the proxy depends on the
+ business model design used in setting up the end system and proxies
+ in the SIP network.
+
+ The end user (SIP User Agent A) sends a REGISTER with credentials
+ (i). The SIP Proxy sends a request to the home AAA server to perform
+ multimedia authentication and authorization by using, for instance, a
+ Diameter multimedia application (ii). The home AAA server checks
+ that the credentials are correct and checks the user profile.
+ Eventually, a 200 OK response (iii) is sent to the User Agent. Note
+ that the authentication and authorization are valid for the
+ registration validity period duration (i.e., until re-registration is
+ performed). Several SIP sessions may be established without
+ re-authorization.
+
+ User Agent A sends an INVITE (1). The SIP Proxy sends a Diameter
+ Credit-Control-Request (INITIAL_REQUEST) to the Diameter
+ Credit-Control server (2). The Credit-Control-Request contains
+ information obtained from the SIP signaling describing the requested
+ service (e.g., calling party, called party, Session Description
+ Protocol (SDP) attributes). The Diameter Credit-Control server
+ checks the end user's account balance, rates the service, and
+ reserves credit from the end user's account. The reserved quota is
+ returned to the SIP Proxy in the Diameter Credit-Control-Answer (3).
+ The SIP Proxy forwards the SIP INVITE to User Agent B (4). B's phone
+ rings, and B answers. The media flows between them, and the SIP
+ Proxy starts measuring the quota. At the expiry of the allocated
+ quota, the SIP Proxy sends a Diameter Credit-Control-Request
+ (UPDATE_REQUEST) to the Diameter Credit-Control server (5). This
+ message contains the units used thus far. The Diameter
+ Credit-Control server debits the used units from the end user's
+ account and allocates new credit that is returned to the SIP Proxy in
+ the Diameter Credit-Control-Answer (6). The end user terminates the
+ service by sending a BYE message (7). The SIP Proxy forwards the BYE
+ message to User Agent B (8) and sends a Diameter Credit-Control-
+ Request (TERMINATION_REQUEST) to the credit-control server (9). The
+ Diameter Credit-Control server acknowledges the session termination
+ by sending a Diameter Credit-Control-Answer to the SIP Proxy (10).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 115]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+A.3. Flow III
+
+ A credit-control flow for Multimedia Messaging Service is shown in
+ Figure 13. The sender is charged as soon as the messaging server
+ successfully stores the message.
+
+ MMS Server
+ A (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 13: Flow III
+
+ This is an example of Diameter Credit-Control for direct debiting
+ using the Multimedia Messaging Service environment. Although the
+ flow focuses on illustrating the usage of credit-control messages,
+ the MMS signaling is inaccurate, and the diagram is not by any means
+ an attempt to define a service provider's MMS configuration or
+ billing model.
+
+ End user A sends an MMS to the MMS server (1). The MMS server stores
+ the message and sends a Diameter Credit-Control-Request
+ (EVENT_REQUEST with Requested-Action set to 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-Control server
+ checks the end user's account balance, rates the service, and debits
+ the service from the end user's account. The granted quota is
+ returned to the MMS server in the Diameter Credit-Control-Answer (3).
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 116]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The MMS server acknowledges the successful reception of the MMS
+ message (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).
+
+ Note that the transfer of the MMS message can take an extended period
+ of time and can fail, in which case a recovery action is needed. The
+ MMS server should return the already-debited units to the user's
+ account by using the REFUND action described in Section 6.4.
+
+A.4. Flow IV
+
+ Another credit-control flow for Multimedia Messaging Service is shown
+ in Figure 14. The recipient is charged at the time of message
+ delivery.
+
+ MMS Server
+ Content 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 14: Flow IV
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 117]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ This is an example of Diameter Credit-Control for direct debiting
+ using the Multimedia Messaging Service environment. Although the
+ flow focuses on illustrating the usage of credit-control messages,
+ the MMS signaling is inaccurate, and the diagram is not by any means
+ an attempt to define a service provider's MMS configuration or
+ billing model.
+
+ A content server sends an MMS to the MMS server (1), which stores the
+ message. The message recipient will be charged for the MMS message
+ in this case. As there can be a substantially long time between the
+ receipt of the message at the MMS server and the actual retrieval of
+ the message, the MMS server does not establish any credit-control
+ sessions to the Diameter Credit-Control server; rather, it first
+ performs only a balance check (without any credit reservations) by
+ sending a Diameter Credit-Control-Request (EVENT_REQUEST with
+ Requested-Action set to CHECK_BALANCE) to verify that end user B can
+ cover the cost for the MMS (2). The Diameter Credit-Control server
+ checks the end user's account balance and returns the answer to the
+ MMS server in the Diameter Credit-Control-Answer (3). The MMS server
+ acknowledges the successful reception of the MMS message (4). The
+ MMS server notifies the recipient of the new MMS (5), and after some
+ time end user B retrieves the message from the MMS message store (6).
+ The MMS server sends a Diameter Credit-Control-Request (EVENT_REQUEST
+ with Requested-Action set to DIRECT_DEBITING) to the Diameter
+ Credit-Control server (7). The Credit-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 the service, and debits the service
+ from the end user's account. The granted quota is returned to the
+ MMS server in the Diameter Credit-Control-Answer (8). The MMS is
+ transferred to end user B (9).
+
+ Note that the transfer of the MMS message can take an extended period
+ of time and can fail, in which case a recovery action is needed. The
+ MMS server should return the already-debited units to the user's
+ account by using the REFUND action described in Section 6.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 118]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+A.5. Flow V
+
+ Figure 15 provides an example of an Advice of Charge (AoC) service
+ for a SIP call.
+
+ SIP Controller
+ User Agent A (CC Client) User Agent B CC Server
+ |(1)INVITE | | |
+ | User Agent 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 15: Flow V
+
+ This is an example of Diameter Credit-Control for SIP sessions.
+ Although the flow focuses on illustrating the usage of credit-control
+ messages, the SIP signaling is inaccurate, and the diagram is not by
+ any means an attempt to define a service provider's SIP network.
+
+ User Agent A can be either a postpaid or prepaid subscriber using the
+ AoC service. It is assumed that the SIP controller also has HTTP
+ capabilities and delivers an interactive AoC web page with, for
+ instance, the cost information, the details of the call derived from
+ the SDP, and a button to accept/not accept the charges. (There may
+ be many other ways to deliver AoC information; however, this flow
+ focuses on the use of the credit-control messages.) The user has
+ been authenticated and authorized prior to initiating the call and
+ has been subscribed to the AoC service.
+
+ User Agent A sends an INVITE with the SDP to User Agent B via the SIP
+ controller (1). The SIP controller determines that the user is
+ subscribed to an AoC service and sends a Diameter Credit-Control-
+ Request (EVENT_REQUEST with Requested-Action set to PRICE_ENQUIRY) to
+ the Diameter Credit-Control server (2). The Credit-Control-Request
+
+
+
+Bertz, et al. Standards Track [Page 119]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ contains SIP-specific AVPs derived from the SIP signaling, describing
+ the requested service (e.g., calling party, called party, SDP
+ attributes). The Diameter Credit-Control server determines the cost
+ of the service and returns the Credit-Control-Answer, including the
+ Cost-Information AVP (3). The SIP controller manufactures the AoC
+ web page with information received in SIP signaling and with the cost
+ information received from the credit-control server. It then sends a
+ SIP MESSAGE that contains a URL pointing to the AoC information web
+ page (4). Upon receipt of the SIP MESSAGE, User Agent A
+ automatically invokes the web browser that retrieves the AoC
+ information (5). The user clicks on the appropriate button to accept
+ the charges (6). The SIP controller continues the session and sends
+ the INVITE to User Agent B, which accepts the call (7), (8), (9).
+
+A.6. Flow VI
+
+ Figure 16 illustrates a credit-control flow for the REFUND case. It
+ is assumed that there is a trusted relationship and secure connection
+ between the gaming server and the Diameter Credit-Control server.
+ The end user may be a prepaid subscriber or a postpaid subscriber.
+
+ Gaming Server
+ End 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 16: Flow VI
+
+ While the end user is playing the game (1), they enter a new level
+ that entitles them to a bonus. The gaming server sends a Diameter
+ Credit-Control-Request (EVENT_REQUEST with Requested-Action set to
+ REFUND_ACCOUNT) to the Diameter Credit-Control server (2). The
+ Credit-Control-Request contains the Requested-Service-Unit AVP with
+ the CC-Service-Specific-Units containing the number of points the
+ user just won. The Service-Parameter-Info AVP is also included in
+ the request and specifies the service event to be rated (e.g., Tetris
+ Bonus). From information received, the Diameter Credit-Control
+ server determines the amount to be credited, refunds the user's
+ account, and returns the Credit-Control-Answer, including the
+
+
+
+Bertz, et al. Standards Track [Page 120]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Cost-Information AVP (3). The Cost-Information AVP indicates the
+ credited amount. At the first opportunity, the gaming server
+ notifies the end user of the credited amount (4).
+
+A.7. Flow VII
+
+ Figure 17 provides an example of graceful service termination for a
+ SIP call. It is assumed that the call is set up so that the
+ controller is in the call as a B2BUA (Back-to-Back User Agent)
+ performing third-party call control (3PCC). Note that the SIP
+ signaling is inaccurate, as the focus of this flow is on graceful
+ service termination and credit-control authorization. Best practices
+ for 3PCC are defined in [RFC3725].
+
+ SIP Controller Top-Up
+ User Agent A (CC Client) Server User Agent B CC Server
+ | | | | |
+ | | (1)CCR(Update, Used-Units) | |
+ | |------------------------------------------>|
+ | | (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-Units)|
+ | |<------------------------------------------|
+ | (12)INVITE | (11)INVITE | |
+ |<---------------|--------------------------->| |
+
+ Figure 17: Flow VII
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 121]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The call is ongoing between User Agents A and B; User Agent A has a
+ prepaid subscription. At the expiry of the allocated quota, the SIP
+ controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST)
+ to the Diameter Credit-Control server (1). This message contains the
+ units used thus far. The Diameter Credit-Control server debits the
+ used units from the end user's account and allocates the final quota
+ returned to the SIP controller in the Diameter Credit-Control-Answer
+ (2). This message contains the Final-Unit-Indication AVP with
+ Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to
+ SIP URI, and the Redirect-Server-Address set to the top-up server
+ name (e.g., sip:sip-topup-server@domain.com). At the expiry of the
+ final allocated quota, the SIP controller sends a Diameter
+ Credit-Control-Request (UPDATE_REQUEST) to the Diameter
+ Credit-Control server (3) and places the called party on "hold" by
+ sending an INVITE with the appropriate connection address in the SDP
+ (3a). The Credit-Control-Request message contains the units used
+ thus far. The Diameter Credit-Control server debits the used units
+ from the end user's account but does not make any credit
+ reservations. The Credit-Control-Answer message, which contains the
+ Validity-Time to supervise the graceful service termination process,
+ is returned to the SIP controller (4). The SIP controller
+ establishes a SIP session between the prepaid user and the top-up
+ server (5), (6). The top-up server plays an announcement and prompts
+ the user to enter a credit card number and the amount of money to be
+ used to replenish the account (7). The top-up server validates the
+ credit card number, replenishes the user's account (using some means
+ outside the scope of this specification), and releases the SIP
+ session (8). The SIP controller can now assume that communication
+ between the prepaid user and the top-up server took place. It sends
+ a spontaneous Credit-Control-Request (UPDATE_REQUEST) to the Diameter
+ Credit-Control server to check whether the account has been
+ replenished (9). The Diameter Credit-Control server reserves credit
+ from the end user's account and returns the reserved quota to the SIP
+ controller in the Credit-Control-Answer (10). At this point, the SIP
+ controller reconnects the caller and the called party (11), (12).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 122]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+A.8. Flow VIII
+
+ Figure 18 provides an example of graceful service termination
+ initiated when the first interrogation takes place because the user's
+ account is empty. In this example, the credit-control server
+ supports the server-initiated credit re-authorization. The Diameter
+ protocol application is implemented in the NAS per [RFC7155].
+
+ NAS Top-Up CC
+ End 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 18: Flow VIII
+
+ The user logs on to the network (1). The Diameter NAS sends a
+ Diameter AA-Request (AAR) to the home Diameter AAA server (2). The
+ credit-control client populates the AAR with the Credit-Control AVP
+ set to CREDIT_AUTHORIZATION, and service-specific AVPs are included,
+ as usual [RFC7155]. The home Diameter AAA server performs service-
+ specific authentication and authorization, as usual. The home
+ Diameter AAA server determines that the user has a prepaid
+ subscription and notices from the Credit-Control AVP that the NAS has
+ credit-control capabilities. It sends a Diameter Credit-Control-
+
+
+
+Bertz, et al. Standards Track [Page 123]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter
+ Credit-Control server to perform credit authorization (3) and to
+ establish a credit-control session. (The home Diameter AAA server
+ may forward service-specific AVPs received from the NAS as input for
+ the rating process.) The Diameter Credit-Control server checks the
+ end user's account balance, determines that the account cannot cover
+ the cost of the service, and initiates graceful service termination.
+ The Credit-Control-Answer is returned to the home Diameter AAA server
+ (4). This message contains the Final-Unit-Indication AVP and the
+ Validity-Time AVP set to a reasonable amount of time, to give the
+ user a chance to replenish their account (e.g., 10 minutes). The
+ Final-Unit-Indication AVP includes the Final-Unit-Action set to
+ REDIRECT, the Redirect-Address-Type set to URL, and the Redirect-
+ Server-Address set to the HTTP top-up server name. The home Diameter
+ AAA server sends the received Credit-Control AVPs to the NAS in the
+ Diameter AA-Answer (5). Upon successful AAA, the NAS starts the
+ credit-control session and immediately starts graceful service
+ termination, as instructed by the server. The NAS grants limited
+ access to the user (6). The HTTP client software running in the
+ user's device opens the transport connection redirected by the NAS to
+ the top-up server (7), (8). An appropriate web page is provided for
+ the user where the user can enter the credit card number and the
+ amount of money to be used to replenish the account, along with a
+ notification message that they are granted unlimited access if the
+ replenishment operation will be successfully executed within, for
+ example, the next 10 minutes. The top-up server validates the credit
+ card number and replenishes the user's account (using some means
+ outside the scope of this specification) (9). After successful
+ account top-up, the credit-control server sends a Re-Auth-Request
+ message to the NAS (10). The NAS acknowledges the request by
+ returning the Re-Auth-Answer message (11) and initiates the credit
+ re-authorization by sending a Credit-Control-Request (UPDATE_REQUEST)
+ to the Diameter Credit-Control server (12), (13).
+
+ The Diameter Credit-Control server reserves credit from the
+ end user's account and returns the reserved quota to the NAS via the
+ home Diameter AAA server in the Credit-Control-Answer (14), (15).
+ The NAS removes the restriction applied by graceful service
+ termination and starts monitoring the granted units.
+
+A.9. Flow IX
+
+ The Diameter Credit-Control application defines the Multiple-
+ Services-Credit-Control AVP, which can be used to support independent
+ credit-control of multiple services in a single credit-control
+ (sub-)session for Service Elements that have such capabilities. It
+ is possible to request and allocate resources as a credit pool that
+ is shared between services or rating-groups.
+
+
+
+Bertz, et al. Standards Track [Page 124]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ Figure 19 illustrates a usage scenario where the credit-control
+ client and server support independent credit-control of multiple
+ services, as defined in Section 5.1.2. It is assumed that service-
+ identifiers, rating-groups, and their associated parameters (e.g., IP
+ 5-tuples) are locally configured in the Service Element or
+ provisioned by an entity other than the credit-control server.
+
+ End User Service Element CC Server
+ (CC Client)
+ |(1)User logon | |
+ |------------------>|(2)CCR(Initial, Service-Id access, |
+ | | Access-specific AVPs, |
+ | | Multiple-Services-Indicator) |
+ | |------------------------------------------->|
+ | |(3)CCA(Multiple-Services-CC ( |
+ | | Granted-Units(Total-Octets), |
+ | | Service-Id access, |
+ | | Validity-Time, |
+ | | G-S-U-Pool-Reference(Pool-Id 1, |
+ | | Multiplier 10))) |
+ | |<-------------------------------------------|
+ : : :
+ |(4)Service-Request (Service 1) |
+ |------------------>|(5)CCR(Update, Multiple-Services-CC ( |
+ | | Requested-Units(), Service-Id 1, |
+ | | Rating-Group 1)) |
+ | |------------------------------------------->|
+ | |(6)CCA(Multiple-Services-CC ( |
+ | | Granted-Units(Time), |
+ | | Rating-Group 1, |
+ | | G-S-U-Pool-Reference(Pool-Id 1, |
+ | | Multiplier 1))) |
+ | |<-------------------------------------------|
+ : : :
+ |(7)Service-Request (Service 2) |
+ |------------------>| |
+ : : :
+ : : :
+ |(8)Service-Request (Services 3 & 4) |
+ |------------------>|(9)CCR(Update, Multiple-Services-CC ( |
+ | | Requested-Units(), Service-Id 3, |
+ | | Rating-Group 2), |
+ | | Multiple-Services-CC ( |
+ | | Requested-Units(), Service-Id 4, |
+ | | Rating-Group 3)) |
+ | |------------------------------------------->|
+
+
+
+
+
+Bertz, et al. Standards Track [Page 125]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ | |(10)CCA(Multiple-Services-CC ( |
+ | | Granted-Units(Total-Octets), |
+ | | Service-Id 3, Rating-Group 2, |
+ | | Validity-Time, |
+ | | G-S-U-Pool-Reference(Pool-Id 2, |
+ | | Multiplier 2)), |
+ | | Multiple-Services-CC ( |
+ | | Granted-Units(Total-Octets), |
+ | | Service-Id 4, Rating-Group 3 |
+ | | Validity-Time, |
+ | | Final-Unit-Ind.(Terminate), |
+ | | G-S-U-Pool-Reference(Pool-Id 2, |
+ | | Multiplier 5))) |
+ | |<-------------------------------------------|
+ : : :
+ : : :
+ | +--------------+ | |
+ | |Validity time | |(11)CCR(Update, |
+ | |expires for | | Multiple-Services-CC ( |
+ | |Service-Id | | Requested-Unit(), |
+ | | access | | Used-Units(In-Octets, Out-Octets), |
+ | +--------------+ | Service-Id access)) |
+ | |------------------------------------------->|
+ | |(12)CCA(Multiple-Services-CC ( |
+ | | Granted-Units(Total-Octets), |
+ | | Service-Id access, |
+ | | Validity-Time, |
+ | | G-S-U-Pool-Reference(Pool-Id 1, |
+ | | Multiplier 10))) |
+ | |<-------------------------------------------|
+ : : :
+ : : :
+ | +--------------+ | |
+ | |Total quota | |(13)CCR(Update, |
+ | |elapses for | | Multiple-Services-CC ( |
+ | |Pool 2: | | Requested-Unit(), |
+ | |Service 4 not | | Used-Units(In-Octets, Out-Octets),|
+ | |allowed, | | Service-Id 3, Rating-Group 2), |
+ | |Service 3 | | Multiple-Services-CC ( |
+ | |continues | | Used-Units(In-Octets, Out-Octets),|
+ | +--------------+ | Service-Id 4, Rating-Group 3)) |
+ | |------------------------------------------->|
+ | |(14)CCA(Multiple-Services-CC ( |
+ | | Result-Code 4011, |
+ | | Service-Id 3)) |
+ | |<-------------------------------------------|
+ : : :
+ : : :
+
+
+
+Bertz, et al. Standards Track [Page 126]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ |(15)User logoff | |
+ |------------------>|(16)CCR(Term., |
+ | | Multiple-Services-CC ( |
+ | | Used-Units(In-Octets, Out-Octets),|
+ | | Service-Id access), |
+ | | Multiple-Services-CC ( |
+ | | Used-Units(Time), |
+ | | Service-Id 1, Rating-Group 1), |
+ | | Multiple-Services-CC ( |
+ | | Used-Units(Time), |
+ | | Service-Id 2, Rating-Group 1)) |
+ | |------------------------------------------->|
+ | |(17)CCA(Term.) |
+ | |<-------------------------------------------|
+
+ Figure 19: Flow IX: Example of Independent Credit-Control of
+ Multiple Services in a Credit-Control (Sub-)Session
+
+ The user logs on to the network (1). The Service Element sends a
+ Diameter Credit-Control-Request with CC-Request-Type set to
+ INITIAL_REQUEST to the Diameter Credit-Control server to perform
+ credit authorization for the bearer service (e.g., Internet access
+ service) and to establish a credit-control session (2). In this
+ message, the credit-control client indicates support for independent
+ credit-control of multiple services within the session by including
+ the Multiple-Services-Indicator AVP. The Diameter Credit-Control
+ server checks the end user's account balance, with rating information
+ received from the client (i.e., Service-Id and access-specific AVPs);
+ rates the request; and reserves credit from the end user's account.
+ Suppose that the server reserves $5 and determines that the cost is
+ $1/MB. It then returns to the Service Element a Credit-Control-
+ Answer message that includes the Multiple-Services-Credit-Control AVP
+ with a quota of 5 MB associated to the Service-Id (access), to a
+ multiplier value of 10, and to Pool-Id 1 (3).
+
+ The user uses service 1 (4). The Service Element sends a Diameter
+ Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to
+ the credit-control server to perform credit authorization for
+ service 1 (5). This message includes the Multiple-Services-Credit-
+ Control AVP to request service units for service 1 that belong to
+ Rating-Group 1. The Diameter Credit-Control server determines that
+ service 1 draws credit resources from the same account as the access
+ service (i.e., pool 1). It rates the request according to
+ Service-Id/rating-group and updates the existing reservation by
+ requesting more credit. Suppose that the server reserves $5 more
+ (now the reservation is $10) and determines that the cost is
+ $0.1/minute. The server authorizes the whole rating-group. It then
+ returns to the Service Element a Credit-Control-Answer message that
+
+
+
+Bertz, et al. Standards Track [Page 127]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ includes the Multiple-Services-Credit-Control AVP with a quota of
+ 50 minutes associated to Rating-Group 1, to a multiplier value of 1,
+ and to Pool-Id 1 (6). The client adjusts the total amount of
+ resources for pool 1 according to the received quota, which gives S
+ for pool 1 = 100.
+
+ The user uses service 2, which belongs to the authorized rating-group
+ (Rating-Group 1) (7). Resources are then consumed from pool 1.
+
+ The user now requests services 3 and 4 as well, which are not
+ authorized (8). The Service Element sends a Diameter Credit-Control-
+ Request with CC-Request-Type set to UPDATE_REQUEST to the
+ credit-control server in order to perform credit authorization for
+ services 3 and 4 (9). This message includes two instances of the
+ Multiple-Services-Credit-Control AVP to request service units for
+ service 3 that belong to Rating-Group 2 and service units for
+ service 4 that belong to Rating-Group 3. The Diameter Credit-Control
+ server determines that services 3 and 4 draw credit resources from
+ another account (i.e., pool 2). It checks the end user's account
+ balance and, according to Service-Id/rating-group information, rates
+ the request. It then reserves credit from pool 2.
+
+ For example, the server reserves $5 and determines that service 3
+ costs $0.2/MB and service 4 costs $0.5/MB. The server authorizes
+ only services 3 and 4. It returns to the Service Element a
+ Credit-Control-Answer message that includes two instances of the
+ Multiple-Services-Credit-Control AVP (10). One instance grants a
+ quota of 12.5 MB associated to Service-Id 3 to a multiplier value
+ of 2 and to Pool-Id 2. The other instance grants a quota of 5 MB
+ associated to Service-Id 4 to a multiplier value of 5 and to
+ Pool-Id 2.
+
+ The server also determines that pool 2 is exhausted and service 4 is
+ not allowed to continue after these units will be consumed.
+ Therefore, the Final-Unit-Indication AVP with action TERMINATE is
+ associated to Service-Id 4. The client calculates the total amount
+ of resources that can be used for pool 2 according to the received
+ quotas and multipliers, which gives S for pool 2 = 50.
+
+ The Validity-Time for the access service expires. The Service
+ Element sends a Credit-Control-Request message to the server in order
+ to perform credit re-authorization for the Service-Id (access) (11).
+ This message carries one instance of the Multiple-Services-Credit-
+ Control AVP that includes the units used by this service. Suppose
+ that the total amount of used units is 4 MB. The client adjusts the
+ total amount of resources for pool 1 accordingly, which gives S for
+ pool 1 = 60.
+
+
+
+
+Bertz, et al. Standards Track [Page 128]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+ The server deducts $4 from the user's account and updates the
+ reservation by requesting more credit. Suppose that the server
+ reserves $5 more (now the reservation is $11) and already knows the
+ cost of the Service-Id (access), which is $1/MB. It then returns to
+ the Service Element a Credit-Control-Answer message that includes the
+ Multiple-Services-Credit-Control AVP with a quota of 5 MB associated
+ to the Service-Id (access), to a multiplier value of 10, and to
+ Pool-Id 1 (12). The client adjusts the total amount of resources for
+ pool 1 according to the received quota, which gives S for
+ pool 1 = 110.
+
+ Services 3 and 4 consume the total amount of pool 2's credit
+ resources (i.e., C1*2 + C2*5 >= S). The Service Element immediately
+ starts the TERMINATE action for service 4 and sends a Credit-Control-
+ Request message with CC-Request-Type set to UPDATE_REQUEST to the
+ credit-control server in order to perform credit re-authorization for
+ service 3 (13). This message contains two instances of the Multiple-
+ Services-Credit-Control AVP to report the units used by services 3
+ and 4. The server deducts the last $5 from the user's account
+ (pool 2) and returns the answer with Result-Code 4011 in the
+ Multiple-Services-Credit-Control AVP to indicate that service 3 can
+ continue without credit-control (14).
+
+ The end user logs off from the network (15). To debit the used units
+ from the end user's account and to stop the credit-control session,
+ the Service Element sends a Diameter Credit-Control-Request with
+ CC-Request-Type set to TERMINATION_REQUEST to the credit-control
+ server (16). This message contains the units used by each service in
+ multiple instances of the Multiple-Services-Credit-Control AVP. The
+ used units are associated with the relevant Service-Identifier and
+ rating-group. The Diameter Credit-Control server debits the used
+ units to the user's account (pool 1) and acknowledges the session
+ termination by sending a Diameter Credit-Control-Answer to the
+ Service Element (17).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 129]
+
+RFC 8506 Diameter Credit-Control Application March 2019
+
+
+Acknowledgements
+
+ The original authors of RFC 4006 are Harri Hakala, Leena Mattila,
+ Juha-Pekka Koskinen, Marco Stura, and John Loughney.
+
+ The authors would like to thank Bernard Aboba, Jari Arkko, Robert
+ Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior,
+ Jussi Maki, Paco Marin, Jeff Meyer, Anne Narhi, John Prudhoe,
+ Christopher Richards, Juha Vallinen, and Mark Watson for their
+ comments and suggestions.
+
+Authors' Addresses
+
+ Lyle Bertz (editor)
+ Sprint
+ 6220 Sprint Parkway
+ Overland Park, KS 66251
+ United States of America
+
+ Email: lyleb551144@gmail.com
+
+
+ David Dolson (editor)
+ Sandvine
+ 408 Albert Street
+ Waterloo, ON N2L 3V3
+ Canada
+
+ Email: ddolson@acm.org
+
+
+ Yuval Lifshitz (editor)
+ Sandvine
+ 408 Albert Street
+ Waterloo, ON N2L 3V3
+ Canada
+
+ Email: yuvalif@yahoo.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bertz, et al. Standards Track [Page 130]
+