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
AbstractHigh 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 dont 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, preconfigured 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.

1 INTRODUCTION

he 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 solutions. The common characteristic of the proposed solutions 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 Access Points (APs) called WTPs [2]. As mentioned in CAPWAP specification [3], the aim of CAPWAP protocol is centralizing authentication and policy functions, shifting 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 different 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 machine of the centralized CAPWAP architecture and explained different configuration scenarios. In section 5, we explored and discussed the results of the association latency. Finally, section 6 concludes the paper and shows our future work.

2
M. Balfaqih is with Mobile Platform Department, MIMOS Berhad Technology Park Malaysia, 57000 Kuala Lumpur, Malaysia and International Islamic University Malaysia (IIUM), Gomback, 50728 Kuala Lumpur, Malaysia 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, Malaysia S. Haseeb, and S. N. Hasnan, are with Mobile Platform Department, MIMOS Berhad Technology Park Malaysia, 57000 Kuala Lumpur, Malaysia.

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 CAPWAP 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-

23

sented some experimental tests to measure the performance of their CAPWAP implementation. The related measurement to our work is the set-up phase measurement for one locally configured AC and one WTP. This means that the WTP had specific AC determined by administrator 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 authentication. 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.

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.

CAPWAP CENTRALIZED ARCHITECTURES

CAPWAP architecture consists of WTPs communicating to AC via CAPWAP protocol (see Fig. 1). According to the centralization level of the control operations, CAPWAP supports two different operational architectures [2]: Local and Split Medium Access Control (MAC). The naming reflects how the 802.11 MAC functions are

CAPWAP PROTOCOL

Fig.1: CAPWAP Centralized Architecture

distributed between AC and WTP.

of WTP with 1 AC

In both architectures, CAPWAP functions entirely left to the AC while the WTP is responsible for physical functions. WTPs in Local MAC Architecture have the whole MAC functionalities including control and management frames. Consequently, Integration and Distribution services 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 centralized because that stations state information remains at WTP and it is processed locally and, in some cases, it is

There are several connectivity options between ACs and a collection of WTPs including direct connection, layer 2 switched connection and layer 3 routed connection. The CAPWAP protocol is defined to be layer 2 technology concerned with management and configuration of the WTP devices, configuration and control of the radio resource 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 CAPWAP 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 Discovery Response message. Based on the capabilities and load in ACs, the WTP will determine to which AC will establish a secure DTLS connection in DTLS establishment phase. Then, the WTP and AC will exchange configuration 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 directly through DTLS Establishment phase. The CAPWAP exchange messages are shown in Figure 3.

24

Occurs when the DTLS connection setup fails Once device initialization is complete To support the CPAWAP discovery process To establish a secure DTLS session with the peer WTP Occurs when Occurs when an incoming DTLS session is being established and the DTLS

Start

Idle

Discovery determines the DTLS

to which AC session to connect failed

DTLS stack needs authorization Autherize Setup

Is Executed by the AC to enable it to listen for new incoming sessions Occurs to notify the DTLS stack that the session should aborted To restarting the WTP after an image downloaded To notify the DTLS stack that the session should be established

Occurs on a WTP when Occurs on the ACs discovery it must restart the thread when the discovery discovery phase processing is complete Occurs when the DTLS session has been shut down Occurs on a WTP when AC discovery fails Silent period to minimize the possibility for Denial-of-Service attack Occurs when repeated attempts to setup the DTLS DTLS connection have failed Occurs when the DTLS session has been shut down

Occurs when repeated attempts to set up the DTLS connection have failed

Sulking

Teardown

Dead

Image Data
Occurs when the firmware download process aborts due to a DTLS error

Reset
Occurs on WTP and AC to download executable firmware

Occurs when the WTP Occurs when an error has does not complete the data occurred in the DTLS stack check exchange

Occur s proces when the join s has failed

Occurs when the CAPWAP reset is complete Occurs when the DTLS session failed to be established

Run
Occurs when the linkage between the control and data channels is established

Data Check

Configure
Occurs when the WTP and AC confirm the configuration Is used by the WTP and the AC to exchange configuration information

