Diameter Credit-Control Application
draft-ietf-dime-rfc4006bis-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8506.
|
|
|---|---|---|---|
| Authors | Lyle Bertz , David Dolson , ylifshitz@sandvine.com | ||
| Last updated | 2017-12-21 | ||
| Replaces | draft-bertz-dime-rfc4006bis | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-07)
by Linda Dunbar
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Waiting for WG Chair Go-Ahead | |
| Document shepherd | Jouni Korhonen | ||
| Shepherd write-up | Show Last changed 2017-12-10 | ||
| IESG | IESG state | Became RFC 8506 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | Jouni Korhonen <jouni.nospam@gmail.com> |
draft-ietf-dime-rfc4006bis-05
#x27;s account (using some means outside the scope of this specification)(9). After successful account top-up, the credit- control server sends a Re-Auth-Request message to the NAS (10). The NAS acknowledges the request by returning the Re-Auth-Answer message (11) and initiates the credit re-authorization by sending a Credit- Control-request (UPDATE_REQUEST) to the Diameter credit-control server (12,13). The Diameter credit-control server reserves credit from the end user's account and returns the reserved quota to the NAS via the home Diameter AAA server in the Credit-Control-Answer (14,15). The NAS removes the restriction placed by the graceful service termination and starts monitoring the granted units. B.9. Flow IX The Diameter credit-control application defines the Multiple- Services-Credit-Control AVP that can be used to support independent credit-control of multiple services in a single credit-control (sub-) session for service elements that have such capabilities. It is possible to request and allocate resources as a credit pool that is shared between services or rating groups. Bertz, et al. Expires June 23, 2018 [Page 115] Internet-Draft Diameter Credit-Control Application December 2017 The flow example hereafter illustrates a usage scenario where the credit-control client and server support independent credit-control of multiple services, as defined in Section 5.1.2. It is assumed that Service-Identifiers, Rating-Groups, and their associated parameters (e.g., IP 5-tuple) are locally configured in the service element or provisioned by an entity other than the credit-control server. End User Service Element CC Server (CC client) |(1)User logon | | |------------------>|(2)CCR(initial, Service-Id access, | | | Access specific AVPs, | | | Multiple-Service-Indicator) | | |---------------------------------------->| | |(3)CCA(Multiple-Services-CC ( | | | Granted-Units(Total-Octets), | | | Service-Id access, | | | Validity-time, | | | G-S-U-Pool-Reference(Pool-Id 1, | | | Multiplier 10))) | | |<----------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(update, Multiple-Services-CC( | | | Requested-Units(), Service-Id 1, | | | Rating-Group 1)) | | |---------------------------------------->| | |(6)CCA(Multiple-Services-CC ( | | | Granted-Units(Time), | | | Rating-Group 1, | | | G-S-U-Pool-Reference(Pool-Id 1, | | | Multiplier 1))) | | |<----------------------------------------| : : : |(7)Service-Request (Service 2) | |------------------>| | : : : : : : |(8)Service-Request (Service 3&4) | |------------------>|(9)CCR(update, Multiple-Services-CC ( | | | Requested-Units(), Service-Id 3, | | | Rating-Group 2), | | | Multiple-Services-CC ( | | | Requested-Units(), Service-Id 4, | | | Rating-Group 3)) | | |---------------------------------------->| | |(10)CCA(Multiple-Services-CC ( | Bertz, et al. Expires June 23, 2018 [Page 116] Internet-Draft Diameter Credit-Control Application December 2017 | | Granted-Units(Total-Octets), | | | Service-Id 3, Rating-Group 2, | | | Validity-time, | | | G-S-U-Pool-Reference(Pool-Id 2, | | | Multiplier 2)), | | | Multiple-Services-CC ( | | | Granted-Units(Total-Octets), | | | Service-Id 4, Rating-Group 3 | | | Validity-Time, | | | Final-Unit-Ind.(Terminate), | | | G-S-U-Pool-Reference(Pool-Id 2, | | | Multiplier 5))) | | |<----------------------------------------| : : : : : : | +--------------+ | | | |Validity time | |(11)CCR(update, | | |expires for | | Multiple-Services-CC ( | | |Service-Id | | Requested-Unit(), | | | access | | Used-Units(In-Octets,Out-Octets),| | +--------------+ | Service-Id access)) | | |---------------------------------------->| | |(12)CCA(Multiple-Services-CC ( | | | Granted-Units(Total-Octets), | | | Service-Id access, | | | Validity-Time, | | | G-S-U-Pool-Reference(Pool-Id 1, | | | Multiplier 10))) | | |<----------------------------------------| : : : : : : | +--------------+ | | | |Total Quota | |(13)CCR(update, | | |elapses for | | Multiple-Services-CC ( | | |pool 2: | | Requested-Unit(), | | |service 4 not | | Used-Units(In-Octets,Out-Octets),| | |allowed, | | Service-Id 3, Rating-group 2), | | |service 3 cont| | Multiple-Services-CC ( | | +--------------+ | Used-Units(In-Octets,Out-Octets),| | | Service-Id 4, Rating-Group 3)) | | |---------------------------------------->| | |(14)CCA(Multiple-Services-CC ( | | | Result-Code 4011, | | | Service-Id 3)) | | |<----------------------------------------| : : : : : : |(15) User logoff | | Bertz, et al. Expires June 23, 2018 [Page 117] Internet-Draft Diameter Credit-Control Application December 2017 |------------------>|(16)CCR(term, | | | Multiple-Services-CC ( | | | Used-Units(In-Octets,Out-Octets),| | | Service-Id access), | | | Multiple-Services-CC ( | | | Used-Units(Time), | | | Service-Id 1, Rating-Group 1), | | | Multiple-Services-CC ( | | | Used-Units(Time), | | | Service-Id 2, Rating-Group 1)) | | |---------------------------------------->| | |(17)CCA(term) | | |<----------------------------------------| Figure 19: Flow example independent credit-control of multiple services in a credit-control (sub-)Session The user logs on to the network (1). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization for the bearer service (e.g., Internet access service) and to establish a credit-control session (2). In this message, the credit-control client indicates support for independent credit-control of multiple services within the session by including the Multiple-Service-Indicator AVP. The Diameter credit-control server checks the end user's account balance, with rating information received from the client (i.e., Service-Id and access specific AVPs), rates the request, and reserves credit from the end user's account. Suppose that the server reserves $5 and determines that the cost is $1/MB. It then returns to the service element a Credit-Control- Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (3). The user uses Service 1 (4). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server to perform credit authorization for service 1 (5). This message includes the Multiple-Services-Credit-Control AVP to request service units for Service 1 that belong to Rating- Group 1. The Diameter credit-control server determines that Service 1 draws credit resources from the same account as the access service (i.e., pool 1). It rates the request according to Service-Id/Rating- Group and updates the existing reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $10) and determines that the cost is $0.1/minute. The server authorizes the whole Rating-Group. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services- Credit-Control AVP with a quota of 50min. associated to the Rating- Bertz, et al. Expires June 23, 2018 [Page 118] Internet-Draft Diameter Credit-Control Application December 2017 Group 1, to a multiplier value of 1, and to the Pool-Id 1 (6). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 100. The user uses Service 2, which belongs to the authorized Rating- Group, 1 (7). Resources are then consumed from the pool 1. The user now requests Services 3 and 4 as well, which are not authorized (8). The service element sends a Diameter Credit-Control- Request with CC-Request-Type set to UPDATE_REQUEST to the credit- control server in order to perform credit authorization for Services 3 and 4 (9). This message includes two instances of the Multiple- Services-Credit-Control AVP to request service units for Service 3 that belong to Rating-Group 2 and for Service 4 that belong to Rating-Group 3. The Diameter credit-control server determines that Services 3 and 4 draw credit resources from another account (i.e., pool 2). It checks the end user's account balance and, according to Service-Ids/Rating-Groups information, rates the request. Then it reserves credit from pool 2. For example, the server reserves $5 and determines that Service 3 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes only Services 3 and 4. It returns to the service element a Credit- Control-Answer message that includes two instances of the Multiple- Services-Credit-Control AVP (10). One instance grants a quota of 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and to the Pool-Id 2. The other instance grants a quota of 5 MB associated to the Service-Id 4 to a multiplier value of 5 and to the Pool-Id 2. The server also determines that pool 2 is exhausted and Service 4 is not allowed to continue after these units will be consumed. Therefore the Final-Unit-Indication AVP with action TERMINATE is associated to the Service-Id 4. The client calculates the total amount of resources that can be used for pool 2 according the received quotas and multipliers, which gives S for Pool 2 = 50. The Validity-Time for the access service expires. The service element sends a Credit-Control-Request message to the server in order to perform credit re-authorization for Service-Id (access) (11). This message carries one instance of the Multiple-Services-Credit- Control AVP that includes the units used by this service. Suppose that the total amount of used units is 4MB. The client adjusts the total amount of resources for pool 1 accordingly, which gives S for Pool 1 = 60. The server deducts $4 from the user's account and updates the reservation by requesting more credit. Suppose that the server Bertz, et al. Expires June 23, 2018 [Page 119] Internet-Draft Diameter Credit-Control Application December 2017 reserves $5 more (now the reservation is $11) and already knows the cost of the Service-Id (access), which is $1/MB. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5 MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (12). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 110. Services 3 and 4 consume the total amount of pool 2 credit resources (i.e., C1*2 + C2*5 >= S). The service element immediately starts the TERMINATE action concerning Service 4 and sends a Credit-Control- Request message with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit re-authorization for Service 3 (13). This message contains two instances of the Multiple- Services-Credit-Control AVP to report the units used by Services 3 and 4. The server deducts the last $5 from the user's account (pool 2) and returns the answer with Result-Code 4011 in the Multiple- Services-Credit-Control AVP to indicate that Service 3 can continue without credit-control (14). The end user logs off from the network (15). To debit the used units from the end user's account and to stop the credit-control session, the service element sends a Diameter Credit-Control-Request with CC- Request-Type set to TERMINATION_REQUEST to the credit-control server (16). This message contains the units consumed by each of the used services in multiple instances of the Multiple-Services-Credit- Control AVP. The used units are associated with the relevant Service-Identifier and Rating-Group. The Diameter credit-control server debits the used units to the user's account (Pool 1) and acknowledges the session termination by sending a Diameter Credit- Control-Answer to the service element (17). Appendix C. Changes relative to RFC4006 The following changes were made relative to RFC4006: Update references to obsolete RFC 3588 to refer to RFC 6733. Update references to obsolete RFC 4005 to refer to RFC 7155. Update references to obsolete RFC 2486 to refer to RFC 7542. Update references to current 3GPP documents. Update AVP per Errata ID 3329. Update reference to "IPsec or TLS" to be "TLS/TCP, DTLS/SCTP or IPsec". Bertz, et al. Expires June 23, 2018 [Page 120] Internet-Draft Diameter Credit-Control Application December 2017 Clarify Filter-Rule AVP in Restrict Access Action. Remove Encr column from AVP flag rules. Clarify that RESTRICT_ACCESS action applies after consumption of final granted units (Section 5.6.3). Clarify that values in Used-Service-Unit AVP may exceed Granted- Service-Unit AVP (Section 8.19). Clarify that IPv6 representation in Redirect-Address-Type AVP conforms to RFC5952 (Section 8.38). Describe immediate graceful service termination procedure (in Section 5.6). Add extensible User-Equipment-Info-Extension AVP and included types (from Section 8.52 to Section 8.57). Add extensible Subscription-Id-Extension AVP and included types (from Section 8.58 to Section 8.63). Add extensible Redirect-Server-Extension AVP and included types (from Section 8.64 to Section 8.67). Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68). Updated Security Section to include language consistent with structures of latest base protocol specification. Update references to obsolete RFC 5226 to refer to RFC 8126, and resulting updateds to Section 12. Authors' Addresses Lyle Bertz (editor) Sprint 6220 Sprint Parkway Overland Park, KS 66251 United States Email: lyleb551144@gmail.com Bertz, et al. Expires June 23, 2018 [Page 121] Internet-Draft Diameter Credit-Control Application December 2017 David Dolson (editor) Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada Phone: +1 519 880 2400 Email: ddolson@sandvine.com Yuval Lifshitz (editor) Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada Phone: +1 519 880 2400 Email: ylifshitz@sandvine.com Bertz, et al. Expires June 23, 2018 [Page 122]