Enterprise controller design guide 4 21

LWAPP defines the following: Control messaging protocol and format Data encapsulation LWAPP Control messages are exchanged between the WLC and AP for a variety of reasons, including the

Cisco Confidential

Cisco Campus Wireless LAN Controller Design Guide 4.2

Executive Summary

The Cisco Unified Wireless Network (CUWN) supports business critical, mobile applications The base components of the CUWN are

Wireless LAN (WLAN) controllers, wireless access points, and the Wireless Control System (WCS) management software This paper

provides architectural understanding and design guidance for WLAN Controller deployments Key topics include Lightweight Access

Point Protocol (LWAPP), WLAN security support, mobility, radio resource management, controller placement in the network, and

support for network redundancy

1.0 Introduction

Modern business-class Wireless LAN (WLAN) networks must support mission-critical data applications as well as important networked

services, such as Voice Over WLAN (VoWLAN), Location-Based Services (LBS), and converged applications Furthermore, these

WLANs must be high-performance, resilient, scalable, manageable, and easy to deploy The Cisco Unified Wireless Network (CUWN) is

designed to meet these challenges and represents the current generation of 802.11 WLANs from Cisco Systems Cisco customers are

rapidly adopting the CUWN for a new level of WLAN performance, scalability, manageability, and services and application support This

document reviews the fundamental architectural concepts and design considerations necessary to successfully plan for and design a

CUWN

This document covers architectural fundamentals of the CUWN and common design considerations The document targets Cisco Systems

Engineers, Consulting Systems Engineers, Cisco Partners, and technical customer staff The document assumes an understanding of

802.11 WLAN fundamentals and basic Cisco networking This document is written assuming version 4.2 of the Cisco WLAN controller

software

Glossary of Terms and Acronyms

Glossary of Terms and Acronyms

802.11 IEEE Protocol defining basic behavior of a Wireless Local Area Network

802.11i IEEE Addendum to the 802.11 Protocol defining secure authentication andencryption for data access.

AP/Access Point A network device that acts as a translational bridge between a radio link and awired data link.

CAPWAP

Acronym for “Control And Provisioning of Wireless Access Points,” and IETFWorking Group effort to standardize a set of control and data access protocolsfor mobile networks, including 802.11 WLANs CAPWAP is based on theLWAPP RFC draft

Cisco CKM Cisco Centralized Key Management A Cisco proprietary technique for fast

re-authentication and re-keying of roaming client sessions

EtherIP Ethernet in IP A protocol for rapid encapsulation of layer 2 Ethernet framesinside an IP tunnel EtherIP is defined by RFC 3378.

H-REAP

Acronym for Hybrid Remote Edge Access Point An operational mode foraccess points that allows local data traffic bridging instead of centralizedbridging at a WLAN controller

LAG Acronym for Link Aggregation WLAN controller implementation of staticEtherchannel.

PKC Proactive Key Caching An extension to an optional component of the 802.11ithat allows for fast re-keying and re-authentication of roaming WLAN clients.

RF Group Self-forming cluster of WLAN controllers that cooperate in running RRMalgorithms.

RRM Radio Resource Management An advanced set of features in the CUWN for

dynamically managing radio transmit power and channel plans

VoWLAN Voice Over IP Over Wireless Local Area Network

WLC

WLAN Controller A intelligent layer-2 network device that controls a set oflightweight APs, enabling the WLAN network to operate as an intelligentWLAN system with support for modern and advanced business applications andservices

WPA/WPAv2

Wi-fi Protected Access An interoperability certification for secureauthentication and encryption for data access, based on IEEE 802.11i standardsdocument, from the Wi-fi Alliance industry consortium This is the WLANindustry's baseline for data access security

Icon Reference

This document assumes readers are familiar with Cisco icons for Campus routing and switching We provide a table of icons specific to

the CUWN for those new to the technology area

Cisco Unified Wireless Network Icons

3750G Integrated WLAN Controller Switch Icon

Dual-radio Lightweight Access Point Icon

Single-radio Lightweight Access Point Icon

RF Link Icon

General WLAN Controller Icon

WiSM Specific Icon

2.0 Understanding the Cisco Unified Wireless Network Architecture

In this section, we will examine the fundamental building blocks of the CUWN and architecture After a brief overview of the CUWN,

we will look at the Lightweight Access Point Protocol (LWAPP) in depth and examine how packets enter and traverse the network In

later sections, we will look at how Cisco extends the architecture to support seamless mobility and advanced features

Since this document focuses on practical design concepts of the Cisco Unified Wireless Network solution, a detailed, bit-and-byte

discussion of the architecture and LWAPP is outside our scope We will however, review the fundamentals in some detail to provide the

foundation for discussions to follow in the rest of the document

2.1 Basics of the Cisco Unified Wireless Network Architecture

The basics of the Cisco Unified Wireless Network are illustrated in Figure 1:

The CUWN architecture centralizes WLAN configuration and control into a device called a WLAN Controller (WLC) This allows the

entire WLAN to operate as an intelligent information network that uses wireless as the access medium to support advanced services,

unlike legacy 802.11 WLAN infrastructures that are built from autonomous, discrete access points The CUWN simplifies operational

management by collapsing large numbers of managed end-points—autonomous access points—into a single managed system comprised

of the WLAN controller(s) and its corresponding, joined access points

In the CUWN architecture, APs are “lightweight”, meaning that they cannot act independently of a WLC APs are typically “zero-touch”

deployed and no individual configuration of APs is required The APs learn the IP address of one or more WLC via a controller discovery

algorithm and then establish a trust relationship with a controller via a “join” process Once the trust relationship is established, the WLC

pushes firmware to the AP if necessary and a run-time configuration APs do not store a configuration locally

Once joined to a controller, the APs are also lightweight in the sense that they handle only a subset of 802.11 MAC functionality

Typically, this subset includes only real-time 802.11 MAC functionality, with the controller handling all non-real-time 802.11 MAC

processing This division of 802.11 labor is called “Split MAC” and enables the architecture to seamless mobility and a number of

