Jerry Perser, [e-mail]

1
IETF BMWG WLAN Switch Benchmarking

• Jerry Perser, jperser_at_veriwave.com
• Tom Alexander, tom_at_veriwave.com
• Muninder Singh Sambi, msambi_at_cisco.com

67th IETF San Diego
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
• Its all very ad-hoc today
• Lack of accepted benchmarks gt poor equipment
  performance
• Test vendors would like to have a common approach
  to testing too
• IEEE 802.11T 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
Whats CAPWAP? Whats 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!
• Its a combination of termination device,
  multiprotocol bridge/router and stateful
  firewall/traffic manager

5
CAPWAP System Architecture
WLAN Client
SUT
Access Controller (AC, or WLAN Switch)
WLAN Termination Point (WTP, or AP)
WLAN Client
WLAN Client
CAPWAP Tunnels Carrying Wireless Packets
WLAN Client
WLAN Termination Point (WTP, or AP)
Rest Of Network
WLAN Client
WLAN Client
Wireless Links
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 dont 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 gt 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?