1 / 10

Diameter Credit-control Application

Diameter Credit-control Application http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-00.txt Harri Hakala Juha-Pekka Koskinen John Loughney Leena Mattila Marco Stura. Goals. Support existing credit control solutions, for example, ones used in 3GPP

lhandler
Download Presentation

Diameter Credit-control Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Diameter Credit-control Application http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-00.txt Harri Hakala Juha-Pekka Koskinen John Loughney Leena Mattila Marco Stura

  2. Goals • Support existing credit control solutions, for example, ones used in 3GPP • Support for generic credit control solutions, for example prepaid WLAN access. • Interwork with existing AAA protocols

  3. Updates - Overview • After much discussion on the AAA WG mailing list, the document has been updated to accommodate Authorization-based requests for credit control. • We tried to address the following points: • Better clarify the scope of this application • Clarify all the definitions with special care to the Service Element one. • Make architectural changes and explain how AA messages are used etc. • Draw some flows with different use cases and different scenarios • Clarify that NAS will never issue price inquiry or credit check or refund. • Clarify failover procedures.

  4. Main changes • Introduction & architecture diagram. • New commands & AVPs. • Updated protocol operation. • Updated state machines. • Added section on RADIUS/Diameter Credit-control Interworking, for support of legacy systems. • Updated examples.

  5. Architecture 1 Service Element AAA and credit-control +----------+ +---------+ protocols +-----------+ +--------+ | End |<---->|+-------+|<------------>| AAA | |Business| | User | +->|| CC || | Server |->|Support | | | | || client||<-----+ | | |System | +----------+ | |+-------+| | +-----------+ | | | +---------+ | ^ +--------+ +----------+ | | CC protocol | ^ | End |<--+ | +-----v----+ | | User | +------>|Credit- | | +----------+ credit-control |control |--------+ protocol |server | +----------+

  6. Architecture 2(Interworking) AAA +--------+ +---------+ protocol +------------+ +--------+ | End |<----->| Service |<------------>| AAA | |Business| | User | | Element | | Server | |Support | +--------+ +-->| | |+----------+|-->|System | | +---------+ ||CC client || | | | |+----------+| | | +--------+ | +------^-----+ +--------+ | End |<--+ credit-control | ^ | User | protocol | | +--------+ +-------V------+ | |Credit-control|--------+ | Server | +--------------+

  7. New command, AVPs • <Credit-Control-Request>; <Credit-Control-Answer> • Used between the Diameter credit-control client and the credit-control server to request/answer credit authorization for a given service. • Renamed accounting AVPs to CC AVPs • New AVPs: • CC-Request-Number • used in matching credit control messages with confirmations • used in CCS to detect duplicate and out of sequence messages • CC-Request-Type • contains the reason for sending the Credit-control request message – initial request, update, termination, etc. • CC-Sub-Session-Id • Indicates multiple sessions for which credit control is applicable. • CC-Failover-Supported • Indicates if failover is supported by the server for on-going session • Credit-Control • included in AA requests when service element has credit control capabilities – indicates credit-authorization / re-authorization. • Validity-Time • contains the validity time of the granted service units.

  8. To Do • Some editorial fixes identified. • Completeness & interworking check. • Additional review needed. • Improve graceful service termination support • Received the comment: • In many instances in the text the action to take when a user resources are no longer available is to terminate the session. That is one possible action, the other possible action is to restrict access (or direct the user) to a portal where they can recharge their account etc... • Enhancements to the Credit Control Session failure procedure

  9. Flow for granting Prepaid Network Access End-User NAS (cc client) AAA Server CC Server |(1)User Logon |(2)AA Request (CC AVPs) | |------------------>|------------------->| | | | |(3)CCR(initial, CC AVPs) | | |------------------->| | | | (4)CCA(granted Units) | | |<-------------------| | |(5)AA Answer(granted Units) | |(6)Access granted |<-------------------| | |<----------------->| | | | | | | : : : : | |(7)CCR(update,used Units) | | |------------------->|(8)CCR (upd, used-units) | | |------------------->| | | |(9)CCA(granted Units) | |(10)CCA(granted Units)<------------------| | |<-------------------| | | (Auth. lifetime expires) | | | |(11) AAR (CC AVP) | | | |------------------->| | | | (12) AAA | | | |<-------------------| |

  10. Flow for logging-off Prepaid Network Access End-User NAS (cc client) AAA Server CC Server |(13) User logoff | | | |------------------>|(14)CCR(term,used-Units) | | |------------------->|(15)CCR | | | | (term.,used-Units) | | |------------------->| | | | (16)CCA | | | (17)CCA |<-------------------| | |<-------------------| | | |(18)STR | | | |------------------->| | | | (19)STA | | | |<-------------------| |

More Related