CAPWAP Taxonomy Recommendations Pat R. Calhoun, Cisco Systems Bob O’Hara, Cisco Systems Inderpreet Singh, Chantry Networks

Problem The taxonomy document did a great job of providing a survey of architectures It did not provide an unambiguous definition of Split and Local MAC As a consequence, all protocols assume different meaning to the terms –This became obvious in discussions between the LWAPP and CTP teams The protocol evaluation team cannot successfully compare all protocols without a clear set of definitions –When a protocol claims support for Local MAC, what does it mean?

Architecture Table CAPWAP Functions MAC CAPWAP Functions Non Real-Time MAC Real-Time MAC PHY AC WTP Local APSplit AP

CAPWAP Functions (overview) As listed in taxonomy document –RF monitoring, such as Radar detection, noise and interference detection and measurement. –RF configuration, e.g., for retransmission, channel selection, transmission power adjustment, etc. –WTP configuration, e.g., for SSID, etc. –WTP firmware loading, e.g., automatic loading and upgrading of WTP firmware for network wide consistency. –Network-wide STA state information database, including the information needed to support value-added services, such as mobility, load balancing etc. –Mutual authentication between network entities, e.g., for AC and WTP authentication in a Centralized WLAN Architecture.

Contradicting Text Following taxonomy text comes to a different conclusion: –The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 and Figure 10. The commonality between the two is that control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that in the latter the WTP terminates only the control frames, while in the former the WTP may terminate all frames. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between and frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC.

So what is the difference then? Split MAC –Access Point Function (APF) resides in AC – MAC management frames are sent to the AC –User frames are tunneled Local MAC –APF resides in the WTP –SME event notifications are sent to the AC –User frames MAY be tunneled Local MAC did not split the MAC due to latency issues between the STA and the AP for MAC Management packets

Two modes of operation We believe the crux of the problem is the terms chosen by the CAPWAP WG, split and local MAC The WG should focus on where functionality resides, instead of how the MAC is divided. –The draft proposes the use of the terms Split and Local AP

Proposed Split vs. Local* AP FunctionLocation Distribution ServiceWTP Integration ServiceWTP Beacon GenerationWTP Probe ResponseWTP Power Mgmt/Packet BufferingWTP Fragmentation/DefragWTP Assoc/Disassoc/ReassocWTP e ClassifyingWTP SchedulingWTP QueuingWTP i 802.1X/EAPAC Key ManagementAC Encryption/DecryptionWTP FunctionLocation Distribution ServiceAC Integration ServiceAC Beacon GenerationWTP Probe ResponseWTP Power Mgmt/Packet BufferingWTP Fragmentation/DefragWTP Assoc/Disassoc/ReassocAC e ClassifyingAC SchedulingWTP/AC QueuingWTP i 802.1X/EAPAC Key ManagementAC Encryption/DecryptionWTP Given the vast differences between architectures reviewed, this table uses the most common functionality split

What about Local AP latency issues? Introduce Proxy MAC –Proposal is to allow the WTP to process MAC management frames, but forward the frame to the AC –The end solution is exactly the same, but allows for a single simpler CAPWAP protocol

SME vs MAC management? CAPWAP AC Function MAC Management AC WTP Local APSplit AP SME Layer CAPWAP Protocol Real-Time MAC Management CAPWAP Protocol (Local AP) Non real-time MAC mgmt (Split AP) non real-time MAC mgmt CAPWAP AC Function

Options, capabilities and negotiations There is a desire to provide a large number of modes of operation We contend that allowing for a complex matrix of modes of operation will harm interoperability Proposal: –Limit number of options –Clearly define the mandatory to implement mode

Proposed modes of operation Support the following optional features: –User Frame Tunneling: mandatory is local bridge –Local vs. Split: mandatory is Local – Encryption: mandatory is WTP

Conclusion The authors of the CAPWAP Taxonomy Recommendation strongly urge the WG to adopt this document And of course…. Comments are more than welcomed!