tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4006

 
 
 

Diameter Credit-Control Application

Part 4 of 5, p. 68 to 93
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 68 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.


Next RFC Part