advanced features in an elegant and scalable way

As you can see from Figure 1, APs interact with the WLAN controller via the Lightweight Access Point Protocol (LWAPP) LWAPP

defines the following:

Control messaging protocol and format

Data encapsulation

LWAPP Control messages are exchanged between the WLC and AP for a variety of reasons, including the controller discovery and join

process, AP configuration and firmware push from the controller, as well as statistics gathering and wireless security enforcement WLC

control messages are also used to support wireless station access, authentication, and mobility

WLAN client data packets are encapsulated in LWAPP between the AP and WLC When a WLAN client sends a packet, it is received by

the AP and encapsulated with an LWAPP header and forwarded to the controller At the controller, the LWAPP header is stripped off and

the frame switched from the controller onto a VLAN in the switching infrastructure When a client on the wired network sends a packet

to a WLAN client, the packet first goes into the WLC where it is encapsulated with an LWAPP header and then forwarded to the

appropriate AP The AP strips off the LWAPP header and then bridges the frame on to the RF medium This process will be explained in

detail in Section 2.3

Certain network architectures require some level of “hybrid” deployment LWAPP supports an architecture called “Hybrid REAP”, or

H-REAP REAP is an acronym for Remote Edge Access Point In the H-REAP architecture, more 802.11 MAC processing is pushed to

the network edge at the AP and some data traffic may be bridged onto the Ethernet LAN at the AP instead of being encapsulated in

LWAPP and carried to the controller The H-REAP architecture is described in more detail in Section 2.3

2.2 Understanding LWAPP Fundamentals

This section reviews the fundamentals of LWAPP, but is not an in depth bit-and-byte discussion Rather, it is intended to provide

necessary background for the design scenarios and set the tone for further discussions The LWAPP protocol is defined by an IETF RFC

draft document that is included in the IETF Control and Provisioning of Wireless Access Points (CAPWAP) working group’s efforts

Ultimately, the CAPWAP working group will produce an industry standard wireless protocol, but today, LWAPP is the most mature

protocol available

As defined in the RFC draft, LWAPP is a generic mobility protocol with a binding definition for the IEEE 802.11 WLAN protocol Our

discussion assumes the 802.11 binding since the CUWN is based on 802.11 technology LWAPP, in simple terms, defines how access

point(s) communicate with WLAN controller(s) The LWAPP RFC defines the following:

Control protocol and message format

Data encapsulation

Transport modes for LWAPP Messages

System level operational state machine

Split and Local MAC processing modes

The following sections will examine these LWAPP definitions in greater detail

2.2.1 LWAPP Protocol Messages

LWAPP defines how APs and WLCs communicate with each other in the CUWN LWAPP defines both control messages and a data

encapsulation mechanism

2.2.1.1 LWAPP Control Messages

The LWAPP Protocol defines a control protocol and message format The LWAPP control protocol is used for the following purposes:

WLC discovery by APs

Establishing a trust relationship between APs and the WLC

Downloading firmware to the APs

Downloading configurations to the APs

Statistics collection from the AP by the WLC

Mobility related tasks

Event notifications from the AP to the WLC

Other tasks

LWAPP Control messages are marked with a “Control Bit” or C-bit in the LWAPP encapsulation header that, when set to one, indicates

the LWAPP Message is a control message We will look at many of these LWAPP control messages in functional context throughout this

document

2.2.1.2 LWAPP Data Messages

An LWAPP data message is a forwarded data frame, encapsulated inside an LWAPP transport header The C-bit in the LWAPP header of

LWAPP data packets is set to zero

When the data frame is forwarded from the AP to the WLC, the entire 802.11 frame received by the AP is encapsulated with the LWAPP

header and then transported to the WLC using the appropriate LWAPP transport technology When the data frame is forwarded from a

host on the wired network through the WLC to the AP, the WLC receives an Ethernet encapsulated frame The WLC strips off the

Ethernet header and builds an 802.11 frame This frame is then encapsulated with an LWAPP header and transported to the WLC using

the appropriate transport technology This process is discussed in further detail in Section 2.3

According to the LWAPP specification, the sender of the LWAPP packet—either the AP or the WLC—is responsible for fragmenting the

frame when the encapsulated frame exceeds the transport layer MTU Re-assembly of the original fragmented frame is handled by the

receiver—either the AP or the WLC—before the frame is processed further The fragmentation and reassembly process is described in

further detail in Section 2.3

2.2.2 LWAPP Transport

LWAPP messages are encapsulated in UDP datagrams and transported between the AP and WLC in network layer, IP packets

Technically, this is known as “Layer 3 LWAPP”, but for the sake of brevity, just “LWAPP” is used in this document There is a “Layer 2

LWAPP” defined by the LWAPP RFC, in which LWAPP control and data messages are encapsulated in Layer-2 Ethernet frames, but this

transport architecture is deprecated and not supported on any current AP platforms so it is not discussed in this design guide

In Layer 3 LWAPP Mode, LWAPP Control and Data messages are transported over the IP network in UDP packets Figure 2 illustrates

Layer 3 LWAPP transport:

As shown in Figure 2, the LWAPP Control and Data messages are encapsulated in UDP packets that are carried over the IP network The

only requirement is established IP connectivity between the APs and the WLC The LWAPP tunnel uses the AP’s IP address and the

WLC’s “AP Manager” interface IP address as end-points The AP Manager interface is explained in further detail in the Section 3.2 On

the AP side, both LWAPP Control and Data messages use an ephemeral port that is derived from a hash of the AP Ethernet MAC address

as the UDP port On the WLC side, LWAPP Data messages always use UDP port 12222 On the WLC side, LWAPP Control messages

always use UDP port 12223 Figure 2 shows how LWAPP Control Messages, including the LWAPP Header with the C-Bit set to one and

the LWAPP Control Message elements are transported in UDP packets encapsulated in IP Figure 2 also shows how LWAPP Data

Messages are also transported in UDP packets, with the C-Bit in the LWAPP Header set to zero

