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 7 of 9 – Pages 83 to 100
First   Prev   Next

Top   ToC   RFC8506 - Page 83   prevText
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.

   The Subscription-Id AVP is defined as follows (per grouped-avp-def as
   defined in [RFC6733]):

         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 IANA as
   defined in Section 12.  A server MUST implement all the Subscription-
   Id-Type values required to perform credit authorization for the
   services it supports, including possible future values.  Unknown or
   unsupported Subscription-Id-Type values MUST be treated according to
   the 'M' flag rule, as defined in [RFC6733].

   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 IMSI format, according to the ITU-T E.212
   identification 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 [RFC3261].
Top   ToC   RFC8506 - Page 84
   END_USER_NAI       3

   The identifier is in the form of a Network Access Identifier, as
   defined in [RFC7542].

   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 the network.

   The User-Equipment-Info AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

         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 IANA
   as defined in Section 12.

   IMEISV           0

   The identifier contains the International Mobile Equipment Identifier
   and Software Version (IMEISV) in the IMEISV format according to 3GPP
   TS 23.003 [TGPPIMEI].
Top   ToC   RFC8506 - Page 85
   MAC              1

   The 48-bit Media Access Control (MAC) address is formatted as
   described in Section 3.21 of [RFC3580].

   EUI64            2

   The 64-bit identifier used to identify the hardware instance of the
   product, as defined in [EUI64].

   MODIFIED_EUI64   3

   There are a number of types of terminals that have identifiers other
   than the International Mobile Equipment Identifier (IMEI), IEEE 802
   MACs, or EUI-64.  These identifiers can be converted to modified
   EUI-64 format as described in [RFC4291] 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.

8.52.  User-Equipment-Info-Extension AVP

   The User-Equipment-Info-Extension AVP (AVP Code 653) 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 the network.  If the type of the equipment is one of
   the enumerated User-Equipment-Info-Type AVP values, then the
   credit-control client SHOULD send the information in the
   User-Equipment-Info AVP, in addition to or instead of the
   User-Equipment-Info-Extension AVP.  This is done in order to preserve
   backward compatibility with credit-control servers that support only
   [RFC4006].  Exactly one AVP MUST be included inside the
   User-Equipment-Info-Extension AVP.
Top   ToC   RFC8506 - Page 86
   The User-Equipment-Info-Extension AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

    User-Equipment-Info-Extension ::= < AVP Header: 653 >
                                  [ User-Equipment-Info-IMEISV ]
                                  [ User-Equipment-Info-MAC ]
                                  [ User-Equipment-Info-EUI64 ]
                                  [ User-Equipment-Info-ModifiedEUI64 ]
                                  [ User-Equipment-Info-IMEI ]
                                  [ AVP ]

8.53.  User-Equipment-Info-IMEISV AVP

   The User-Equipment-Info-IMEISV AVP (AVP Code 654) is of type
   OctetString.  The User-Equipment-Info-IMEISV AVP contains the
   International Mobile Equipment Identifier and Software Version in the
   IMEISV format according to 3GPP TS 23.003 [TGPPIMEI].

8.54.  User-Equipment-Info-MAC AVP

   The User-Equipment-Info-MAC AVP (AVP Code 655) is of type
   OctetString.  The User-Equipment-Info-MAC AVP contains the 48-bit MAC
   address; the MAC address is formatted as described in Section 4.1.7.8
   of [RFC5777].

8.55.  User-Equipment-Info-EUI64 AVP

   The User-Equipment-Info-EUI64 AVP (AVP Code 656) is of type
   OctetString.  The User-Equipment-Info-EUI64 AVP contains the 64-bit
   identifier used to identify the hardware instance of the product, as
   defined in [EUI64].

8.56.  User-Equipment-Info-ModifiedEUI64 AVP

   The User-Equipment-Info-ModifiedEUI64 AVP (AVP Code 657) is of type
   OctetString.  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 [RFC4291] or by using some other methods referred to in the
   service-specific documentation.  The User-Equipment-Info-
   ModifiedEUI64 AVP contains such identifiers.

