RFC 4006
Diameter Credit-Control Application
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.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 one of the following: UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of the 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.
UNIT_AFTER_TARIFF_CHANGE 1
When present in the Multiple-Services-Credit-Control AVP, this
value indicates the amount of the 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 tariff change had
occurred.
UNIT_INDETERMINATE 2
The used unit contains the amount of 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). This value is to be used only in the Used-
Service-Unit AVP.
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
Service-Context-Id and Service-Identifier AVPs.
A usage example of this AVP is illustrated in Appendix A (Flow IX).
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 Service-Context-Id and Rating-Group AVPs.
A usage example of this AVP is illustrated in Appendix A (Flow IX).
8.30. G-S-U-Pool-Reference 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.
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 service or rating group associated with the same pool). The G-S-U-Pool-Reference AVP is defined as follows (per the grouped- avp-def of RFC 3588 [DIAMBASE]): G-S-U-Pool-Reference ::= < AVP Header: 457 > { G-S-U-Pool-Identifier } { CC-Unit-Type } { Unit-Value }8.31. G-S-U-Pool-Identifier 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 58.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 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.
The Validity-Time AVP is also used for the 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 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 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, no other AVPs MUST be present. If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server AVP 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.
The Filter-Id AVP is defined in [NASREQ]. 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. The Final-Unit-Indication AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]): Final-Unit-Indication ::= < AVP Header: 430 > { Final-Unit-Action } *[ Restriction-Filter-Rule ] *[ Filter-Id ] [ Redirect-Server ]8.35. Final-Unit-Action 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. The Final-Unit-Action can be one of the following: 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. REDIRECT 1 The service element MUST redirect the user to the address specified in the Redirect-Server-Address AVP. The redirect action is defined in section 5.6.2. RESTRICT_ACCESS 2 The access device MUST restrict the user access according to the IP packet filters defined in the Restriction-Filter-Rule AVP or according to the IP packet filters identified by the Filter-Id AVP. All the packets not matching the filters MUST be dropped (see section 5.6.3).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. It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]): Redirect-Server ::= < AVP Header: 434 > { Redirect-Address-Type } { Redirect-Server-Address }8.38. Redirect-Address-Type 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. The address type can be one of the following: IPv4 Address 0 The address type is in the form of "dotted-decimal" IPv4 address, as defined in [IPv4]. IPv6 Address 1 The address type is in the form of IPv6 address, as defined in [IPv6Addr]. The address is a text representation of the address in either the preferred or alternate text form [IPv6Addr]. Conformant implementations MUST support the preferred form and SHOULD support the alternate text form for IPv6 addresses. URL 2 The address type is in the form of Uniform Resource Locator, as defined in [URL]. SIP URI 3 The address type is in the form of SIP Uniform Resource Identifier, as defined in [SIP].
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.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 Client does not support independent credit-control of multiple services within a (sub-)session. MULTIPLE_SERVICES_SUPPORTED 1 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 by 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.
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
reservation 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 enquiry 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 that applies to the request (as defined in section
4.1.2). This is an identifier allocated by the service provider, by
the service element manufacturer, or by 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 FQDN of the service provider
(e.g., provider.example.com) or of the vendor (e.g.,
vendor.example.com) if the identifier is allocated by a private
entity.
This AVP SHOULD be placed as close to the Diameter header as
possible.
Service-specific documents that are for private use only (i.e., to one provider's own use, where no interoperability is deemed useful) may define private identifiers without need of coordination. However, when interoperability is wanted, coordination of the identifiers via, for example, publication of an informational RFC is RECOMMENDED in order to make Service-Context-Id 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. It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]): Service-Parameter-Info ::= < AVP Header: 440 > { Service-Parameter-Type } { Service-Parameter-Value }8.44. Service-Parameter-Type 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., 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.
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. It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]): Subscription-Id ::= < AVP Header: 443 > { Subscription-Id-Type } { Subscription-Id-Data }8.47. Subscription-Id-Type 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 an IANA designated expert, as defined in section 12. A server MUST implement all the Subscription-Id-Types required to perform credit authorization for the services it supports, including possible future values. Unknown or unsupported Subscription-Id-Types MUST be treated according to the 'M' flag rule, as defined in [DIAMBASE]. 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 international IMSI format, according to the ITU-T E.212 numbering 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 [SIP]. END_USER_NAI 3 The identifier is in the form of a Network Access Identifier, as defined in [NAI].
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 network.
It is defined as follows (per the grouped-avp-def of RFC 3588
[DIAMBASE]):
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
8.50. User-Equipment-Info-Type 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 an
IANA designated expert, as defined in section 12.
IMEISV 0
The identifier contains the International Mobile Equipment
Identifier and Software Version in the international IMEISV format
according to 3GPP TS 23.003 [3GPPIMEI].
MAC 1
The 48-bit MAC address is formatted as described in [RAD802.1X].
EUI64 2
The 64-bit identifier used to identify 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 IMEI, IEEE 802 MACs, or EUI-64. These identifiers can
be converted to modified EUI-64 format as described in [IPv6Addr]
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.
9. Result Code AVP Values
This section defines new Result-Code AVP [DIAMBASE] 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 transient failures category are used to
inform a 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., 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.
9.2. Permanent Failures
Errors that fall within the permanent failure category 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 an AVP value that is not recognized or supported in the rating. The Failed-AVP AVP MUST be included and contain a copy of the entire AVP(s) that could not be processed successfully or 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 following table presents the AVPs defined in this document and specifies in which Diameter messages they MAY or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. The table uses the following symbols: 0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in 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. 1+ At least one instance of the AVP MUST be present in the message.
10.1. Credit-Control AVP Table
The table in this section is used to represent which credit-control applications 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- | 0 | 0-1 | Handling | | | Destination-Host | 0-1 | 0 | Destination-Realm | 1 | 0 | Direct-Debiting-Failure- | 0 | 0-1 | Handling | | | Event-Timestamp | 0-1 | 0-1 | Failed-AVP | 0 | 0+ | Final-Unit-Indication | 0 | 0-1 | Granted-Service-Unit | 0 | 0-1 | Multiple-Services-Credit- | 0+ | 0+ | Control | | | Multiple-Services-Indicator | 0-1 | 0 | Origin-Host | 1 | 1 | Origin-Realm | 1 | 1 | Origin-State-Id | 0-1 | 0-1 | Proxy-Info | 0+ | 0+ | Redirect-Host | 0 | 0+ | Redirect-Host-Usage | 0 | 0-1 | Redirect-Max-Cache-Time | 0 | 0-1 | Requested-Action | 0-1 | 0 | Requested-Service-Unit | 0-1 | 0 | Route-Record | 0+ | 0+ | Result-Code | 0 | 1 | Service-Context-Id | 1 | 0 | Service-Identifier | 0-1 | 0 | Service-Parameter-Info | 0+ | 0 |
Session-Id | 1 | 1 |
Subscription-Id | 0+ | 0 |
Termination-Cause | 0-1 | 0 |
User-Equipment-Info | 0-1 | 0 |
Used-Service-Unit | 0+ | 0 |
User-Name | 0-1 | 0-1 |
Validity-Time | 0 | 0-1 |
------------------------------|-----+-----+
10.2. Re-Auth-Request/Answer AVP 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/Answer (RAR/RAA) message [DIAMBASE].
Re-Auth-Request/Answer 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 inter-working 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, such as the RADIUS prepaid
specification.
The Diameter credit-control architecture may have a Translation Agent
capable of translation between RADIUS prepaid and Diameter credit-
control protocols. An 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 7, and interworking flow in Figure 8. In a roaming situation the service element (e.g., the NAS) may be located in the visited network, and a visited AAA server is usually contacted. The visited AAA server connects then 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 7: 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 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. Then the home AAA server 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 this 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 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.
A following diagram illustrates a RADIUS prepaid - Diameter credit- control interworking sequence. Service Element Translation Agent (e.g., NAS) (CC Client) CC Server | Access-Request | | |----------------------->| | | | CCR (initial) | | |----------------------->| | | CCA (Granted-Units) | | |<-----------------------| | Access-Accept | | | (Granted-Units) | | |<-----------------------| | : : : | Access-Request | | | (Used-Units) | | |----------------------->| | | | CCR (update, | | | Used-Units) | | |----------------------->| | | CCA (Granted-Units) | | |<-----------------------| | Access-Accept | | | (Granted-Units) | | |<-----------------------| | : : : | Access-Request | | |----------------------->| | | | CCR (terminate, | | | Used-Units) | | |----------------------->| | | CCA | | |<-----------------------| | Access-Accept | | |<-----------------------| | | | | Figure 8: Message flow example with RADIUS prepaid - Diameter credit-control interworking12. IANA Considerations
This section contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA.
In the subsections below, when we speak about review by a Designated Expert, please note that the designated expert will be assigned by the IESG. Initially, such Expert discussions take place on the AAA WG mailing list.12.1. Application Identifier
This specification assigns the value 4, 'Diameter Credit Control', to the Application Identifier namespace defined in [DIAMBASE]. See section 1.3 for more information.12.2. Command Codes
This specification uses the value 272 from the Command code namespace defined in [DIAMBASE] for the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) commands.12.3. AVP Codes
This specification assigns the values 411 - 461 from the AVP code namespace defined in [DIAMBASE]. See section 8 for the assignment of the namespace in this specification.12.4. Result-Code AVP Values
This specification assigns the values 4010, 4011, 4012, 5030, 5031 from the Result-Code AVP value namespace defined in [DIAMBASE]. See section 9 for the assignment of the namespace 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. All remaining values are available for assignment by a Designated Expert [IANA].12.6. CC-Session-Failover AVP
As defined in section 8.4, the CC-Failover-Supported AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].
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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].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. All remaining values are available for assignment by a Designated Expert [IANA].13. Credit-Control Application Related Parameters
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, the 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 an action to the end user according to the value of the Credit-Control-Failure-Handling AVP
or Direct-Debiting-Failure-Handling AVP. 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 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 equals 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 value and behavior
is defined in section 5.7 for the Credit-Control-Failure-Handling
and in section 6.5 for the Direct-Debiting-Failure-Handling.
14. Security Considerations
The Diameter base protocol [DIAMBASE] requires that each Diameter
implementation use underlying security; i.e., IPsec or TLS. These
mechanisms are believed to provide sufficient protection under the
normal Internet threat model; that is, assuming that the authorized
nodes engaging in the protocol have not been compromised, but that
the attacker has complete control over the communication channels
between them. This includes eavesdropping, message modification,
insertion, and man-in-the-middle and replay attacks. Note also that
this application includes a mechanism for application layer replay
protection by means of the Session-Id from [DIAMBASE] and CC-
Request-Number, 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 or IPsec is sufficient. The details of TLS and IPsec
related security considerations are discussed in the [DIAMBASE].
Because this application handles monetary transactions (directly or
indirectly), it increases the interest for 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 of 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 Id, granted units, used units, 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 modification to the messages, an adversary can invite a security threat by eavesdropping, as the transactions contain private information about the user. 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 proxy are involved, the hop-by-hop security does not necessarily provide sufficient protection for Diameter user session. In some cases, it may be inappropriate to send Diameter messages, such as CCR and CCA, 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 [DIAMBASE], section 2.7) for the realm of the credit-control server in the end user's home domain. 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 Diameter credit-control server(s) information (Redirect-Host AVP) and information (Redirect-Host-Usage AVP) about how the routing entry resulting from the Redirect-Host is to be used. The Diameter credit-control agent then forwards the CCR message directly to one of the hosts identified by the CCA message from the redirect agent. If the value of the Redirect-Host-Usage AVP is unequal to zero, all following messages are sent to the host specified in the Redirect- Host AVP until the time specified by the Redirect-Max-Cache-Time AVP is expired. There are some authorization issues even with redirects. 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 [DIAMEAP], section 8.
15. References
15.1. Normative References
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [3GPPCHARG] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Service aspects; Charging and Billing, (release 5), 3GPP TS 22.115 v. 5.2.1, 2002-03. [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [E164] Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997. [CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List of ITU-T Recommendation E.164 assigned country codes", June 2000. [E212] Recommendation E.212 (11/98): The international identification plan for mobile terminals and mobile users. 1998. [CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List of mobile country or geographical area codes", February 1999. [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IPv6Addr] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[ISO4217] Codes for the representation of currencies and funds, International Standard ISO 4217,2001 [NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html March 1997. [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-1215.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005. [DIAMEAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", Work in Progress. [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, April 2004.
16. Acknowledgements
The authors would like to thank Bernard Aboba, Jari Arkko, Robert Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, Christopher Richards, Juha Vallinen, and Mark Watson for their comments and suggestions.