JOURNAL OF TELECOMMUNICATIONS, VOLUME 17, ISSUE 1, NOVEMBER 2012

22

Setup Latency Analysis of CAPWAP Centralized WLAN Network

M. Balfaqih, A. Hashim, O. Mahmoud, M. H. Mazlan, S. Haseeb and S. N. Hasnan

Abstract—High number of Access Points (APs) in large-scale networks have introduced several overheads such as control, management and monitoring. Distributing and maintaining a consistent configuration while considering security issues presents even more challenges in large deployments and new architectures. These issues forced many network vendors such as Aruba, Cisco and Meraki to offer proprietary centralized solutions. Since the proposed solutions don’t provide any form of interoperability, Control and Provisioning of Wireless Access Point (CAPWAP) Working Group had defined standard interoperable protocol to address the aforementioned problems. By using Access Controller (AC) and Wireless Termination Point (WTP), this interoperable protocol allows network operators to control their wireless network infrastructure and extends manageability. This paper evaluates the latency involved with setup process in three cases; normal setup process, pre-configured setup process and setup process with considering failure states. The results showed that the main latency contributor is the Discovery phase, while the error during DTLS Establishment phase cost more time than other phases.

Index Terms— Centralized Network, CAPWAP, Wireless network, Network management.

—————————— u ——————————

1 INTRODUCTIONhe notion of wireless network is to provide internet access for mobile client anywhere and anytime. This in turn increased the popularity of wireless LAN due

to the ease of expansion and deployment Nowadays, Wireless LAN technologies have picked up momentum as large-scale network deploys multiple APs that cooperate with each other to create a fabric network. Large-scale network setup is not trivial because of their management, control and configuration issues. In order to simplify the administration, some network vendors such as Aruba, Cisco and Meraki to offer proprietary centralized solu-tions. The common characteristic of the proposed solu-tions is splitting functionality of APs and adding more centralized operation functions for configuring, managing and monitoring purposes.

Internet Engineering Task Force (IETF) working group had developed standard interoperable protocol called Control and Provisioning of Wireless Access Points (CAPWAP) protocol [1]. The CAPWAP protocol enables Access Controller (AC) to manage a group of simple Ac-cess Points (APs) called WTPs [2]. As mentioned in CAPWAP specification [3], the aim of CAPWAP protocol is centralizing authentication and policy functions, shift-ing higher-level process from WTP to AC and providing an extensible protocol via a generic encapsulation and

transport mechanism. In this paper, we extend the investigations in [4,5,6], by

analyzing the set-up process between AC and WTPs with and without considering failure states. The setup process (see Fig.2) consists of three phases: Initialization phase, Discovery phase and DTLS Establishment phase. The main contribution of this paper is performing three sets of measurements; 1) the association latency of AC and WTP if the WTP was configured locally to specific AC. 2) the association latency of a different number of AC and dif-ferent number of WTPs without error. This includes the spent time through three phases to establish a connection between WTP and AC. 3) the association latency of one AC with a different number of WTPs with considering a different type of errors during different phases.

The rest of the paper is organized as a follow; section 2 explores the related works. Section 3 describes CAPWAP centralized architecture and differentiates it from other architectures. In section 4, we detailed the finite state ma-chine of the centralized CAPWAP architecture and ex-plained different configuration scenarios. In section 5, we explored and discussed the results of the association la-tency. Finally, section 6 concludes the paper and shows our future work.

2 RELATED WORK There is not much work done in CAPWAP protocol,

even though it was defined since 2009. According to [7] the reason is that the vendors still use their proprietary solutions. That is because they try to stand out from the crowd by promoting their own methods. Moreover, it is also probably because of the late introduction of CAP-WAP protocol compared to other proprietary centralized solutions.

M. Bernaschi et al. proposed the first open source CAPWAP implementation in [8] and [9]. The authors pre-

T

———————————————— • M. Balfaqih is with Mobile Platform Department, MIMOS Berhad Tech-

nology Park Malaysia, 57000 Kuala Lumpur, Malaysia and International Islamic University Malaysia (IIUM), Gomback, 50728 Kuala Lumpur, Ma-laysia

• A. Hashim and O. Mahmoud are with International Islamic University Malaysia (IIUM) Gomback, 50728 Kuala Lumpur, Malaysia

• M. H. Mazlanis with Universiti Teknologi Malaysia (UTM), Johor, Ma-laysia

