tech-invite   World Map     

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

RFC 4006

 Errata 
Proposed STD
Pages: 114
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: AAA

Diameter Credit-Control Application

Part 1 of 5, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                          H. Hakala
Request for Comments: 4006                                    L. Mattila
Category: Standards Track                                       Ericsson
                                                           J-P. Koskinen
                                                                M. Stura
                                                             J. Loughney
                                                                   Nokia
                                                             August 2005


                 Diameter Credit-Control Application

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies a Diameter application that can be used to
   implement real-time credit-control for a variety of end user services
   such as network access, Session Initiation Protocol (SIP) services,
   messaging services, and download services.

Table of Contents

   1.  Introduction.................................................   4
       1.1.   Requirements Language.................................   5
       1.2.   Terminology...........................................   5
       1.3.   Advertising Application Support.......................   7
   2.  Architecture Models..........................................   7
   3.  Credit-Control Messages......................................   9
       3.1.   Credit-Control-Request (CCR) Command..................   9
       3.2.   Credit-Control-Answer (CCA) Command...................  11
   4.  Credit-Control Application Overview..........................  11
       4.1.   Service-Specific Rating Input and Interoperability....  13
   5.  Session Based Credit-Control.................................  15
       5.1.   General Principles....................................  15
       5.2.   First Interrogation...................................  21
       5.3.   Intermediate Interrogation............................  27
       5.4.   Final Interrogation...................................  29

Top      ToC       Page 2 
       5.5.   Server-Initiated Credit Re-Authorization..............  30
       5.6.   Graceful Service Termination..........................  32
       5.7.   Failure Procedures....................................  38
   6.  One Time Event...............................................  41
       6.1.   Service Price Enquiry.................................  42
       6.2.   Balance Check.........................................  42
       6.3.   Direct Debiting.......................................  43
       6.4.   Refund................................................  44
       6.5.   Failure Procedure.....................................  44
   7.  Credit-Control Application State Machine.....................  46
   8.  Credit-Control AVPs..........................................  55
       8.1.   CC-Correlation-Id AVP.................................  58
       8.2.   CC-Request-Number AVP.................................  58
       8.3.   CC-Request-Type AVP...................................  58
       8.4.   CC-Session-Failover AVP...............................  59
       8.5.   CC-Sub-Session-Id AVP.................................  59
       8.6.   Check-Balance-Result AVP..............................  60
       8.7.   Cost-Information AVP..................................  60
       8.8.   Unit-Value AVP........................................  61
       8.9.   Exponent AVP..........................................  61
       8.10.  Value-Digits AVP......................................  61
       8.11.  Currency-Code AVP.....................................  62
       8.12.  Cost-Unit AVP.........................................  62
       8.13.  Credit-Control AVP....................................  62
       8.14.  Credit-Control-Failure-Handling AVP...................  62
       8.15.  Direct-Debiting-Failure-Handling AVP..................  63
       8.16.  Multiple-Services-Credit-Control AVP..................  64
       8.17.  Granted-Service-Unit AVP..............................  65
       8.18.  Requested-Service-Unit AVP............................  66
       8.19.  Used-Service-Unit AVP.................................  66
       8.20.  Tariff-Time-Change AVP................................  67
       8.21.  CC-Time AVP...........................................  67
       8.22.  CC-Money AVP..........................................  67
       8.23.  CC-Total-Octets AVP...................................  68
       8.24.  CC-Input-Octets AVP...................................  68
       8.25.  CC-Output-Octets AVP..................................  68
       8.26.  CC-Service-Specific-Units AVP.........................  68
       8.27.  Tariff-Change-Usage AVP...............................  68
       8.28.  Service-Identifier AVP................................  69
       8.29.  Rating-Group AVP......................................  69
       8.30.  G-S-U-Pool-Reference AVP..............................  69
       8.31.  G-S-U-Pool-Identifier AVP.............................  70
       8.32.  CC-Unit-Type AVP......................................  70
       8.33.  Validity-Time AVP.....................................  70
       8.34.  Final-Unit-Indication AVP.............................  71
       8.35.  Final-Unit-Action AVP.................................  72
       8.36.  Restriction-Filter-Rule AVP...........................  72
       8.37.  Redirect-Server AVP...................................  73

