Diameter Credit Control Application Tutorial - IETF67 IETF67 – Diameter Tutorial Diameter Credit Control Application Tolga Asveren Ulticom Inc. Diameter Credit Control Application Tutorial - IETF67

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

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

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 Client Server 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

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

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

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

Diameter Credit Control Application Tutorial - IETF67 End of Tutorial Thank You Diameter Credit Control Application Tutorial - IETF67