• S. Haseeb, and S. N. Hasnan, are with Mobile Platform Department, MI-MOS Berhad Technology Park Malaysia, 57000 Kuala Lumpur, Malaysia.

23

sented some experimental tests to measure the perfor-mance of their CAPWAP implementation. The related measurement to our work is the set-up phase measure-ment for one locally configured AC and one WTP. This means that the WTP had specific AC determined by ad-ministrator to associate with. The results showed that the association latency across 15 experiments was 86.51 ms. However, the limitation of this paper is the small scale for their testbed.

In [6], the authors extended the previous work by measuring setup process with different number of WTPs and ACs. The paper also evaluated the authentication protocols latency during mobile node and AP authentica-tion. However, it did not consider the possibility of error during setup phase.

In this paper, we show more results and extend the measurements by studying the setup process latency with considering error in the three sub phases; Initialization Phase, DTLS Establishment Phase and Joining Phase.

3 CAPWAP CENTRALIZED ARCHITECTURES CAPWAP architecture consists of WTPs communi-

cating to AC via CAPWAP protocol (see Fig. 1). Accord-ing to the centralization level of the control operations, CAPWAP supports two different operational architec-tures [2]: Local and Split Medium Access Control (MAC). The naming reflects how the 802.11 MAC functions are

distributed between AC and WTP. In both architectures, CAPWAP functions entirely left

to the AC while the WTP is responsible for physical func-tions. WTPs in Local MAC Architecture have the whole MAC functionalities including control and management frames. Consequently, Integration and Distribution ser-vices are implemented by WTP or are bridged to AC. The Integration service enables delivery of MAC service data units (MSDUs) between 802.11 and 802.3. The distribution service enables MAC layer to deliver (MSDUs) within the distribution system (DS).

The downside of Local MAC architecture is the extra loading over WTP. Local MAC Architecture has less cen-tralized because that station’s state information remains at WTP and it is processed locally and, in some cases, it is

forwarded to AC. This causes some difficulties to manage a growing network of many WTP devices. Comparing to Split MAC WTP, Local MAC WTP is more expensive and lesser secured.

On the other hand, in Split MAC architecture, in order to allow AC to scale to a large number of WTP devices, non-realtime MAC functions are handled by AC while WTP terminates realtime MAC functions. The realtime functions are time-sensitive functions such as beacon generation, probe response and processing of control frames. Due to that AC is responsible for control frames, the distribution and integration services reside on the AC. CAPWAP protocol encapsulates and exchanges all layer 2 wireless data and management frames between AC and WTP.

However, Split MAC has some latency from splitting MAC functions and the dependency on AC because all data and signalling traffic has to flow through the AC. The two architectural variants may be appropriate for different deployment scenarios.

4 CAPWAP PROTOCOL There are several connectivity options between ACs

and a collection of WTPs including direct connection, lay-er 2 switched connection and layer 3 routed connection. The CAPWAP protocol is defined to be layer 2 technolo-gy concerned with management and configuration of the WTP devices, configuration and control of the radio re-source and security regarding the registration of the WTP to an AC [10]. The CAPWAP transport layer carries CAPWAP data messages and control messages, which are sent over separate User Datagram Protocol (UDP) ports. Datagram Transport Layer Security (DTLS) is used to secure CAPWAP control messages and optionally CAP-WAP data messages. As shown in fig. 2, the state machine of CAPWAP centralized architecture consists of 4 sub phases namely, Initialization Phase, Discovery phase, DTLS Establishment Phase and Joining Phase. The state machine is an overall operation of WTP and AC. Some operations are only for AC while others are only for WTP. The discovery to discovery transition - for example - is defined for WTP only in order to select potential AC to connect with. After initialization phase is complete, The Discovery phase is the start for the normal session of CAPWAP protocol. The WTP sends a Discovery request message to ACs, which in turn will respond, with Discov-ery Response message. Based on the capabilities and load in ACs, the WTP will determine to which AC will estab-lish a secure DTLS connection in DTLS establishment phase. Then, the WTP and AC will exchange configura-tion and provisioning settings during Join phase. If the configuration process was successfully confirmed in Data check state, the normal state of operation, which is the Run phase is started, where the WTP and the AC are ready to exchange CAPWAP messages. In case that WTP is preconfigured with specific AC, the WTP will go direct-ly through DTLS Establishment phase. The CAPWAP exchange messages are shown in Figure 3.

Fig.1: CAPWAP Centralized Architecture

of WTP with 1 AC

24

