Diameter Credit-Control Application
RFC 4006
| Document | Type |
RFC
- Proposed Standard
(August 2005)
Errata
IPR
Obsoleted by RFC 8506
|
|
|---|---|---|---|
| Authors | Juha-Pekka Koskinen , Leena Mattila , Marco Stura , John A. Loughney , Harri Hakala | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Bert Wijnen | |
| Send notices to | (None) |
RFC 4006
gt;| |
| | | (4) CCA(Validity-Time)|
| |<------------------------------------------|
| (5)INVITE | (6)INVITE | | |
|<--------------|------------->| | |
| (7)RTP | | |
|..............................| | |
| | (8)BYE | | |
| |<-------------| | |
| | (9)CCR(Update) | |
| |------------------------------------------>|
| | (10)CCA(Granted-Unit) |
| |<------------------------------------------|
| (12)INVITE | (11)INVITE | |
|<--------------|--------------------------->| |
Figure A.7: Flow VII
Figure A.7 is an example of the graceful service termination for a
SIP call. It is assumed that the call is set up so that the
controller is in the call as a B2BUA (Back to Back User Agent)
performing third-party call control (3PCC). Note that the SIP
signaling is inaccurate, as the focus of this flow is in the graceful
service termination and credit-control authorization. The best
practice for 3PCC is defined in [RFC3725].
The call is ongoing between users A and B; user A has a prepaid
subscription. At the expiry of the allocated quota, the SIP
controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST)
to the Diameter credit-control server (1). This message contains the
units used thus far. The Diameter credit-control server debits the
used units from the end user's account and allocates the final quota
returned to the SIP controller in the Diameter Credit-Control-Answer
(2). This message contains the Final-Unit-Indication AVP with the
Hakala, et al. Standards Track [Page 103]
RFC 4006 Diameter Credit-Control Application August 2005
Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to
SIP URI, and the Redirect-Server-Address set to the Top-up server
name (e.g., sip:sip-topup-server@domain.com). At the expiry of the
final allocated quota, the SIP controller sends a Diameter Credit-
Control-Request (UPDATE_REQUEST) to the Diameter credit-control
server (3) and places the called party on "hold" by sending an INVITE
with the appropriate connection address in the SDP (3a). The
Credit-Control-Request message contains the units used thus far. The
Diameter credit-control server debits the used units from the end
user's account but does not make any credit reservation. The
Credit-Control-Answer message, which contains the Validity-Time to
supervise the graceful service termination, is returned to the SIP
controller (4). The SIP controller establishes a SIP session between
the prepaid user and the Top-up server (5, 6). The Top-up server
plays an announcement and prompts the user to enter a credit card
number and the amount of money to be used to replenish the account
(7). The Top-up server validates the credit card number and
replenishes the user's account (using some means outside the scope of
this specification) and releases the SIP session (8). The SIP
controller can now assume that communication between the prepaid user
and the Top-up server took place. It sends a spontaneous Credit-
Control-Request (UPDATE_REQUEST) to the Diameter credit-control
server to check whether the account has been replenished (9). The
Diameter credit-control server reserves credit from the end user's
account and returns the reserved quota to the SIP controller in the
Credit-Control-Answer (10). At this point, the SIP controller re-
connects the caller and the called party (11,12).
Hakala, et al. Standards Track [Page 104]
RFC 4006 Diameter Credit-Control Application August 2005
A.8. Flow VIII
NAS Top-up CC
End-User (CC Client) AAA Server Server Server
|(1)User Logon |(2)AA Request (CC AVPs) | |
|------------------>|------------------->| | |
| | |(3)CCR(initial, CC AVPs)
| | |------------------->|
| | |(4)CCA(Final-Unit, |
| | | Validity-Time)|
| | |<-------------------|
| |(5)AA Answer(Final-Unit,Validity-Time) |
|(6)Limited Access |<-------------------| | |
| granted | | | |
|<----------------->| | | |
| | | | |
| (7)TCP/HTTP | (8)TCP/HTTP | |
|<----------------->|<----------------------------->| |
| (9) Replenish account | |
|<------------------------------------------------->| |
| | | (10)RAR |
| |<-------------------|<-------------------|
| | (11) RAA | |
| |------------------->|------------------->|
| |(12)CCR(update) | |
| |------------------->|(13)CCR(Update) |
| | |------------------->|
| | |(14)CCA(Granted-Units)
| |(15)CCA(Granted-Units)<------------------|
| |<-------------------| |
Figure A.8: Flow VIII
Figure A.8 is an example of the graceful service termination
initiated when the first interrogation takes place because the user's
account is empty. In this example, the credit-control server
supports the server-initiated credit re-authorization. The Diameter
[NASREQ] is implemented in the Network Access Server (NAS).
The user logs on to the network (1). The Diameter NAS sends a
Diameter AA-Request to the home Diameter AAA server. The credit-
control client populates the AAR with the Credit-Control AVP set to
CREDIT_AUTHORIZATION, and service specific AVPs are included, as
usual [NASREQ]. The home Diameter AAA server performs service
specific Authentication and Authorization, as usual. The home
Diameter AAA server determines that the user has a prepaid
subscription and notices from the Credit-Control AVP that the NAS has
credit-control capabilities. It sends a Diameter Credit-Control-
Hakala, et al. Standards Track [Page 105]
RFC 4006 Diameter Credit-Control Application August 2005
Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter
credit-control server to perform credit authorization (3) and to
establish a credit-control session. (The home Diameter AAA server
may forward service specific AVPs received from the NAS as input for
the rating process.) The Diameter credit-control server checks the
end user's account balance, determines that the account cannot cover
the cost of the service, and initiates the graceful service
termination. The Credit-Control-Answer is returned to the home
Diameter AAA server (4). This message contains the Final-Unit-
Indication AVP and the Validity-Time AVP set to a reasonable amount
of time to give the user a chance to replenish his/her account (e.g.,
10 minutes). The Final-Unit-Indication AVP includes the Final-Unit-
Action set to REDIRECT, the Redirect-Address-Type set to URL, and the
Redirect-Server-Address set to the HTTP Top-up server name. The home
Diameter AAA server sends the received credit-control AVPs to the NAS
in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts
the credit-control session and immediately starts the graceful
service termination, as instructed by the server. The NAS grants
limited access to the user (6). The HTTP client software running in
the user's device opens the transport connection redirected by the
NAS to the Top-up server (7,8). The user is displayed an appropriate
web page on which to enter the credit card number, and the amount of
money to be used to replenish the account, and with a notification
message that she is granted unlimited access if the replenishment
operation will be successfully executed within the next, for example,
10 minutes. The Top-up server validates the credit card number and
replenishes the user'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.
Hakala, et al. Standards Track [Page 106]
RFC 4006 Diameter Credit-Control Application August 2005
A.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.
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) |
|------------------>| |
Hakala, et al. Standards Track [Page 107]
RFC 4006 Diameter Credit-Control Application August 2005
: : :
: : :
|(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 ( |
| | 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))) |
| |<----------------------------------------|
: : :
: : :
Hakala, et al. Standards Track [Page 108]
RFC 4006 Diameter Credit-Control Application August 2005
| +--------------+ | |
| |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 | |
|------------------>|(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 A.9: 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
Hakala, et al. Standards Track [Page 109]
RFC 4006 Diameter Credit-Control Application August 2005
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-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.
Hakala, et al. Standards Track [Page 110]
RFC 4006 Diameter Credit-Control Application August 2005
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
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
Hakala, et al. Standards Track [Page 111]
RFC 4006 Diameter Credit-Control Application August 2005
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).
Authors' Addresses
Harri Hakala
Oy L M Ericsson Ab
Joukahaisenkatu 1
20520 Turku
Finland
Phone: +358 2 265 3722
EMail: Harri.Hakala@ericsson.com
Leena Mattila
Oy L M Ericsson Ab
Joukahaisenkatu 1
20520 Turku
Finland
Phone: +358 2 265 3731
EMail: Leena.Mattila@ericsson.com
Juha-Pekka Koskinen
Nokia Networks
Hatanpaanvaltatie 30
33100 Tampere
Finland
Phone: +358 7180 74027
EMail: juha-pekka.koskinen@nokia.com
Hakala, et al. Standards Track [Page 112]
RFC 4006 Diameter Credit-Control Application August 2005
Marco Stura
Nokia Networks
Hiomotie 32
00380 Helsinki
Finland
Phone: +358 7180 64308
EMail: marco.stura@nokia.com
John Loughney
Nokia Research Center
Itamerenkatu 11-13
00180 Helsinki
Finland
Phone: +358 50 483 642
EMail: John.Loughney@nokia.com
Hakala, et al. Standards Track [Page 113]
RFC 4006 Diameter Credit-Control Application August 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hakala, et al. Standards Track [Page 114]