Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: DIME

RFC 8506

Diameter Credit-Control Application

Pages: 130
Proposed STD
Obsoletes:  4006
Part 2 of 9 – Pages 9 to 17
First   Prev   Next

Top   ToC   RFC8506 - Page 9   prevText
2.  Architecture Models

   The current accounting models specified in the RADIUS accounting and
   Diameter base specifications [RFC2866] [RFC6733] are not sufficient
   for real-time credit-control, where creditworthiness is to be
   determined prior to service initiation.  Also, the existing Diameter
   authorization applications [RFC7155] [RFC4004] only provide service
   authorization; they do not provide credit authorization for prepaid
   users.  In order to support real-time credit-control, a new type of
   server is needed in the AAA infrastructure: the Diameter
   Credit-Control server.  The Diameter Credit-Control server is the
   entity responsible for credit authorization for prepaid subscribers.

   A Service Element may authenticate and authorize the end user with
   the AAA server by using AAA protocols, e.g., RADIUS or the Diameter
   base protocol (possibly extended via a Diameter application).

   Accounting protocols such as RADIUS accounting and the Diameter base
   accounting protocol can be used to provide accounting data to the
   accounting server after service is initiated and to provide possible
   interim reports until service completion.  However, for real-time
   credit-control, these authorization and accounting models are not
   sufficient.

   When real-time credit-control is required, the credit-control client
   contacts the credit-control server with information about a possible
   service event.  The credit-control process is performed to determine
   potential charges and to verify whether the end user's account
   balance is sufficient to cover the cost of the service being
   rendered.

   Figure 1 illustrates the typical credit-control architecture, which
   consists of a Service Element with an embedded Diameter
   Credit-Control client, a Diameter Credit-Control server, and a AAA
   server.  A Business Support System is usually deployed; at a minimum,
   it includes billing functionality.  The credit-control server and AAA
   server in this architecture model are logical entities.  The real
   configuration can combine them into a single host.  The
   credit-control protocol is the Diameter base protocol [RFC6733] with
   the Diameter Credit-Control application.
Top   ToC   RFC8506 - Page 10
   When an end user requests services such as SIP or messaging, the
   request is typically forwarded to a Service Element (e.g., a SIP
   Proxy) in the user's home realm as defined in [RFC6733].  In some
   cases, it might be possible that the Service Element in the local
   realm [RFC6733] can offer services to the end user; however, a
   commercial agreement must exist between the local realm and the home
   realm.  Network access is an example of a service offered in the
   local realm where the NAS, through a AAA infrastructure,
   authenticates and authorizes the user with the user's home network.

                  Service Element   AAA and CC
   +----------+      +---------+     Protocols+-----------+  +--------+
   |  End     |<---->|+-------+|<------------>|    AAA    |  |Business|
   |  User    |   +->|| CC    ||              |   Server  |->|Support |
   |          |   |  || Client||<-----+       |           |  |System  |
   +----------+   |  |+-------+|      |       +-----------+  |        |
                  |  +---------+      |             ^        +--------+
   +----------+   |                   | CC Protocol |             ^
   |  End     |<--+                   |       +-----v----+        |
   |  User    |                       +------>|Credit-   |        |
   +----------+                Credit-Control |Control   |--------+
                               Protocol       |Server    |
                                              +----------+

               Figure 1: Typical Credit-Control Architecture

   There can be multiple credit-control servers in the system for
   redundancy and load balancing.  The system can also contain separate
   rating server(s), and accounts can be located in a centralized
   database.  To ensure that the end user's account is not debited or
   credited multiple times for the same service event, only one entity
   in the credit-control system should perform duplicate detection.
   System-internal interfaces can exist to relay messages between
   servers and an account manager.  However, the detailed architecture
   of the credit-control system and its interfaces is implementation
   specific and is out of scope for this specification.

   Protocol-transparent Diameter relays can exist between the
   credit-control client and credit-control server.  Also, Diameter
   redirect agents that refer credit-control clients to credit-control
   servers and allow them to communicate directly can exist.  These
   agents transparently support the Diameter Credit-Control application.
   The different roles of Diameter agents are defined in Diameter base
   [RFC6733], Section 2.8.

   If Diameter Credit-Control proxies exist between the credit-control
   client and the credit-control server, they MUST advertise support for
   the Diameter Credit-Control application.