Setup phase is not always straightforward as shown in

Fig. 2; there are 5 failure states to cater for setup failures. The sulking state is where the system goes to a latency mode when either AP or AC is unable to communicate with each other. The WTP goes back to Discovery state after Silent Interval expires. DTLS Teardown happens when the AC or WTP has been unable to authorize each other. Typically after DTLS Teardown, the system reaches a Dead state and needs to reinitiate the steps from the beginning. If the configurations received from the AC are not valid, the system goes to the Image Data state to download executable firmware and then reset the DTLS connection by restarting the WTP after an image download.

5 SIMULATION ANALYSIS Our simulation results of the setup latency are divided

into three sections; the normal setup process where the WTP determines AC to connect with via optional discovery state, setup process when the WTP is pre-configured and setup process with considering failure states.

We developed custom simulator software in VB, the simulator has modules for different setup scenarios. The simulator allows to assuming any number of AC and WTP.

5.1 Normal Setup Process This consists of four sub-phases where the transitions

between their states appear as thicker line in fig.1. Here, we used a different number of WTPs (1, 6, 12, 16, 20 and 24) connecting to one AC to evaluate the effect of increas-ing the number of WTP. On the other hand, to study the effect of increasing number of AC, we assumed different number of AC (1, 2, 3, 4 and 5) in the network. Figure 4 shows the setup latency of different number of WTP and AC with 50 repetitions and its average. The average delay for 1 AC, with 1 WTP is 5.02 Sec., with 6 WTPs is 12.74 Sec., with 12 WTPs is 21.69 Sec., with 16 WTPs is 27.71 Sec., with 20 WTPs 33.79 Sec. and with 24 WTPs is 39.71

Idle DiscoveryStart

Run

AutherizeDTLS Setup

JoinConfigureData Check

DTLS Connect

Once device initialization is complete

WTP determines to which AC to connectOccurs on the AC’s discovery

thread when the discovery processing is complete

To support the CPAWAP discovery process

Occurs when the linkage between the control and

data channels is established

Occurs when the WTP and AC confirm the

configuration

Is used by the WTP and the AC to exchange

configuration information

Occurs when the DTLS session is successfully

established

To establish a secure DTLS session with the peer

Occurs when an incoming DTLS session is being

established and the DTLS stack needs authorization

Is Executed by the AC to enable it to listen for new

incoming sessions

To notify the DTLS stack that the

session should be established

Initialization Phase Discovery Phase DTLS Establishment Phase

Join Phase

Sulking DTLS Teardown Dead Image

Data Reset

Occurs on a WTP when AC discovery fails

Occurs on a WTP when it must restart the discovery phase

Silent period to minimize the possibility for

Denial-of-Service attack

Occurs when the DTLS connection setup fails

Occurs when repeated attempts to set up the DTLS

connection have failed

Occurs when the DTLS session failed

Occurs to notify the DTLS stack that the session should

aborted

Occurs when the DTLS session failed to be established

Occurs when the join process has failed

Occurs on WTP and AC to download

executable firmware

To reset the connection either due to an error during the

configuration phase or when the WTP determines it needs to

reset Is used when either the ACor WTP tears down the connection

Failure Status

To restarting the WTP after an image downloaded

Occurs when the firmware download process aborts due to

a DTLS errorOccurs when the WTP

does not complete the data check exchange

Occurs when an error has occurred in the DTLS stack

Occurs when the DTLS session has been shut

down

Occurs when repeated attempts to setup the DTLS

connection have failed

Occurs when the CAPWAP reset is complete

Occurs when the DTLS session has been shut

down

Fig.2: Finite State machine of CAPWAP Protocol

Joining  Phase

DTLS  Establishment  Phase

Discovery  Phase  

Discovery  Request  Message

Discovery  Response  Message

ClientHello

HelloVerifyRequest  (with  cookie)

ClientHello  (with  cookie)ServerHello,  Certificate,  ServerHelloDone

Certificate,  ClientKeyExchang,  CertficateVerify,  ChangeCipherSpec,  Finished

ChangeCipherSpec,  Finished

Join  Request

Configuration  Status  Request  

Change  State  Event  Request

Join  Response

Configuration  Status  Response

Change  State  Event  Response

Fig.3: CAPWAP Protocol exchange messages

Fig. 5: The relation between setup latency and increasing number of WTP with 1 AC

25

Sec. The relation between setup latency and increasing number of WTP and one AC is shown in figure 5. The reason of increasing the setup latency is the waiting time between sending each discovery request message which is called Max Dicover Interval.