Top      ToC       Page 3 
       8.38.  Redirect-Address-Type AVP.............................  73
       8.39.  Redirect-Server-Address AVP...........................  74
       8.40.  Multiple-Services-Indicator AVP.......................  74
       8.41.  Requested-Action AVP..................................  74
       8.42.  Service-Context-Id AVP................................  75
       8.43.  Service-Parameter-Info AVP............................  76
       8.44.  Service-Parameter-Type AVP............................  76
       8.45.  Service-Parameter-Value AVP...........................  77
       8.46.  Subscription-Id AVP...................................  77
       8.47.  Subscription-Id-Type AVP..............................  77
       8.48.  Subscription-Id-Data AVP..............................  78
       8.49.  User-Equipment-Info AVP...............................  78
       8.50.  User-Equipment-Info-Type AVP..........................  78
       8.51.  User-Equipment-Info-Value AVP.........................  79
   9.  Result Code AVP Values.......................................  79
       9.1.   Transient Failures....................................  79
       9.2.   Permanent Failures....................................  80
   10. AVP Occurrence Table.........................................  80
       10.1.  Credit-Control AVP Table..............................  81
       10.2.  Re-Auth-Request/Answer AVP Table......................  82
   11. RADIUS/Diameter Credit-Control Interworking Model............  82
   12. IANA Considerations..........................................  85
       12.1.  Application Identifier................................  86
       12.2.  Command Codes.........................................  86
       12.3.  AVP Codes.............................................  86
       12.4.  Result-Code AVP Values................................  86
       12.5.  CC-Request-Type AVP...................................  86
       12.6.  CC-Session-Failover AVP...............................  86
       12.7.  CC-Unit-Type AVP......................................  87
       12.8.  Check-Balance-Result AVP..............................  87
       12.9.  Credit-Control AVP....................................  87
       12.10. Credit-Control-Failure-Handling AVP...................  87
       12.11. Direct-Debiting-Failure-Handling AVP..................  87
       12.12. Final-Unit-Action AVP.................................  87
       12.13. Multiple-Services-Indicator AVP.......................  87
       12.14. Redirect-Address-Type AVP.............................  88
       12.15. Requested-Action AVP..................................  88
       12.16. Subscription-Id-Type AVP..............................  88
       12.17. Tariff-Change-Usage AVP...............................  88
       12.18. User-Equipment-Info-Type AVP..........................  88
   13. Credit-Control Application Related Parameters................  88
   14. Security Considerations......................................  89
       14.1.  Direct Connection with Redirects......................  90
   15. References...................................................  91
       15.1.  Normative References..................................  91
       15.2.  Informative References................................  92
   16. Acknowledgements.............................................  93
   Appendix A Credit-Control Sequences..............................  94

Top      ToC       Page 4 
       A.1.   Flow I................................................  94
       A.2.   Flow II...............................................  96
       A.3.   Flow III..............................................  98
       A.4.   Flow IV...............................................  99
       A.5.   Flow V................................................ 100
       A.6.   Flow VI............................................... 102
       A.7.   Flow VII.............................................. 103
       A.8.   Flow VIII............................................. 105
       A.9.   Flow IX............................................... 107
   Authors' Addresses............................................... 112
   Full Copyright Statement......................................... 114