8.57.  User-Equipment-Info-IMEI AVP

   The User-Equipment-Info-IMEI AVP (AVP Code 658) is of type
   OctetString.  The User-Equipment-Info-IMEI AVP contains the
   International Mobile Equipment Identifier in the IMEI format
   according to 3GPP TS 23.003 [TGPPIMEI].
Top   ToC   RFC8506 - Page 87
8.58.  Subscription-Id-Extension AVP

   The Subscription-Id-Extension AVP (AVP Code 659) is used to identify
   the end user's subscription and is of type Grouped.  The
   Subscription-Id-Extension group AVP MUST include an AVP holding the
   subscription identifier.  The type of this included AVP indicates the
   type of the subscription identifier.  For each of the enumerated
   values of the Subscription-Id-Type AVP, there is a corresponding
   sub-AVP for use within the Subscription-Id-Extension group AVP.  If a
   new identifier type is required, a corresponding new sub-AVP SHOULD
   be defined for use within the Subscription-Id-Extension group AVP.

   If full backward compatibility with [RFC4006] is required, then the
   Subscription-Id AVP MUST be used to indicate identifier types
   enumerated in the Subscription-Id-Type AVP, whereas the Subscription-
   Id-Extension AVP MUST be used only for newly defined identifier
   types.  If full backward compatibility with [RFC4006] is not
   required, then the Subscription-Id-Extension AVP MAY be used to carry
   the existing identifier types.  In this case, the Subscription-Id-
   Extension AVP MAY be sent together with the Subscription-Id AVP.

   Exactly one sub-AVP MUST be included inside the Subscription-Id-
   Extension AVP.

   The Subscription-Id-Extension AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

         Subscription-Id-Extension ::= < AVP Header: 659 >
                                   [ Subscription-Id-E164 ]
                                   [ Subscription-Id-IMSI ]
                                   [ Subscription-Id-SIP-URI ]
                                   [ Subscription-Id-NAI ]
                                   [ Subscription-Id-Private ]
                                   [ AVP ]

8.59.  Subscription-Id-E164 AVP

   The Subscription-Id-E164 AVP (AVP Code 660) is of type UTF8String.
   The Subscription-Id-E164 AVP contains the international E.164 format
   (e.g., MSISDN), according to the ITU-T E.164 numbering plan defined
   in [E164] and [CE164].

8.60.  Subscription-Id-IMSI AVP

   The Subscription-Id-IMSI AVP (AVP Code 661) is of type UTF8String.
   The Subscription-Id-IMSI AVP contains the IMSI format, according to
   the ITU-T E.212 identification plan as defined in [E212] and [CE212].
Top   ToC   RFC8506 - Page 88
8.61.  Subscription-Id-SIP-URI AVP

   The Subscription-Id-SIP-URI AVP (AVP Code 662) is of type UTF8String.
   The Subscription-Id-SIP-URI AVP contains the identifier in the form
   of a SIP URI, as defined in [RFC3261].

8.62.  Subscription-Id-NAI AVP

   The Subscription-Id-NAI AVP (AVP Code 663) is of type UTF8String.
   The Subscription-Id-NAI AVP contains the identifier in the form of a
   Network Access Identifier, as defined in [RFC7542].

8.63.  Subscription-Id-Private AVP

   The Subscription-Id-Private AVP (AVP Code 664) is of type UTF8String.
   The Subscription-Id-Private AVP contains a credit-control server
   private identifier.

8.64.  Redirect-Server-Extension AVP

   The Redirect-Server-Extension AVP (AVP Code 665) 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 inside the QoS-Final-Unit-Indication AVP when the Final-Unit-
   Action AVP is set to REDIRECT.  If the type of the redirect server is
   one of the enumerated values of the Redirect-Address-Type AVP, then
   the credit-control server SHOULD send the information in the
   Redirect-Server AVP, in addition to or instead of the Redirect-
   Server-Extension AVP.  This is done in order to preserve backward
   compatibility with credit-control clients that support only
   [RFC4006].  Exactly one AVP MUST be included inside the Redirect-
   Server-Extension AVP.

   The Redirect-Server-Extension AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

        Redirect-Server-Extension ::= < AVP Header: 665 >
                                  [ Redirect-Address-IPAddress ]
                                  [ Redirect-Address-URL ]
                                  [ Redirect-Address-SIP-URI ]
                                  [ AVP ]
