AP Functional Needs of CAPWAP

1. AP Functional Needs of CAPWAP Mahalingam Mani Avaya Inc. Dorothy Gellert Nokia Inc. mmani@avaya.com dorothy.gellert@nokia.com Mani, Gellert

2. Problem Statement • In a large network, the issue is 100s-1000s of APs. • Directly managing each of these devices is difficult and error prone • Traditional APs only have visibility into their own cell • Configuration changes on the AP does not take into account how it could impact neighboring APs • RF configuration algorithms require real-time access to load & RF data - so they must be run in the data path Mani, Gellert

3. Problem Statement (contd.) • Central security enforcement provides a greater view into potential security threats and facilitates (W)LAN-wide access control • Authentication and Authorization of APs increases network security Mani, Gellert

4. Overview • Motivation • WLAN system architecture for coordinating • Physical Distribution of APs • Logical Management of Services they collectively provide • Ease of Use • Central management of WLAN System • Increased Security • Centralized Policy Decision & Consolidated Enforcement Mani, Gellert

5. Motivation (contd.) • Enhanced Mobility • Management flows coordinated at the AC obviate the need for client software to provide triggers across APs • Quality of Service • Systemic view offers efficient means of load-balancing across APs enhancing WLAN network efficiency Mani, Gellert

6. CAPWAP WG • Current Status • Problem statement draft requires clarifications • separate security considerations section sought by security AD • Architecture Taxonomy draft work in progress • Design team approved and commenced work • Two revisions have been issued. • IEEE Ad-Hoc is reviewing; under WG review in IETF. • A third revision a while after May 2nd week Mani, Gellert

7. CAPWAP: Status and Plan of Progression IETF IESG Review CAPWAP WG formed PS & Arch. Taxonomy Info RFC close WG (/recharter) CAPWAP protocol dev.? IEEE IETF Liaison IEEE expert ad-hoc review IEEE CFI on AP Functions SG & TG formed Best Practices Mani, Gellert

8. AP AP AP AP AP AP CAPWAP Topologies Access Controller Access Controller Access Controller Host L2/L3 Directly Connected - Split-AP L2/L3 Cloud-Connected Mani, Gellert

9. AP AP AP AP AP AP AP AP AP AP AP AP CAPWAP Topologies (contd.) L2/L3 Cloud-Connected: Directly Connected: Access Controller Access Controller Access Controller Access Controller Host L2/L3 • CAPWAP taxonomy collection includes cloud and direct-connect topologies. • Topologies may be constrained by WLAN architecture types. Mani, Gellert

10. Challenges with Centralization • The flexibility allowed in AP functional definitions has led to a problem of varied interpretations on what stays in the AP • Some implementations split ‘atomicity’ of 802.11 MAC implementation across the ‘AP’ and the Central Controller. • Some MAC functions terminate at Controller. • IAPP model only allows exchange/context transfers between two APs Mani, Gellert

11. Summary • IEEE 802.11 defines the 802.11 MAC & PHY. • 802.1 defines the Link Layer. • We need IEEE 802.11 to take a look at the taxonomy variants that have come to be. • the customer needs an Interoperability Assurance that has led to CAPWAP initiative at IETF. • IEEE 802.11 is the one to provide guidelines • draw the line on AP functions and clear interface definitions to Control and Management Entities between the higher layer functions and the MAC and PHY interfaces. • AP functions and their scope (especially in light of recent TGe/i/h/r enhancements) • IETF can use the guidelines to frame AP-AC protocols fitting the guidelines. Mani, Gellert