Diameter Credit-Control Application
RFC 8506
| Document | Type |
RFC
- Proposed Standard
(March 2019)
IPR
Obsoletes RFC 4006
|
|
|---|---|---|---|
| Authors | Lyle Bertz , David Dolson , Yuval Lifshitz | ||
| Last updated | 2019-03-01 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Ben Campbell | |
| Send notices to | (None) |
RFC 8506
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]