Top   ToC   RFC8506 - Page 89
8.65.  Redirect-Address-IPAddress AVP

   The Redirect-Address-IPAddress AVP (AVP Code 666) is of type Address
   and defines the IPv4 or IPv6 address of the redirect server with
   which the end user is to be connected when the account cannot cover
   the service cost.

   When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6
   format [RFC4291] MAY be used to indicate an IPv4 address.

   The interpretation of Redirect-Address-IPAddress by the Diameter
   Credit-Control client is a matter of local policy.

8.66.  Redirect-Address-URL AVP

   The Redirect-Address-URL AVP (AVP Code 667) is of type UTF8String and
   defines the address of the redirect server with which the end user is
   to be connected when the account cannot cover the service cost.  The
   address type is in the form of a Uniform Resource Locator, as defined
   in [RFC3986].  Note that individual URL schemes may restrict the
   contents of the UTF8String.

8.67.  Redirect-Address-SIP-URI AVP

   The Redirect-Address-SIP-URI AVP (AVP Code 668) is of type UTF8String
   and defines the address of the redirect server with which the end
   user is to be connected when the account cannot cover the service
   cost.  The address type is in the form of a SIP Uniform Resource
   Identifier, as defined in [RFC3261].

8.68.  QoS-Final-Unit-Indication AVP

   The QoS-Final-Unit-Indication AVP (AVP Code 669) 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 QoS-Final-Unit-Indication AVP with
   Final-Unit-Action set to 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 that the client is to execute the specified action
Top   ToC   RFC8506 - Page 90
   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 QoS-Final-Unit-Indication AVP is included in
   a command.

   If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit-
   Indication group AVP MUST NOT contain any other AVPs.

   If the Final-Unit-Action AVP is set to REDIRECT, then the Redirect-
   Server-Extension AVP MUST be present.  The 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-Extension
   AVP or if access to these services needs to be limited in some way
   (e.g., QoS).

   If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
   Filter-Rule AVP or the Filter-Id AVP SHOULD be present.

   The Filter-Rule AVP is defined in [RFC5777].  The Filter-Rule AVP can
   be used to define a specific combination of a condition and an
   action.  If used only with traffic conditions, it should define which
   traffic should be allowed when no more service units are granted.
   However, if QoS or treatment information exists in the AVP, these
   actions should be executed, e.g., limiting the allowed traffic with
   certain QoS information.  When multiple Filter-Rule AVPs exist,
   precedence should be determined as defined in [RFC5777].

   The Filter-Id AVP is defined in [RFC7155].  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.

   If the Final-Unit-Action AVP is (1) set to TERMINATE, (2) set to
   RESTRICT_ACCESS and the action required is to allow only traffic that
   could be classified using an IPFilterRule, or (3) set to REDIRECT
   using a type that is one of the types in the Redirect-Address-Type
   AVP, then the credit-control server SHOULD send the information in
   the Final-Unit-Indication AVP, in addition to or instead of the
   QoS-Final-Unit-Indication AVP.  This is done in order to preserve
   backward compatibility with credit-control clients that support only
   [RFC4006].
Top   ToC   RFC8506 - Page 91
   The QoS-Final-Unit-Indication AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

         QoS-Final-Unit-Indication ::= < AVP Header: 669 >
                                   { Final-Unit-Action }
                                  *[ Filter-Rule ]
                                  *[ Filter-Id ]
                                   [ Redirect-Server-Extension ]
                                  *[ AVP ]

9.  Result-Code AVP Values

   This section defines new Result-Code AVP [RFC6733] 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 category of transient failures are used
   to inform the 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., the 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   ToC   RFC8506 - Page 92
