RFC 8506
Diameter Credit-Control Application
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].
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].
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.
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].
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].
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 ]
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
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].
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.
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.
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 |
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
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
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
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.
+-----------------------------------+------+--------------+ | 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 Assignments12.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.
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.
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)