Since the WLC is the point of ingress/egress for WLAN traffic, the IP address of WLAN clients like Host A comes from the pool of

addresses on the network upstream of the WLC Details on how WLCs connect to networks are considered in Section 3.2 How data

frames are bridged on and off the wired network are considered in Section 2.3

2.2.3 LWAPP State Machine

The LWAPP RFC defines a state machine The state machine explains how infrastructure devices—specifically APs and WLCs—interact

with each other from start up through operations The LWAPP RFC explains the LWAPP State Machine in detail; this section explains

only some of the key states in the LWAPP state machine for the sake of simplicity

Figure 3 shows the simplified LWAPP State Machine:

As can be seen from Figure 3, the key states considered in this document are:

When an AP powers up or is rebooted, it first enters the “Discovery” state During the Discovery state, the AP searches for one or more

candidate WLCs, from which is will select one to “join” If the AP cannot find a WLAN controller while in the Discovery state, it resets

and then starts the Discovery state again

After an AP finds one or more candidate WLCs during the Discovery state, it transitions to the LWAPP Join state In the LWAPP Join

state, the AP selects a WLC from the candidates found in the Discovery state and attempts to establish a trusted relationship via the

LWAPP Join process If the AP fails to establish a trusted, LWAPP Join relationship with a WLC during the LWAPP Join state, it will

transition to the Reset state and then enters the Discovery state again

On the other hand, if the trusted relationship between the AP and WLC is successfully established, the AP will transition to the Image

Data state to download code or to the Config state to receive a configuration from the WLC Once the AP is successfully configured by

the WLC, it enters the Run state and begins to process data to and from wireless clients The Run state is the normal operational state for

the AP

2.2.3.1 Discovery and Join Process

In this section we will look at the details of the LWAPP Discovery and Join states shown in Figure 4 As discussed in Section 2.2.2.2, the

AP enters the LWAPP Discovery state after booting up In the Discovery state, two important LWAPP Control messages are used—the

LWAPP Discovery Request and the LWAPP Discovery Response The AP sends LWAPP Discovery Request messages to one or more

WLCs, expecting an LWAPP Discovery Response message from the WLC

Each WLC that responds to the LWAPP Discovery Request with an LWAPP Discovery Response gets put into a “Candidate WLC” list by

the AP The AP will select the WLC to join from the Candidate WLC list Before discussing the details of the LWAPP Join process, we

need to fill in the details of how the AP determines where to send the LWAPP Discovery Request messages

The LWAPP RFC does not define how APs discover WLCs Cisco LWAPP APs implement a WLC hunting and discovery algorithm that

is defined as follows

First of all, the AP attempts to acquires an IP address, typically via DHCP DISCOVER, unless of course, it has previously been

configured with a static IP address Subsequently:

The AP broadcasts an LWAPP Discovery Request on the local IP subnet Any WLC that is connected on the local IP subnet will

receive the Layer 3 LWAPP Discovery Request Each of the WLCs receiving the LWAPP Discovery Request reply with a unicast

LWAPP Discovery Response message to the AP

1

When a feature called Over-the-Air Provisioning (OTAP) is enabled on a WLC, APs that are joined to the WLC advertise their

known WLCs in neighbor messages that are sent over the air New APs attempting to discover WLCs hear these messages and

then unicast LWAPP Discovery Requests to each of the WLCs learned via OTAP WLCs receiving the LWAPP Discovery Request

messages unicast an LWAPP Discovery Response to the AP

2

The AP maintains previously learned WLC IP addresses locally in NVRAM The AP sends a unicast LWAPP Discovery Request to

each of these WLC IP addresses Any WLC receiving the LWAPP Discovery Request respond by sending an LWAPP Discovery

Response to the AP These WLC IP addresses are learned by the AP from previously joined controllers The stored WLC IP

addresses include previously joined controllers and controller IP addresses from the “Mobility List” of previously joined

controllers

3

DHCP servers can be programmed to return WLC IP addresses in vendor specific “Option 43” in the DHCP Offer to lightweight

Cisco APs When the AP gets an IP address via DHCP, it will look for WLC IP addresses in the Option 43 field in the DHCP Offer

The AP will send a unicast LWAPP Discovery Request to each of the WLCs listed in the DHCP option 43 WLCs receiving the

LWAPP Discovery Request messages unicast a LWAPP Discovery Response to the AP

4

The AP will attempt to resolve the DNS name “CISCO-LWAPP-CONTROLLER.localdomain” When the AP is able to resolve

this name to one or more IP address, the AP sends a unicast LWAPP Discovery Request to the resolved IP address(es) Each WLC

receiving the LWAPP Discovery Request will reply with a unicast LWAPP Discovery Response to the AP

5

If, after steps 1 through 5, no LWAPP Discovery Response is received, the AP resets and restarts the hunting algorithm

6

The controller hunting process repeats ad infinitum until at least one WLC is found and joined.

It is important to understand that during the LWAPP WLC discovery, the AP will always complete steps 1 through 5 to build a list of

candidate WLCs Once the AP has completed the LWAPP WLC Discovery steps, it selects a WLC from the candidate WLC list and

attempts to join that WLC Two important LWAPP Control messages are used in the LWAPP Join process—the LWAPP Join Request and

the LWAPP Join Response The LWAPP Join process is illustrated in Figure 4:

The AP sends an LWAPP Join Request to the WLC The WLC validates and authenticates the LWAPP Join Request and then responds

with an LWAPP Join Response The AP validates and authenticates the LWAPP Join Response from the WLC If the LWAPP Join

Response is valid and authentic, the LWAPP Join process is considered complete and the AP will transition into an operational state

But how does the AP select a WLC from the candidate WLC list? WLCs embed important information in the LWAPP Discovery

Response, including: the controller’s sysName, the controller type, the controller AP capacity and its current AP load (how many APs are

joined to the WLC), and something called the “Master Controller” status The AP uses this information to make a controller selection,

using the following precedence rules:

If the AP has previously been configured with a primary, secondary, and/or tertiary controller, the AP will select these controllers

based on precedence If the AP finds a match, it then sends an LWAPP Join to the secondary controller If the secondary WLC

cannot be found or the LWAPP Join fails, the AP repeats the process for its tertiary controller

1

When no primary, secondary, and/or tertiary controllers have been configured for an AP, or these controllers cannot be found in the

candidate list, or if the LWAPP Join Requests to those controllers have failed, the AP then looks at the “Master Controller” status

field in the LWAPP Discovery Responses from the candidate WLCs If a WLC is configured as a Master Controller, the AP will

select that WLC and send it an LWAPP Join Request

2

If the AP is unsuccessful at joining a WLC based on the criteria in (1) and (2), it will attempt to join the WLC with the greatest

excess capacity The greatest excess capacity is defined as the ratio of currently joined APs to the total controller capacity

expressed as a percentage

3

As previously stated, once the AP selects a WLC, it sends an LWAPP Join Request message to the WLC, expecting an LWAPP Join

Response The LWAPP Join process provides for strong, standards-based mutual authentication and encryption key derivation The

encryption key is used to encrypt the payload of LWAPP Control messages after the join process is completed The payload of LWAPP

Control messages (other than the LWAPP Discovery and Join sequences) is encrypted using the AES-CCM algorithm

As a basis for explaining how the LWAPP Control Plane is protected, we must first establish these key facts:

The AP and WLC have X.509 certificates burned into protected flash

The X.509 certificates are signed by a private key that is burned into the devices at time of manufacture Both the AP and WLC

have the appropriate public encryption keys installed

The AP and WLC have certificates installed that allow them to trust the issuing certificate authority (of the AP or WLC certificate)

All of the appropriate certificates and keys are burned into the AP and WLC at the time of manufacture, with the exception of APs

that are upgraded from autonomous IOS to LWAPP mode

As shown in Figure 4, when the AP sends the LWAPP Join Request to the WLC, it embeds its X.509 certificate in the LWAPP message It

also generates a random session ID that is also included in the LWAPP Join Request When the WLC receives the LWAPP Join Request,

it validates the signature of the X.509 certificate using the appropriate public key for the AP and checks that the certificate was issued by

a trusted certificate authority (CA) It also looks at the starting date and time for the AP certificate’s validity interval and compares that

date and time to its own date and time If the certificate is properly signed and issued by a trusted CA, and the WLC’s date and time are

within the start and ending parameters of the certificate’s validity interval, the WLC declares the AP valid and authenticated

If the X.509 certificate “checks out”, the WLC generates a random AES encryption key The WLC plumbs the AES key into its crypto

engine so that it can encrypt and decrypt future LWAPP Control Messages exchanged with the AP

The WLC next encrypts the key using the AP’s public key, concatenates the resulting ciphertext with the session ID in the LWAPP Join

Request, and encrypts the concatenated value using its own private key The WLC copies the results into the LWAPP Join Response along

with its own X.509 certificate

When the AP receives the LWAPP Join Response, it validates the WLC certificate signature using the WLC’s public key and checks that

the certificate was issued by a trusted certificate authority If the WLC certificate is validated, the AP extracts the encrypted key portion It

decrypts the concatenated ciphertext using the WLC’s public key and validates the session ID It then decrypts the AES key using its

private key Finally, it plumbs the AES key into its crypto engine to secure future LWAPP Control Message exchanges with the WLC At

this point, the LWAPP Join process is completed

The AP maintains a key lifetime timer When the timer expires, the AP generates a new session ID and embeds it in an LWAPP Key

Update Request control message to the WLC The WLC repeats the previously described key generation and distribution process and

embeds the new ciphertext in an LWAPP Key Update Response The key lifetime timer is eight hours

The X.509 certificates, certificate authority stores and public and private key pairs are burned into protected flash on both the AP and

WLC at the factory by Cisco On the AP, factory installed certificates are called manufacturing installed certificates (MIC) All Cisco

access points manufactured after July 18, 2005 have MICs

Cisco Aironet 1120, 1130, 1200, 1240, and BR1310 access points manufactured prior to July 15, 2005 that have been upgraded from

autonomous IOS to LWAPP IOS will have generated a self-signed certificate (SSC) during the upgrade process SSCs are not trusted by

default by WLCs, so a file containing a mapping of AP MAC addresses to public key hashes is created at upgrade time by the LWAPP

Upgrade Utility supplied by Cisco This file must be imported into the WLC before an AP with an SSC is allowed to join The

autonomous IOS to LWAPP upgrade process is described in detail in the following document:

http://www.cisco.com/en/US/partner/products/hw/wireless/ps430/prod_technical_reference09186a00804fc3dc.html

The rest of this document assumes a MIC implementation on the AP unless otherwise noted explicitly

2.2.3.2 LWAPP Operational States

As shown in Figure 3, after the LWAPP Join process is completed, the AP transitions to either the Image Data state or the Config state

The AP transitions to the Image Data state when the code version running on the AP is out-of-sync with the code version running on the

WLC The AP will always synchronize its code revision with the WLC This means the AP will downgrade its code if it joins a WLC

running a lower code revision than what is currently running on the AP

Code is downloaded from the WLC to the AP in LWAPP control messages The AP requests chunks of code from the WLC in LWAPP

Image Data Request messages and the WLC responds with LWAPP Image Data Response messages The payload of LWAPP Image Data

Response Messages is chunks of the AP code The AP continues to send the LWAPP Image Data Request messages to the WLC until all

code is downloaded It then assembles and installs the new software Once the new software is installed, it transitions to the Reset state as

shown in Figure x and reboots The AP will run through the LWAPP Discovery and Join states again

When the AP software revision is synchronized with the WLC, the AP transitions from the Join state into the Config state (see Figure 3)

In the Config state, the WLC provisions the AP with the appropriate SSID, security, QoS, and other parameters that have been configured

at the WLC The AP then transitions into the Run state and is ready to serve WLAN clients