9.2.  Permanent Failures

   Errors that fall within the category of permanent failures 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
   AVP value that is not recognized or supported in the rating.  The
   Failed-AVP AVP MUST be included and contain (1) a copy of the entire
   AVP or AVPs that could not be processed successfully or (2) 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 table in Section 10.1 presents the AVPs defined in this document
   and specifies in which Diameter messages they MAY or MUST NOT be
   present.  Note that AVPs that can only be present within a Grouped
   AVP are not represented in the 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.
Top   ToC   RFC8506 - Page 93
10.1.  Credit-Control AVP Table

   The table in this section is used to represent which credit-control
   application-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-Handling   | 0   | 0-1 |
           Destination-Host                  | 0-1 | 0   |
           Destination-Realm                 | 1   | 0   |
           Direct-Debiting-Failure-Handling  | 0   | 0-1 |
           Event-Timestamp                   | 0-1 | 0-1 |
           Failed-AVP                        | 0   | 0+  |
           Final-Unit-Indication             | 0   | 0-1 |
           QoS-Final-Unit-Indication         | 0   | 0-1 |
           Granted-Service-Unit              | 0   | 0-1 |
           Multiple-Services-Credit-Control  | 0+  | 0+  |
           Multiple-Services-Indicator       | 0-1 | 0   |
           Origin-Host                       | 1   | 1   |
           Origin-Realm                      | 1   | 1   |
           Origin-State-Id                   | 0-1 | 0-1 |
           Proxy-Info                        | 0+  | 0+  |
           Redirect-Host                     | 0   | 0+  |
           Redirect-Host-Usage               | 0   | 0-1 |
           Redirect-Max-Cache-Time           | 0   | 0-1 |
           Requested-Action                  | 0-1 | 0   |
           Requested-Service-Unit            | 0-1 | 0   |
           Route-Record                      | 0+  | 0+  |
           Result-Code                       | 0   | 1   |
           Service-Context-Id                | 1   | 0   |
           Service-Identifier                | 0-1 | 0   |
           Service-Parameter-Info            | 0+  | 0   |
           Session-Id                        | 1   | 1   |
           Subscription-Id                   | 0+  | 0   |
Top   ToC   RFC8506 - Page 94
           Subscription-Id-Extension         | 0+  | 0   |
           Termination-Cause                 | 0-1 | 0   |
           User-Equipment-Info               | 0-1 | 0   |
           User-Equipment-Info-Extension     | 0-1 | 0   |
           Used-Service-Unit                 | 0+  | 0   |
           User-Name                         | 0-1 | 0-1 |
           Validity-Time                     | 0   | 0-1 |
           ----------------------------------|-----+-----+

10.2.  Re-Auth-Request/Re-Auth-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/Re-Auth-Answer (RAR/RAA) message [RFC6733].

   The RAR/RAA 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 interworking 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.

   The Diameter Credit-Control architecture may have a Translation Agent
   capable of translation between RADIUS prepaid and Diameter
   Credit-Control protocols.  A AAA server (usually the home AAA server)
   may act as a Translation Agent and as a Diameter Credit-Control
   client for Service Elements that use credit-control mechanisms other
   than Diameter Credit-Control -- for instance, RADIUS prepaid.  In
   this case, the home AAA server contacts the Diameter Credit-Control
   server as part of the authorization process.  The interworking
   architecture is illustrated in Figure 9, and an interworking flow is
   illustrated in Figure 10.  In a roaming situation, the Service
Top   ToC   RFC8506 - Page 95
   Element (e.g., the NAS) may be located in the visited network, and a
   visited AAA server is usually contacted.  The visited AAA server then
   connects 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 9: 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 a 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.  The home AAA server then 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 thus far to the home
   AAA server.  The home AAA server shall map a RADIUS Access-Request
   containing the reported units to the Diameter Credit-Control server
   in a Diameter Credit-Control-Request (UPDATE_REQUEST).  The Diameter
   Credit-Control server debits the used units from the end user's
   account and allocates a new quota that is returned to the home AAA
   server in the Diameter Credit-Control-Answer.  The quota is
   transferred to the Service Element in the RADIUS Access-Accept.  When
   the end user terminates the service or when the entire quota has been
