they are supported on the WTP and, in some cases, for-
warded to the AC, when Local MAC is in use. For instance,
since the AC may need to be aware of mobility events with-
in WTPs, the WTP has to forward to the AC all the Associ-
ation Request messages it receives.
When needed, the transport of IEEE 802.11 frames is
realized using the CAPWAP data message encapsulation
rules. IEEE 802.11 header and payload are encapsulated,
while the FCS checksum (see [4]) is excluded. An optional
CAPWAP header may be added. When the frame is encap-
sulated by the WTP, the optional header is that depicted in
Fig. 1a and it gathers information on the Received Signal
Strength Information (RSSI), the Signal-to-Noise-Ratio
(SNR) and the data rate used by the sending station. When
the frame is encapsulated by the AC, the optional header is
that depicted in Fig. 1b and it informs the WTP about the
WLAN ID to be used when sending the frame.
CAPWAP control messages for IEEE 802.11 are enriched
by the introduction of specific information for radio con-
trol, management and monitoring. Moreover, special con-
trol frames for the Quality of Service management using
Wireless Multimedia (WMM) extensions are defined in
[2]. WMM is a WiFi Alliance interoperability certification,
based on the IEEE 802.11e standard [5].
1
WMM prioritizes
traffic according to four Access Categories (ACs): (VO) Voice,
(VI) Video, (BE) Best Effort and (BK) Background. The quality
of each Access Category is controlled by five MAC layer
parameters: AIFS, CW
min
, CW
max
, TXOP
limit
and q
depth
.Tobe
more specific, each AC within each station implements a
slotted CSMA/CA channel access protocol. The AIFS defines
the fixed waiting time for carrier sensing that a specific AC
has to use before any attempt to transmit. The CW
min
and
CW
max
control the exponential backoff algorithm imple-
mented by each AC. They aim at mitigating network conges-
tion. The TXOP
limit
is a maximum channel holding time.
When an AC transmits successfully, that AC can transmit
other frames without contending with other ACs and STAs
until this time has expired. The q
depth
parameter is not
directly specified by IEEE 802.11e, but it represents the max-
imum number of packet that may be buffered in each AC
queue. It can be used to control the trade-off between delay
and loss in the sending queue. CAPWAP allows the configu-
ration of four of such parameters with the WTP Quality of
Service message depicted in Fig. 2.
3. Protocol implementation
There are several other projects aimed at developing an
open source implementation of the CAPWAP protocol (e.g.,
[10]). However, to the best of our knowledge, none of them
has released code yet or, as in the case of [10], only a lim-
ited and outdated implementation is provided.
The state diagram reported in Fig. 3 represents the
lifecycle of a WTP-AC session with a Finite State Machine
(FSM), as defined in the protocol specification [1]. Use of
DTLS by the CAPWAP protocol results in the juxtaposition
of two nominally separate yet tightly bound state ma-
chines. The DTLS and CAPWAP state machines are cou-
pled through an API consisting of commands and
notifications. Certain transitions in the DTLS state ma-
chine are triggered by commands from the CAPWAP state
machine, while certain transitions in the CAPWAP state
machine are triggered by notifications from the DTLS
state machine.
The same FSM is defined for both the WTP and the AC,
although some states and transitions are implemented
only on either the WTP or the AC. A complete description
of the FSM is reported in the Section 2.3 of [1]. A normal
session for the WTP begins with the Start state. After
the initialization is complete, the WTP enters the Idle
state. The WTP then proceeds to the Discovery phase to
find an AC to connect with. The Discovery state is
skipped if the WTP is instructed to try to connect to a fixed
AC. In both cases the WTP moves to the DTLS Setup phase,
to establish a secure DTLS connection with the AC. A tran-
sition from DTLS Setup to Authorize occurs when the
DTLS session is being established, and the DTLS stack needs
authorization to proceed with the session establishment. If
all goes well, the WTP enters the DTLS Connect state, and
when the DTLS connection is established the Join state is
reached. In the Join state the AC and the WTP start com-
municating with each other and the CAPWAP session can
begin. Upon the reception of a successful Join Response
message from the AC, the WTP is instructed to either
download new executable firmware (in which case it en-
ters the Image Data state, and the session ends because
the device is reset) or it is configured through the appropri-
ate messages sent by the AC (in the Configure state). If
the success of the configuration process is confirmed by
messages exchanged in the Data Check state, the WTP
eventually reaches its normal operating state, represented
in the FSM by the Run state. There are a number of possible
events that may occur in the Run state, the most relevant is
the Configuration Update Request by which the AC requires
the WTP to modify its configuration.
The other states illustrated in the FSM have intuitive
meanings. The Sulking state is somehow a special case
that is defined for situations in which the WTP can not
communicate with an AC. The WTP exits from the Sulking
state and starts a new Discovery phase (after a tempo-
rary transition to the Idle
state) when the SilentInte
rval
timer
expires.
Our
implementati
on of the CAPWAP protocol consists of
two Linux applications, one running on the ACs and one
running on the WTPs. Each WTP acts as a client of an AC.
Each AC manages both the communication with WTPs
31
RSSI SNR Data Rate
0816
ReservedWLAN ID bitmap
13610
Fig. 1. Optional wireless specific information. (a) Frame info. (b) Desti-
nation WLANs.
1
WMM extensions are a subset of EDCA, the Enhanced Distributed
Channel Access mechanism defined in the IEEE 802.11e standard.
M. Bernaschi et al. / Computer Networks 53 (2009) 217–230
219