Top   ToC   RFC8506 - Page 11
3.  Credit-Control Messages

   This section defines new Diameter message Command Code values that
   MUST be supported by all Diameter implementations that conform to
   this specification.  The Command Codes are as follows:

         +------------------------+---------+------+-------------+
         | Command Name           | Abbrev. | Code | Reference   |
         +------------------------+---------+------+-------------+
         | Credit-Control-Request | CCR     | 272  | Section 3.1 |
         | Credit-Control-Answer  | CCA     | 272  | Section 3.2 |
         +------------------------+---------+------+-------------+

                     Table 1: Credit-Control Commands

   Section 3.2 of [RFC6733] (Diameter base) defines the Command Code
   Format specification.  These formats are observed in credit-control
   messages.

3.1.  Credit-Control-Request (CCR) Command

   The Credit-Control-Request message (CCR) is indicated by the Command
   Code field being set to 272 and the 'R' bit being set in the Command
   Flags field.  It is used between the Diameter Credit-Control client
   and the credit-control server to request credit authorization for a
   given service.

   The Auth-Application-Id MUST be set to the value 4, indicating the
   Diameter Credit-Control application.

   The CCR is extensible via the inclusion of one or more
   Attribute-Value Pairs (AVPs).

   Message Format:

   <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
                                < Session-Id >
                                { Origin-Host }
                                { Origin-Realm }
                                { Destination-Realm }
                                { Auth-Application-Id }
                                { Service-Context-Id }
                                { CC-Request-Type }
                                { CC-Request-Number }
                                [ Destination-Host ]
                                [ User-Name ]
                                [ CC-Sub-Session-Id ]
                                [ Acct-Multi-Session-Id ]
Top   ToC   RFC8506 - Page 12
                                [ Origin-State-Id ]
                                [ Event-Timestamp ]
                               *[ Subscription-Id ]
                               *[ Subscription-Id-Extension ]
                                [ Service-Identifier ]
                                [ Termination-Cause ]
                                [ Requested-Service-Unit ]
                                [ Requested-Action ]
                               *[ Used-Service-Unit ]
                                [ Multiple-Services-Indicator ]
                               *[ Multiple-Services-Credit-Control ]
                               *[ Service-Parameter-Info ]
                                [ CC-Correlation-Id ]
                                [ User-Equipment-Info ]
                                [ User-Equipment-Info-Extension ]
                               *[ Proxy-Info ]
                               *[ Route-Record ]
                               *[ AVP ]

3.2.  Credit-Control-Answer (CCA) Command

   The Credit-Control-Answer message (CCA) is indicated by the Command
   Code field being set to 272 and the 'R' bit being cleared in the
   Command Flags field.  It is used between the credit-control server
   and the Diameter Credit-Control client to acknowledge a
   Credit-Control-Request command.

   Message Format:

        <Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
                                    < Session-Id >
                                    { Result-Code }
                                    { Origin-Host }
                                    { Origin-Realm }
                                    { Auth-Application-Id }
                                    { CC-Request-Type }
                                    { CC-Request-Number }
                                    [ User-Name ]
                                    [ CC-Session-Failover ]
                                    [ CC-Sub-Session-Id ]
                                    [ Acct-Multi-Session-Id ]
                                    [ Origin-State-Id ]
                                    [ Event-Timestamp ]
                                    [ Granted-Service-Unit ]
                                   *[ Multiple-Services-Credit-Control ]
                                    [ Cost-Information ]
                                    [ Final-Unit-Indication ]
                                    [ QoS-Final-Unit-Indication ]
Top   ToC   RFC8506 - Page 13
                                    [ Check-Balance-Result ]
                                    [ Credit-Control-Failure-Handling ]
                                    [ Direct-Debiting-Failure-Handling ]
                                    [ Validity-Time ]
                                   *[ Redirect-Host ]
                                    [ Redirect-Host-Usage ]
                                    [ Redirect-Max-Cache-Time ]
                                   *[ Proxy-Info ]
                                   *[ Route-Record ]
                                   *[ Failed-AVP ]
                                   *[ AVP ]