In figure 6, the average setup latency of using different

number of AC and WTP in a network. The average setup latency of one WTP, with 1 AC is 5.077 Sec., with 2 ACs is 5.080 Sec., with 3 ACs is 5.083 Sec., with 4 ACs is 5.084 Sec. and with 5 ACs is 5.086 Sec. it is clear that there is no much different in setup process with increasing number of AC. This is because Max Discovery Interval where each WTP receives discovery response messages before anoth-er WTP sends its discovery request message.

5.2 Pre-configured WTP setup process In pre-configured case the WTP does not need for dis-

covery phase where each WTP is specified to particular AC. As shown in fig. 7, there is no significant increase in the average latency of setup process by increasing num-ber of WTP or AC. This is because of that each WTP has its own AC. In order to evaluate the setup latency, we

have been simulated 1 AC with different number of WTP. The average setup latency of 50 experiments was between 84 ms and 85 ms.

5.3 Setup Process with Considering Failure States

The possibility of error during setup process is in Dis-cover phase, DTLS Establishment phase and/or Join phase. The error that occurs during Discovery phase is that the WTP does not receive discovery response and discovery interval timer expires with possibility that dis-covery count variable reached equal to the Max discover-ies variable or not.

In DTLS establishment phase the error occurs because of that Wait DTLS timer expires during one of the states or one of the following reasons. in DTLS Setup state –for example- the error occurs due to that AC receives DTLS Establish Fail notification while In Authorize State, the error may be that AC has been unable to authorize the WTP. In DTLS Connect State, the error occurs if DTLS Aborted or AC receives DTLS Authenticate Fail notifica-tion.

Fig. 6: the average setup latency of using different num-ber of AC and WTP in a network and the average setup

latency of 1 AC with 1 WTP

a) Setup latency of 1 AC with 1 WTP b) Setup latency of 1 AC with 6 WTPs c) Setup latency of 1 AC with 12 WTPs

d) Setup latency of 1 AC with 16 WTPs e) Setup latency of 1 AC with 20 WTPs f) Setup latency of 1 AC with 24 WTPs

Fig. 4: The setup process latency of 1 AC with different number of WTP in 50 experiments and its average

Fig. 7: The average setup latency of using Pre-configured WTP

setup process

26

On the other hand, during Join phase the error may be occurs during Join state because of one of six reasons. 1) The WTP or AC receives DTLS notifications; DTLS Aborted, DTLS Reassembly Failure, or DTLS Peer Dis-connect. 2) The WTP receives a join response message with a result code message element containing error. 3) The image identifier provided by the AC in the join re-sponse message differs from the WTP’s currently running firmware version. 4) Wait Join timer expires. 5) The image data start timer expires. 6) The WTP receives an image data response message indicating a failure. If the error occurs during Configure state, the cause is one of the fol-lowing; 1) The WTP receives a Configuration Status Re-sponse message indicating an error. 2) The WTP deter-mines that a reset of the WTP is required, due to the char-acteristics of a new configuration. 3) The AC receives a Change State Event message containing an error for which AC policy does not permit the WTP to provide the Service. 4) The AC Change State Pending Timer expired. In Data Check State, the error happens due to 1) the un-derlying reliable transport’s Retransmit Count counter has reached the Max Retransmit variable. 2) The WTP does not receive the Change State Event Response mes-sage before a CAPWAP retransmission timeout occurs 3) Data Check Timer expires.

Fig. 8 shows the setup latency with considering errors in each phase individually and combined with other phases and compares the latency with normal setup pro-cess. In fig. 8 (a), we considered error in Discovery phase. As we can see the error increased the latency by almost 9 to 14 ms. By increasing number of WTP, the error in DTLS Establishment phase as shown in fig. 8 (b) in-creased the latency by about 30 to 100 ms . In fig. 8 (c) the latency was increased by 30 to 50 ms. Obviously, the error during DTLS Establishment phase cost more latency comparing to the other two phases. In order to evaluate

the failure states comprehensively, we assumed that the error happens in two different phases during the setup process. Fig. 8 (d, e and f) shows that the latency with 24 WTPs and AC increases to almost 4 times.

Fig. 9 shows the latency of setup process with error in the three phases (Discovery, DTLS Establishment and Join) and compares it with the normal setup latency. The increasing of the latency is between 60 to 150 ms com-pared to normal setup process.

