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

2. 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?

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

4. 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.

5. 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 802.11 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 802.11 control frames, while in the former the WTP may terminate all 802.11 frames. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC.

6. So what is the difference then? Split MAC –Access Point Function (APF) resides in AC –802.11 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

7. 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

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

9. What about Local AP latency issues? Introduce Proxy MAC –Proposal is to allow the WTP to process 802.11 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

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

11. 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

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

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