Network Working Group P. Calhoun Internet-Draft B. O'Hara Expires: February 11, 2004 Airespace J. Kempf Docomo Labs USA August 13, 2003 CAPWAP Problem Statement draft-calhoun-capwap-problem-statement-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 11, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. Calhoun, et al. Expires February 11, 2004 [Page 1] Internet-Draft CAPWAP Problem Statement August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 Calhoun, et al. Expires February 11, 2004 [Page 2] Internet-Draft CAPWAP Problem Statement August 2003 1. Introduction Historically, wireless LAN (WLAN) deployments have been done using stand-alone 802.11 access points (APs) that perform layer 2 bridging, connected to a layer 2 network for distribution of the packets from 802.11 mobile client devices to other devices, both wired and wireless. This network architecture sufficed for the limited size of 802.11 networks, until recently. As the limitations that have held back the growth of the size of 802.11 networks have been addressed, those networks have begun to increase in size. Some 802.11 networks have grown to include thousands of APs. This growth of individual 802.11 network size has introduced four problems that need to be addressed. Note that the limitations on the scalability of bridging should come as no suprise to the networking community, since similar limitations arose in the early 1980's for wired network bridging during the expansion and interconnection of wired local area networks. Calhoun, et al. Expires February 11, 2004 [Page 3] Internet-Draft CAPWAP Problem Statement August 2003 2. Problem Statement The first problem created by increased size of an 802.11 network is that the individual APs are each IP addressable devices that require management, monitoring, and control. Typical 802.11 networks that provide wireless coverage for all the office space of an installation usually double the number of devices requiring management in that installation, over the wired devices that are already present. This presents a significant additional burden to the network administration resources and is often a hurdle to adoption of wireless technologies. Centralizing the management, monitoring, and control of the APs in a secure manner will reduce the burden of deploying and operating large 802.11 networks. The second problem created by increased size of an 802.11 network is distributing and maintaining a consistent configuration in the many APs. Designing an 802.11 network can involve a significant amount of manual surveying and configuration of the APs. Keeping track of the APs' configuration is an arduous task, as is modifying the configuration of the 802.11 network (because the configuration of a single AP can affect the operation of one or more of its neighbor APs, and so on). An additional part of the AP configuration is maintaining a consistent code base that is running in the APs throughout the network. To minimize the variation of functionality across the 802.11 network and to maximize the interoperability between the APs and the mobile wireless clients, all of the APs should be operating on the same code base. Distributing this code base to the APs securely, under the control of the network administrator, in a consistent fashion, and in a timely fashion, is currently addressed only in proprietary solutions. The third problem with the traditional architecture is that each AP only has visibility into its own cell. The typical AP is a device that stands alone, without much regard for neighboring APs, its effect on those neighbors, or the neighbors effects on itself. This architecture makes it virtually impossible to be able to look at potential attacks (or patterns), and correlate this information with additional information from various other neighboring cells. Centralizing the 802.11 policy management provides a much greater view into the RF network, and allows vendors to add many value added features that directly address security, which is one of the biggest impedements hindering large scale deployments. It is felt that this new centralized architecture allows vendors to provide significant value added features, such as RF management, which are out of scope of this problem statement. A fourth problem has to do with the authorization of access points on Calhoun, et al. Expires February 11, 2004 [Page 4] Internet-Draft CAPWAP Problem Statement August 2003 the network. There is a growing concern among IT managers regarding the unauthorized use of Access Points in their network, creating a serious security threat. It is therefore necessary for access points to be authorized prior to delivering wireless service. Recently, multiple vendors have begun offering proprietary solutions that combine aspects of network switching, centralized control and management, and distributed wireless access to solve the above mentioned problems. Since interoperable solutions allow service providers a broader choice, a standardized, interoperable interface between access points and a centralized controller addressing the above mentioned problems seems desirable. The physical portions of this network system, in currently fielded devices, are one or more 802.11 access points (APs) and one or more central control devices, alternatively described as controllers (or ARs). Ideally, a network designer would be able to choose one or more vendors for the APs and one or more vendors for the central control devices in sufficient numbers to design a network with 802.11 wireless access to meet the designer's requirements. Current implementations are proprietary and not interoperable. Defining an interface between these two layers of the hierarchy, identifying existing standard protocols that can be used to provide the necessary functions to solve the problems described above, and developing one or more new protocols to provide functions not met by existing protocols is necessary to enable multi-vendor interoperability in this new architecture for wireless access. Calhoun, et al. Expires February 11, 2004 [Page 5] Internet-Draft CAPWAP Problem Statement August 2003 3. Security Considerations To the extent of our knowledge, this problem statement does not create any security issues to the Internet. Calhoun, et al. Expires February 11, 2004 [Page 6] Internet-Draft CAPWAP Problem Statement August 2003 References [1] "Mobility Related Terminology", April 2003, . Authors' Addresses Pat R. Calhoun Airespace 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2000 EMail: pcalhoun@airespace.com Bob O'Hara Airespace 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2025 EMail: bob@airespace.com James Kempf Docomo Labs USA 181 Metro Drive, Suite 300 San Jose, CA 95110 Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com Calhoun, et al. Expires February 11, 2004 [Page 7] Internet-Draft CAPWAP Problem Statement August 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Calhoun, et al. Expires February 11, 2004 [Page 8]