4.  Credit-Control Application Overview

   The credit authorization process takes place before and during
   service delivery to the end user and generally requires the user's
   authentication and authorization before any requests are sent to the
   credit-control server.  The credit-control application defined in
   this specification supports two different credit authorization
   models: credit authorization with money reservation and credit
   authorization with direct debiting.  In both models, the
   credit-control client requests credit authorization from the
   credit-control server prior to allowing any services to be delivered
   to the end user.

   In the first model, the credit-control server rates the request,
   reserves a suitable amount of money from the user's account, and
   returns the amount of credit reserved.  Note that credit resources
   may not imply actual monetary credit; credit resources may be granted
   to the credit-control client in the form of units (e.g., data volume
   or time) to be metered.

   Upon receipt of a successful credit authorization answer with a
   certain amount of credit resources, the credit-control client allows
   service delivery to the end user and starts monitoring the usage of
   the granted resources.  When the credit resources granted to the user
   have been consumed or the service has been successfully delivered or
   terminated, the credit-control client reports back to the server the
   used amount.  The credit-control server deducts the used amount from
   the end user's account; it may perform rating and make a new credit
   reservation if the service delivery is continuing.  This process is
   accomplished with session-based credit-control that includes the
   first interrogation, possible intermediate interrogations, and the
   final interrogation.  For session-based credit-control, both the
   credit-control client and the credit-control server are required to
   maintain credit-control session state.  Session-based credit-control
   is described in more detail, with more variations, in Section 5.
Top   ToC   RFC8506 - Page 14
   In contrast, credit authorization with direct debiting is a
   single-transaction process wherein the credit-control server directly
   deducts a suitable amount of money from the user's account as soon as
   the credit authorization request is received.  Upon receipt of a
   successful credit authorization answer, the credit-control client
   allows service delivery to the end user.  This process is
   accomplished with the one-time event.  Session state is not
   maintained.

   In a multi-service environment, an end user can issue an additional
   service request (e.g., data service) during an ongoing service (e.g.,
   voice call) toward the same account.  Alternatively, during an active
   multimedia session, an additional media type is added to the session,
   causing a new simultaneous request toward the same account.
   Consequently, this needs to be considered when credit resources are
   granted to the services.

   The credit-control application also supports operations such as
   service price inquiries, user's balance checks, and refunds of credit
   on the user's account.  These operations are accomplished with the
   one-time event.  Session state is not maintained.

   Flexible failure handling, specific to the credit-control
   application, is defined in the application.  This allows the service
   provider to control the credit-control client's behavior according to
   its own risk management policy.

   The Credit-Control-Failure-Handling AVP (also referred to as the
   CCFH) and the Direct-Debiting-Failure-Handling AVP (also referred to
   as the DDFH) are defined to determine what is done if the sending of
   credit-control messages to the credit-control server has been
   temporarily prevented.  The usage of the CCFH and the DDFH allows
   flexibility, as failure handling for the credit-control session and
   one-time event direct debiting may be different.

4.1.  Service-Specific Rating Input and Interoperability

   The Diameter Credit-Control application defines the framework for
   credit-control; it provides generic credit-control mechanisms
   supporting multiple service applications.  The credit-control
   application therefore does not define AVPs that could be used as
   input in the rating process.  Listing the possible services that
   could use this Diameter application is out of scope for this generic
   mechanism.
Top   ToC   RFC8506 - Page 15
   It is reasonable to expect that a service level agreement will exist
   between providers of the credit-control client and the credit-control
   server covering the charging, services offered, roaming agreements,
   agreed-upon rating input (i.e., AVPs), and so on.

   Therefore, it is assumed that a Diameter Credit-Control server will
   provide service only for Diameter Credit-Control clients that have
   agreed beforehand as to the content of credit-control messages.
   Naturally, it is possible that any arbitrary Diameter Credit-Control
   client can interchange credit-control messages with any Diameter
   Credit-Control server, but with a higher likelihood that unsupported
   services/AVPs could be present in the credit-control message, causing
   the server to reject the request with an appropriate Result-Code.