Once the LWAPP Join process is completed, the WLC starts a “Heartbeat” timer for the AP The WLC is expecting to receive an LWAPP

Echo Request control message from the AP before the timer expires If it does not receive this message before the timer expires, the WLC

removes the AP from its internal data structures

The AP also maintains an LWAPP Heartbeat timer internally When the AP’s Heartbeat timer expires, the AP sends the LWAPP Echo

Request message to the WLC and starts a timer called the NeighborDeadInterval timer The WLC responds to the LWAPP Echo Request

with an LWAPP Echo Response When the AP receives the Echo Response, it stops the NeighborDeadInterval time and restarts the

Heartbeat timer When the NeighborDeadInterval timer expires, meaning the LWAPP Echo Response has not been received by the AP, the

AP resends the LWAPP Echo Request message up to five times at 1 second intervals If no acknowledgement is received after 5 retries,

the AP declares the controller unreachable, releases and renews its IP address, and transitions from the Run state to look for a new

controller

While the AP is in the Run state, the WLC periodically queries the AP for statistics in LWAPP Control messages These statistics are used

for dynamic radio resource management (known as RRM), alarming, reporting, and other tasks

2.2.4 LWAPP MAC Modes

The LWAPP RFC defines two modes for handling 802.11 MAC functionality—Split MAC Mode and Local MAC Mode This section

describes these modes

2.2.4.1 Split MAC

The default LWAPP Mode of operation is called “Split MAC” mode The term “Split MAC” derives from the fact that responsibility for

processing the 802.11 MAC is divided between the AP and the WLC Figure 5 illustrates LWAPP Split MAC mode:

Conceptually, the “division of labor” is between real-time and non-real-time 802.11 MAC functionality 802.11 MAC functionality that

requires direct, real-time access to the RF medium—for example, 802.11 control frames—are processed directly at the AP 802.11 MAC

functionality requiring non-real-time access to the RF medium—for example, 802.11 association requests—is processed at the WLC

When the system is operating in Split MAC mode, all wireless station data must traverse the network through the WLC Wireless data

coming off the RF medium is encapsulated in LWAPP Data Messages and forwarded to the controller Data intended for any wireless

client device is routed/switched to the WLC, where it is encapsulated in LWAPP and forwarded to the appropriate AP

LWAPP Split MAC mode allows the CUWN to support scalable, secure client mobility as well as other interesting advanced services It

is the default mode of operation in the CUWN Unless otherwise explicitly specified, LWAPP Split MAC mode is the assumed mode of

operation in this document

2.2.4.2 Local MAC

The LWAPP RFC also defines a operational mode called “Local MAC” Local MAC mode is illustrated in Figure 6:

The Local MAC implementation pushes some of the non-real-time MAC functionality back to the AP Additionally, the Local MAC

implementation allows the AP to bridge data traffic onto a local network instead of encapsulating and forwarding it to the WLC

Local MAC Mode provides has some advantages over Split MAC Mode when the network between the AP and WLC is bandwidth and

latency constrained But it also has big disadvantages in that key non-real-time functionality related to managing mobility is distributed

instead of centralized This means that in Local MAC Mode, support for roaming and other advanced features related to mobility is more

challenging and has some limitations

In the Cisco implementation, Local MAC mode is manifested in the Hybrid REAP (H-REAP) local switching features

2.2.5 Summary

An understanding of LWAPP fundamentals is essential to designing and deploying the CUWN LWAPP is the underlying fabric of the

CUWN LWAPP defines the control protocol and data encapsulation mechanisms used by the CUWN LWAPP is transported in UDP

datagrams across the network The LWAPP state machine describes the lifetime of APs in the CUWN The key states are: Discovery,

Join, Image Data, Config, and Run LWAPP has two MAC processing modes—Split MAC and Local MAC

2.3 Packet Flow in the Cisco Unified Wireless Network

In this section, we will look at how packets flow in the CUWN We will start by looking at LWAPP Control messages and then move onto

LWAPP Data messages Finally, we will look at how the system handles packet fragmentation and reassembly

For this section, we will refer to Figure 7:

2.3.1 LWAPP Control

Figure 7 illustrates an LWAPP Control Message being transmitted between a WLC and an AP As shown in Figure 7, LWAPP Control

Messages flow between the AP and WLC in UDP datagrams The AP uses a UDP port number that is derived from a hash of the AP’s

Ethernet MAC address This port number is always greater than 1024 and will be unique for each AP The WLC will always use UDP

port number 12223 for LWAPP Control Messages

Naturally, the UDP datagrams are transported over the network in IP packets The IP addresses used are the AP’s IP address and the

WLC’s AP Manager IP address

2.3.2 LWAPP Data Path: Centrally Bridged Traffic

Figure 7 also illustrates the data path when the system is centrally switching LWAPP data traffic, which is typical with “Split MAC”

operation and the default with the CUWN In Figure 7, wireless station “Host A” is associated to AP-1 and is communicating with the

wired device “Host B” When Host A transmits a data frame, it is received by AP-1, encapsulated into an LWAPP data packet, and

transmitted to the WLC As can be seen from the figure, the entire 802.11 data frame is encapsulated with an LWAPP header, and then

encapsulated into a UDP datagram, which of course is carried as an IP packet The IP packet uses the AP’s IP Address as the source IP

address and the WLC’s AP Manager IP address as the destination address Once the IP packet arrives at the WLC, the WLC extracts the

LWAPP header for processing The WLC extracts the 802.11 data frame, strips off the 802.11 MAC header, then places the payload into

an 802.3 Ethernet frame that is bridged onto an appropriate VLAN on the wired network The wired, switched/routed network delivers

the data frame to Host B

When Host B transmits a data packet to Host A, the process essentially works in reverse The wired, switched/routed network delivers an

Ethernet encapsulated IP packet to the WLC The WLC, extracts the IP packet from the Ethernet frame and builds an 802.11 data frame

The controller adds an LWAPP header and builds a UDP datagram with the LWAPP encapsulated 802.11 data frame as the PDU Of