1.  Introduction

   This document specifies a Diameter application that can be used to
   implement real-time credit-control for a variety of end user services
   such as network access, Session Initiation Protocol (SIP) services,
   messaging services, and download services.  It provides a general
   solution to real-time cost and credit-control.

   The prepaid model has been shown to be very successful, for instance,
   in GSM networks, where network operators offering prepaid services
   have experienced a substantial growth of their customer base and
   revenues.  Prepaid services are now cropping up in many other
   wireless and wire line based networks.

   In next generation wireless networks, additional functionality is
   required beyond that specified in the Diameter base protocol.  For
   example, the 3GPP Charging and Billing requirements [3GPPCHARG] state
   that an application must be able to rate service information in
   real-time.  In addition, it is necessary to check that the end user's
   account provides coverage for the requested service prior to
   initiation of that service.  When an account is exhausted or expired,
   the user must be denied the ability to compile additional chargeable
   events.

   A mechanism has to be provided to allow the user to be informed of
   the charges to be levied for a requested service.  In addition, there
   are services such as gaming and advertising that may credit as well
   as debit a user account.

   The other Diameter applications provide service specific
   authorization, and they do not provide credit authorization for
   prepaid users.  The credit authorization shall be generic and
   applicable to all the service environments required to support
   prepaid services.

Top      ToC       Page 5 
   To fulfill these requirements, it is necessary to facilitate credit-
   control communication between the network element providing the
   service (e.g., Network Access Server, SIP Proxy, and Application
   Server) and a credit-control server.

   The scope of this specification is the credit authorization.  Service
   specific authorization and authentication is out of the scope.

1.1.  Requirements Language

   In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [KEYWORDS].

1.2.  Terminology

   AAA

   Authentication, Authorization, and Accounting

   AA answer

   AA answer generically refers to a service specific authorization and
   authentication answer.  AA answer commands are defined in service
   specific authorization applications, e.g., [NASREQ] and [DIAMMIP].

   AA request

   AA request generically refers to a service specific authorization and
   authentication request.  AA request commands are defined in service
   specific authorization applications e.g., [NASREQ] and [DIAMMIP].

   Credit-control

   Credit-control is a mechanism that directly interacts in real-time
   with an account and controls or monitors the charges related to the
   service usage.  Credit-control is a process of checking whether
   credit is available, credit-reservation, deduction of credit from the
   end user account when service is completed and refunding of reserved
   credit that is not used.

   Diameter Credit-control Server

   A Diameter credit-control server acts as a prepaid server, performing
   real-time rating and credit-control.  It is located in the home
   domain and is accessed by service elements or Diameter AAA servers in

Top      ToC       Page 6 
   real-time for purpose of price determination and credit-control
   before the service event is delivered to the end-user.  It may also
   interact with business support systems.

   Diameter Credit-control Client

   A Diameter credit-control client is an entity that interacts with a
   credit-control server.  It monitors the usage of the granted quota
   according to instructions returned by credit-control server.

   Interrogation

   The Diameter credit-control client uses interrogation to initiate a
   session based credit-control process.  During the credit-control
   process, it is used to report the used quota and request a new one.
   An interrogation maps to a request/answer transaction.

   One-time event

   Basically, a request/answer transaction of type event.

   Rating

   The act of determining the cost of the service event.

   Service

   A type of task performed by a service element for an end user.

   Service Element

   A network element that provides a service to the end users.  The
   Service Element may include the Diameter credit-control client, or
   another entity (e.g., RADIUS AAA server) that can act as a Credit-
   control client on behalf of the Service Element.  In the latter case,
   the interface between the Service Element and the Diameter credit-
   control client is outside the scope of this specification.  Examples
   of the Service Elements include Network Access Server (NAS), SIP
   Proxy, and Application Servers such as messaging server, content
   server, and gaming server.

   Service Event

   An event relating to a service provided to the end user.

Top      ToC       Page 7 
   Session based credit-control

   A credit-control process that makes use of several interrogations:
   the first, a possible intermediate, and the final.  The first
   interrogation is used to reserve money from the user's account and to
   initiate the process.  The intermediate interrogations may be needed
   to request new quota while the service is being rendered.  The final
   interrogation is used to exit the process.  The credit-control server
   is required to maintain session state for session-based credit-
   control.

