18 June 2007 1

Subject: Selection of Protocol for eBS/SRNC<->AGWand AGW<->AAAInterfaces for UMB

Date: 18 June 2007Source: Airvana, Hitachi, KDDI, QualcommContact: Minsh Den, Doug Knisely, Ravi Valmikam

{mden, dknisely, rvalmikam}@airvana.comKoji Watanabekoji.watanabe.az@hitachi.comRyuhei Munakata, Kazushi Imamoto

{ry-munakata, kaz-imamoto}@kddi.comJun Wangjwang@qualcomm.com

cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2.

The contributors grant a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. The contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution.This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributions specifically reserve the right to amend or modify the material contained herein and to any intellectual property of the contributors other than provided in the copyright statement above.

18 June 2007 2

Key Characteristics for theeBS/SRNC<->AGW<->AAA Interfaces • Suitability to the task

– Functional capabilities– Protocol capabilities– Suitability to real hardware and software implementations

• Scalability– 10,000s of eBSs– Millions of sessions

• Complexity– “Stateful-ness”– Protocol stack requirements (e.g., TCP, UDP, etc.)– Desire a light-weight, efficient, and effective per-session relay

function

• Candidates (decision currently open):– Diameter– Radius

18 June 2007 3

Concerns with Diameter

• Previously discussed model is essentially a “Diameter proxy agent”

• Unfortunately, it is much more than a simple proxy:– In reality it becomes a terminate and re-generate Diameter

Gateway– More stateful– Requires a separate TCP/SCTP connection at AGW for each

eBS/SRNC (10,000s)

• AGW now becomes a big AAA proxy server (in this case, a Diameter Agent) in addition to all other tunneling/switching/security functionality across multiple access technologies which may need to be handled by an AGW

18 June 2007 4

Problems with Diameter Server Role

• According to RFC3588 section 2.1– “Diameter clients MUST support either TCP or SCTP, while

agents and servers MUST support both.”

• Implementation problems:– AGW must implement Diameter client and server stacks– Huge number of TCP/SCTP connections at AGW to/from the

eBS/SRNC– Associated “maintenance” protocol overhead for all those

connections– Complexity of implementing session-level load balancing within a

typical AGW architecture that uses multiple processing elements– Two levels of load-balancing:

• Load balancing of TCP/SCTP connections,• Load balancing of per-session information exchange/processing

18 June 2007 5

Diameter Scalability Issues

• Load balancing of TCP/SCTP connections– Difficult to terminate 10,000s of TCP/SCTP connections on a

single element– Cleanest way for TCP/SCTP connection-level load

balancing requires multiple IP addresses at AGW. While this may be ok for AAA server farm, it may not be acceptable for an AGW to publish multiple IP addresses tightly coupled with its internal resource utilization.

• Load balancing at session-level– Stateful nature of TCP and SCTP make session-level load

balancing difficult– TCP/SCTP connection-level load balancing does not

guarantee session-level load balancing – therefore, one element could still be overloaded

18 June 2007 6

Proposed Solution

• UDP-based Radius should be selected as the initial protocol for the eBS/SRNC<->AGW<->AAA interfaces

• Diameter can be kept as an option to be added in a future revision of the specifications

• Benefits of Radius:– UDP based protocol => no TCP/SCTP scalability issues– Much simpler relay protocol stack; no need to implement

complex Diameter server-side stack on AGW– Practical solutions exist to support single-level load

balancing with Radius– Satisfies functional requirements– Conservative, safe, well understood

18 June 2007 7

Radius Load Balancing• Need a “cookie” mechanism to identify sessions for the purpose of load

balancing– AGW/Server passes a cookie with the first response (RADIUS Access-

Accept, Accounting-Response etc.,)– Client passes it in each subsequent request (RADIUS Access-Request,

Accounting-Request etc.,)– Server can use cookie to optimize the session search

• 4G networks will have many more users, resulting in frequent RADIUS transactions

• UMB network is flatter - thousands of AAA clients (eBS, SRNC) to one AAA server(AGW)

• Need to supplement Radius with a “cookie” mechanism for UMB usage– "Class" attribute is not allowed in Access-Request– "Proxy-State" attribute cannot be used by NAS– “acct-session-id” is not applicable

• Recommendation:– Agree upon a 3GPP2 Specific VSA "AGW-State" or "Proxy-Server-

State"– No need to go to IANA; 3GPP2 already has vendor ID 5535 (0x159F) for

vendor-specific attribute assignment

18 June 2007 8

Summary

• Many scalability/complexity issues with using Diameter for the eBS/SRNC<->AGW<->AAA interfaces

• Recommend UDP-based Radius for these interfaces in the first phase of the specifications

• Add a 3GPP2 Specific VSA "AGW-State" or "Proxy-Server-State"

• Keep Diameter FFS to be added in a future release of the specifications if needed