Join
Occurs when the DTLS session is successfully established To reset the connection either due to an error during the configuration phase or when the WTP determines it needs to reset

DTLS Connect

Is used when either the AC or WTP tears down the connection

Initialization Phase

Discovery Phase

DTLS Establishment Phase

Join Phase

Failure Status

Fig.2: Finite State machine of CAPWAP Protocol

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.

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 preconfigured 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.

Discovery Phase

Discovery Request Message

Discovery Response Message

DTLS Establishment Phase ClientHello

HelloVerifyRequest (with cookie)

ClientHello (with cookie)

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 increasing 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

ServerHello, Certificate, ServerHelloDone

Certificate, ClientKeyExchang, CertficateVerify, ChangeCipherSpec, Finished

ChangeCipherSpec, Finished
Joining Phase

Join Request

Join Response
Configuration Status Request

Configuration Status Response

Change State Event Request 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

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

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

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

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

Fig. 6: the average setup latency of using different number of AC and WTP in a network and the average setup latency of 1 AC with 1 WTP 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 another WTP sends its discovery request message.

5.2 Pre-configured WTP setup process In pre-configured case the WTP does not need for discovery 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 number of WTP or AC. This is because of that each WTP has its own AC. In order to evaluate the setup latency, we

5.3 Setup Process with Considering Failure States The possibility of error during setup process is in Discover 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 discovery count variable reached equal to the Max discoveries 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 notification.

26

a) Considering error in Discovery phase

b) Considering error in DTLS Establishment phase

c) Considering error in Join phase

f) Considering error in DTLS Establishment and Join phases

d) Considering error in Discovery and DTLS Establishment phases

e) Considering error in Discovery and Join phases

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

On the other hand, during Join phase the error may be the failure states comprehensively, we assumed that the L. Hubert and P. Arabie, Comparing Partitions, J. Classification, vol. 2, no. 4, pp. 193-218, Apr. 1985. (Journal orthe setup citaoccurs during Join state because of one of six reasons. 1) error happens in two different phases during magazine tion) The WTP or AC receives DTLS notifications; DTLS process. Fig. 8 (d, e and f) shows that the latency with 24 Aborted, DTLS Reassembly Failure, or DTLS Peer Dis- WTPs and AC increases to almost 4 times. connect. 2) The WTP receives a join response message Fig. 9 shows the latency of setup process with error in with a result code message element containing error. 3) the three phases (Discovery, DTLS Establishment and The image identifier provided by the AC in the join re- Join) and compares it with the normal setup latency. The sponse message differs from the WTPs currently running increasing of the latency is between 60 to 150 ms comfirmware version. 4) Wait Join timer expires. 5) The image pared to normal setup process. 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 following; 1) The WTP receives a Configuration Status Response message indicating an error. 2) The WTP determines that a reset of the WTP is required, due to the characteristics 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 underlying reliable transports Retransmit Count counter has reached the Max Retransmit variable. 2) The WTP does not receive the Change State Event Response message before a CAPWAP retransmission timeout occurs 3) Fig. 9: the latency of setup process with error in Discovery, DTLS EstabData Check Timer expires. lishment and Join phases comparing to the normal setup process 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- 6 CONCLUSION cess. In fig. 8 (a), we considered error in Discovery phase. Control and Provisioning of Wireless Access Point As we can see the error increased the latency by almost 9 (CAPWAP) Working Group had defined standard to to 14 ms. By increasing number of WTP, the error in manage large scale network. The setup process consists of DTLS Establishment phase as shown in fig. 8 (b) in- four phases; Initialization Phase, Discovery Phase, DTLS creased the latency by about 30 to 100 ms . In fig. 8 (c) the Establishment Phase and Join Phase. latency was increased by 30 to 50 ms. Obviously, the error In this paper we investigate the setup process latency, during DTLS Establishment phase cost more latency where we studied three cases; normal setup process, precomparing to the other two phases. In order to evaluate configured WTP setup process and setup process with

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 process 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 latency 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. OHara 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 Specification, 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 Centralized 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 Authentication 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 management and QoS support, Telecommunication Networking Workshop 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 Computer 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.