Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4006

Diameter Credit-Control Application

Pages: 114
Obsoleted by:  8506
Part 4 of 5 – Pages 68 to 93
First   Prev   Next

ToP   noToC   RFC4006 - Page 68   prevText

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.
ToP   noToC   RFC4006 - Page 69
      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.
ToP   noToC   RFC4006 - Page 70
   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 5

8.33. Validity-Time AVP

The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is sent from the credit-control server to the credit-control client. The 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.
ToP   noToC   RFC4006 - Page 71
   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.
ToP   noToC   RFC4006 - Page 72
   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
ToP   noToC   RFC4006 - Page 73
   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].
ToP   noToC   RFC4006 - Page 74

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.
ToP   noToC   RFC4006 - Page 75
   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.
ToP   noToC   RFC4006 - Page 76
   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.
ToP   noToC   RFC4006 - Page 77

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].
ToP   noToC   RFC4006 - Page 78
   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].
ToP   noToC   RFC4006 - Page 79
   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.
ToP   noToC   RFC4006 - Page 80

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.
ToP   noToC   RFC4006 - Page 81

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 |
ToP   noToC   RFC4006 - Page 82
         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
ToP   noToC   RFC4006 - Page 83
   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
ToP   noToC   RFC4006 - Page 84
   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.
ToP   noToC   RFC4006 - Page 85
   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 interworking

12. 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.
ToP   noToC   RFC4006 - Page 86
   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].
ToP   noToC   RFC4006 - Page 87

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].
ToP   noToC   RFC4006 - Page 88

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
ToP   noToC   RFC4006 - Page 89
      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.
ToP   noToC   RFC4006 - Page 90
   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.
ToP   noToC   RFC4006 - Page 91

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.
ToP   noToC   RFC4006 - Page 92
   [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-12

15.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.
ToP   noToC   RFC4006 - Page 93

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.