67th IETF San Diego IETF BMWG WLAN Switch Benchmarking Jerry Perser, Tom Alexander, Muninder Singh Sambi,

2 Recap - Motivation and Background Enterprise WLANs highly IP-centric and switched WLAN switches and lightweight APs Layer 3/4 aware (sometimes even Layer-7 aware) Incorporates many IETF-defined functions: ARP caching and proxying, DHCP service, firewalling, IPsec, etc Considerable work in IETF in this area CAPWAP – WLAN switch protocols Equipment vendors would like to use the same WLAN switch performance benchmarking techniques as their customers It’s all very ad-hoc today Lack of accepted benchmarks => poor equipment performance Test vendors would like to have a common approach to testing too IEEE T has decided not to take up this work (out of scope) But it would like to be kept informed of progress

3 Scope of Proposed Work Extend existing router/switch RFCs and drafts to cover WLAN switches, in support of CAPWAP work RFC 1242, RFC 2285, RFC 2544, RFC 2889, RFC 3918, etc. Adapt hash & stuffing draft Random MACs + wireless security = problems Extend for specific attributes of WLAN switches/networks Mobility, overlay WLANs, secure multicast, etc. Update to handle general WLAN switch data plane performance “Zero-loss throughput” not possible with wireless PHYs Specific areas of proposed work: Data-plane performance: throughput, latency, multicast, etc. Control-plane performance: reset recovery, etc. Failover performance: AP failover, controller failover Scalability: AP capacity, client capacity, etc. Mobility: intra- and inter-subnet roaming, etc. Both terminology and methodology drafts are needed

4 What’s CAPWAP? What’s a WLAN switch? CAPWAP – Control And Provisioning of Wireless Access Points Specifies architecture & protocol for centralized, switched approach to WLAN infrastructure General architecture: WLAN clients talking to Wireless Termination Points (APs) talking to Access Controllers (WLAN switches) Packets from clients to WTPs transit wireless medium Packets are then tunneled over UDP (Ethernet) from WTPs to ACs ACs centralize security, policy management, higher-level protocols and configuration management, and frequently also datapath switching CAPWAP protocol specifies control plane, data tunneling, security Supports both ”split-MAC” (lightweight APs) and ”local-MAC” Provides for discovery, configuration, provisioning, failover functions An AC is not simply a switch, bridge or router! It’s a combination of termination device, multiprotocol bridge/router and stateful firewall/traffic manager

5 CAPWAP System Architecture Access Controller (AC, or WLAN Switch) WLAN Client WLAN Client WLAN Client WLAN Client WLAN Client WLAN Client WLAN Termination Point (WTP, or AP) WLAN Termination Point (WTP, or AP) Wireless Links CAPWAP Tunnels Carrying Wireless Packets Rest Of Network SUT

6 Extensions Needed To RFCs ACs are not routers, but still highly involved in Layer 3/4 processing ARP proxies, DHCP snooping, firewalling, QoS enforcement, etc. Mobility is a significant issue Wireless clients move – mobility performance must be tested WTPs support 1-16 ”overlay networks” (logical WLANs) Multicast performance becomes quite interesting, esp. with security General symmetry assumptions in RFC 2544/2889 do not hold WLAN clients don’t usually talk to each other – not an interesting case General assumption that all endpoints are peers no longer works Frame size changes as traffic transits ACs WLAN frame sizes also vary with security, QoS, etc. Other differences from wired switch benchmarking as well ACs impose restrictions on MAC/IP address mapping Intrusion detection and rogue client exclusion Shared-medium on wireless side => switched medium on wired side WLAN PHY does not support zero-loss throughput

7 Specific Items Expected for Terminology Define items not already covered by existing RFCs Topology-related Access Controller, Wireless Termination Point, client, etc. Functionality-related Roaming, DoS attack, rogue client, etc. Metrics-related Provisioning database capacity, provisioning rate, etc. Upstream traffic, downstream traffic, etc. Wireless-specific SSID, BSSID, etc.

8 Specific Items Expected for Methodology Adapt metrics from existing RFCs & augment with new Data-plane performance Throughput, latency, etc. QoS differentiation, etc. Control-plane performance AP & client provisioning capacity, provisioning rate, etc. DoS attack control, etc. Reset recovery Failover performance: AP failover, controller failover, etc. Wireless-specific Intra/inter-subnet roaming, power-save capacity, etc.

9 Next steps Start discussion on work proposals Solicit help Submit drafts Terminology Methodology Comments?