Prepaid Extensions to RADIUS

(draft-lior-radius-prepaid-extensions-10.txt)

A. Lior Bridgewater Systems

P. Yegani Cisco Systems
K. Chowdhury Starent Networks
H. Tschofenig Siemens
A. Pashalidis Siemens

<slides by Andreas Pashalidis>

 What’s new in -10 …

• Aligned with Diameter Credit Control

i.e. RADIUS Prepaid now supports:
 Balance check: are sufficient funds available for
a given service in the user account?
 Price enquiry: how is a given service rated? The
response AVP returns the cost information for the
requested service
• Detailed example message flows
– Simple flow
– Flow with tariff switching
– Flow with resource pools, rating groups, and
multiple services
 What’s new in -10

• Contains high level description of translation

agent between RADIUS prepaid and Diameter
Credit Control for scenarios below:
 RADIUS PP-based client, Diameter CC-based AAA
infrastructure
 Diameter CC-based client, RADIUS PP-based
infrastructure

• No more reliance on “Authorize-Only”

 RADIUS Design Guidelines
(Ref: draft-weber-radius-attr-guidelines-02.txt)
• Backwards Compatibility [6.1]
• Intermediate nodes [6.1.1]
• Dictionary-based implementations [6.1.2]
• Unaware endpoints [6.1.3]
• Existing Vendor-Specific Attribute Usage [6.2]
• Transport Impact [6.3]
• Diameter Compatibility [6.5]
• Security [6.6]

Hence it appears that all guidelines are

respected (pending peers review)
 RADIUS PP vs DIAMETER CC

• RADIUS Prepaid uses a grouped AVP

(as does Diameter Credit Control)
 see section 4.3.19
• Translation Agent in {Diameter CC-based
client, RADIUS Prepaid-based infrastructure}
case not described (yet)
 Is tricky due to many Diameter Credit Control
AVPs and few RADIUS Prepaid Attributes
 Some AVPs are semantically only partially
equivalent
 Open issues

• Translation between RADIUS Prepaid and

Diameter Credit Control
 Diameter TCP-based; messages include quota
difference from previous quota
 RADIUS: UDP-based; message include cumulative
quota since start of session
• Hence; either translation agent needs per
session state, or excessively large ‘state’
AVPs (e.g. in multiple services scenario)
 Next Step

Should this be a WG item?