220 likes | 954 Views
IETF67 – Diameter Tutorial Diameter Credit Control Application Tolga Asveren Ulticom Inc. Tutorial Outline Diameter Credit Control Application – Overview Messages Operation Modes Other Protocol Features Timers Subsessions/Multiple Services Duplicate Detection
E N D
IETF67 – Diameter TutorialDiameter Credit Control ApplicationTolga AsverenUlticom Inc. Diameter Credit Control Application Tutorial - IETF67
Tutorial Outline • Diameter Credit Control Application – Overview • Messages • Operation Modes • Other Protocol Features • Timers • Subsessions/Multiple Services • Duplicate Detection • High Availability/Failure Handling • Notes for Authors of New Applications Diameter Credit Control Application Tutorial - IETF67
Credit Control Application Overview • Specified in RFC 4006 • Can be used to provide real time credit control for various applications, e.g. messaging services, gaming services • Used between the network element providing the service (client) and credit control server (server) • Uses Application-Id 4 Diameter Credit Control Application Tutorial - IETF67
Credit Control Application Messages • Credit Control Request (CCR) • Sent from client to server to request authorization for a given service • Credit Control Answer (CCA) • Sent from server to client and carries the result of the corresponding authorization request • Reauthorization Request (RAR) • Sent by server to trigger a new CCR, e.g. after successful credit replenishment during a service • Reauthorization Answer (RAA) • Sent by client as an answer to RAR Diameter Credit Control Application Tutorial - IETF67
Operation Modes • Event Based • A single CCR/CCA exchange in each session • Used when it is sure that requested service event will be successful • Session Based • Multiple CCR/CCA exchanges in a session • Required when there is a need to reserve credits before providing the service • Requires state maintenance on the server side • Server first reserves the credits and debits them after receiving the subsequent CCR Diameter Credit Control Application Tutorial - IETF67
Some important AVPs • CC-Request-Type AVP • Indicates type of the request for a CCR • Possible values are INITIAL_REQUEST, UPDATE_REQUEST, TERMINATION_REQUEST for session based scenarios and EVENT_REQUEST for event based scenarios • CC-Request-Number AVP • Identifies a request within a session • Requested-Action AVP • Used to indicate type of the requested action for event based scenarios. Possible values are DIRECT_DEBITING, REFUND_ACCOUNT, CHECK_BALANCE and PRICE_ENQUIRY Diameter Credit Control Application Tutorial - IETF67
Event Based Scenario Example Server Client CCR, Session-Id = S-Id1, Service-Identifier CC-Request-Type = EVENT_BASED Requested-Action = PRICE_ENQUIRY CCA, Session-Id = S-Id1 Cost-Information CCR, Session-Id = S-Id2, Subscription-Id, CC-Request-Type = EVENT_BASED Requested-Action = BALANCE_CHECK, Service-Identifier CCA, Session-Id = S-Id2 Check-Balance-Result CCR, Session-Id = S-Id3, Service-Identifier CC-Request-Type = EVENT_BASED Requested-Action = DIRECT_DEBITING Subscription-Id CCA, Session-Id = S-Id3 Granted-Service-Unit Diameter Credit Control Application Tutorial - IETF67
Session Based Scenario Example Client Server CCR, Session-Id = S-Id1, Requested-Service-Unit CC-Request-Type = INITIAL_REQUEST Subscription-Id CCA, Session-Id = S-Id1 Granted-Service-Unit, Validity-Time CCR, Session-Id = S-Id1, Requested-Service-Unit, CC-Request-Type = UPDATE_REQUEST Subscription-Id CCA, Session-Id = S-Id1 Granted-Service-Unit, Validity-Time CCR, Session-Id = S-Id1, CC-Request-Type = TERMINATION_REQUEST Used-Service-Unit CCA, Session-Id = S-Id1 Cost-Information Diameter Credit Control Application Tutorial - IETF67
Credit Control Timers • Tx timer • Used by client to guard against non-receipt of CCA after a CCR is sent • Can’t rely on Tw, configuring Tw to a low value may be undesirable and Tw on the whole message path may not be under control of the client administrating entity • Tcc timer • Used by server to guard against non-receipt of CCR for session based scenarios Diameter Credit Control Application Tutorial - IETF67
Subsessions and Multiple Services • Multiple sub-sessions may be included in a credit control sessions. Each of them is identified by a unique CC-Sub-Session -Id AVP and have their own credit control life cycle • Credit control for multiple services could be performed in a credit control session • The goal is to limit use of network and client/server resources • Multiple-Services-Indicator AVP is sent by client to indicate support for multiple services • Multiple-Services-Credit-Control AVP carries credit control related information from server to client Diameter Credit Control Application Tutorial - IETF67
Multiple Services Related Terms • Service-Id • Identifier for a specific service • Rating-Group • A group of services subject to the same cost and rating type • Quota • Authorized amount of resources for a specific service or rating group • Credit Pool • Authorized amount of resources for services/rating groups with different charging characteristics Diameter Credit Control Application Tutorial - IETF67
Tariff-Change • Server can inform client when a tariff change will occur with Tariff-Time-Change AVP • Client reports used units before and after tariff change with Tariff-Change-Usage AVP Diameter Credit Control Application Tutorial - IETF67
Duplicate Detection • Session-Id AVP, CC-Request-Number AVP and CC-Request-Type can be used to detect duplicates (mechanism described in RFC3588 will work too, i.e. using Origin-Host AVP and End-to-End Identifier Diameter Credit Control Application Tutorial - IETF67
High Availability/Failure Handling Features • CC-Session-Failover AVP • Used by servers to inform clients whether a backup instance is present ( Client needs to know identity of backup peer by other means ) • Credit-Control-Failure-Handling AVP • Used by server to inform client about the expected behavior for session based scenarios, when CCA for a CCR is not received • Direct-Debiting-Failure-Handling AVP • Used by server to inform client about the expected behavior for event based scenarios, when CCA for a CCR is not received Diameter Credit Control Application Tutorial - IETF67
Notes for Authors of New Applications • Define application layer timers, to guard against non-receipt of expected messages • Carrying state related information in messages facilitates development of highly available implementations • If there is some application specific information, which can be used for duplicate detection purposes, it is useful to mention about this Diameter Credit Control Application Tutorial - IETF67
End of Tutorial Thank You Diameter Credit Control Application Tutorial - IETF67