course, the UDP datagram is carried in an IP packet, with the WLC AP Manager IP address as the source IP address and the AP’s IP

address as the destination Once the LWAPP packet arrives at the AP, the AP processes the LWAPP header and extracts the 802.11 data

frame The 802.11 data frame is bridged onto the wireless network to deliver it to Host A

As shown in Figure 7, the AP uses a UDP port number that is derived from a hash of the AP’s Ethernet MAC address This port number is

always greater than 1024 and will be unique for each AP The WLC will always use UDP port number 12222 for LWAPP Data Messages

2.3.3 LWAPP Data Path: Locally Bridged Traffic

When an AP is configured to operate in “Hybrid REAP”, or H-REAP, mode, data traffic can be locally bridged on a per WLAN basis

Figure 8 represents locally switched traffic with H-REAP APs:

As shown in Figure 8, when the AP is in H-REAP mode with locally bridged traffic, data frames are bridged directly onto or off the wired

network at the AP instead of being passed through the WLC So, when the wireless station “Host A” sends a data frame destined for

wired “Host B”, the AP receives the 802.11 data frame off the air, strips off the 802.11 header, and replaces it with an 802.3 Ethernet

header The Ethernet frame is then bridged directly onto the wired network by the AP The wired switched/routed network delivers the

data frame to Host B

When wired Host B sends a data frame destined for wireless Host B, the switched/routed network delivers the data frame to the AP as an

Ethernet frame The AP, strips off the Ethernet header and replaces it with an 802.11 header to make an 802.11 data frame This 802.11

data frame is subsequently sent out over the air by the AP to wireless station Host A

2.3.4 Fragmentation and Re-assembly of LWAPP Packets

In the CUWN, both the AP and WLC assume a 1500 byte MTU for LWAPP communications When either the AP or the WLC assemble

an LWAPP packet that exceeds 1500 bytes, the packet will be fragmented The fragmentation process is illustrated in Figure 9:

As shown in Figure 9, an “oversized” LWAPP packet, defined as a packet exceeding 1500 bytes, is fragmented by the originator of the

LWAPP packet The process is simple; the “excess” part of the LWAPP packet is lopped off and sent as an IP fragment Note that there is

no LWAPP encapsulation on the IP fragment Reassembly takes place at the receiving end of the LWAPP packet

2.3.5 Summary

Understanding how packets flow is important for successfully designing and deploying the CUWN successfully LWAPP Control

Messages traverse the network between the AP and WLC as UDP datagrams The WLC always uses UDP port 12223 for LWAPP Control

Messages while the AP uses a port number that is greater than 1024 and is based on a hash of the AP’s Ethernet MAC address

Data packets will traverse the network differently depending LWAPP MAC Mode With LWAPP Split MAC Mode, all data frames flow

through the WLC on and off the network The data packets are carried between the WLC and AP in LWAPP encapsulated packets The

WLC will always use UDP port 12223 for LWAPP data packets, while the AP uses a port number that is greater than 1024 and is based on

a hash of the AP’s Ethernet MAC address With LWAPP Local MAC Mode, data frames are bridged on and off the wired network at the

AP instead of at the WLC

2.5 Mobility

One can argue that the real killer benefit derived from wireless networks is mobility But mobility introduces challenges in a network

implementation A WLAN client must be able to maintain its association seamlessly from one AP to another, securely, and with as little

latency as possible These mobility requirements are completely supported by the Cisco Unified Wireless Network architecture This

section covers the basic operational theory to keep the deployment guide simple and easy to understand For further information, please

refer to the product documentation for a complete overview of the solution

2.5.1 Client Roaming

A wireless client roams when it moves its 802.11 association from one AP to another AP Wireless client devices initiate roaming based

on the internal roaming algorithms programmed into the client radio firmware Typically, a client's roaming logic is triggered by crossing

an RSSI or SNR threshold that causes the client to look for a better signal from a new AP Device roaming behavior and performance

differ by vendor, so it is wise to characterize device roaming and look to device configuration best practices from the client vendor

WLAN clients are always re-authenticated by the system in some way on a roam; this is always necessary to protect against session

spoofing and replay attacks Normally, the re-authentication requires a full authentication transaction In the case of 802.1X

authentication, a full EAP re-authentication and re-keying will be required However, the CUWN supports two methods of fast secure

roaming that short-cut the re-authentication process while maintaining security: Cisco Centralized Key Management (Cisco CKM) and

Proactive Key Caching (PKC) While no special client software is required for roaming, Cisco CKM and PKC do require supplicant

support Cisco CKM and PKC are discussed in more detail in Section 2.5.3

From a roaming client's perspective, it is only roaming between APs However, there is a considerable amount of choreography going on

in the infrastructure that is opaque to the client When a wireless client associates and authenticates to an AP, the AP’s joined WLC places

an entry for that client in its client database This entry includes the client’s MAC and IP addresses, security context and associations, and

QoS context, WLAN and associated AP The WLC uses this information to forward frames and manage traffic to and from the wireless

client What a client roams, this client database information must be updated and possibly copied or moved to another controller

CUWN client roaming will be discussed in three “flavors”:

Intra-controller Roaming

Inter-controller Layer-2 Roaming

Inter-controller Layer-3 Roaming

All inter-controller roaming requires controllers be in the same “Mobility Group” The concept of a Mobility Group is discussed in

Section 2.5.2

2.5.1.1 Intra-Controller Roaming

Now, let’s look at what happens when the wireless client roams from one AP to another when both the original and new AP are joined to

the same WLC This is illustrated in Figure 10:

When the wireless client moves its association from one AP to another, the WLC simply updates the client database with the new

associated AP The client is re-authenticated to establish a new security context

2.5.1.2 Inter-Controller Layer-2 Roaming

Now let’s consider what happens when a client roams from an AP joined to one WLC and an AP joined to a different WLC? Figure 11

illustrates an inter-controller roam in the event of a “Layer 2” roam:

