Diameter Credit-Control Application
obsoletes
- rfc-4006 — Diameter Credit-Control Application
Extracted elements (32)
The credit pool concept (Section 5.1.2) was introduced to avoid credit fragmentation (many small parallel reservations on the same account) and to fix the over-reservation problem of the basic single-quota tariff time change mechanism; multipliers translate per-service units into a shared abstract pool, allowing a single reservation to cover multiple services.
Two first-interrogation approaches are defined (post-authorization CCR vs. credit-control AVPs embedded in AA-Request) because some environments (3GPP, SIP) decouple authentication from service requests, making a separate CCR more appropriate, while NAS environments benefit from combining them for protocol efficiency.
Section 11 defines a RADIUS/Diameter credit-control interworking model in which a Diameter/RADIUS gateway translates between RADIUS accounting attributes and Diameter credit-control AVPs, enabling prepaid services for RADIUS-based Service Elements.
All sub-sessions MUST be closed separately before the main session is closed so that units per sub-session may be reported; absence of CC-Sub-Session-Id implies no sub-sessions are in use.
At final interrogation (CC-Request-Type=TERMINATION_REQUEST), the credit-control server MUST refund the reserved credit not used to the end user's account and deduct the used monetary amount from the account.
Diameter nodes conforming to this specification MUST advertise support by including the value 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
Each credit-control session MUST have a globally unique Session-Id as defined in RFC 6733, and this Session-Id MUST NOT be changed during the lifetime of a credit-control session.
If a client does not support the tariff change mechanism and receives a CCA carrying the Tariff-Time-Change AVP, it MUST terminate the credit-control session with Termination-Cause set to DIAMETER_BAD_ANSWER.
If a rating input is incorrect in the CCR or the server does not support the requested service context, the CCA MUST contain the error code DIAMETER_RATING_FAILED and MUST include one or more Failed-AVP AVPs; a client receiving DIAMETER_RATING_FAILED MUST NOT send similar requests in the future.
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 (session-based credit-control), and in this case the credit-control server MUST maintain the credit-control session state.
Re-authorization of a credit pool is triggered when C1*M1 + C2*M2 + ... + Cn*Mn >= S, where Cx is used resources for service x and Mx is the corresponding multiplier; this formula governs pooled-quota exhaustion across multiple services.
The credit-control client MUST indicate support for independent credit-control of multiple services by including the Multiple-Services-Indicator AVP in the first interrogation; a server not supporting this feature MUST treat the Multiple-Services-Indicator AVP and any received Multiple-Services-Credit-Control AVPs as invalid.
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.
When all granted service units for a unit type are spent or the Validity-Time expires, the Diameter Credit-Control client MUST send a new Credit-Control-Request (CC-Request-Type=UPDATE_REQUEST) to the credit-control server.
When session-based credit-control is required, the first interrogation (CC-Request-Type=INITIAL_REQUEST) MUST be sent before the Diameter Credit-Control client allows any service events for the end user.
When the Diameter Credit-Control client reports used units and a tariff change has occurred, it MUST separately itemize units used before and after the tariff change; units that straddle the boundary and cannot be distinguished MUST be itemized in a third category.
Data minimization principles apply: credit-control clients SHOULD include only the subscription identifiers and equipment information required for rating, and SHOULD NOT send more granular service usage data than the credit-control server needs.
Several AVPs in CCR messages are privacy-sensitive, including Subscription-Id (MSISDN, IMSI, NAI), User-Equipment-Info (IMEI, MAC, EUI64), and service-specific rating AVPs; implementations SHOULD minimize the set of identifiers included and MUST protect them in transit using the Diameter security mechanisms.
The CC-Request-Type AVP (Enumerated) conveys the interrogation type: INITIAL_REQUEST (1), UPDATE_REQUEST (2), TERMINATION_REQUEST (3), and EVENT_REQUEST (4) for one-time events.
The Credit-Control-Answer (CCA) command uses Command Code 272 with the 'R' bit cleared, and includes mandatory AVPs: Session-Id, Result-Code, Origin-Host, Origin-Realm, Auth-Application-Id, CC-Request-Type, and CC-Request-Number.
The Credit-Control-Failure-Handling (CCFH) AVP and Direct-Debiting-Failure-Handling (DDFH) AVP allow service providers to specify per-policy behavior (TERMINATE, CONTINUE, or RETRY_AND_TERMINATE) when credit-control messages cannot reach the server.
The Credit-Control-Request (CCR) command uses Command Code 272 with the 'R' bit set, carries Auth-Application-Id=4, and includes mandatory AVPs: Session-Id, Origin-Host, Origin-Realm, Destination-Realm, Auth-Application-Id, Service-Context-Id, CC-Request-Type, and CC-Request-Number.
The Final-Unit-Indication AVP signals to the credit-control client that the granted units are the final ones; it carries a Final-Unit-Action AVP (TERMINATE, REDIRECT, or RESTRICT_ACCESS) defining what to do when the final units are consumed.
The Multiple-Services-Credit-Control AVP enables independent credit-control of multiple services within a single (sub-)session; it carries Requested-Service-Unit, Granted-Service-Unit, Used-Service-Unit, Service-Identifier, Rating-Group, Validity-Time, Final-Unit-Indication, and G-S-U-Pool-Reference sub-AVPs.
The Service-Context-Id AVP (UTF8String) uniquely identifies the service-specific document applicable to the CCR; the specific service is further identified by the combination of Service-Context-Id with Service-Identifier or Rating-Group.
IANA assigned Application-Id value 4 to the Diameter Credit-Control application, updating the 'Diameter Application IDs' registry.
IANA assigned Command Code 272 to both Credit-Control-Request (CCR) and Credit-Control-Answer (CCA), updating the 'Diameter Command Codes' registry.
New Result-Code values are registered: transient failure DIAMETER_END_USER_SERVICE_DENIED (4010), DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (4011), DIAMETER_CREDIT_LIMIT_REACHED (4012); permanent failures DIAMETER_USER_UNKNOWN (5030), DIAMETER_RATING_FAILED (5031).
This document allocates numerous new AVP Codes in the 'Diameter AVP Codes' registry, including CC-Request-Type (416), Granted-Service-Unit (431), Used-Service-Unit (446), Multiple-Services-Credit-Control (456), Final-Unit-Indication (430), and many others defined in Section 8.
Application-level redirects (Final-Unit-Action=REDIRECT) carry a risk of abuse, where a compromised credit-control server could redirect end users to malicious hosts; the redirect address returned in Final-Unit-Indication SHOULD be validated against a configured policy before use.
When Diameter redirect agents are used in the credit-control path, a malicious redirect agent could direct the credit-control client to a rogue server; implementations SHOULD use TLS/DTLS or IPsec to authenticate and protect connections to redirect agents and the servers they recommend.
Section 7 defines the credit-control application state machines. Key states include Idle, PendingI (awaiting initial answer), Open (session active), PendingU (awaiting update answer), PendingT (awaiting termination answer), and PendingE (one-time event pending); transitions are triggered by CCR/CCA exchanges, timer expiry (Tx, Tcc), and failure events.