1.3.  Advertising Application Support

   Diameter nodes conforming to this specification MUST advertise
   support by including the value of 4 in the Auth-Application-Id of the
   Capabilities-Exchange-Request and Capabilities-Exchange-Answer
   command [DIAMBASE].

2.  Architecture Models

   The current accounting models specified in the Radius Accounting
   [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real-
   time credit-control, where credit-worthiness is to be determined
   prior to service initiation.  Also, the existing Diameter
   authorization applications, [NASREQ] and [DIAMMIP], only provide
   service authorization, but 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: 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 a Diameter
   base protocol with a possible 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.

Top      ToC       Page 8 
   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 an AAA server.
   A Business Support System is usually deployed; it includes at least
   the 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 with the Diameter
   credit-control application.

   When an end user requests services such as SIP or messaging, the
   request is typically forwarded to a service element (e.g., SIP Proxy)
   in the user's home domain.  In some cases it might be possible that
   the service element in the visited domain can offer services to the
   end user; however, a commercial agreement must exist between the
   visited domain and the home domain.  Network access is an example of
   a service offered in the visited domain where the NAS, through an 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 place 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 are implementation specific
   and are out of scope of this specification.

Top      ToC       Page 9 
   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
   [DIAMBASE], section 2.8.

   If Diameter credit-control proxies exist between the credit-control
   client and the credit-control server, they MUST advertise the
   Diameter credit-control application support.

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      3.1
   Credit-Control-Answer         CCA        272      3.2

   Diameter Base [DIAMBASE] defines in the section 3.2 the Command Code
   ABNF 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.

Top      ToC       Page 10 
   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 ]
                                   [ Origin-State-Id ]
                                   [ Event-Timestamp ]
                                  *[ Subscription-Id ]
                                   [ 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 ]
                                  *[ Proxy-Info ]
                                  *[ Route-Record ]
                                  *[ AVP ]

Top      ToC       Page 11 
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 ]
                                  [ 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 request is 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

Top      ToC       Page 12 
   authorization with direct debiting.  In both models, the credit-
   control client requests credit authorization from the credit-control
   server prior to allowing any service 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 corresponding amount of credit resources.  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.

   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 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 enquiry, user's balance check, and refund of credit on
   the user's account.  These operations are accomplished with the one-
   time event.  Session state is not maintained.

Top      ToC       Page 13 
   A flexible credit-control application specific failure handling is
   defined in which the home service provider can model the credit-
   control client behavior according to its own credit risk management
   policy.

   The Credit-Control-Failure-Handling AVP and the Direct-Debiting-
   Failure-Handling AVP 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 Credit-Control-
   Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP
   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.

   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 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: either by using AVPs or by including them in the Service-
   Parameter-Info AVP.  The general principles for sending rating
   parameters are as follows:

   1a. The service SHOULD re-use existing AVPs if it can use AVPs
   defined in existing Diameter applications (e.g., NASREQ for network
   access services).  Re-use of existing AVPs is strongly recommended in
   [DIAMBASE].

Top      ToC       Page 14 
   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
   [DIAMBASE], section 1.2.

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

   1c. 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 [DIAMBASE].

   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.

   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, 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.  The
   specification of another cooperative standardization body (e.g.,
   3GPP, OMA, and 3GPP2) SHOULD be used.  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 service specific
   documents, governs the credit-control message.  Service specific
   documents define which existing AVPs or new AVPs are used as input to
   the rating process (i.e., those that do not define new credit-control
   applications), and thus have to be included in the Credit-Control-
   Request command by a Diameter credit-control client supporting a
   given service as *[AVP].  Should Service-Parameter-Info be used, then
   the service specific document MUST specify the exact content of this
   grouped AVP.

Top      ToC       Page 15 
   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 the
   Mandatory rating AVPs defined in service specific documentation of
   the services they support, according to the 'M' bit rules in
   [DIAMBASE].

   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 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 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 [NASREQ] 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 15 continued on part 2)

Next RFC Part