One document matched: draft-calhoun-capwap-problem-statement-00.txt

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, <ftp://ftp.isi.edu/
        internet-drafts/draft-ietf-seamoby-terminology-04.txt>.


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]