As you can see from Figure 11, a Layer 2 roam occurs when the controllers bridge the WLAN traffic on and off the same VLAN and the

same IP subnet When the client re-associates to an AP connected to a new WLC, the new WLC exchanges mobility messages with the

original WLC and the client database entry is moved to the new WLC The client is re-authenticated to establish a new security context

and the client database entry is updated for the new AP with which the client is associated

2.5.1.3 Inter-Controller Layer-3 Roaming

Figure 12 illustrates an inter-controller roam in the event of a “Layer 3” roam:

As you can see from Figure 12, a Layer 3 roam occurs when the controllers bridge the WLAN on and off different VLANs and IP

subnets The inter-controller roaming is similar to Layer 2 roaming in that the WLCs exchange mobility messages on the client roam

However, instead of moving the client’s entry to the new controller’s client database, the original WLAN controller marks the client with

an “Anchor” entry in its own client database The database entry is copied to the new controller client database and marked with a

“Foreign” entry in the new WLC The client is re-authenticated to establish a new security context and the client database entry is updated

for the new AP with which the client is associated The choreography on the backend is totally opaque to the wireless client and the

wireless client maintains its original IP address

If a wireless client subsequently roams to a new AP joined to a different WLC, the “Foreign” client database entry is moved from the

original Foreign WLC to the new Foreign WLC, but the original Anchor WLC is always maintained

As you can see from Figure 12, after a Layer 3 roam, data to and from the wireless client flows in an asymmetric traffic path Traffic from

the client to the network is forwarded directly into the network by the foreign WLC Traffic to the client arrives at the Anchor WLC,

which forwards the traffic to the Foreign WLC in an Ethernet in IP (EtherIP) tunnel The Foreign WLC then forwards the data to the

client EtherIP is defined in IETF RFC 3378

Asymmetric traffic tunneling is the default in all WLAN controller configurations However, asymmetric tunneling can present challenges

in network design For example, reverse path forwarding/filtering (RPF) and stateful security mechanisms are incompatible with

asymmetric traffic tunneling

Starting with the 4.1 release of code, WLAN controllers can be configured to tunnel traffic symmetrically Figure 13 illustrates symmetric

traffic tunneling:

The symmetric mobility tunneling feature allows both a roamed client's ingress and egress traffic to be tunneled to and from the anchor

controller This means that roamed clients reside logically in their anchor controller and traffic patterns between the anchor and foreign

controllers operates fully as a point-to-point symmetric tunnel The only difference in operation between regular, asymmetric mobility

tunneling and this new symmetric traffic flow is that the upstream traffic from roamed clients will not be forwarded to the destination by

the foreign controller, but will instead be tunneled to the anchor controller, where delivery to the network will occur

This feature allows the underlying wired network architecture to remain fully unchanged when features such as reverse path

forwarding/filtering (RPF) checking is enabled on intermediary layer 3 interfaces or stateful security prevent such operation between

controllers

2.5.3 Roaming Latency and Fast Secure Roaming

One of the key advanced mobility requirements is that device roaming be transparent to applications, particularly latency sensitive

applications like VoWLAN Roaming latency is introduced by:

The device selecting a new AP

Device re-association and re-authentication

Device IP address refresh

The amount of latency introduced by a device selecting a new AP will vary by device vendor implementation A roaming device needs to

scan for and select it's next, best AP Usually, this introduces no more than 10-15 milliseconds The CUWN mobility solutions eliminate

the problem of device IP refresh latency via the architectural solutions described in Section 2.5.1

Which leaves us with the problem of device re-association and re-authentication This is particularly an issue when using Enterprise grade

802.1X/EAP authentication and encryption key derivation Without additional support beyond the 802.11i and WPA standards to shortcut

the re-authentication and re-keying process, a full RADIUS re-authentication and full re-keying is required for every roam This may

introduce latencies of anywhere from 250 milliseconds to well over 2 seconds To address this challenge, the CUWN supports two

algorithms for fast re-authentication and re-keying: Cisco Centralized Key Management (Cisco CKM) and Proactive Key Caching

(PKC)

2.5.3.1 Roaming Without Enterprise Grade Security

Roaming is supported without enterprise grade authentication and encryption For the purposes of this document, non-enterprise grade

security includes:

Open authentication

Static WEP

WPA/WPAv2 Personal, also known as “Pre-shared key” (PSK)

When a device is associated via 802.11 open authentication, the client device will simply dis-associate from it's current AP and then

re-associate with the new AP it has selected The infrastrucure choreography is as described in Section 2.5.1

When static WEP is used for link encryption, a roaming device will dis-associate from it's current AP and go through an 802.11 open

authentication to establish link connectivity between itself and the new AP Once this is completed, data frames will be passed provided

the WEP keys match between the client device and new AP The infrastrucure choreography is as described in Section 2.5.1

When WPA/WPAv2 personal is implemented as the authentication and encryption scheme, a roaming device dis-associates from it's

current AP and re-associates with the new AP The roaming device will then perform the four-way handshake, as defined by the IEEE

802.11i specification, with the new AP's controller to derive a pairwise transient key (PTK) for encrypting the link with the new AP The

infrastrucure choreography is as described in Section 2.5.1; the device re-authentication is accomplished via the four-way handshake

2.5.3.2 Roaming With Enterprise Grade Security

Enterprise grade security is defined as WPA/WPAv2 Enterprise security This means the wireless client's authentication to the network is

done via 802.1X/EAP and either TKIP or AES encryption with key derivation as described in the 802.11i specification For the purposes

of this discussion on roaming, we will generically treat all EAP types as the same

When a device secured via enterprise grade security decides to roam, it will first dis-associate from it's current AP then perform an 802.11

re-association with the new AP At this point, a full 802.1X/EAP re-authentication will take place between the client and the new AP's

controller unless a fast secure roaming algorithm is supported The infrastrucure choreography is as described in Section 2.5.1 but the

device re-authentication and re-keying are accomplished via a full 802.1X/EAP authentication and key derivation as described in the

802.11i specification