6 CONCLUSION Control and Provisioning of Wireless Access Point

(CAPWAP) Working Group had defined standard to manage large scale network. The setup process consists of four phases; Initialization Phase, Discovery Phase, DTLS Establishment Phase and Join Phase.

In this paper we investigate the setup process latency, where we studied three cases; normal setup process, pre-configured WTP setup process and setup process with

Fig. 8: Comparing the average setup latency with considering errors in each phase individually and combined with other phases with the normal set-

up latency

L. Hubert and P. Arabie, “Comparing Partitions,” J. Classification, vol. 2, no. 4, pp. 193-218, Apr. 1985. (Journal or magazine cita-tion)

Fig. 9: the latency of setup process with error in Discovery, DTLS Estab-

lishment and Join phases comparing to the normal setup process

d) Considering error in Discovery and DTLS Establishment phases

f) Considering error in DTLS Establishment

and Join phases

b) Considering error in DTLS Establishment phase

a) Considering error in Discovery phase

c) Considering error in Join phase

e) Considering error in Discovery and Join

phases

27

considering failure states. The main latency contributor in normal setup process is the Discovery phase where it costs from 20% to 98% depending on the number of WTPs. Increasing number of WTP increase the setup pro-cess linearly while increasing number of AC does not have a significant effect.

Important conclusion during the pre-configured setup process was that DTLS Establishment is the more time cost phase. The results also conclusively showed that by pre-configuring the IP address of the AC in the WTPs could bring down the setup latency to 84ms, regardless of the number of APs per AC.

The case of setup process with considering failure states showed that error during negotiation - in worst case - increases the setup latency by almost 12 times. It showed that error during DTLS Establishment cost more time comparing to Discovery and Join phase.

In the next part of this project, we plan to evaluate the association of the mobile user with WTP to know the la-tency components. This is in order to reduce the overall mobile user experience. By using preconfigured AC the overall setup will reduce to a value that can satisfy real time applications.

REFERENCES [1] B. O’Hara al, P. Calhoun and PJ. Kempf, RFC 3990,”Configuration

and Provisioning for Wireless Access Points (CAPWAP), Problem Statement”, IETF, February 2005.

[2] L. Yang, P. Zerfos and E. Sadot, RFC4118, “Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)”, IETF, June 2005.

[3] P. Calhoun, M. Montemurro and D. Stanley,RFC 5415, “Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specifi-cation”, IETF, March 2009.

[4] M. Balfaqih, S. Haseeb, M. H. Mazlan, S. N. Hasnan, O. Mahmoud and A. Hashim, “CAPWAP Status and Design Considerations for Seamless Roaming Support”, International Conference on Computer, Communication and Information Sciences and Engineering (ICCCISE), Kuala Lumpur, Malaysia, August, 2012.

[5] M. H. Mazlan, S. H. Syed Ariffin, M. Balfaqih, S. N. M. Hasnan and S. Haseeb, “Latency Evaluation of Authentication Protocols in Cen-tralized 802.11 Architecture”, presented at “International Conference on Wireless Communications and Applications (ICWCA),Kuala Lumpur, Malaysia, October, 2012.

[6] S. Haseeb, M. H. Mazlan, M. Balfaqih, S. N. Hasnan, M. A. Abdullah and S. Sivanand, “Latency Evaluations in the Setup and Authentica-tion Phases of Centralized WLAN Hotspot Networks”, in Proceedings of 3rd Worl Conferane on Information Technlogy (WCIT), Barcelona, Spain, November, 2012.

[7] X. Cheng, “High density multi-cell wireless network”, bacholer thesis, Liden institute of Advanced Comuter Science (LIACS), 2011.

[8] M. Bernaschi, F. Cacace, G. Iannello, M. Vellucci and L. Vollero, “OpenCAPWAP: an open-source CAPWAP implementation for man-agement and QoS support,” Telecommunication Networking Work-shop on QoS in Multiservice IP Networks, 2008. IT-NEWS 2008. 4th International, vol., no., pp.72-77, 13-15 Feb. 2008.

[9] M. Bernaschi, F. Cacace, G. Iannello, M. Vellucci and L. Vollero, “OpenCAPWAP: An open source CAPWAP implementation for the management and configuration of WiFi hot-spots”, presented at Com-puter Networks, 2009, pp.217-230.

[10] S. Govindan,H. Cheng,ZH. Yao,WH. Zhou and L. Yang, RFC 4564 , “Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)”, IETF, July 2006.