Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8506

Diameter Credit-Control Application

Pages: 130
Proposed Standard
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 page on part 8)

Next Section