The full 802.1X/EAP re-authentication and key derivation introduces substantial latency to a device roam, perhaps on the order of several

seconds Clearly, this is too much roaming latency to support applications like VoWLAN, so Cisco has innovated on two fronts to provide

mechanisms to bypass full 802.1X/EAP authentication while maintaining security These mechanisms are Cisco Centralized Key

Management (Cisco CKM) and Proactive Key Caching (PKC)

Cisco Centralized Key Management (Cisco CKM) Cisco Centralized Key Management (Cisco CKM) was initially developed by Cisco

as part of the Structured Wireless Aware Network (SWAN) architecture and later adopted in the CUWN Cisco CKM shortcuts the

re-authentication process by caching a set of master key materials in the controller and on the client device When the device roams, the

master keying material is used both to authenticate the client and negotiate a new PTK for the new session The details of Cisco CKM

choreography are beyond the scope of this document

To implement Cisco CKM requires support on the client devices and supplicant Cisco CKM is a feature first included in CCXv2 with

LEAP authentication CCXv3 added Cisco CKM with EAP-FAST authentication CCXv4 added support for Cisco CKM with all EAP

types Check with your device vendor(s) on Cisco CKM support Cisco CKM also currently supports TKIP encryption only, not AES

Proactive Key Caching

Proactive Key Caching (PKC) is an extension of an optional component of the 802.11i security specification With PKC, the controller

and client cache Pairwise Master Keys (PMK) after the initial authentication When the client device roams, it embeds a unique number

called the PMKID calculated using the PMK in its re-assocation request If the controller can match the PMKID using it's cached

PMKID, then the controller and client skip EAP authentication, going directly to the four-way handshake to derive a new PTK

PKC is extremely fast, but like Cisco CKM, requires client and supplicant support PKC also is only supported with WPAv2 and AES

encryption Check with your device and supplicant vendor(s) for PKC support PKC is sometimes called Opportunistic Key Caching

(OKC)

Cisco CKM or PKC?

Selecting a fast secure roaming option is really dependent on what your client and supplicant vendors support Cisco CKM and PKC can

co-exist in the same network

Latency Expectations

Vendors make many claims about roaming times, some quite absurd Most vendor published roam times come from contained test

environments with little or no relevance to real world environments There are several factors to remember when evaluating vendor

claims:

Client devices initiate roaming The algorithms clients use to decide when to roam vary based on vendor implementation Some

clients are inherently more “sticky” than others

The algorithms clients use to select a new AP once they've decided to roam vary by vendor implementation Some clients take

longer than others to select a new AP

Re-authentication times are affected by factors like network latency and RADIUS server performance

The RF environment makes a difference; busy RF environments affect roaming frequency and times

AP placement, co-channel interference levels, and supported data rates affect client roam times

The implication of these factors is obvious–your roaming times may very well be unique to your environment and vary wildly from

vendor supplied numbers Cisco's guidance is to pilot test your client devices in your environment In most environments, roam times

well under 100 milliseconds are achievable with Cisco CKM and PKC These roam times are more than adequate to support a properly

installed VoWLAN implementation

2.5.2 Mobility Groups

A set of WLC devices can be configured in a cluster called a Mobility Group A Mobility Group allows you to deploy multiple WLC

devices in a network and have the devices dynamically share important information between them and also to forward data traffic when

inter-controller roaming occurs The important information shared includes client device’s context and state, and WLC loading

information With this information, the network can support inter-controller WLAN device roaming, AP load balancing, and controller

redundancy Figure 14 illustrates the mobility group concept:

As you can see from Figure 14, each WLC in the Mobility Group is configured with a list of the other members of the Mobility Group.

Each WLC device builds a neighbor relationship with every other member of the group When client data is forwarded between members

of a Mobility Group to support Layer 3 roaming, the packets are carried over an Ethernet in IP (EtherIP) tunnel

A Mobility Group can include up to 24 WLC devices in all code versions up to release 4.2 The number of APs supported in a Mobility

Group will be bounded by the number of controllers and controller types in the mobility group For example, a Mobility Group made up

of 24 4404-100 WLC devices will support up to 2400 APs since a 4404-100 supports up to 100 APs per WLC (24 * 100 = 2400 APs) A

Mobility Group made up of 12 4402-25 and 12 4402-50 WLC devices will support up to 900 APs since the 4402-25 supports up to 25

APs and the 4402-50 supports up to 50 APs (12 * 25 + 12 * 50 = 300 + 600 = 900 APs) and so on A WiSM controller module counts as

two controllers in a Mobility Group, so a maximum of 12 WiSM modules can be supported in a single Mobility Group

Design-wise, WLCs should be placed in the same Mobility Group when an inter-controller roam is possible If there is not the possibility

of a roaming event, then it may make sense to not put WLCs in the same Mobility Group

For example, suppose you have deployed two separate WLCs in two buildings, with each WLC managing the APs in its building If the

buildings are separated by a large parking area with no RF coverage, then a WLAN client is not going to roam from an AP in one

building to an AP in the other building So, the WLCs don’t necessarily need to be members of the same Mobility Group

Redundant WLCs should be in the same Mobility Group in most cases When APs join a WLC, it learns the IP addresses of the other

WLCs in the Mobility Group from its joined WLC These addresses are remembered and used the next time the AP does an LWAPP

discovery More details on redundancy are covered in Section 4.1.1

2.6 Radio Resource Management

An RF Domain, also known as an RF Group, is another critical deployment concept An RF Domain is a cluster of WLC devices type

that coordinate their dynamic radio resource management (RRM) calculations on a per 802.11 PHY type An RF Domain exists for each

802.11 PHY type Clustering WLCs into RF Domains allows the dynamic radio resource management (RRM) algorithms to scale beyond

a single WLC and span building floors, buildings, and even campuses An in depth discussion of RRM is beyond the scope of this

document, but we offer an abbreviated explanation in the following paragraphs For a more in depth explanation of dynamic RRM in the

CUWN, please see this document:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml