[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mani-capwap-arch) 00 01 02 03 04 05 06 RFC 4118

CAPWAP Working Group                                    L. Yang (Editor)
Internet-Draft                                               Intel Corp.
Expires: January 26, 2005                                      P. Zerfos
                                                                    UCLA
                                                                E. Sadot
                                                                   Avaya
                                                           July 28, 2004


 Architecture Taxonomy for Control and Provisioning of Wireless Access
                             Points(CAPWAP)
                       draft-ietf-capwap-arch-04

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 January 26, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document provides a taxonomy of the architectures employed in
   the existing IEEE 802.11 products in the market, by analyzing WLAN
   (Wireless LAN) functions and services and describing the different



Yang (Editor), et al.    Expires January 26, 2005               [Page 1]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   variants in distributing these functions and services among the
   architectural entities.  This taxonomy may be utilized by the IEEE
   802.11 Working Group as input to their task of defining the Access
   Point (AP) functional architecture.

Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Conventions used in this document  . . . . . . . . . . . .  3
     1.2   IEEE 802.11 Definitions  . . . . . . . . . . . . . . . . .  3
     1.3   Terminology Used in this Document  . . . . . . . . . . . .  4
     1.4   Terminology Used Historically but Not Recommended  . . . .  6
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.1   IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . . .  7
     2.2   CAPWAP Functions . . . . . . . . . . . . . . . . . . . . .  9
     2.3   WLAN Architecture Proliferation  . . . . . . . . . . . . . 10
     2.4   Taxonomy Methodology and Document Organization . . . . . . 12
   3.  Autonomous Architecture  . . . . . . . . . . . . . . . . . . . 14
     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.2   Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.  Centralized WLAN Architecture  . . . . . . . . . . . . . . . . 16
     4.1   Interconnection between WTPs and ACs . . . . . . . . . . . 17
     4.2   Overview of Three Centralized WLAN Architecture
           Variants . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.3   Local MAC  . . . . . . . . . . . . . . . . . . . . . . . . 20
     4.4   Split MAC  . . . . . . . . . . . . . . . . . . . . . . . . 23
     4.5   Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . 28
     4.6   Comparisons of Local MAC, Split MAC and Remote MAC . . . . 29
     4.7   Communication Interface between WTPs and ACs . . . . . . . 30
     4.8   Security . . . . . . . . . . . . . . . . . . . . . . . . . 31
       4.8.1   Client Data Security . . . . . . . . . . . . . . . . . 31
       4.8.2   Security of control channel between the WTP and AC . . 31
   5.  Distributed Mesh Architecture  . . . . . . . . . . . . . . . . 33
     5.1   Security . . . . . . . . . . . . . . . . . . . . . . . . . 34
   6.  Summary and Conclusions  . . . . . . . . . . . . . . . . . . . 35
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 38
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
       Intellectual Property and Copyright Statements . . . . . . . . 42











Yang (Editor), et al.    Expires January 26, 2005               [Page 2]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


1.  Definitions

1.1  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

1.2  IEEE 802.11 Definitions

   Station (STA): Any device that contains an IEEE 802.11 conformant
   medium access control (MAC) and physical layer (PHY) interface to the
   wireless medium (WM).

   Access Point (AP): Any entity that has station functionality and
   provides access to the distribution services, via the wireless medium
   (WM) for associated stations.

   Basic Service Set (BSS): A set of stations controlled by a single
   coordination function.

   Station Service (SS): The set of services that support transport of
   medium access control (MAC) service data units (MSDUs) between
   stations within a basic service set (BSS).

   Distribution System (DS): A system used to interconnect a set of
   basic service sets (BSSs) and integrated local area networks (LANs)
   to create an extended service set (ESS).

   Extended Service Set (ESS): A set of one or more interconnected basic
   service sets (BSSs) with the same SSID and integrated local area
   networks (LANs) that appears as a single BSS to the logical link
   control layer at any station associated with one of those BSSs.

   Portal: The logical point at which medium access control (MAC)
   service data units (MSDUs) from a non-IEEE 802.11 local area network
   (LAN) enter the distribution system (DS) of an extended service set
   (ESS).

   Distribution System Service (DSS): The set of services provided by
   the distribution system (DS) that enable the medium access control
   (MAC) to transport MAC service data units (MSDUs) between stations
   that are not in direct communication with each other over a single
   instance of the wireless medium (WM).  These services include
   transport of MSDUs between the access points (APs) of basic service
   sets (BSSs) within an extended service set (ESS), transport of MSDUs
   between portals and BSSs within an ESS, and transport of MSDUs
   between stations in the same BSS in cases where the MSDU has a



Yang (Editor), et al.    Expires January 26, 2005               [Page 3]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   multicast or broadcast destination address or where the destination
   is an individual address, but the station sending the MSDU chooses to
   involve DSS.  DSSs are provided between pairs of IEEE 802.11 MACs.

   Integration: The service that enables delivery of medium access
   control (MAC) service data units (MSDUs) between the distribution
   system (DS) and an existing, non-IEEE 802.11 local area network (via
   a portal).

   Distribution: The service that, by using association information,
   delivers medium access control (MAC) service data units (MSDUs)
   within the distribution system (DS).

1.3  Terminology Used in this Document

   One of the motivations in defining new terminology in this document
   is to clarify some of the ambiguity and confusion surrounding some
   conventional terms.  One of such terms is "Access Point (AP)".
   Typically ,when people talk about "AP", they refer to the physical
   entity (box) that has an antenna, implements 802.11 PHY and receives/
   transmits the station (STA) traffic over the air.  However, the
   802.11 Standard [1] describes the AP mostly as a logical entity that
   implements a set of logical services so that station traffic can be
   received and transmitted effectively over the air.  So when people
   talk about "AP functions", they usually mean the logical functions
   the whole WLAN access networks support, not just the part of the
   functions supported by the physical entity (box) that the STAs
   communicate to directly.  Such confusion can be especially profound
   when the logical functions is implemented across a network instead of
   within a single physical entity.  So to avoid further confusion, we
   define the following terminology used in this document:

   CAPWAP: Control and Provisioning of Wireless Access Points.

   IEEE 802.11 WLAN Functions: a set of logical functions defined by
   IEEE 802.11 Working Group, including all the MAC services, Station
   Services, and Distribution Services.  These logical functions are
   required to be implemented in the IEEE 802.11 Wireless LAN (WLAN)
   access networks by the IEEE 802.11 Standard[1].

   CAPWAP Functions: a set of WLAN control functions that are not
   directly defined by IEEE 802.11 Standards, but deemed essential for
   effective control, configuration and management of 802.11 WLAN access
   networks.

   Wireless Termination Point (WTP): the physical or network entity that
   contains RF antenna and 802.11 PHY to transmit and receive station
   traffics for the IEEE 802.11 WLAN access networks.  Such physical



Yang (Editor), et al.    Expires January 26, 2005               [Page 4]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   entities are often called "Access Points" (AP) previously, but "AP"
   can also be used to refer to logical entity that implements 802.11
   services.  So we recommend using "WTP" instead to explicitly refer to
   the physical entity.

   Autonomous WLAN Architecture: the WLAN access network architecture
   family in which all the logical functions, including both IEEE 802.11
   and CAPWAP functions (wherever applicable), are implemented within
   each Wireless Termination Point (WTP) in the network.  The WTPs in
   such networks are also called standalone APs, or fat APs, because
   these devices implement the full set of functions that enable the
   devices to operate without any other support from the network.

   Centralized WLAN Architecture: the WLAN access network architecture
   family in which the logical functions, including both IEEE 802.11 and
   CAPWAP functions (wherever applicable), are implemented across a
   hierarchy of network entities.  At the low level of such hierarchy
   are the WTPs while at the higher level are the Access Controllers
   (ACs), which are responsible to control, configure and manage the
   entire WLAN access networks.

   Distributed WLAN Architecture: the WLAN access network architecture
   family in which some of the control functions (e.g., CAPWAP
   functions) are implemented across a distributed network consisting of
   peer entities.  A wireless mesh network can be considered as an
   example of such an architecture.

   Access Controller (AC): The network entity in the Centralized WLAN
   architectures that provide WTPs access to the centralized
   hierarchical network infrastructure, either in the data plane,
   control plane, or management plane, or a combination therein.

   Standalone WTP: referred to the WTP in Autonomous WLAN Architecture.

   Controlled WTP: referred to the WTP in Centralized WLAN Architecture.

   Split MAC Architecture: A sub-group of the Centralized WLAN
   Architecture, with the characteristic that WTPs in such WLAN access
   networks only implement the delay sensitive MAC services  (including
   all control frames and some management frames) for IEEE 802.11, while
   tunneling all the remaining management and data frames to AC for
   centralized processing.  The IEEE 802.11 MAC as defined by IEEE
   802.11 Standards in [1] is effectively split between the WTP and AC.

   Remote MAC Architecture: A sub-group of the Centralized WLAN
   Architecture, where the entire set of 802.11 MAC functions (including
   delay-sensitive functions) are implemented at the AC.  The WTP
   terminates the 802.11 PHY functions.



Yang (Editor), et al.    Expires January 26, 2005               [Page 5]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   Local MAC Architecture: A sub-group of the Centralized WLAN
   Architecture, where the majority or entire set of 802.11 MAC
   functions (including most of the 802.11 management frame processing)
   are implemented at the WTP.  Therefore, the 802.11 MAC stays intact
   and local in the WTP, along with PHY.

1.4  Terminology Used Historically but Not Recommended

   While some terminology has been used by vendors historically to
   describe "Access Points", we recommend to defer its use, in order to
   avoid further confusion.  A list of such terms and the recommended
   new terminology are provided below:

   Split WLAN Architecture: use Centralized WLAN Architecture.

   Hierarchical WLAN Architecture: use Centralized WLAN Architecture.

   Standalone Access Point: use WTP or Standalone WTP.

   Fat Access Point: the same as Standalone Access Point.  Use WTP or
   Standalone WTP.

   Thin Access Point: use WTP, or Controlled WTP.

   Light weight Access Point: the same as Thin Access Point, use WTP, or
   Controlled WTP.

   Split AP Architecture: use Local MAC Architecture.

   Antenna AP Architecture: use Remote MAC Architecture.





















Yang (Editor), et al.    Expires January 26, 2005               [Page 6]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


2.  Introduction

   As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale
   deployment of WLAN networks is highlighting certain technical
   challenges.  As outlined in [2], management, monitoring and control
   of large number of Access Points (APs) in the network may prove to be
   a significant network administration burden.  Distributing and
   maintaining a consistent configuration throughout the entire set of
   APs in the WLAN is a difficult task.  The shared and dynamic nature
   of the wireless medium also demands effective coordination among the
   APs to minimize radio interference and maximize network performance.
   Network security issues, which have always been a concern in WLAN's,
   present even more challenges in large deployments and new
   architectures.

   Recently many vendors have begun offering partially proprietary
   solutions to address some or all of the above mentioned problems.
   Since interoperable solutions allow for a broader choice, a
   standardized interoperable solution addressing the aforementioned
   problems is desirable.  As the first step toward establishing
   interoperability in the market place, this document attempts to
   provide a taxonomy of the architectures employed in existing WLAN
   products.  We hope to provide a cohesive understanding of the market
   practices for the standard bodies involved (including the IETF and
   IEEE 802.11).  This document may be reviewed and utilized by the IEEE
   802.11 Working Group as input to their task of defining the
   functional architecture of an access point.

2.1  IEEE 802.11 WLAN Functions

   The IEEE 802.11 specifications are wireless standards that specify an
   "over-the-air" interface between a wireless client (STA) and an
   Access Point (AP), and also among wireless clients.  802.11 also
   describes how mobile devices can associate together into a basic
   service set (BSS).  A BSS is identified by a basic service set
   identifier (BSSID) or name.  The WLAN architecture can be considered
   as a type of 'cell' architecture where each cell is the Basic Service
   Set (BSS) and each BSS is controlled by the Access Point (AP).  When
   more than one AP are connected via a broadcast layer 2 network and
   all are using the same SSID, an extended service set (ESS) is
   created.

   The architectural component used to interconnect BSSs is the
   distribution system (DS).  An access point (AP) is a STA that
   provides access to the DS by providing DS services in addition to
   acting as a STA.  Another logical architectural component -- portal
   -- is introduced to integrate the IEEE 802.11 architecture with a
   traditional wired LAN.  It is possible for one device to offer both



Yang (Editor), et al.    Expires January 26, 2005               [Page 7]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   the functions of an AP and a portal.

   IEEE 802.11 explicitly does not specify the details of DS
   implementations.  Instead, the 802.11 standard defines services that
   provide the functions that the LLC layer requires for sending MAC
   Service Data Units (MSDUs) between two entities on the network.
   These services can be classified into two categories: the station
   service (SS) and the distribution system service (DSS).  Both
   categories of service are used by the IEEE 802.11 MAC sublayer.
   Station services consist of the following four services:
   o  Authentication: The service used to establish the identity of one
      station as a member of the set of stations authorized to associate
      with another station.
   o  Deauthentication: The service that voids an existing
      authentication relationship.
   o  Confidentiality: The service used to prevent the content of
      messages from being read by other than the intended recipients.
   o  MSDU Delivery: The service to deliver the MAC service data unit
      (MSDU) for the Stations.

   Distribution system services consist of the following five services:
   o  Association: The service used to establish access point/station
      (AP/STA) mapping and enable STA invocation of the distribution
      system services.
   o  Disassociation: The service that removes an existing association.
   o  Reassociation: The service that enables an established association
      [between access point (AP) and station (STA)] to be transferred
      from one AP to another (or the same) AP.
   o  Distribution: The service that provides MSDU forwarding by APs for
      the STAs associated with them.  MSDUs can be either forwarded to
      the Wireless destination or to the Wired (Ethernet) destination
      (or both) using the "Distribution System" concept of 802.11.
   o  Integration: The service that is used to translate the MSDU
      received from the Distribution System to a non-802.11 format and
      vice versa.  Any MSDU that is received from the DS invokes the
      "Integration" services of the DSS before the 'Distribution'
      services are invoked.  The point of connection of the DS to the
      wired LAN is termed as 'portal'.

   Apart from these services the IEEE 802.11 also defines additional MAC
   services that must be implemented by the APs in the WLAN.  For
   example:
   o  Beacon Generation
   o  Probe Response/Transmission
   o  Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
   o  Synchronization
   o  Retransmissions




Yang (Editor), et al.    Expires January 26, 2005               [Page 8]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   o  Transmission Rate Adaptation
   o  Privacy: 802.11 Encryption/Decryption

   In addition to the services offered by the 802.11, the IEEE 802.11 WG
   is also developing technologies to support Quality of Service
   (802.11e), Security Algorithms (802.11i), Inter-AP Protocol (IAPP, or
   802.11F -- recommended practice) to update APs when a STA roams from
   one BSS to the other, Radio Resource Management (802.11k) etc.

   IEEE 802.11 does not exactly specify how all these functions get
   implemented, nor does it specify that these functions be implemented
   all in one physical device (e.g., the WTP).  Conceptually, all it
   requires is that the WTPs and the rest of the DS together implements
   all these services.  Typically, vendors implement not only the
   services defined in the IEEE 802.11 standard, they also implement a
   variety of value-added services or functions, like load balancing
   support, QoS, station mobility support, rogue AP detection, etc.
   What will become clear from the rest of this document is that vendors
   do take advantage of the flexibility in the 802.11 architecture, and
   have come up with many different flavors of architectures and
   implementations of the WLAN services.

   Because many vendors choose to implement these WLAN services across
   multiple network elements, we want to make a clear distinction
   between the logical WLAN access network functions, and the individual
   physical devices.  Each of these physical devices may implement only
   part of the logical functions.  But the DS including all the physical
   devices as a whole implements all, or most of the functions.

2.2  CAPWAP Functions

   In order to address the four problems identified in the [2]
   (management, consistent configuration, RF control, security)
   additional functions, especially in the control plane and management
   plane, are typically offered by vendors to assist better coordination
   and control across the entire ESS network.  Such functions are
   especially important when the IEEE 802.11 WLAN functions are
   implemented across a large scale network of multiple entities,
   instead of within a single entity.  Such functions are:
   o  RF monitoring, like Radar detection, noise and interference
      detection and measurement.
   o  RF configuration, e.g., for retransmission, channel selection,
      transmission power adjustment, etc.
   o  WTP configuration, e.g., for SSID, etc.
   o  WTP firmware loading, e.g., automatic loading and upgrading of WTP
      firmware for network wide consistency.
   o  Network-wide STA state information database, including the
      information needed to support value-added services, such as



Yang (Editor), et al.    Expires January 26, 2005               [Page 9]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


      mobility, load balancing etc.
   o  Mutual authentication between network entities, e.g., for AC and
      WTP authentication in a Centralized WLAN Architecture.

   The services listed are concerned with configuration and control of
   the radio resource ('RF Monitoring' and 'RF Configuration'),
   management and configuration of the WTP device ('WTP Configuration',
   'WTP Firmware upgrade'), and also security regarding the registration
   of the WTP to an AC ('AC/WTP mutual authentication').  Moreover, the
   device from which other services such as mobility management across
   subnets, and load balancing can obtain state information regarding
   the STA(s) associated with the wireless network, is also reported as
   a service ('STA state info database').

   The above list of CAPWAP functions does not attempt to be an
   exhaustive enumeration of all additional services offered by vendors.
   Instead, we included only those functions that are commonly
   represented in the survey data, and are also pertinent to the
   understanding of the central problem of interoperability.

   Most of these functions are not explicitly specified by IEEE 802.11,
   but some of the functions are.  For example, control and management
   of the radio-related functions of an AP are described implicitly in
   the MIB, such as:
   o  Channel Assignment
   o  Transmit Power Control
   o  Radio Resource Measurement (work currently under way in IEEE
      802.11k)

   The 802.11h [6] amendment to the base 802.11 standard specifies the
   operation of a MAC management protocol to accomplish the requirements
   of some regulatory bodies (principally in Europe, but expanding to
   others) in these areas:
   o  RADAR detection
   o  Transmit Power Control
   o  Dynamic Channel Selection

2.3  WLAN Architecture Proliferation

   This document provides a taxonomy of the WLAN network architectures
   developed by the vendor community in an attempt to address some or
   all of the problems outlined in  [2].  As the IEEE 802.11 standard
   purposely avoids to specify the details of DS implementations,
   different architectures have proliferated in the market.  While all
   these different architectures conform to the IEEE 802.11 standard as
   a whole, their individual functional components are not standardized.
   The interfaces between the network architecture components are mostly
   proprietary, and there is no guarantee of cross-vendor



Yang (Editor), et al.    Expires January 26, 2005              [Page 10]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   interoperability of products, even within the same architecture
   family.

   In order to achieve interoperability in the market place, the IETF
   CAPWAP working group is taking on the first logical task of
   documenting both the functions and the network architectures offered
   by the existing WLAN vendors today.  The end result of this task is
   this taxonomy document.

   After analyzing more than a dozen different vendors' architectures,
   we believe that the existing 802.11 WLAN access network architectures
   can be broadly categorized into three distinct families, based on the
   characteristics of the Distribution Systems that are employed to
   provide the 802.11 functions.
   o  Autonomous WLAN Architecture: The first architecture family is the
      traditional autonomous WLAN architecture, where each WTP is a
      single physical device that implements all the 802.11 services,
      including both the distribution and integration services, and the
      portal function.  Such an AP architecture is called Autonomous
      WLAN Architecture because each WTP is autonomous in its
      functionality, and no explicit 802.11 support is needed from
      devices other than the WTP.  The WTP in such architecture is
      typically configured and controlled individually, and can be
      monitored and managed via typical network management protocols
      like SNMP.  The WTPs in this architecture are the traditional
      Access Points most people are familiar with.  Sometimes such WTPs
      are referred to as "Fat APs" or "Standalone APs".
   o  Centralized WLAN Architecture: The second WLAN architecture family
      is an emerging hierarchical architecture utilizing one or more
      centralized controllers for managing a large number of WTP
      devices.  The centralized controller is commonly referred to as an
      Access Controller (AC), whose main function is to manage, control
      and configure the WTP devices that are present in the network.  In
      addition to being a centralized entity for the control and
      management plane, it may also become a natural aggregation point
      for the data plane, since it is typically situated in a
      centralized location in the wireless access network.  The AC is
      often co-located with an L2 bridge, a switch, or an L3 router, and
      hence may be referred to as Access Bridge, or Access Router in
      those particular cases.  Therefore, an Access Controller could be
      either an L3 or L2 device, and Access Controller is the generic
      terminology we use throughout this document.  It is also possible
      that multiple ACs are present in a network for purposes of
      redundancy, load balancing, etc.  This architecture family has
      several distinct characteristics that are worth noting.  First of
      all, the hierarchical architecture and the centralized AC afford
      much better manageability for the large scale networks.  Secondly,
      since the IEEE 802.11 functions and the CAPWAP control functions



Yang (Editor), et al.    Expires January 26, 2005              [Page 11]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


      are provided by the WTP devices and the AC together, the WTP
      devices themselves may not implement the full 802.11 functions as
      defined in the standards any more.  Therefore, it can be said that
      the full 802.11 functions are implemented across multiple physical
      network devices, namely, the WTPs and ACs.  Since the WTP devices
      only implement a portion of the functions that standalone APs
      implement, WTP devices in this architecture are sometimes referred
      to as light weight or thin APs by some vendors.
   o  Distributed WLAN Architecture: The third emerging WLAN
      architecture family is the distributed architecture in which the
      participating wireless nodes are capable of forming a distributed
      network among themselves, via either wired or wireless media.  A
      wireless mesh network is one example in the distributed
      architecture family,  where the nodes themselves form a mesh
      network, and connect with neighboring mesh nodes via 802.11
      wireless links.  Some of these nodes also have wired Ethernet
      connections, acting as gateways to the external network.

2.4  Taxonomy Methodology and Document Organization

   Before the IETF CAPWAP working group started documenting the various
   WLAN architectures, we conducted an open survey soliciting WLAN
   architecture description contributions via the IETF CAPWAP mailing
   list.  We provided the interested parties with a common template that
   included a number of questions about their WLAN architectures.  We
   received 16 contributions in the form of short text descriptions
   answering those questions..  15 of them are from WLAN vendors
   (AireSpace, Aruba, Avaya, Chantry Networks, Cisco, Cranite Systems,
   Extreme Networks, Intoto, Janusys Networks, Nortel, Panasonic,
   Trapeze, Instant802, Strix Systems, Symbol) and one from academic
   research community (UCLA).  Out of the 16 contributions, one
   described an Autonomous WLAN Architecture, three Distributed Mesh
   Architectures, while the rest twelve entries represent architectures
   that fall into the family of Centralized WLAN Architecture.

   The main objective of this survey is to identify the general
   categories and trends in WLAN architecture evolution, discover their
   common characteristics, determine what is performed differently among
   them, and why.  In order to represent the survey data in a compact
   format, a "Functional Distribution Matrix" is used in this document,
   mostly in the Centralized WLAN architecture section, to tabulate the
   various services and functions in the vendors' offerings.  These
   services and functions are classified into three main categories:
   o  Architecture Considerations: the choice of the connectivity
      between the AC and the WTP; the design choices regarding the
      physical device on which processing of management, control, and
      data frames of the 802.11 takes place.




Yang (Editor), et al.    Expires January 26, 2005              [Page 12]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   o  802.11 Functions: as described in Section 2.1.
   o  CAPWAP Functions: as described in Section 2.2.

   For each one of these categories, the mapping of each individual
   function to network entities implemented by each vendor is shown in
   tabular form.  The rows in the Functional Distribution Matrix
   represent the individual functions that are organized into the above
   mentioned three categories, while each column of the Matrix
   represents one vendor's architecture offering in the survey data.
   See Figure 7 as an example of the Matrix.

   This Functional Distribution Matrix is intended for the sole purpose
   of organizing the architecture taxonomy data, and represents the
   contributors' view of their architectures, from an engineering
   perspective.  It does not necessarily imply an existing product,
   shipping or not, nor an intent by the vendor to build such a product.

   The rest of this document is organized around the three broad WLAN
   architecture families that were introduced in Section 2.3.  Each
   architecture family is discussed in a separate section.  The section
   on Centralized Architecture contains more in-depth details than the
   other two families, largely due to the large number of the survey
   data (11 out of 16) collected falling into the Centralized
   Architecture category.

   Summary and conclusions are provided at the end of the document to
   highlight the basic findings from this taxonomy exercise.
























Yang (Editor), et al.    Expires January 26, 2005              [Page 13]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


3.  Autonomous Architecture

3.1  Overview

   Figure 1 shows an example network of the Autonomous WLAN
   Architecture.  This architecture implements all the 802.11
   functionality in a single physical device, the Wireless Termination
   Point (WTP).  A common embodiment of this architecture is a WTP that
   translates between 802.11 frames to/from its radio interface and
   802.3 frames to/from an Ethernet interface.  An 802.3 infrastructure
   that interconnects the Ethernet interfaces of different WTPs together
   provides the distribution system.  It can also provide portals for
   integrated 802.3 LAN segments.

       +---------------+     +---------------+     +---------------+
       |  802.11 BSS 1 |     |  802.11 BSS 2 |     |  802.11 BSS 3 |
       |  ...          |     |  ...          |     |  ...          |
       |    +-----+    |     |    +-----+    |     |    +-----+    |
       +----| WTP |----+     +----| WTP |----+     +----| WTP |----+
            +--+--+               +--+--+               +--+--+
               |Ethernet             |                     |
               +------------------+  |  +------------------+
                                  |  |  |
                              +---+--+--+---+
                              | Ethernet    |
     802.3 LAN  --------------+ Switch      +-------------- 802.3 LAN
     segment 1                |             |               segment 2
                              +------+------+

           Figure 1: Example of Autonomous WLAN Architecture

   A single physical WTP can optionally be provisioned as multiple
   virtual WTPs by supporting multiple SSIDs to which 802.11 clients may
   associate.  In some cases, this will also involve putting a
   corresponding 802.1Q VLAN tag on each packet forwarded to the
   Ethernet infrastructure and removal of 802.1Q tags prior to
   forwarding the packets to the wireless medium.

   The scope of the ESS(s) created by interconnecting the WTPs will be
   confined by the constraints imposed by the Ethernet infrastructure.

   Authentication of 802.11 clients may be performed locally by the WTP
   or by using a centralized authentication server.

3.2  Security

   Since both the 802.11 and CAPWAP functionality is tightly integrated
   into a single physical device, the security issues with this



Yang (Editor), et al.    Expires January 26, 2005              [Page 14]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   architecture are confined to the WTP.  There are no extra
   implications from the client authentication and encryption/decryption
   perspective as the AAA interface is integrated into the WTP, so is
   the key generation mechanisms required for 802.11i encryption/
   decryption.

   One of the security issues in this architecture is the need for
   mutual authentication between the WTP and the Ethernet
   infrastructure.  This can be ensured by existing mechanisms such as
   802.1x between the WTP and the Ethernet switch it plugs into.
   Another critical security issue with this architecture is the very
   fact that the WTP is most likely not under lock and key, but does
   contain secret information in order to communicate with the backend
   systems, such as AAA, SNMP, etc.  Due to the common management method
   used by IT personnel of pushing a "template" to all devices, theft of
   such a device would potentially compromise the wired network.



































Yang (Editor), et al.    Expires January 26, 2005              [Page 15]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


4.  Centralized WLAN Architecture

   Centralized WLAN Architecture is an emerging architecture family in
   the WLAN market.  Contrary to the Autonomous WLAN Architecture where
   the 802.11 functions and network control functions are all
   implemented within each Wireless Termination Point (WTP), the
   Centralized WLAN Architecture employs one or multiple centralized
   controllers, called Access Controller(s), to enable network-wide
   monitoring, improve management scalability, and facilitate dynamic
   configurability.

   The following figure shows schematically the Centralized WLAN
   Architecture network diagram, where the Access Controller (AC)
   connects to multiple Wireless Termination Points (WTPs) via a certain
   interconnection.  This can be either a direct connection, an
   L2-switched, or an L3-routed network as described in Section 4.1.
   The AC exchanges configuration and control information with the WTP
   devices, allowing the management of the network from a centralized
   point.  Also, designs of the Centralized WLAN Architecture family do
   not presume (as the diagram might suggest to some readers) that the
   AC necessarily intercedes in the data plane to/from the WTP(s).  More
   details are provided later in this section.

    +---------------+     +---------------+     +---------------+
    |  802.11 BSS 1 |     |  802.11 BSS 2 |     |  802.11 BSS 3 |
    |  ...          |     |  ...          |     |  ...          |
    |    +-------+  |     |    +-------+  |     |    +-------+  |
    +----|  WTP  |--+     +----|  WTP  |--+     +----|  WTP  |--+
         +---+---+             +---+---+             +---+---+
             |                     |                     |
             +------------------+  |   +-----------------+
                                |  |...|
                           +----+--+---+--------+
                           |  Interconnection   |
                           +-------+------------+
                                   |
                                   |
                             +-----+----+
                             |    AC    |
                             +----------+

            Figure 2: Centralized WLAN Architecture Diagram

   In the diagram above, the AC is shown as a single physical entity
   that provides all of the CAPWAP functions listed in section 2.2.  But
   that may not be always the case.  Closer examination of the functions
   reveals that their different resource requirements (e.g.  CPU,
   memory, storage) may lend themselves to being distributed across



Yang (Editor), et al.    Expires January 26, 2005              [Page 16]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   different devices.  For instance, complex radio control algorithms
   can be CPU intensive.  Storing and downloading images and
   configurations can be storage intensive.  Control plane services like
   mobility and load balancing may be better supported in network
   devices that may be lacking in one or more of these resources.  The
   network entity marked 'AC' in the diagram above should accordingly be
   thought of as a multiplicity of logical functions, and not
   necessarily as a single physical device.  The AC(s) may also choose
   to implement some of the control functions locally while providing
   interfaces to access other global network management functions which
   are typically implemented on separate boxes, such as a SNMP Network
   Management Station and an AAA backend server (e.g., Radius
   Authentication Server).

4.1  Interconnection between WTPs and ACs

   There are several connectivity options which can be considered
   between the AC(s) and the WTPs, including direct connection, L2
   switched connection, or L3 routed connection, as shown in Figure 3,
   Figure 4, and Figure 5.

                             -------+------ LAN
                                    |
                            +-------+-------+
                            |      AC       |
                            +----+-----+----+
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | WTP |       | WTP |
                          +--+--+       +--+--+

                      Figure 3: Directly Connected

















Yang (Editor), et al.    Expires January 26, 2005              [Page 17]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


                             -------+------ LAN
                                    |
                            +-------+-------+
                            |      AC       |
                            +----+-----+----+
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+    +-----+-----+
                          | WTP |    |   Switch  |
                          +--+--+    +---+-----+-+
                                         |     |
                                      +-----+  +-----+
                                      | WTP |  | WTP |
                                      +-----+  +-----+

                     Figure 4: Switched Connections


                            +-------+-------+
                            |      AC       |
                            +-------+-------+
                                    |
                            --------+------ LAN
                                    |
                            +-------+-------+
                            |     router    |
                            +-------+-------+
                                    |
                            -----+--+--+--- LAN
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | WTP |       |  WTP|
                          +--+--+       +--+--+

                      Figure 5: Routed Connections


4.2  Overview of Three Centralized WLAN Architecture Variants

   While dynamic and consistent network management is one of the primary
   motivations for the Centralized Architecture, the survey data from
   vendors also shows that different varieties of this architecture
   family have emerged to meet a complex set of different requirements
   for possibly different deployment scenarios.  This is also a direct
   result of the inherent flexibility in the 802.11 standard [1]



Yang (Editor), et al.    Expires January 26, 2005              [Page 18]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   regarding the implementation of the logical functions that are
   broadly described under the term "Access Point (AP)".  As there is no
   standard mapping of these AP functions to physical network entities,
   several design choices have been made by vendors that offer related
   products.  Moreover, the increased demand for monitoring and
   consistent configuration of large wireless networks has resulted into
   a set of 'value-added' services provided by the various vendors, most
   of which share common design properties and service goals.

   In the following, we describe the three main variants observed from
   the survey data within the family of Centralized WLAN Architecture,
   namely the Local MAC, Split MAC,  and Remote MAC approaches.  For
   each approach we provide the mapping characteristics of the various
   functions into the network entities from each vendor.  The naming of
   Local MAC, Split MAC and Remote MAC reflects how the functions, and
   especially the 802.11 MAC functions, are mapped onto the network
   entities.  Local MAC indicates that the MAC functions stay intact and
   local to WTPs, while Remote MAC denotes that the MAC is moved away
   from the WTP to a remote AC in the network.  Split MAC shows the MAC
   being split between the WTPs and ACs, largely along the line of real
   time sensitivity.  Typically, Split MAC vendors choose to put real
   time functions on the WTPs while leaving non-real time functions to
   the ACs.  802.11 does not clearly specify what constitutes real-time
   functions versus non-real-time functions, and so there does not exist
   such a clear and definitive line among them.  As shown in Section
   4.4, each vendor has its own interpretation on this and so there
   exists some discrepancy in where to draw the line between real time
   However, vendors also manage to agree on the characterization of the
   majority of the MAC functions.  For example, every vendor classifies
   the DCF  as a real-time function.





















Yang (Editor), et al.    Expires January 26, 2005              [Page 19]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   The differences among Local MAC, Split MAC and Remote MAC
   architectures are shown graphically in the following figure:

    +--------------+---    +---------------+---    +--------------+---
    |  CAPWAP      |       |  CAPWAP       |       |  CAPWAP      |
    |  functions   |AC     |  functions    |AC     |  functions   |
    |==============|===    |---------------|       |--------------|
    |              |       |  non RT MAC   |       |              |AC
    |  802.11 MAC  |       |===============|===    |  802.11 MAC  |
    |              |WTP    | Real Time MAC |       |              |
    |--------------|       |---------------|WTP    |==============|===
    |  802.11 PHY  |       |  802.11 PHY   |       |  802.11 PHY  |WTP
    +--------------+---    +---------------+---    +--------------+---

     (a) "Local MAC"         (b) "Split MAC"        (c) "Remote MAC"

     Figure 6: Three Architectural Variants within Centralized WLAN
                          Architecture Family


4.3  Local MAC

   The main motivation of Local MAC architecture model, as shown in
   Figure 6.(a), is to offload network access policies and management
   functions (CAPWAP functions described in Section 2.2) to the AC,
   without splitting the 802.11 MAC functionality between WTPs and AC.
   The whole 802.11 MAC resides on the WTPs locally, including all the
   802.11 management and control frame processing for the STAs; on the
   other hand, information related to management and configuration of
   the WTP devices is communicated with a centralized AC, to facilitate
   management of the network, and maintain a consistent network-wide
   configuration for the WTP devices.

   Figure 7 offers a tabular representation of the design choices made
   by the six vendors in the survey that follow the Local MAC approach
   with respect to the aforementioned architecture considerations.
   "WTP-AC connectivity" shows the kind of connectivity between WTPs and
   AC each vendor's architecture can support.  It is clear that all the
   vendors can support L3 routed network connectivity between WTPs and
   AC, which implies that direct connections and L2 switched networks
   are also supported by all vendors.  By '802.11 mgmt termination', and
   '802.11 control termination' we denote the physical network device on
   which processing of the 802.11 management and control frames is done
   respectively.  All the vendors here choose to terminate 802.11
   management and control frames at the WTPs.  The last row of the
   table, '802.11 data aggregation', refers to the device on which
   aggregation and delivery of 802.11 data frames from one STA to
   another (possibly through a DS) is performed.  As we can see from the



Yang (Editor), et al.    Expires January 26, 2005              [Page 20]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   table, vendors make different choices as whether or not all the
   802.11 data traffic is aggregated and routed through the AC.  The
   survey data shows that some vendors choose to tunnel or encapsulate
   all the station traffic to or from the ACs, implying the AC also acts
   as the access router for this WLAN access network; other vendors
   choose to separate the control plane and data plane by letting the
   station traffic being bridged or routed locally while keeping the
   centralized control at the AC.


                      Arch7   Arch8   Arch9   Arch10   Arch11
                      -----   -----   -----   ------   ------



   WTP-AC
   connectivity       L3      L3       L3      L3      L3

   802.11 mgmt
   termination        WTP     WTP      WTP     WTP     WTP

   802.11 control
   termination        WTP     WTP      WTP     WTP     WTP

   802.11 data
   aggregation        AC      AC       WTP     AC      WTP


    Figure 7: Architecture Considerations for Local MAC Architecture

   Figure 8 shows that most of the CAPWAP functions as described in
   Section 2.2 are implemented at the AC, with help from WTPs to monitor
   RF channels, and collect statistics and state information from the
   STAs, as the AC offers the advantages of network-wide visibility,
   which is essential for many of the control, configuration and
   value-added services.















Yang (Editor), et al.    Expires January 26, 2005              [Page 21]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


                   Arch7   Arch8   Arch9   Arch10   Arch11
                   -----   -----   -----   ------   ------

      RF
      Monitoring    WTP     WTP    AC/WTP    WTP     WTP

      RF
      Config.       AC       AC      AC      AC      AC

      WTP config.   AC       AC      AC      AC      AC

      WTP
      Firmware      AC       AC      AC      AC      AC

      STA state
      info
      database      AC    AC/WTP   AC/WTP  AC/WTP    AC

      AC/WTP
      mutual
      authent.     AC/WTP  AC/WTP  AC/WTP AC/WTP  AC/WTP

    Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture

   The matrix shown in Figure 9 shows that most of the 802.11 functions
   are implemented at the WTPs for Local MAC Architecture, with some
   minor differences among the vendors with regard to distribution
   service, 802.11e scheduling and 802.1x/EAP authentication.  The
   difference in distribution service is consistent with the difference
   described earlier with regard to "802.11 data aggregation" in the
   Figure 7.


                   Arch7   Arch8   Arch9   Arch10   Arch11
                   -----   -----   -----   ------   ------

      Distribution
      Service       AC     AC       WTP      AC      WTP

      Integration
      Service       WTP    WTP      WTP      WTP     WTP

      Beacon
      Generation    WTP    WTP      WTP      WTP     WTP

      Probe
      Response      WTP    WTP      WTP      WTP     WTP




Yang (Editor), et al.    Expires January 26, 2005              [Page 22]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


      Power mgmt
      Packet
      Buffering     WTP    WTP      WTP      WTP     WTP

      Fragmentation/
      Defragment.   WTP    WTP      WTP      WTP     WTP

      Association
      Disassoc.
      Reassociation AC     WTP      WTP      WTP     WTP

      WME/11e
      --------------
      classifying   AC                               WTP

      scheduling    WTP    AC/WTP   WTP      WTP     WTP

      queuing       WTP             WTP      WTP     WTP

      Authentication
      and Privacy
      --------------
      802.1x/EAP    AC      AC      AC/WTP   AC       AC/WTP

      Keys
      Management    AC      AC      WTP      AC       AC

      802.11
      Encryption/
      Decryption    WTP     WTP     WTP      WTP      WTP

    Figure 9: Mapping of 802.11 Functions for Local MAC Architecture

   From Figure 7, Figure 8 and Figure 9, it is clear that differences
   among vendors in the Local MAC Architecture are relatively minor, and
   most of the functional mapping appears to be common across vendors.

4.4  Split MAC

   As shown in Figure 6.(b), the main idea behind the Split MAC
   architecture is to implement part of the 802.11 MAC functionality on
   a centralized AC instead of the WTPs, in addition to the services
   required for managing and monitoring the WTP devices.  Usually,  the
   decision of which functions of the 802.11 MAC need to be provided by
   the AC is based on the time-criticality of the services considered.

   In the Split MAC architecture, the WTP terminates the infrastructure
   side of the wireless physical link, provides radio-related



Yang (Editor), et al.    Expires January 26, 2005              [Page 23]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   management, and also implements all time-critical functionality of
   the 802.11 MAC.  In addition, the non real-time management functions
   are handled by a centralized AC, along with higher-level services,
   such as configuration, QoS, policies for load-balancing, access
   control lists, etc.  The subtle but key distinction between Local MAC
   and Split MAC relates to the non real-time functions: in Split MAC
   architecture, the AC terminates 802.11 non real-time functions,
   whereas in Local MAC architecture the WTP terminates the 802.11 non
   real-time functions and consequently sends appropriate messages to
   the AC.

   There are several motivations for taking the Split MAC approach.  The
   first is to offload to the WTP functionality that is specific and
   relevant only to the locality of each BSS, in order to allow the AC
   to scale to a large number of 'light weight' WTP devices.  Moreover,
   real-time functionality is subject to latency constraints and cannot
   tolerate delays due to transmission of 802.11 Control frames (or
   other real-time information) over multiple-hops.  The latter would
   limit the available choices for the connectivity between the AC and
   the WTP, hence the real-time criterion is usually employed to
   separate MAC services between the devices.  Another consideration is
   cost reduction of the WTP to make it as cheap and simple as possible.
   Last but not least,  moving functions like encryption and decryption
   to the AC reduces vulnerabilities from a compromised WTP, since user
   encryption keys no longer reside on the WTP.  As a result, any
   advancements in security protocols and algorithms design do not
   necessarily obsolete the WTPs; the ACs implement the new security
   schemes instead, and the management and update task is therefore
   simplified.  Additionally, the network is protected against LAN-side
   eavesdropping.

   Since there is no clear definition in the 802.11 specification as to
   which 802.11 MAC functions are considered "real time", each vendor
   has taken the liberty to interpret that in his own way.  Most vendors
   agree that the following services of 802.11 MAC are examples of real
   time services and so are chosen to be implemented on the WTPs.
   o  Beacon Generation
   o  Probe Response/Transmission
   o  Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
   o  Synchronization
   o  Retransmissions
   o  Transmission Rate Adaptation

   The following list includes examples of non-real-time MAC functions
   as interpreted by most vendors:
   o  Authentication/Deauthentication
   o  Association/Disassociation/Reassociation/Distribution




Yang (Editor), et al.    Expires January 26, 2005              [Page 24]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   o  Integration Services: bridging between 802.11 and 802.3
   o  Privacy: 802.11 Encryption/Decryption
   o  Fragmentation/Defragmentation

   However, some vendors may choose to classify some of the above
   "non-real time" functions as real-time functions, in order to support
   specific applications with strict QoS requirements.  For example
   Reassociation is sometimes implemented as "real-time" function in
   order to support VoIP applications.

   The non-real-time aspects of the 802.11 MAC are handled by the AC,
   through the processing of raw 802.11 management frames (Split MAC).
   The following matrix in Figure 10 offers a tabular representation of
   the design choices made by the six vendors that follow the Split MAC
   design with respect to the architecture considerations.  While most
   vendors support L3 connectivity between WTPs and ACs, some vendors
   can only support L2 switched connections, due to the tighter delay
   constraint resulting from splitting MAC between two physical entities
   across a network.  Comparing to Figure 7, it is clear that the
   commonality between Split MAC and Local MAC is that the 802.11
   control frames are all processed by the WTP, while the difference
   lies in the termination point for 802.11 management frames.  Local
   MAC terminates 802.11 management frames at WTP, while at least some
   of the 802.11 management frames are terminated at the AC for the
   Split MAC Architecture.  In most cases, since WTP devices are
   IP-addressable, any of the direct connection, L2-switched, or
   L3-routed connections of Section 2.2 can be used.  In the case where
   only Ethernet-encapsulation is performed (e.g., as in Architecture 4)
   then only direct connection and L2-switched connections are
   supported.





















Yang (Editor), et al.    Expires January 26, 2005              [Page 25]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


                Arch1   Arch2   Arch3   Arch4   Arch5   Arch6
                -----   -----   -----   -----   -----   -----


   WTP-AC
   connectivity   L3     L3      L3      L2      L3      L3

   802.11 mgmt
   termination    AC     AC      AC      AC    AC/WTP    AC

   802.11 control
   termination    WTP    WTP    WTP     WTP      WTP     WTP

   802.11 data
   aggregation    AC     AC       AC      AC     AC      AC


   Figure 10: Architecture Considerations for Split MAC Architecture

   Similar to the Local MAC Architecture, the following matrix in Figure
   11 shows that most of the CAPWAP control functions are implemented at
   the AC, with the exception of RF monitoring and in some cases RF
   configuration being done locally at the WTPs.




























Yang (Editor), et al.    Expires January 26, 2005              [Page 26]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


                 Arch1   Arch2   Arch3   Arch4   Arch5   Arch6
                 -----   -----   -----   -----   -----   -----
   RF
   Monitoring    WTP     WTP      WTP    WTP     WTP     WTP

   RF
   Config.       AC/WTP          AC/WTP  AC      AC      AC

   WTP config.   AC               AC     AC      AC      AC

   WTP
   Firmware      AC               AC     AC      AC      AC

   STA state
   info
   database      AC               AC     AC      AC       AC

   AC/WTP
   mutual
   authent.     AC/WTP  AC/WTP  AC/WTP   AC/WTP


   Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture

   The most interesting matrix for Split MAC Architecture is the
   Functional Distribution Matrix for 802.11 functions, as shown below
   in Figure 12.  There exists certain regularity in how the vendors map
   the functions onto the WTPs and AC.  For example, all vendors choose
   to implement Distribution, Integration Service at the AC, along with
   802.1x/EAP authentication and keys management.  All vendors also
   choose to implement beacon generation at WTPs.  On the other hand, it
   is also clear that vendors choose to map many of the other functions
   differently.  Therefore, Split MAC Architectures are not consistent
   regarding the exact way the MAC is split.


                 Arch1   Arch2   Arch3   Arch4    Arch5   Arch6
                 -----   -----   -----   ------   -----   -----

   Distribution
   Service       AC        AC      AC      AC      AC      AC

   Integration
   Service       AC        AC      AC      AC      AC      AC

   Beacon
   Generation    WTP       WTP     WTP    WTP     WTP     WTP




Yang (Editor), et al.    Expires January 26, 2005              [Page 27]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   Probe
   Response      WTP       AC/WTP   WTP   WTP     WTP     WTP

   Power mgmt
   Packet
   Buffering     WTP       WTP      WTP    AC     AC/WTP   WTP

   Fragmentation
   Defragment.   WTP               WTP     AC      AC      AC

   Association
   Disassoc.
   Reassociation AC        AC      AC     AC      WTP      AC

   WME/11e
   --------------
   classifying                     AC      AC       AC      AC

   scheduling    WTP/AC    AC      WTP     AC      AC       WTP/AC

   queuing       WTP/AC    WTP     WTP     AC      WTP      WTP

   Authentication
   and Privacy
   --------------

   802.1x/EAP    AC        AC      AC      AC      AC       AC

   Keys
   Management    AC        AC      AC      AC      AC       AC

   802.11
   Encryption/
   Decryption    WTP       AC      WTP     AC      AC       AC

   Figure 12: Mapping of 802.11 Functions for Split MAC Architecture


4.5  Remote MAC

   One of the main motivations for the Remote MAC Architecture is to
   keep the WTPs as light weight as possible, by having only the radio
   interfaces on the WTPs and offloading the entire set of 802.11 MAC
   functions (including delay-sensitive ones)  to the Access Controller.
   This leaves all the complexities of the MAC and other CAPWAP control
   functions to the centralized controller.

   The WTP acts only as a pass-through between the Wireless LAN clients



Yang (Editor), et al.    Expires January 26, 2005              [Page 28]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   (STA) and the AC, though they may have an additional feature to
   convert the frames from one format (802.11) to the other (Ethernet,
   TR, Fiber etc.).  The centralized controller provides network
   monitoring, management and control, entire set of the 802.11 AP
   services, security features, resource management, channel selection
   features, guarantees of Quality of Service to the users, etc.
   Because the MAC is separated from the PHY, we call this the "Remote
   MAC Architecture".  Typically such architecture is deployed with
   special attention to the connectivity between the WTPs and AC so that
   the delay is minimized.  The RoF (Radio over Fiber) from Architecture
   5  is such an example of Remote MAC Architecture.

4.6  Comparisons of Local MAC, Split MAC and Remote MAC

   Two commonalities across all the three Centralized Architectures
   (Local MAC, Split MAC and Remote MAC) are:
   o  Most of the CAPWAP functions related to network control and
      configuration reside on the AC.
   o  IEEE 802.11 PHY resides on the WTP.

   The difference between Remote MAC and the other two Centralized
   Architectures (namely, Local MAC and Split MAC) is pretty clear, as
   the 802.11 MAC is completely separated from the PHY in the former,
   while the other two at least keep some portion of the MAC functions
   together with PHY at the WTPs.  So the implication of PHY and MAC
   separation is that it severely limits the kind of interconnection
   between WTPs and ACs, so that the 802.11 timing constraints are
   satisfied.  As pointed out earlier, this usually results in tighter
   constraint over the interconnection between WTP and AC for the Remote
   MAC Architecture.  The advantage of Remote MAC Architecture is that
   it offers the lightest possible WTPs for certain deployment
   scenarios.

   The commonalities and differences between Local MAC and Split MAC are
   most clearly seen by comparing Figure 7 and Figure 10.  The
   commonality between the two is that 802.11 control frames are
   terminated at WTPs in both cases.  The main difference between Local
   MAC and Split MAC is that in the latter the WTP terminates only the
   802.11 control frames, while in the former the WTP may terminate all
   802.11 frames.  An interesting consequence of this difference is that
   the Integration Service, which essentially refers to bridging between
   802.11 and 802.3 frames, is implemented by the AC in the Split MAC,
   but can be part of either the AC or WTP in the Local MAC.

   As a second note, the Distribution Service, although usually provided
   by the AC, can also be implemented at the WTP in some Local MAC
   architectures.  The rationale behind this approach is to increase
   performance in delivering STAs data traffic by avoiding tunnelling it



Yang (Editor), et al.    Expires January 26, 2005              [Page 29]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   to the AC, and also relax the dependency of the WTP from the AC.
   Therefore, it is possible that the data and control planes are
   separated in the Local MAC Architecture.

   Even though all the 802.11 traffic is aggregated at ACs in the case
   of Split MAC Architecture, the data plane and control plane can still
   be separated by employing multiple ACs.  For example, one AC can
   implement most of the CAPWAP functions (control plane), while other
   ACs can be used for 802.11 frames bridging (data plane).

   Each of the three architectural variants may be advantageous in
   certain aspects for certain deployment scenarios.  While Local MAC
   retains most of the STAs state information at the local WTPs, Remote
   MAC centralizes most of the state into the backend AC.  Split MAC
   sits somewhat in the middle of that spectrum, keeping some state
   information locally at the WTPs, and the rest centrally at the AC.
   Many factors should be taken into account to determine the exact
   balance desired between centralized v.s.  decentralized state.  The
   impact of such balance on network manageability is currently a matter
   of dispute within the technical community.

4.7  Communication Interface between WTPs and ACs

   Before any messages can be exchanged between an AC and WTP, the WTP
   needs to discover, authenticate and register with the AC first, then
   download the firmware and establish control channel with the AC.
   Message exchanges between the WTP and AC for control and
   configuration can happen after that.  The following list outlines the
   basic operations that are typically performed between the WTP and the
   AC in the typical order:
   1.  Discovery : The WTPs discover the AC with which they will be
       bound to and controlled by.  The discovery procedure can employ
       either static or dynamic configuration.  In the latter case, a
       protocol is used in order for the WTP to discover candidate
       AC(s).
   2.  Authentication: After discovery, the WTP device authenticates
       itself with the AC.  However, mutual authentication, in which the
       WTP also authenticates the AC, is not always supported since some
       vendors strive for zero-configuration on the WTP side.  This is
       not necessarily secure as it leaves the possible vulnerability of
       the WTP being attached to a rogue AC.
   3.  WTP Association: After successful authentication, an WTP
       registers with the AC, in order to start receiving management and
       configuration messages.
   4.  Firmware Download: After successful association, the WTP may
       pull, or the AC may push the WTPs firmware, which may be
       protected by some manner, such as digital signatures.




Yang (Editor), et al.    Expires January 26, 2005              [Page 30]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   5.  Control Channel Establishment: The WTP establishes either an
       IP-tunnel or performs Ethernet encapsulation with the AC, in
       order to transfer data traffic and management frames.
   6.  Configuration Download: Following the control channel
       establishment process, the AC may push configuration parameters
       to the WTPs.

4.8  Security

   Given the varied distribution of functionalities for the Centralized
   Architecture as surveyed in Section 4.3, it is obvious that an extra
   network binding is created between the WTP and the AC.  This brings
   along new and unique security issues and subsequent requirements.

4.8.1  Client Data Security

   The survey shows clearly that the termination point for "over the
   air" 802.11 encryption (802.11i) can be implemented either in the WTP
   or in the AC.  Furthermore, the 802.1x/EAP functionality is also
   distributed between the WTP and the AC where, in almost all cases,
   the AC performs the necessary functions as the authenticator in the
   802.1x exchange.  If the encryption is done at the WTPs, the
   resultant cryptographic keys for the session are required to be
   securely pushed from the AC to the WTP.  Since this keying material
   is part of the control and provisioning of the WTPs, a secure
   encrypted tunnel for control frames is employed to transport the
   keying material.  In the case where the 802.11i encryption/decryption
   is performed in the AC, the authentication and key management is also
   fully performed in the AC.

   Regardless of 802.11i termination point, the Centralized WLAN
   Architecture assumes two possibilities for "over the wire" client
   data security.  In some cases there is an encrypted tunnel (IPsec or
   SSL ) between the WTP and AC which assumes the security boundary to
   be in the AC.  In other cases an end-to-end mutually authenticated
   secure VPN tunnel is assumed between the client and AC, other
   security gateway or end host entity.

4.8.2  Security of control channel between the WTP and AC

   In order for the CAPWAP functions to be implemented in the
   Centralized WLAN Architecture it is necessary for a control channel
   to exist between the WTP and AC.

   In order to address potential security threats against the control
   channel, existing implementations feature one or more of the
   following security mechanisms:




Yang (Editor), et al.    Expires January 26, 2005              [Page 31]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   1.  Secure discovery of WTP and AC.
   2.  Authentication of the WTPs to the ACs (and possibly mutual
       authentication).
   3.  Confidentiality and integrity of control channel frames.
   4.  Secure management of WTPs and ACs, including mechanisms for
       securely setting and resetting secrets.

   Discovery and authentication of WTPs are addressed in the submissions
   by implementing authentication mechanisms that range from X.509
   certificates, AAA authentication to pre-shared credential
   authentication.  In all cases, the issues of confidentiality,
   integrity and of protection against man-in-the-middle attacks of the
   control frames are addressed by a secure encrypted tunnel between WTP
   and AC(s) utilizing keys derived from the varied authentication
   methods mentioned previously.  Finally, one of the motivations for
   the Centralized WLAN Architecture is to minimize the storage of
   cryptographic and security sensitive information, in addition to
   operational configuration parameters within the WTPs.  It is for that
   reason that the majority of the submissions under the Centralized
   Architecture category have employed a post WTP authenticated
   discovery phase of configuration provisioning, which in turn protects
   against the theft of WTPs.





























Yang (Editor), et al.    Expires January 26, 2005              [Page 32]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


5.  Distributed Mesh Architecture

   Out of the 16 architecture survey submissions, 3 belong to the
   Distributed Mesh Architecture family.  An example of the Distributed
   Mesh Architecture is shown in Figure 13, which reflects some of the
   common characteristics found in these 3 submissions.  One of the main
   characteristics of these mesh architecture submissions is that the
   mesh nodes in the network may act as APs to the client stations in
   their respective BSS, as well as traffic relays to neighboring mesh
   nodes via 802.11 wireless links, in order to provide wider wireless
   coverage.  It is also possible that some of the mesh nodes in the
   network may serve only as wireless traffic relays for other mesh
   nodes, but not as APs for any client stations.  Instead of pulling
   Ethernet cable connections to each AP, wireless mesh networks provide
   an attractive alternative to relaying backhaul traffic.

   Another key characteristic of these mesh architecture submissions is
   that mesh nodes can keep track of the state of their neighboring
   nodes, or even nodes beyond their immediate neighborhood, by
   exchanging information periodically amongst them; this way, mesh
   nodes can be fully aware of the dynamic network topology and RF
   conditions around them.  Such peer-to-peer communication model allows
   the mesh nodes to actively coordinate among themselves to achieve
   self-configuration and self-healing.  This is the major distinction
   between this Distributed Architecture family and the Centralized
   Architecture -- much of the CAPWAP functions can be implemented
   across the mesh nodes in a distributed fashion, without a centralized
   entity making all the control decisions.

   On the other hand, it is worthwhile to point out that mesh networks
   do not necessarily preclude the use of centralized control.  It is
   possible that a combination of centralized and distributed control
   co-exists in the mesh networks.  Some global configuration or policy
   change may be better served in a coordinated fashion if some form of
   Access Controller (AC) exists in the mesh network, even if not the
   full blown version of the AC as defined in the Centralized WLAN
   Architecture.  For example, a centralized management entity can be
   used to update every mesh node's default configuration; it may also
   be more desirable to leave certain functions such as user
   authentication to a single centralized end point (such as a RADIUS
   server), but mesh networks allows the possibility of each mesh AP to
   directly talk to the RADIUS server.  This reduces single point of
   failure and takes advantage of the client distribution in the
   network.

   The backhaul transport network of the mesh network can be either an
   L2 or L3 networking technology.  Currently, vendors are using
   proprietary mesh technologies on top of standard 802.11 wireless



Yang (Editor), et al.    Expires January 26, 2005              [Page 33]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   links to enable peer-to-peer communication between the mesh nodes,
   and hence no interoperability exists among mesh nodes from different
   vendors.  IEEE 802.11 WG has recently started a new Task Group (TGs)
   to define the mesh standard for 802.11.

    +-----------------+         +-----------------+
    |  802.11 BSS 1   |         |  802.11 BSS 2   |
    |  ...            |         |  ...            |
    |    +---------+  |         |    +---------+  |
    +----|mesh node|--+         +----|mesh node|--+
         +-+---+---+                 +-+-+-----+
           |   |                       | |
           |   |                       | |           +----------+
           |   +-----------------------+ |  Ethernet | Ethernet |
           |    802.11 wireless links    |  +--------+ Switch   |
           |   +-----------------------+ |  |        |          |
           |   |                       | |  |        +----------+
         +-+---+---+                   +-+--+----+
    +----|mesh node|--+           +----|mesh node|--+
    |    +---------+  |           |    +---------+  |
    |  ...            |           |  ...            |
    |  802.11 BSS 4   |           |  802.11 BSS 3   |
    +-----------------+           +-----------------+

          Figure 13: Example of Distributed Mesh Architecture


5.1  Security

   Similar security concerns for client data security as described in
   Section 4.8.1 also apply to the Distributed Mesh Architecture.
   Additionally, one important security consideration for the mesh
   networks is that the mesh nodes must authenticate each other within
   the same administrative domain, and data transmission among
   neighboring nodes must be secured.  Each node that is part of the
   mesh must be fully trusted for the mesh to be secure.  It is often
   recommended that all communication between mesh nodes be encrypted,
   since they may carry user traffic that is not.  For this reason, the
   operator should always encrypt mesh links, in order to fully secure
   the network.











Yang (Editor), et al.    Expires January 26, 2005              [Page 34]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


6.  Summary and Conclusions

   We requested existing WLAN vendors and other interested parties to
   submit a short description of existing or desired WLAN access network
   architectures to define a taxonomy of possible WLAN access network
   architectures.  The information from the 16 submissions was condensed
   and summarized in this document.

   New terminology has been defined wherever existing terminology was
   found to be either insufficient or ambiguous in describing the WLAN
   architectures and supporting functions listed in the document.  For
   example, the broad set of Access Point functions has been divided
   into two categories - 802.11 functions which include those that are
   required by the IEEE 802.11 standards, and CAPWAP functions which
   include those that are not required by the IEEE 802.11, but are
   deemed essential for control, configuration, and management of 802.11
   WLAN access networks.  Another term that has caused considerable
   ambiguity is "Access Point" which was usually tied to reflect a
   physical box that has the antennas, but did not have a uniform set of
   externally verifiable behavior across all the submissions.  To remove
   this ambiguity, we have re-defined the AP to be the set of 802.11 and
   CAPWAP functions, while the physical box that terminates the 802.11
   PHY is called the Wireless Termination Point.

   Based on the submissions during the architectural survey phase, we
   have classified the existing WLAN architectures into three broad
   classes:
   1.  Autonomous WLAN Architecture indicates a family of architectures
       where all the 802.11 functions and, where applicable, CAPWAP
       functions are implemented in the WTPs.
   2.  Centralized WLAN Architecture indicates a family of architectures
       where the AP functions are split between the WTPs and the AC with
       the AC, typically, acting as a centralized control point for
       multiple WTPs.
   3.  Distributed WLAN Architecture indicates a family of architectures
       where the AP functions are implemented across a distributed
       network of peer entities.

   Within the Centralized WLAN Architecture, there are a few
   sub-categories that are visible depending on how one maps the MAC
   functions, at a high-level, between the WTP and the AC.  Three
   prominent ones emerged from the information present in the
   submissions:
   1.  Split MAC Architecture, where the 802.11 MAC functions are split
       between the WTP and the AC.  This subgroup includes all
       architectures that split the 802.11 MAC functions even though
       individual submissions differed on the specifics of the split.




Yang (Editor), et al.    Expires January 26, 2005              [Page 35]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   2.  Local MAC Architecture, where the entire set of 802.11 MAC
       functions is implemented on the WTP.
   3.  Remote MAC Architecture, where the entire set of 802.11 MAC
       functions is implemented on the AC.

   The following tree diagram summarizes the architectures documented in
   this taxonomy.

                 +----------------+
                 |Autonomous      |
     +---------->|Architecture    |
     |           |Family          |
     |           +----------------+
     |                                     +--------------+
     |                                     |Local         |
     |                               +---->|MAC           |
     |                               |     |Architecture  |
     |                               |     +--------------+
     |                               |
     |           +----------------+  |     +--------------+
     |           |Centralized     |  |     |Split         |
     +---------->|Architecture    |--+---->|MAC           |
     |           |Family          |  |     |Architecture  |
     |           +----------------+  |     +--------------+
     |                               |
     |                               |     +--------------+
     |                               |     |Remote        |
     |                               +---->|MAC           |
     |                                     |Architecture  |
     |                                     +--------------+
     |           +----------------+
     |           |Distributed Mesh|
     +---------->|Architecture    |
                 |Family          |
                 +----------------+


   A majority of the submitted WLAN access network architectures (12 out
   of 16)  followed the Centralized WLAN Architecture.  All but one of
   the centralized WLAN architecture submissions were grouped into
   either a Split MAC architecture or a Local MAC architecture.  There
   was one submission that followed the Autonomous WLAN Architecture.
   There were three submissions under the Distributed WLAN Architecture.

   The WLAN access network architectures in the submissions indicated
   that the connectivity assumptions were:
   o  Direct connection between the WTP and the AC.




Yang (Editor), et al.    Expires January 26, 2005              [Page 36]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


   o  L2 switched connection between the WTP and the AC.
   o  L3 routed connection between the WTP and the AC.
   o  Wireless connection between the mesh nodes in the distributed mesh
      architecture.

   Interoperability between equipment from different vendors is one of
   the fundamental problems in the WLAN market today.  In order to
   achieve interoperability via open standard development, the following
   next steps are suggested for IETF and IEEE 802.11.

   Using this taxonomy, a functional model of an Access Point should be
   defined, by the new study group recently formed within the IEEE
   802.11.  The functional model will consist of defining functional
   elements of an 802.11 access point that are considered atomic, i.e.
   not subject to further splitting across multiple network elements.
   Such a functional model should serve as a common foundation to
   support the existing WLAN architectures as outlined in this taxonomy,
   and any further architecture development either within or outside of
   IEEE 802.11 group.  It is possible, or even recommended, that the
   work on the functional model definition may also include impact
   analysis of implementing each functional element on either the WTP or
   the AC.

   As part of the functional model definition, interfaces must be
   defined in the form of primitives between these functional elements.
   If a pair of functional elements that have an interface defined
   between them is subject to being implemented on two different network
   entities, then a protocol specification between such pair of network
   elements is required to be defined, and should be developed by IETF.






















Yang (Editor), et al.    Expires January 26, 2005              [Page 37]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


7.  Security Considerations

   A comprehensive threat analysis of all of the security issues with
   the different WLAN architectures is not a goal of this document.
   Nevertheless, in addition to documenting the architectures employed
   in the existing IEEE 802.11 products in the market, this taxonomy
   document also catalogs, in a non-exhaustive manner, the security
   issues that arise and the manner in which vendors address these
   security threats.  The WLAN architectures are broadly categorized
   into three families: Autonomous Architecture, Centralized
   Architecture, and Distributed Architecture.  While Section 3, Section
   4 and Section 5 are devoted to each of these three architecture
   families, respectively, each section also contains a subsection to
   address the security issues within each architecture family.

   In summary, the main security concern in the Autonomous Architecture
   is the mutual authentication between WTP and the wired (Ethernet)
   infrastructure equipment.  Physical secuirty of the WTPs is also a
   network security concern because the WTPs contain secret information
   and theft of these devices could potentially compromise even the
   wired network.

   In the Centralized Architecture there are a few new security concerns
   because of the introduction of a new network binding between WTP and
   AC.  The following security concerns are raised for this architecture
   family: keying material for mobile client traffic may need to be
   securely transported from AC to WTP; secure discovery of WTP and AC
   is required, mutual authentication of WTPs and AC is needed, man-
   in-the-middle attacks to the control channel between WTP and AC,
   confidentiality and integrity of control channel frames, and theft of
   WTPs for extraction of embedded secrets within.  Each of the survey
   results for this broad architecture category have presented a variety
   of mechanisms to address these security issues.

   The new secuirty issue in the Distributed mesh architecture is the
   needs for the mesh nodes to authenticate each other before forming a
   secure mesh network.  It is also recommended that all communication
   between mesh nodes be encrypted to protect both the control and user
   data.












Yang (Editor), et al.    Expires January 26, 2005              [Page 38]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


8.  Acknowledgements

   This taxonomy is truly a collaborative effort with contributions from
   a large group of people.  First of all, we want to thank all the
   CAPWAP Architecture Design Team members who have spent many hours in
   the teleconference calls, over emails and in writing and reviewing
   the draft.  The full Design Team is listed here:
   o  Peyush Agarwal
         STMicroelectronics
         Plot# 18, Sector 16A
         Noida, U.P  201301
         India
         Phone: +91-120-2512021
         EMail: peyush.agarwal@st.com
   o  Dave Hetherington
         Roving Planet
         4750 Walnut St., Suite 106
         Boulder, CO  80027
         United States
         Phone: +1-303-996-7560
         EMail: Dave.Hetherington@RovingPlanet.com
   o  Matt Holdrege
         Strix Systems
         26610 Agoura Road
         Calabasas, CA  91302
         Phone: +1 818-251-1058
         EMail: matt@strixsystems.com
   o  Victor Lin
         Extreme Networks
         3585 Monroe Street
         Santa Clara, CA  95051
         Phone: +1 408-579-3383
         EMail: vlin@extremenetworks.com
   o  James M.  Murphy
         Trapeze Networks
         5753 W.  Las Positas Blvd.
         Pleasanton, CA  94588
         Phone: +1 925-474-2233
         EMail: jmurphy@trapezenetworks.com
   o  Partha Narasimhan
         Aruba Wireless Networks
         180 Great Oaks Blvd
         San Jose, CA  95119
         Phone: +1 408-754-3018
         EMail: partha@arubanetworks.com
   o  Bob O'Hara
         Airespace




Yang (Editor), et al.    Expires January 26, 2005              [Page 39]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


         110 Nortech Parkway
         San Jose, CA  95134
         Phone: +1 408-635-2025
         EMail: bob@airespace.com
   o  Emek Sadot (see Authors' Addresses)
   o  Ajit Sanzgiri
         Cisco Systems
         170 W Tasman Drive
         San Jose, CA  95134
         Phone: +1 408-527-4252
         EMail: sanzgiri@cisco.com
   o  Inderpreet Singh
         Chantry Networks
         1900 Minnesota Court
         Mississauga, Ontario  L5N 3C9
         Canada
         Phone: +1 905-567-6900
         EMail: isingh@chantrynetworks.com
   o  L.  Lily Yang (Editor, see Authors' Addresses)
   o  Petros Zerfos (see Authors' Addresses)

   In addition, we would also like to acknowledge the contributions from
   the following individuals who participated in the architecture
   survey, and provided detailed input data in preparation of the
   taxonomy: Parviz Yegani, Cheng Hong, Saravanan Govindan, Bob Beach,
   Dennis Volpano, Shankar Narayanaswamy, Simon Barber, Srinivasa Rao
   Addepalli, Subhashini A.  Venkataramanan, Kue Wong, Kevin Dick, Ted
   Kuo, and Tyan-shu Jou.  It would be simply impossible to write this
   taxonomy without the large representative set of data points that
   they provided us.  We would also like to thank our CAPWAP WG
   co-chairs, Mahalingam Mani and Dorothy Gellert, and our Area
   Director, Bert Wijnen, for their unfailing support.

9  References

   [1]  "IEEE WLAN MAC and PHY Layer Specifications", August 1999, <IEEE
        802.11-99>.

   [2]  "CAPWAP Problem Statement", May 2004, <http://www.ietf.org/
        internet-drafts/draft-ietf-capwap-problem-statement-01.txt>.

   [3]  "The Internet Standards Process Revision 3", October 1996,
        <ftp://ftp.isi.edu/in-notes/rfc2026>.

   [4]  "Key words for use in RFCs to Indicate Requirement Levels",
        March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.

   [5]  "IEEE Std 802.11i/6.0: Specification for Enhanced Security",



Yang (Editor), et al.    Expires January 26, 2005              [Page 40]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


        September 2003.

   [6]  "IEEE Std 802.11h: Spectrum and Transmit Power Management
        Extensions in the 5 GHz Band in Europe", October 2003.

   [7]  "IEEE Std 802.1X: Port-based Network Access Control", June 2001.


Authors' Addresses

   L. Lily Yang
   Intel Corp.
   MS JF3 206, 2111 NE 25th Avenue
   Hillsboro, OR  97124

   Phone: +1 503-264-8813
   EMail: lily.l.yang@intel.com


   Petros Zerfos
   UCLA - Computer Science Department
   4403 Boelter Hall
   Los Angeles, CA  90095

   Phone: +1 310-206-3091
   EMail: pzerfos@cs.ucla.edu


   Emek Sadot
   Avaya
   Atidim Technology Park, Building #3
   Tel-Aviv  61131
   Israel

   Phone: +972-3-645-7591
   EMail: esadot@avaya.com















Yang (Editor), et al.    Expires January 26, 2005              [Page 41]

Internet-Draft           CAPWAP Arch. Taxonomy                 July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Yang (Editor), et al.    Expires January 26, 2005              [Page 42]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/