1. 18 June 20071 Subject:Selection of Protocol for eBS/SRNC AGW and AGW AAA Interfaces for UMB Date: 18 June 2007 Source: Airvana, Hitachi, KDDI, Qualcomm Contact: Minsh Den, Doug Knisely, Ravi Valmikam {mden, dknisely, rvalmikam}@airvana.com Koji Watanabe koji.watanabe.az@hitachi.com Ryuhei Munakata, Kazushi Imamoto {ry-munakata, kaz-imamoto}@kddi.com Jun Wang jwang@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.

2. 18 June 20072 Key Characteristics for the eBS/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

3. 18 June 20073 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

4. 18 June 20074 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

5. 18 June 20075 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

6. 18 June 20076 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

7. 18 June 20077 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

8. 18 June 20078 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