Top   ToC   RFC8506 - Page 96
   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.

   Figure 10 illustrates a Diameter Credit-Control / RADIUS prepaid
   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 10: Message Flow Example with Diameter
               Credit-Control / RADIUS Prepaid Interworking
Top   ToC   RFC8506 - Page 97
12.  IANA Considerations

   This document uses several registries that were originally created in
   [RFC4006] or the values assigned to existing namespaces managed by
   IANA.  IANA has updated these registries to reference this document.
   The registries and their allocation policies are specified below.

12.1.  Application Identifier

   This specification assigns the value 4, "Diameter Credit Control", to
   the "Application IDs" namespace defined in [RFC6733].  See
   Section 1.3 for more information.

12.2.  Command Codes

   This specification uses the value 272 from the "Command Codes"
   namespace defined in [RFC6733] for the Credit-Control-Request (CCR)
   and Credit-Control-Answer (CCA) commands.

12.3.  AVP Codes

   See Section 8 for the assignments in this specification.

   This document describes new AVP codes beyond those described in
   [RFC4006].  IANA has allocated codes for the AVPs listed in Table 7.
Top   ToC   RFC8506 - Page 98
        +-----------------------------------+------+--------------+
        | Attribute Name                    | Code | Defined in   |
        +-----------------------------------+------+--------------+
        | User-Equipment-Info-Extension     | 653  | Section 8.52 |
        | User-Equipment-Info-IMEISV        | 654  | Section 8.53 |
        | User-Equipment-Info-MAC           | 655  | Section 8.54 |
        | User-Equipment-Info-EUI64         | 656  | Section 8.55 |
        | User-Equipment-Info-ModifiedEUI64 | 657  | Section 8.56 |
        | User-Equipment-Info-IMEI          | 658  | Section 8.57 |
        | Subscription-Id-Extension         | 659  | Section 8.58 |
        | Subscription-Id-E164              | 660  | Section 8.59 |
        | Subscription-Id-IMSI              | 661  | Section 8.60 |
        | Subscription-Id-SIP-URI           | 662  | Section 8.61 |
        | Subscription-Id-NAI               | 663  | Section 8.62 |
        | Subscription-Id-Private           | 664  | Section 8.63 |
        | Redirect-Server-Extension         | 665  | Section 8.64 |
        | Redirect-Address-IPAddress        | 666  | Section 8.65 |
        | Redirect-Address-URL              | 667  | Section 8.66 |
        | Redirect-Address-SIP-URI          | 668  | Section 8.67 |
        | QoS-Final-Unit-Indication         | 669  | Section 8.68 |
        +-----------------------------------+------+--------------+

                    Table 7: Requested AVP Assignments

12.4.  Result-Code AVP Values

   This specification assigns the values 4010, 4011, and 4012 in the
   "Result-Code AVP Values (code 268) - Transient Failures" namespace
   and values 5030 and 5031 in the "Result-Code AVP Values (code 268) -
   Permanent Failure" namespace, both of which were defined by
   [RFC6733].  See Section 9 for the assignments 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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.

12.6.  CC-Session-Failover AVP

   As defined in Section 8.4, the CC-Session-Failover AVP includes
   Enumerated type values 0-1.  IANA has created and is maintaining a
   namespace for this AVP.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.
Top   ToC   RFC8506 - Page 99
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.  The definition of new values is subject to the
   Specification Required policy [RFC8126] and conditions for enumerated
   values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values
   is subject to the Specification Required policy [RFC8126] and
   conditions for enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values
   is subject to the Specification Required policy [RFC8126] and
   conditions for enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.
Top   ToC   RFC8506 - Page 100
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.  The definition of new values
   is subject to the Specification Required policy [RFC8126] and
   conditions for enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.

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.  The definition of new values is subject to
   the Specification Required policy [RFC8126] and conditions for
   enumerated values described in [RFC7423], Section 5.6.


Next Section