4.1.1.  Specifying Rating Input AVPs

   There are two ways to provide rating input to the credit-control
   server: by either using AVPs or including the rating input in the
   Service-Parameter-Info AVP.  The general principles for sending
   rating parameters are as follows:

   1.  Using AVPs:

       A.  The service SHOULD reuse existing AVPs if it can use AVPs
           defined in existing Diameter applications (e.g., [RFC7155]
           for network access services).  [RFC6733] strongly recommends
           the reuse of existing AVPs.

           For AVPs of type Enumerated, the service may require a new
           value to be defined.  Allocation of new AVP values is done as
           specified in [RFC6733], Section 1.3.

       B.  New AVPs can be defined if the existing AVPs do not provide
           sufficient rating information.  In this case, the procedures
           defined in [RFC6733] for creating new AVPs MUST be followed.

       C.  For services specific only to one vendor's implementation, a
           vendor-specific AVP code for private use can be used.  Where
           a vendor-specific AVP is implemented by more than one vendor,
           allocation of global AVPs is encouraged instead; refer to
           [RFC6733].

   2.  The Service-Parameter-Info AVP MAY be used as a container to pass
       legacy rating information in its original encoded form (e.g.,
       ASN.1 BER).  This method can be used to avoid unnecessary
       conversions from an existing data format to an AVP format.  In
       this case, the rating input is embedded in the Service-Parameter-
       Info AVP as defined in Section 8.43.
Top   ToC   RFC8506 - Page 16
   New service applications SHOULD favor the use of explicitly defined
   AVPs as described in items 1a and 1b, to simplify interoperability.

4.1.2.  Service-Specific Documentation

   The service-specific rating input AVPs, and the contents of the
   Service-Parameter-Info AVP or Service-Context-Id AVP (defined in
   Section 8.42), are not within the scope of this document.  To
   facilitate interoperability, it is RECOMMENDED that the rating input
   and the values of the Service-Context-Id be coordinated via an
   informational RFC or other permanent and readily available reference
   (preferably that of another cooperative standardization body, e.g.,
   3GPP, the Open Mobile Alliance (OMA), or 3GPP2).  However, private
   services may be deployed that are subject to agreements between
   providers of the credit-control server and client.  In this case,
   vendor-specific AVPs can be used.

   This specification, together with the above-mentioned service-
   specific documents, governs the credit-control message.  Service-
   specific documents (i.e., those documents that do not define new
   credit-control applications) define which existing AVPs or new AVPs
   are used as input to the rating process; thus, the AVPs in question
   have to be included in the Credit-Control-Request command by a
   Diameter Credit-Control client supporting a given service as
   "* [AVP]".  Should the Service-Parameter-Info AVP be used, the
   service-specific document MUST specify the exact content of this
   Grouped AVP.

   The Service-Context-Id AVP MUST be included at the command level of a
   Credit-Control-Request to identify the service-specific document that
   applies to the request.  The specific service or rating-group the
   request relates to is uniquely identified by the combination of
   Service-Context-Id and Service-Identifier or rating-group.

4.1.3.  Handling of Unsupported/Incorrect Rating Input

   Diameter Credit-Control implementations are required to support
   mandatory rating-related AVPs defined in service-specific documents
   for the services they support, according to the 'M' bit rules in
   [RFC6733].

   If a rating input required for the rating process is incorrect in
   the Credit-Control-Request or if the credit-control server does not
   support the requested service context (identified by the
   Service-Context-Id AVP at the command level), the
   Credit-Control-Answer MUST contain the error code
   DIAMETER_RATING_FAILED.  A CCA message with this error MUST contain
   one or more Failed-AVP AVPs containing the missing and/or unsupported
Top   ToC   RFC8506 - Page 17
   AVPs that caused the failure.  A Diameter Credit-Control client that
   receives the error code DIAMETER_RATING_FAILED in response to a
   request MUST NOT send similar requests in the future.

4.1.4.  RADIUS Vendor-Specific Rating Attributes

   When service-specific documents include RADIUS vendor-specific
   attributes that could be used as input in the rating process, the
   rules described in [RFC7155] for formatting the Diameter AVP MUST be
   followed.

   For example, if the AVP code used is the vendor attribute type code,
   the Vendor-Specific flag MUST be set to 1 and the Vendor-Id MUST be
   set to the IANA Vendor identification value.  The Diameter AVP Data
   field contains only the attribute value of the RADIUS attribute.



(page 17 continued on part 3)

Next Section