[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: October 15, 2004                                      P. Zerfos
                                                                    UCLA
                                                                E. Sadot
                                                                   Avaya
                                                          April 16, 2004


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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 15, 2004.

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




Yang (Editor), et al.    Expires October 15, 2004               [Page 1]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Conventions used in this document  . . . . . . . . . . . .  4
     1.2   IEEE 802.11 Definitions  . . . . . . . . . . . . . . . . .  4
     1.3   Terminology Used in this Document  . . . . . . . . . . . .  5
     1.4   Terminology Used Historically but Not Recommended  . . . .  7
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.1   IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . . .  8
     2.2   CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . 10
     2.3   WLAN Architecture Proliferation  . . . . . . . . . . . . . 11
     2.4   Taxonomy Methodology and Document Organization . . . . . . 13
   3.  Autonomous Architecture  . . . . . . . . . . . . . . . . . . . 15
     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.2   Security . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Centralized WLAN Architecture  . . . . . . . . . . . . . . . . 17
     4.1   Interconnection Topology between WTPs and ACs  . . . . . . 18
     4.2   Overview of Three Centralized WLAN Architectures . . . . . 19
     4.3   Local MAC  . . . . . . . . . . . . . . . . . . . . . . . . 20
     4.4   Split MAC  . . . . . . . . . . . . . . . . . . . . . . . . 24
     4.5   Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . 28
     4.6   Comparisons of Local MAC, Split MAC and Remote MAC . . . . 28
     4.7   Communication Interface between WTPs and ACs . . . . . . . 29
     4.8   Security . . . . . . . . . . . . . . . . . . . . . . . . . 30
       4.8.1   Client Data Security . . . . . . . . . . . . . . . . . 30
       4.8.2   Security of control channel between WTP and AC . . . . 31
   5.  Distributed Mesh Architecture  . . . . . . . . . . . . . . . . 32
     5.1   Security . . . . . . . . . . . . . . . . . . . . . . . . . 32
   6.  Summary and Conclusions  . . . . . . . . . . . . . . . . . . . 33
     6.1   Taxonomy Summary . . . . . . . . . . . . . . . . . . . . . 33
     6.2   Next Steps . . . . . . . . . . . . . . . . . . . . . . . . 35
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 36
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
   A.  WLAN Architecture Survey Template  . . . . . . . . . . . . . . 40
   B.  Survey Contribution For Architecture 1 . . . . . . . . . . . . 41
   C.  Survey Contribution For Architecture 2 . . . . . . . . . . . . 46
   D.  Survey Contribution For Architecture 3 . . . . . . . . . . . . 50
   E.  Survey Contribution For Architecture 4 . . . . . . . . . . . . 53
   F.  Survey Contribution For Architecture 5 . . . . . . . . . . . . 57
   G.  Survey Contribution For Architecture 6 . . . . . . . . . . . . 61
   H.  Survey Contribution For Architecture 7 . . . . . . . . . . . . 65
   I.  Survey Contribution For Architecture 8 . . . . . . . . . . . . 67
   J.  Survey Contribution For Architecture 9 . . . . . . . . . . . . 70
   K.  Survey Contribution For Architecture 10  . . . . . . . . . . . 74
   L.  Survey Contribution For Architecture 11  . . . . . . . . . . . 77
   M.  Survey Contribution For Architecture 12  . . . . . . . . . . . 82



Yang (Editor), et al.    Expires October 15, 2004               [Page 2]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   N.  Survey Contribution For Architecture 13  . . . . . . . . . . . 84
   O.  Survey Contribution For Architecture 14  . . . . . . . . . . . 86
       Intellectual Property and Copyright Statements . . . . . . . . 88
















































Yang (Editor), et al.    Expires October 15, 2004               [Page 3]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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) 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 October 15, 2004               [Page 4]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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, 802.11
   Standards [1] describes 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 IEEE 802.11 Standards  [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 the 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 October 15, 2004               [Page 5]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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
   functions and CAPWAP functions (wherever applicable) are implemented
   within each Wireless Termination Point (WTP) in the network. The WTPs
   in such networks are also called the standalone APs, or fat APs,
   because these devices implement the full functions that enable the
   devices to function 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
   functions 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 the logical functions including both IEEE 802.11
   functions and CAPWAP functions (wherever applicable) are implemented
   across a distributed network consisting of peer entities. A mesh
   network of WTPs can be considered as an example of such architecture.

   Access Controller (AC): The network entity in the Centralized WLAN
   architectures that control, configure and manage the entire 802.11
   wireless access network including the WTPs.

   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 (like the
   control frame processing) for IEEE 802.11, while tunnel all the
   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 October 15, 2004               [Page 6]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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

   We recognize that some terminology have been used by vendors
   historically, but we recommend stop using to avoid further confusion,
   mostly around the term of "AP". We provide a list of such terms here
   with the recommended new terminology:

   Split WLAN Architecture: use Centralized WLAN Architecture.

   Hierachical WLAN Architcture: use Centralized WLAN Architecture.

   Standalone Access Point: use WTP or Standalone WTP.

   Fat Access Point: the same as Standalone Access Point, relatively to
   Thin Access Points. 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 October 15, 2004               [Page 7]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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,
   have 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 a broader choice, a standardized
   interoperable solution addressing the above mentioned 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), as well as among wireless clients. 802.11 also
   describes how mobile devices can associate together into a basic
   service set (BSS), the rough equivalent of a single broadcast domain
   or a segment of a bridged Ethernet LAN. A BSS is identified by a
   common service set identifier (SSID) or name. The WLAN architecture
   can be considered as a sort of the '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 is connected via a broadcast
   layer 2 network and all are using the same SSID, an extended service
   set (ESS) is created. An ESS is also similar to a single broadcast
   domain, where a mobile device associated with one AP can successfully
   ARP for the address of a mobile device associated with any other AP
   in the ESS. Within an ESS, a mobile station can roam from one AP to
   another through only layer 2 transitions coordinated by the 802.11
   MAC management protocol. Higher layer protocols, including IP are
   unaware that the network attachment point of the mobile device has
   moved.



Yang (Editor), et al.    Expires October 15, 2004               [Page 8]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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
   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  Privacy: 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
      using the "Distribution System" concept of 802.11.
   o  Integration: The service to translate the MSDU received from the
      Distribution System to the 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 MAC services
   that must be implemented by the APs in the WLAN. For example:




Yang (Editor), et al.    Expires October 15, 2004               [Page 9]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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
   o  Privacy: 802.11 Encryption/Decryption

   In addition to the services offered by the 802.11, the IEEE 802.11 WG
   also designs the technique to support the Quality of Service
   (802.11e), Security Algorithms (802.11i), mobility of the STA from
   one BSS to the other (802.11f), Radio Resource Management (802.11f)
   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 physical
   devices that are typically referred to as AP (or thin AP, or mesh AP,
   depends on the architecture family as described below). 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 are typically required. Such functions are
   especially important when the IEEE 802.11 WLAN functions are
   implemented across a large scale of network of multiple entities,
   instead of within one 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, transmission
      power, etc.



Yang (Editor), et al.    Expires October 15, 2004              [Page 10]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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
      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 were frequently
   encountered 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 brings into light the different WLAN network
   architectures that have been followed so far by different vendors, in
   an attempt to address some or all of the problems outlined in  [2].
   As IEEE 802.11 standard explicitly does not specify the details of DS



Yang (Editor), et al.    Expires October 15, 2004              [Page 11]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   implementations, different architectures proliferate in the market.
   While these different architectures all conform to the IEEE 802.11
   standard as a whole, the individual functional components in these
   architectures are not standardized, and the interfaces between the
   network architecture components are mostly proprietary, hence there
   is no guarantee of cross-vendor interoperability even within similar
   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 functional and the network architectures offered
   by the existing WLAN vendors today. The end result of this task is
   this taxonomy document.

   After analyzing about a dozen different vendors' architectures, we
   believe that the existing 802.11 WLAN access network architectures
   can be broadly categorized into three distinct architecture 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 WLAN architecture, where each WTP is one physical
      device that implements all the 802.11 services, including both the
      distribution and integration services, and the portal function.
      Such AP architecture is called Autonomous WLAN Architecture,
      because each WTP is autonomous in its functionality, and it does
      not require 802.11 specific support from any other network
      elements. The WTP in such architecture is typically configured and
      controlled individually and can be monitored and managed via
      typical network management protocols like SNMP. But no explicit
      802.11 support is needed outside of the WTP. So 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 a newly emerging hierarchical architecture utilizing one or
      multiple centralized controller for large number of WTP devices.
      The centralized controller is commonly referred to as Access
      Controller (AC), whose main function in the network is to control,
      manage and monitor the WTP devices that are present in the
      network. Access Controller could be a L3 or L2 device, and it
      could also be co-located with a L2 bridge (switch) or a L3 router,
      and hence may be referred to as Access Bridge, or Access Router in
      those particular cases. But Access Controller is the generic
      terminology we use through this document. 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



Yang (Editor), et al.    Expires October 15, 2004              [Page 12]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      functions 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 two physical
      network devices, namely, the WTPs and ACs. Because the WTP devices
      only implement a portion of the functions that standalone APs
      implement, and such WTP devices in such architecture are sometimes
      referred to as light weight or thin APs.
   o  Distributed WLAN Architecture: The third emerging WLAN
      architecture family is distributed architectures in which the WTPs
      are capable of forming a distributed network among themselves, via
      either wired or wireless media. A wireless mesh network of WTPs is
      one example in the distributed architecture family,  where the APs
      themselves form a mesh network connecting neighboring APs via
      802.11 wireless links, and some of the APs also have wired
      Ethernet connections to the gateway 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 received 14 contributions in the form of short text
   descriptions, 13 of them are from WLAN vendors  (AireSpace, Aruba,
   Avaya, Chantry Networks, Cisco, Cranite Systems, Extreme Networks,
   Intoto, Panasonic, Trapeze, Instant802, Strix Systems, Symbol) and
   one from an academic researcher (UCLA). Out of the 14 contributions,
   one described an Autonomous WLAN Architecture, another a Distributed
   Mesh Architecture, while the rest 12 entries represent architectures
   that fall into the family of Centralized WLAN Architecture.

   The 14 entries that were submitted for the architecture survey are
   included in this document in its original form in the Appendix
   sections. The information provided by each vendor for both the
   "Functionality Distribution Matrix" in this document and the Appendix
   is intended for the use of creating this architectural taxonomy only.
   It represents the contributor's view of the architecture from an
   engineering perspective and does not necessarily imply an existing
   product, shipping or not, nor an intent by the vendor to build such a
   product.

   The interesting data we try to get out of these survey data is not
   which vendor does what, but what are the general categories and
   trends in WLAN architecture evolution, and what are the common
   characteristics and what are being done differently, and why. In
   order to represent the survey data in a compact format, a "Functional
   Distribution Matrix" is used in this document to tabulate the
   various services and functions in various vendor's offerings. These



Yang (Editor), et al.    Expires October 15, 2004              [Page 13]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   services and functions are classified into three main categories:
   o  Architecture Considerations: the choice of the interconnection
      topology between the AC and the AP is an architecture
      consideration. Also, design choices regarding the physical device
      on which processing of management, control, and data frames of the
      802.11 takes place are also interesting to point out.
   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.
   Such matrix will be used throughput the rest of the document to
   represent the data set we have collected from the survey.

   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 14) 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 October 15, 2004              [Page 14]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


3.  Autonomous Architecture

3.1  Overview

   Figure 1 shows an example network of the Autonomous WLAN
   Architecture.  This architecture combines all the 802.11
   functionality in a single physical device, the 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. Usually this will also involve putting a corresponding
   802.1Q tag on each packet forwarded to the Ethernet infrastructure.

   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
   architecture are confined to the WTP.  There are no extra
   implications from the client authentication and encryption/decryption



Yang (Editor), et al.    Expires October 15, 2004              [Page 15]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   perspective as the AAA interface is integrated into the WTP, as is
   the key generation mechanisms required for 802.11i encryption/
   decryption.

   As per problem #4 in [2], the only security issue in this
   architecture is mutual authentication between the WTP and the
   Ethernet infrastructure to ensure that WTPs cannot be easily stolen
   and deployed in unprotected networks. This can be ensured by existing
   mechanisms such as, for instance, 802.1x between the WTP and the
   Ethernet switch it plugs into.









































Yang (Editor), et al.    Expires October 15, 2004              [Page 16]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


4.  Centralized WLAN Architecture

   Centralized WLAN Architecture is a newly 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, the Centralized
   WLAN Architecture employs one or multiple centralized controller
   called Access Controller(s) in the network to provide the network
   wide visibility and improve management scalability and dynamic
   configurability.

   The following diagram shows schematically the Centralized WLAN
   Architecture network diagram where the Access Controller (AC)
   connects to multiple Wireless Termination Points (WTPs) via a certain
   interconnection topology, which can be either a direct connection, a
   L2-switched, or L3-routed network as described in Section 4.1.  The
   AC exchanges configuration, and control information with the AP
   devices, allowing the management of the network from a centralized
   point. Also, designs of the Centralied 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   |
                           |     Topology       |
                           +-------+------------+
                                   |
                                   |
                             +-----+----+
                             |    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.
   Closer scrutiny of the functions reveals that their differing
   resource requirements (e.g. CPU, memory, storage) may lend themselves



Yang (Editor), et al.    Expires October 15, 2004              [Page 17]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   to being distributed across different devices. For instance, complex
   radio control algorithms can be CPU intensive. Storing and
   downloading images and configurations can be storage intensive. Data
   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 box 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.

4.1  Interconnection Topology between WTPs and ACs

   There are several possible topologies 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 October 15, 2004              [Page 18]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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 Architectures

   While dynamic and consistent network manageability is one of the
   primary motivations for the Centralized Architecture, the survey data
   from vendors also show that different varieties of this architecture
   family have emerged as a result of the inherent flexibility in the
   802.11 standard [1] regarding the implementation of the logical
   functions that are broadly described under the term "Access Point".



Yang (Editor), et al.    Expires October 15, 2004              [Page 19]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   As there is no standard mapping of these 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, enterprise
   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 approaches vendors have
   taken, namely, the Local MAC, Split MAC,  and Remote MAC approaches
   within this family of architectures, and provide the mapping
   characteristics of the various functions into the network entities,
   for each approach. The naming of Local MAC, Split MAC and Remote MAC
   reflects how the functions, esp. the 802.11 MAC functions, are mapped
   onto the network entities. Local MAP indicates that the MAC functions
   stay intact and local to WTPs, while Split MAC shows the MAC being
   split between the WTPs and ACs, and remote MAC signifies the MAC is
   moved away from WTP to the remote AC in the network.

   The differences among Local MAC, Split MAC and Remote MAC
   architectures can be shown roughly 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: The Three Different Architectures within Centralized WLAN
                          Architecture Family


4.3  Local MAC

   The Local MAC architecture model, as shown in Figure 6.(a), attempts
   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 WTP(s) and AC(s). The whole 802.11
   MAC resides on the WTP locally, including all the 802.11 management
   and control frame processing for the STAs; however information
   related to management and configuration of the WTP devices is



Yang (Editor), et al.    Expires October 15, 2004              [Page 20]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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 architecture considerations. "WTP-AC topology"
   shows the kind of topology between WTPs and AC each vendor's
   architecture can support. It is clear that all the vendors can
   support L3 routed network topology 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 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 table, vendors
   make different choices as whether or not all the 802.11 data traffic
   are 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; while other vendors choose to separate
   the control plane and data plane by letting the station traffic being
   bridged or routed locally while keeping the control at the AC.


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



   WTP-AC
   topology           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




Yang (Editor), et al.    Expires October 15, 2004              [Page 21]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   Below 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. Most vendors choose to do the similar mapping here as
   the AC offers the advantages of network-wide visibility, which is
   essential for many of the control, configuration and value-added
   services.


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

    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




Yang (Editor), et al.    Expires October 15, 2004              [Page 22]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      Integration
      Service       WTP    WTP      WTP      WTP     WTP

      Beacon
      Generation    WTP    WTP      WTP      WTP     WTP

      Probe
      Response      WTP    WTP      WTP      WTP     WTP

      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   WME    WME      WME              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
   between vendors in the Local MAC Architecture is relatively minor
   while the most of the functional mapping appears to be common across
   the vendors.





Yang (Editor), et al.    Expires October 15, 2004              [Page 23]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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 service required.

   In Split MAC architecture, the WTP terminates the infrastructure side
   of the wireless physical link, provides radio-related 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. One
   of the motivations is to offload to the WTP(s) 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 interconnection
   topology between the AC and the WTP(s), so the real-time criterion is
   usually employed to separate MAC services between the devices.
   Another consideration is cost reduction in the WTP to make it as
   cheap and simple as possible. Last but not least,  moving functions
   like encryption and decryption to the AC instead of WTPs help avoid
   any risk from a compromised WTP by not having user encryption keys on
   the WTP at all.  A side effect of this architecture is that progress
   in security protocols and algorithm does not obsolete the WTPs; the
   ACs implement the new security schemes instead and the management
   problem is therefore simplified. It can also protect from LAN-side
   eavesdropping.

   Examples of real-time services of the 802.11 MAC that are implemented
   on the WTP are the following:
   o  Beacon Generation
   o  Probe Response/Transmission
   o  Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK




Yang (Editor), et al.    Expires October 15, 2004              [Page 24]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   o  Synchronization
   o  Retransmissions
   o  Transmission Rate Adaptation

   The non-real-time aspects of the 802.11 MAC are handled by the AC,
   either directly through the processing of raw 802.11 management
   frames (Split MAC), or after conversion to some other message format
   (Local MAC). These include:
   o  Station Services: Authentication/Deauthentication
   o  Distribution System Services: Association/Disassociation/
      Reassociation/Distribution
   o  Integration Services: bridging between 802.11 and 802.3
   o  Privacy: 802.11 Encryption/Decryption
   o  Fragmentation/Defragmentation

   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 topology 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 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 being terminated at the AC for Split
   MAC Architecture. In most cases, since WTP devices are
   IP-addressable, any of the direct connection, L2-switched, or
   L3-routed topologies of Section 2.2 can be used. In the case where
   only Ethernet-encapsulation is performed (ex. as in Architecture 4)
   then only direct connection and L2-switched topologies are supported.



















Yang (Editor), et al.    Expires October 15, 2004              [Page 25]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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


   WTP-AC
   topology       L3     L3    L3       L2       L3      L3

   802.11 mgmt
   termination    AC    AC     AC      AC     WTP/AC     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 the CAPWAP control functions are implemented at the AC.


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

   RF
   Config.       WTP/AC          WTP/AC  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.       X       X       X        X


   Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture

   The most interesting matrix for Split MAC Architecture is the



Yang (Editor), et al.    Expires October 15, 2004              [Page 26]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   Functional Distribution Matrix for 802.11 functions, as shown below
   in Figure 12. It is clear that even within the Split MAC
   Architecture, vendors choose to map many of the functions
   differently. 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. But there exists wide spread difference among the
   vendors for most other functions. So this clearly indicates that
   Split MAC Architecture represents a category of architectures that
   split the MAC somehow, but it does not represent a single way of
   splitting at all.


                 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

   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   WME/Oth         WME/Oth   AC  WME/802.11e   WME/other

   scheduling    WTP/AC    AC      WTP     AC      AC       WTP/AC

   queuing       WTP/AC    WTP     WTP     AC      WTP      WTP

   Authentication



Yang (Editor), et al.    Expires October 15, 2004              [Page 27]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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 motivation for Remote MAC Architecture is to keep the
   WTPs as light weight as possible by having only the radio interface
   on the WTPs and offloading the entire set of 802.11 MAC functions
   (including delay-sensitive functions)  to the Access Controller. It
   thus keeps all the complexities of the MAC and other CAPWAP control
   functions to the centralized controller and makes the WTP manageable.
   The WTP acts only as a communication means between the Wireless LAN
   clients (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 has a protocol
   for network monitoring, management and control, entire set of the
   802.11 AP services, the WLAN PHY concepts, security features,
   resource management, channel adoption features, guarantying Quality
   of Service to the users etc. Because MAC is separated from the PHY,
   we call this "Remote MAC Architecture". Typically such architecture
   is deployed with special attention to the topology between WTP and AC
   so that the delay is minimized. The RoF (Radio over Fiber) from
   Architecture 5 Appendix F 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  All 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 (i.e., Local MAC and Split MAC) is pretty clear, as the
   802.11 MAC is completely separated from the PHY in the former, while



Yang (Editor), et al.    Expires October 15, 2004              [Page 28]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   the other two at least keep some portion of the MAC functions with
   PHY at the WTPs. So the implication of PHY and MAC separation is that
   it severely limits the interconnection topology between WTPs and ACs
   so that 802.11 timing constraint is still satisfied. As pointed out
   earlier, this usually results in tighter control 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 WTP terminates only the
   802.11 Control frames, while in the former WTP may terminate all
   802.11 frames. An interesting consequence of this difference is that
   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
   architecture. The rationale behind this approach is to increase
   performance in delivering STAs data traffic by avoiding tunnelling it
   to the AC, and also relax the dependency of the WTP from the AC.
   Therefore, it is possible that data plane and control plane are
   separated in the Local MAC Architecture.

   Even though all the 802.11 traffic are 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 employed for 802.11 frames bridging (data plane).

4.7  Communication Interface between WTPs and ACs

   Before any messages can be exchanged between the AC and WTP(s)
   typically  the following operations are first performed that lead to
   the registration of an WTP with an AC:
   1.  Discovery : WTP(s) discover the AC with which they will
       associate, and be controlled by. The discovery procedure can
       employ either static configuration, or dynamic. 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. The opposite is not always supported, since
       some vendors strive for zero-configuration on the WTP side.




Yang (Editor), et al.    Expires October 15, 2004              [Page 29]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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 is digitally
       signed.
   5.  Control Channel Establishment: the WTP establishes either an
       IP-tunnel (ex. Architecture 2 (Appendix C), Architecture 1
       (Appendix B)) or performs Ethernet encapsulation (ex.
       Architecture 4 (Appendix E)) 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 WTP.

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.






Yang (Editor), et al.    Expires October 15, 2004              [Page 30]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


4.8.2  Security of control channel between WTP and AC

   In order for the CAPWAP functions to be implemented in the
   Centralized WLAN Architecture there is a requirement for a control
   channel between WTP and AC.  This is the link where security threats
   may arise.

   Threats to the Centralized WLAN Architecture as presented in the
   submissions are:
   1.  Secure discovery of WTP and AC
   2.  Authentication of the WTPs to the ACs and vice versa
   3.  Man-in-the-middle attacks to the control channel between WTP and
       AC.
   4.  Confidentiality and integrity of control channel frames
   5.  Theft of WTPs and extraction of embedded secrets within.

   Discovery and authentication of WTPs are addressed in the submissions
   by implementing authentication mechanisms that range from X.509
   certificates, AAA authentication and 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 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 October 15, 2004              [Page 31]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


5.  Distributed Mesh Architecture

   Editor's note: This section is only a place holder for now. We will
   need to work on this soon.

   An example of the Distributed Mesh Architecture is shown in Figure
   13, The mesh nodes can keep track of the state of its neighboring
   nodes or even nodes beyond, so that the mesh nodes can coordinate
   among themselves to provide the necessary functions. The distinction
   between this architecture family and the Centralized Architecture is
   the classical distinction between a distributed architecture versus a
   centralized one. Each can have certain advantages for certain
   deployment scenarios.

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

   TBW












Yang (Editor), et al.    Expires October 15, 2004              [Page 32]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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 14 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 devided
   into two categories - 802.11 functions which includes those that are
   required by the IEEE 802.11 standards, and CAPWAP functions which
   includes 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.

6.1  Taxonomy Summary

   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 WTP.
   2.  Centralized WLAN architecture indicates a family of architectures
       where the AP functions are split between the WTP and the AC with
       the AC, typically, acting as a centralization 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 subgroups
   that are visible depending on how one splits 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 October 15, 2004              [Page 33]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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
   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 Remote AP architecture. There was one
   submission under the Distributed WLAN architecture.

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




Yang (Editor), et al.    Expires October 15, 2004              [Page 34]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   o  L2 switched connectivity between the WTP and the AC.
   o  L3 routed connectivity between the WTP and the AC.
   o  Wireless links in the distributed WLAN architecture.

6.2  Next Steps

   Interoperability between equipment from different vendors is one of
   the problems listed in the CAPWAP problem statement. It is not very
   surprising to see that the interoperability problem has arguably seen
   more discussion under the centralized WLAN access network
   architecture, given the number of submissions that seem to favor this
   architecture.

   In order to achieve the interoperability goal, the following are
   possible next steps:
   1.  The CAPWAP taxonomy document needs to be reviewed by both the
       IEEE 802.11 WG and the IETF.
   2.  Using the above taxonomy/terminology, a functional model of an
       Access Point should be defined, possibly, by a group 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.
   3.  As part of the functional model definition, define interfaces in
       the form of primitives between these functional elements.
   4.  If a pair of functional elements that have an interface defined
       between them is subject to a split, i.e., subject to being
       implemented on two different network entities, then a protocol
       specification between such pairs of functional elements is
       required to be defined.















Yang (Editor), et al.    Expires October 15, 2004              [Page 35]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


7.  Security Considerations

   While this taxonomy documents the architectures employed in the
   existing IEEE 802.11 products in the market, it also documents the
   security issues that arise with the varied ways in which vendors have
   chosen to employ these architectures. 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. Please refer to Section 3Section 3 and Section 3  for
   detailed security considerations in each of these architecture
   families.

   In summary, the main security concern in the Autonomous Architecture
   is the mutual authentication between WTP and the wired (Ethernet)
   infrastructure equipment.  The WTP physical entity contains all of
   the 802.11 and CAPWAP functions which isolates it from over the wire
   security issues between WTP and AC.  In the Centralized Architecture
   there are a few new security concerns because of the introduction of
   a network binding between WTP and AC.  The following security
   concerns are raised for this architecture family: keying material for
   mobile client traffic needs 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.

   [Editor's note] Summary of the security issues and concerns
   pertaining to the Distributed architecture needs to be written when
   the description of that architecture is complete.
















Yang (Editor), et al.    Expires October 15, 2004              [Page 36]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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 October 15, 2004              [Page 37]

Internet-Draft           CAPWAP Arch. Taxonomy                April 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. It is simply impossible to
   write a taxonomy without a large representative 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", February 2004, <http://www.ietf.org/
        internet-drafts/draft-ietf-capwap-problem-statement-00.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",
        September 2003.



Yang (Editor), et al.    Expires October 15, 2004              [Page 38]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   [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 October 15, 2004              [Page 39]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix A.  WLAN Architecture Survey Template
   1.  Design considerations and requirements: please briefly describe
       your design principles for this architecture.
   2.  WLAN functions supported: Please list the functions supported in
       this WLAN briefly, but please do not send us the entire data
       sheet. Examples of WLAN functions includes the STA services,
       Distributed System Services (as defined by 802.11), radio
       resource management and control, AP load balancing, mobility
       support, WLAN network wide security functions (including
       authentication, encryption for privacy and integrity, etc.) and
       any others not listed here but deemed important in your design.
   3.  The functional architecture to implement the functions described
       above: whether it is by Autonomous WLAN Architecture, or
       Centralized Architecture. For Centralized Architecture, please
       provide the functional mapping of WLAN functions onto the AP and
       AC -- with just enough details that help us understand the kinds
       of functional interface necessary between the two.
   4.  The protocol used in between AP and AC.
   5.  The topological assumptions between AP and AC (is it directly
       connected, L2 switched, or L3 routed?) -- this also helps us to
       understand the deployment scenarios.
   6.  Security threat analysis: what kinds of threat introduced by the
       split architecture, and how that are addressed.
   7.  Pros and Cons of this architecture, esp. in relation to the four
       problems described in the CAPWAP problem statement. Please keep
       the analysis at technical instead of marketing level.

























Yang (Editor), et al.    Expires October 15, 2004              [Page 40]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix B.  Survey Contribution For Architecture 1

   (1) Design considerations and requirements:

   please briefly describe your design principles for this architecture.

   Ease of deployment, flexibility to deploy in any network
   architecture, simple, centralized management, secure deployments, and
   automation of WLAN configuration, monitoring, and management
   functions are the design goals of this architecture.

   The system consists of three components, the access point (AP), the
   switch or appliance (AC), and the Control System.  For the purposes
   of the CAPWAP work, the Control System can be ignored.

   The AP is "lightweight" in its functionality, compared to traditional
   APs.  The AP implements the "real-time" portions of the 802.11 over
   the air protocol, including RTS/CTS and ACK processing, Beacon
   transmission, Probe Response construction and transmission.  All
   802.11 frames are transferred between the AP and AC in a tunnel.  No
   frames are bridged locally by the AP.  The AP is capable of
   presenting multiple WLANs simultaneously, appearing to be an
   independent AP for each WLAN.

   The AC performs the 802.11 MAC Management functions of authentication
   and association.  In addition, the AC provides the information to
   each AP to configure the operation of each WLAN and to provision the
   AP to operate as a cooperating component of a larger WLAN system.
   The AC performs the bridging function for all data frames entering
   and leaving the WLAN.

   (2) WLAN functions supported:

   Please list the functions supported in this WLAN briefly, but please
   do not send us the entire data sheet. Examples of WLAN functions
   includes all the STA services, Distributed System Services (as
   defined by 802.11), radio resource management and control, load
   balancing, mobility support, WLAN network wide security functions
   (including authentication, encryption for privacy and integrity,
   etc.) and any others not listed here but deemed important in your
   design.

   All 802.11 WLAN functions are provided by this vendor's WLAN system.
   Station services are provided in part by the AP and in part by the
   AC. Distribution services are provided by the AC.  Integration
   services are also provided by the AC.

   a. Beyond those services currently in the 802.11 standard, this WLAN



Yang (Editor), et al.    Expires October 15, 2004              [Page 41]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   system provides WLAN-wide coordinated radio resource management,
   providing both dynamic channel assignment and transmit power control
   in response to local noise and interference measurements at each AP,
   as well as incorporating topology information of the APs in the WLAN
   system.

   b. Rogue detection and containment services are provided, detecting
   both rogue APs (those not part of the WLAN system) and ad hoc
   networks. Containment (prevention of use) is provided through several
   manual and automated methods.

   c. Location services are provided, allowing WLAN devices, both rogue
   APs or ad hoc clients and authorized mobile devices in the WLAN to be
   located to within 3m.

   d. Local IPsec VPN termination in the AC is provided in the AC,
   including forwarding of mobile device security context to other ACs
   as the mobile device roams to APs serviced by those other ACs.

   e. Cross-subnet mobility without any software on the mobile device
   (such as mobile IP or other special client software) is provided by
   the AC.

   f. Access control lists are applied to all traffic from each mobile
   device by the AC.  Access control lists may be configured manually on
   the AC or provided dynamically by AAA attributes for individual
   users.

   g. Dynamic QoS provided via configuration on the AC or from AAA
   attributes for individual users.

   (3) The functional architecture to implement the functions described
   above: whether it is by autonomous AP architecture, or "split"
   architecture. For split architecture, please provide the functional
   mapping of WLAN functions onto the AP and AC -- with just enough
   details that help us understand the kinds of functional interface
   necessary between the two.

   This architecture uses a "split MAC" architecture.  The mapping of
   WLAN functions to the AP and AC are as follows:

   On the AP:

   a. real-time frame exchange over the air (RTS/CTS, Data/ACK),
   including retransmission and rate adaptation

   b. time critical MAC Management (Beacon, Probe Response)




Yang (Editor), et al.    Expires October 15, 2004              [Page 42]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   c. Virtual AP (multiple SSID)

   d. power management packet buffering

   e. RF monitoring (radar detection, noise measurement, interference
   measurement)

   f. LWAPP encapsulation/decapsulation of all frames to/from AC

   g. L2 encryption

   h. L2 QoS

   On the AC:

   a. LWAPP encapsulation/decapsulation of all frames to/from APs

   b. MAC Management processing (authentication, association)

   c. 802.1X/EAP processing

   d. Bridging between 802.11 and 802.3 (integration services)

   e. Configuration of RF parameters for all APs

   f. Provisioning of multiple WLANs

   g. Load balancing between APs

   h. Mobility management between APs and between multiple ACs.

   i. L3 encryption (IPsec VPN)

   j. Access control lists for mobile devices

   k. Location services

   l. Proxy ARP

   m. DoS detection and prevention

   (4) The protocol used in between AP and AC.

   LWAPP (draft-calhoun-seamoby-lwapp-03.txt), operating at either L2 or
   L3.

   (5) The topological assumptions between AP and AC (is it directly
   connected, L2 switched, or L3 routed?) -- this also helps us to



Yang (Editor), et al.    Expires October 15, 2004              [Page 43]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   understand the deployment scenarios.

   There are no assumptions of network topology between AP and AC.

   a. APs may be directly connected to an AC,

   b. There may be an arbitrary L2 switching infrastructure between the
   AP and AC,

   c. There may be an arbitrary L3 network between the AP and AC.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that are addressed.

   Security threats considered:

   a. Interception of control traffic between AP and AC

   b. Insertion of control traffic to AP or AC

   c. Insertion of unauthorized AP

   d. Theft of embedded secrets in APs

   e. Access by unauthorized user

   f. Masquerade as authorized user

   g. DoS threats

   h. ARP spoofing

   Methods used to address security threats (letter of method
   corresponds to same letter of threat, above)

   a. All control traffic between AP and AC is encrypted using dynamic
   session key negotiated using authenticated DH exchange

   b. All control traffic is authenticated in encrypted LWAPP tunnel

   c. APs include individual X.509 certificates to validate identity.
   AAA authentication may also be used to validate individual APs.

   d. There are no secrets in the AP that are in non-volatile memory.

   e. Several user authentication methods are supported, including a
   local authentication via web login, IPsec VPN, 802.1X, WPA, WPA2.




Yang (Editor), et al.    Expires October 15, 2004              [Page 44]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   f. AC maintains address equivalence mappings to prevent masquerade

   g. AC detects DoS attacks and provides system-wide black listing of
   attacking device.

   h. AC provides proxy ARP functions and black lists any device
   spoofing ARP replies.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   All problems described in the problem statement are addressed with
   this solution.  In addition, significant additional functionality is
   provided by the centralization of information in the ACs.




































Yang (Editor), et al.    Expires October 15, 2004              [Page 45]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix C.  Survey Contribution For Architecture 2

   There is considerable ambiguity in the use of the term AP within and
   outside this group. I would like to propose a change in terminology
   that the CAPWAP design team should use in the taxonomy draft.

   I had sent an earlier email to this group on re-defining the term AP
   to mean the set of functions that an access point is expected to
   provide as defined in the 802.11 spec. The physical box that
   terminates the infrastructure side of the wireless link is referred
   to as the wireless termination point (WTP). For implementation
   purposes, the set of AP functions MAY be split between the WTP and
   the AC.

   This document uses the terms "AP" and "WTP" according to the above
   definitions.

   (1) Design considerations and requirements: please briefly describe
   your design principles for this architecture.

   Secure, scalable, large-scale WLAN deployments.

   The AC was designed to be much more than a manager of physical
   Wireless Termination Points (WTPs). All 802.11 data traffic passes
   through a stateful, per-user firewall at the AC before it is allowed
   to enter the network beyond the AC. The AC offers termination of both
   802.11 L2 security and L3 VPNs including configurations that support
   simultaneous operation of both L2 and L3 encryption.

   The WTPs are meant to terminate the infrastructure side of the
   wireless physical link. They are meant to be very intelligent devices
   from an RF perspective (monitor the RF environment around them to aid
   radio resource management), but are very simple devices with user
   state limited to rate adaptation, retransmissions, and power-save
   buffering, no security state and no persistent configuration
   information.

   The connectivity between a WTP and an AC should be very flexible with
   support for three modes - directly connected, connected across an L2
   cloud, and connected across an L3 cloud.

   All configuration is centralized at the AC. The WTPs discover one or
   more ACs to home to and, after mutual authentication, setup multiple
   tunnels that are routable over an L3 cloud to carry control/
   configuration information and 802.11 mgmt/data frames. The control
   tunnels are encrypted while the encryption on the tunnels carrying
   802.11 traffic can be configured to be encrypted.




Yang (Editor), et al.    Expires October 15, 2004              [Page 46]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   All user and security state is maintained at the AC, with the user
   state at the WTP limited to rate adaptation, retransmissions, and
   power-save management. The access control is based on a model of
   assigning roles to users. The mapping of a user into a role is based
   on a very flexible set of configuration options. A set of firewall
   rules associated to each role, including bandwidth contracts and QoS,
   control the traffic flow between a user the network behind the AC.

   The ACs provide dynamic radio resource management aided by
   measurements at the WTPs.

   (2) WLAN functions supported : Please list the functions supported in
   this WLAN briefly, but please do not send us the entire data sheet.
   Examples of WLAN functions includes the STA services, Distributed
   System Services (as defined by 802.11), radio resource management and
   control, AP load balancing, mobility support, WLAN network wide
   security functions (including authentication, encryption for privacy
   and integrity, etc.) and any others not listed here but deemed
   important in your design.

   All of the AP functions as defined in the 802.11 spec

   Load-balancing across WTPs is achieved by exploiting the wider view
   of the RF network that an AC has than what is available at the WTP.

   Intra-AC handoffs, where a station roams between two WTPs homed to
   the same AC, are very quick with a simple table update at the AC.
   Inter-AC handoffs requiring inter-VLAN mobility are supported with
   proxy mobile IP.

   Multiple authentication methods and multiple encryption ciphers (both
   L2 and L3).

   Flow classification and bandwidth contracts for QoS.

   Virtual APs (multiple SSIDs per AP).

   Radio resource management functions are handled by the AC based on
   measurements at the WTPs.

   (3) The functional architecture to implement the functions described
   above: whether it is by autonomous AP architecture, or "split"
   architecture. For split architecture, please provide the functional
   mapping of WLAN functions onto the AP and AC -- with just enough
   details that help us understand the kinds of functional interface
   necessary between the two.

   The set of AP functions is split between the WTP and the AC. All



Yang (Editor), et al.    Expires October 15, 2004              [Page 47]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   real-time (RT) functions stay at the WTP, while all non-RT functions
   are handled at the AC.

   All 802.11 basic media access functions are performed at the WTP. All
   802.11 control frames are generated and processed at the WTP.

   A majority of 802.11 management frames are processed at the AC.
   Beacon frames are generated at the WTP. Power-save management,
   retransmissions, and rate adaptation are implemented at the WTP.
   802.11 authentication and association frame processing is implemented
   at the AC.

   Translation of 802.11 data frames to 802.3 frames is implemented at
   the AC. All 802.11 data frames are tunneled over to the AC in the
   uplink direction while the AC tunnels 802.11 data frames to the WTP
   in the downlink direction. Other 802.11 data frame processing
   functions like encryption and fragmentation and reassembly are
   performed at the AC.

   (4) The protocol used in between WTP and AC.

   Discovery: An WTP is able to discover one or more ACs to authenticate
   with and home to using either static configuration or dynamic,
   run-time discovery methods that work across L2/L3 boundaries.

   Configuration: Configuration is transported through an encrypted
   tunnel back to the AC.  This uses a secure and proven architecture
   while also allowing for each individual WTP to be accounted for and
   monitored at a back-end Radius server.  Each WTP can have its own set
   of access information to differentiate itself from other WTPs.  This
   allows the AC to control access on a per WTP basis.

   Transport: Tunnels (optionally encrypted) that are capable of
   spanning L3 boundaries between an WTP and an AC carry all 802.11
   frames. The 802.11 frames are terminated at the AC - so encryption,
   fragmentation/reassembly, and 802.11-802.3 translation are moved to
   the AC. This also means that if the 802.11 data frames are encrypted
   on the air interface, they are encrypted on the tunnel even if the
   encryption on the tunnel is not turned on.

   (5) The topological assumptions between WTP and AC (is it directly
   connected, L2 switched, or L3 routed?) -- this also helps us to
   understand the deployment scenarios.

   Supports all three of

   - directly connected




Yang (Editor), et al.    Expires October 15, 2004              [Page 48]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   - L2 connected

   - L3 connected

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that are addressed.

   Full control of the WTP may be gained through the proprietary
   messaging for configuring the WTP.  Addressed by encrypting the
   tunnel carrying the configuration to protect this information.

   If the WTP is stolen, a hacker may be able to extract the security
   information required to setup the encrypted tunnel. Addressed by
   protecting this security information with additional encryption.

   If the WTP is stolen, it would still appear to be possible to connect
   to the WTP from another wireless client and gain access to the
   network.  This is addressed by the stateful user firewall in the same
   central location at the AC.  The stolen WTP may connect to the AC,
   but it will still be unable to pass meaningful traffic through the AC
   until the client authenticates itself.

   Possible to masquerade as a different user once a particular
   authentication has passed through due to having several devices being
   involved.  Addressed by keeping all encryption and firewalling at the
   AC to prevent any type of masquerading.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   Problem #1, #2, and #3 are addressed by keeping all configuration and
   dynamic information in one central location.  Problem #4 is protected
   by an encrypted tunnel created between the WTP and AC.  Security
   threats discussed in question #6.
















Yang (Editor), et al.    Expires October 15, 2004              [Page 49]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix D.  Survey Contribution For Architecture 3

   (1) Design considerations and requirements:

   - Secure mobility that scales.

   - User based subnet membership independent of AP association.

   - No client specific code.

   - AP requires no configuration.

   - AP is not capable of autonomous function.

   - Split MAC (ARCH2).

   (2) WLAN functions supported:

   - WPA.

   - WME.

   - AP Load Balancing.

   - Inter-subnet Mobility support.

   - Multiple Authentication Types: MAC-AUTH, WEB-AUTH, DOT1X. AC speaks
   EAP or forwards to RADIUS server.

   - Subnet Membership determined through AAA.

   - Multiple subnets per SSID.

   - Multiple SSIDs/BSSIDs per radio.

   - Multiple Encryption types per radio WEP, TKIP, AES(CCMP).

   - Rouge AP detection, location and countermeasures.

   - Auto or Static RF configuration.

   (3) The functional architecture to implement the functions described
   above:

   - Split MAC (ARCH2).

   - AP:




Yang (Editor), et al.    Expires October 15, 2004              [Page 50]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      + Per packet QoS.
      + Encryption.
      + 802.11 Control Frames.

   - AC:
      + 802.11 Management.
      + QoS Classification.
      + 802.1x.
      + All Configuration/Management and Image Control.
      + L2 forwarding (could be moved to AP).

   (4) The protocol used in between AP and AC.

   - IP tunnels.

   (5) The topological assumptions between AP and AC (is it directly
   connected, L2 switched, or L3 routed?)

   - All of the above.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that are addressed.

   - PTK/GTK transmitted between the AC and AP and must be encrypted.

   - 802.11 station data is transmitted between the AC and AP and may be
   encrypted.

   - AP authentication. AP is authenticated by the AC. It is not
   required that the AC is authenticated by the AP as it would violate
   the zero configuration requirement. An unauthenticated AC reduces to
   a rogue AP and there are other techniques to deal with that.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement.

   - Cons:

   + Assumes the AC is in a trusted network.

   - Pros:
      + Scaling configuration and management.
      + Fast roaming.
      + Encryption processing is distributed to APs but centrally
      controlled.
      + Zero configuration AP - a lost or stolen AP has no sensitive
      information.




Yang (Editor), et al.    Expires October 15, 2004              [Page 51]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      + Extends wired subnet partitioning to wireless network based on
      user not location.

















































Yang (Editor), et al.    Expires October 15, 2004              [Page 52]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix E.  Survey Contribution For Architecture 4

   (1) Design Considerations and Requirements

   The following is a short list of our major technical requirements
   that were used to drive the design of products in this architecture:
      Full functionality and compatibility for current and future 802.11
      standards
      Keep the set of functions in the AR to the absolute minimum while
      pushing as much functionality up to the AC.
      Allow existing, installed Access Points (APs) to be converted into
      an AR with a simple firmware change. This allows many new
      functions to be added to legacy infrastructures since most of the
      new functionality is in the AC.
      Ensure the system provides as much security as the Access Point
      Model
      Provide a platform for "mobility" and other added value functions

   (2) WLAN Functions Supported
      All current 802.11 standards (a,b,e,i,g,....)
      Multiple BSS/ESS operation on both the AC and AR
      802.1p/q support
      Enhanced QoS services
      Support for enhanced WLAN functions to support
         Fast Roaming / Fast Handoff
         Voice over IP support
         Enhanced Power Management for Clients
         Load Balancing and other Mobility Features

   (3) Functional Architecture

   The basic operation is as follows: System operation begins with the
   boot and adoption process. The AR contains only a small boot loader
   that does not include any RF code and must downloaded with runtime
   code from the AC. Once the code is downloaded from the AC into the
   AR, the AR is configured with the runtime parameters by the AC. This
   involves some initial packets that contain channel, power,
   addressing, number of supported BSSs, beacon times, etc.. It also
   involves an ongoing process that updates the AR with beacon
   information, such as the content of the TIM field as well as load
   information. Hence configuration is both a one-time event and a
   continuing event. Once the AR is configured it is ready to begin
   beaconing and respond to packets from MUs. Fully formatted 802.11
   packets are encapsulated and sent over the L2 network from the AC to
   the AR for transmission. Each packet sent by the AC to the AR
   generates a status result back to the AC from the AR.  Sequence
   numbers are used to ensure delivery. Packets received by the AR from
   the radio(s) are encapsulated and forwarded over the L2 network to



Yang (Editor), et al.    Expires October 15, 2004              [Page 53]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   the AC. A key concept is that the ARs are stateless insofar as Mobile
   Units (MUs) are concerned. The AR really does not know about Mobile
   Units.  If a packet is addressed to the AR, it will accept it,
   generate an acknowledgement packet, and then forward the packet to
   the AC in an encapsulated Ethernet frame of an EtherType allocated to
   this vendor.

   The functions performed by the AR once it is loaded, configured, and
   running consist of:
      Basic RF packet transmit tasks such as: Preamble selection, PHY
      interface, Packet CRC, and Sequence number generation
      RF Packet reliability mechanisms such as: Retransmission timers,
      retries, ACK packets and reception
      RF Channel Access and exchange timings (SIFS, etc.). This includes
      RF QoS queuing
      RF Packet reception including: checking PLCP headers, address
      filtering, basic address checking, and packet CRC checking
      Generation of Beacons and DTIM broadcast packet transmission
      Handling of Probe/probe response and RTS/CTS sequences
      Interface to the wired network.
      Status reporting to the AC including per packet results and as
      well as global counters
      Packet Buffering for immediate RF transmit scheduling purposes

   The functions performed by the AC include:
      Association and authentication
      Key management, key mixing, etc.
      Packet format conversion between 802.11 and 802.3
      Encryption/MIC using multiple algorithms WEP, WPA, AES, etc..
      Packet/user level buffering and QoS scheduling
      Address filtering (collecting packets off the wired/wireless
      network for Mobile Units)
      802.1 p/q mapping to 802.11 priority classes
      Support for QoS mechanisms
      Communication between different ACs
      Management and configuration utilities like Telnet, HTML, SNMP,
      etc.

   (4/5)  Topological Assumptions/encapsulation protocol

   This implementation currently uses an L2 protocol in an EtherType
   frame allocated to this vendor. This allows the AR and the AC to
   either be directly connected or connected via one or more L2
   switches. Since this AC supports multiple VLANs, the ARs may be on
   one or more different VLANs and these VLANs may be different than
   those upon which the Mobile Units logically reside.

   We chose the L2 operation as the best model for AC and AR



Yang (Editor), et al.    Expires October 15, 2004              [Page 54]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   connectivity for several reasons.

   The first is that it is consistent with the goal of keeping the AR as
   simple as possible. The AR does not require an IP address, subnet
   mask, or default gateway nor does it need DHCP, SNMP, ICMP, UDP,
   etc..  In addition, there is no need to pre-configure the AR prior to
   installation. The AR is truly a zero configuration device.  The
   configuration of the AR takes place entirely at load time. If the AR
   had to support additional networking protocols the AR would have to
   become much like a regular "fat" Access Point and most of the
   management advantages of the AR/AC model are seriously diluted.

   The second reason is that current Access Points are L2 devices. Since
   the AC/AR model represents a different partitioning of access point
   functionality, it seemed reasonable that the combined AC/AR should
   also be L2 device.

   The third reason is that L2 operation is more secure than L3
   operation.  More discussion of this issue follows in section 6.

   (6) Security Threat Analysis

   The security concerns with a split architecture can be divided into
   two general areas: User data security and system management security.

   User data security is concerned with both unauthorized access to the
   wired network as well as privacy of the user data. Both are
   automatically taken care of in our model since the user data from MUs
   remains encrypted using the "over the air" security mechanisms used
   by 802.11. The AR-AC is essentially treated as another RF "hop" and
   hence is as secure as the AR-MU link. In addition all 802.11 packets
   are encapsulated in Ethernet frames and are addressed only to either
   the AR or the AC. Such packets cannot  "escape" onto or from the
   wired network since they are always inside properly addressed
   Ethernet packets. Given these two mechanisms, nothing else is
   required to ensure both secure network access and user privacy.

   System management security is essentially concerned with "hijacking"
   of the AR by "a rogue AC." The worry here is that another station on
   the network may pretend to be the AC and take control of the AR. If
   this happens the AR may be mis-configured or taken control of
   entirely to become part of a virtual "rogue" AP.

   In this architecture system management attacks are unlikely to take
   place and can be easily detected. Given the communication between the
   AR and AC takes place at L2, any attacker would need to be on the
   same subnet (or VLAN) as the AR and AC. This implies the user already
   has physical access to the network and so the network is already



Yang (Editor), et al.    Expires October 15, 2004              [Page 55]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   compromised. Attacking an AR when one already has physical access to
   the network is pointless.

   Should an attacker still try to mis-configure a working AR by
   pretending to be the actual AC, it must send a packet with the same
   source address as the actual AC since the AR verifies the source
   address of all frames it receives. If this occurred the L2 switch
   would reconfigure itself to direct all traffic for the actual AC to
   the rogue AC and essentially isolate the actual AC. That AC would
   quickly detect this and notify an administrator as well as shut down
   the WLAN.

   Boot time attacks will also be detected by the actual AC since it
   will see the boot request and also respond to the AR.

   It should be noted that a rogue AR and rogue AC do not present any
   threat to Mobile Units provided the Mobile Units follow the proper
   standards for mutual authentication.  From a Mobile Unit perspective
   a rogue AP/AC combination is equivalent to a rogue Access Point.

   Hence our split network model introduces no new security issues over
   a conventional Access Point model and in fact offers greater
   security.

   (7) Pros and Cons of Architecture

   Overall we are quite satisfied with our current architecture.  The
   basic model has been implemented on a number of AR and AC devices
   without any problems. We have also successfully upgraded old 802.11
   Access Points to support the latest encryption protocols like WPA and
   AES.

   There are of course areas of enhancement. One is the location of the
   transmit side of the encryption process. Some of our current ARs are
   built with chips that did not support all desired encryption
   algorithms but going forward the chips we use to build future ARs
   will likely include such functionality. It would be nice to be able
   to take advantage of this capability on new ARs while also supporting
   the older ARs.












Yang (Editor), et al.    Expires October 15, 2004              [Page 56]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix F.  Survey Contribution For Architecture 5

   Abstract

   This document describes an architecture for residential WLAN
   deployments. It presents simple equipment for consumers while
   complexity and overall network management are left to service
   providers. Additionally, it also integrates radio-over-fiber (RoF)
   technology to provide network services to common areas outside
   individual residences.

   1. Introduction

   This architecture includes a set-top box (STB) at the consumer's
   residence, a radio-over-fiber (RoF) antenna in common areas around a
   number of residences and a controller at the service provider's
   premises. The STB wirelessly streams data and media content to other
   products like TVs and display consoles. It is also capable of PHY
   layer and partial MAC layer processing for wireless transmissions to
   other client devices. An antenna structure outside individual
   residences provides network access to common areas. This is in
   conjunction with the service provider's controller by means of
   radio-over-fiber transmissions.

   This document describes the Broadnow+ WLAN architecture with respect
   to the needs of the CAPWAP Architecture Taxonomy document.

   2. Design Considerations and Requirements

   Broadnow+ is based on a high-speed, dedicated backbone between STBs,
   RoF antennas and the central controller. This allows for flexibility
   in the physical location of various processing requirements.

   The central controller realizes complete IEEE802.11 functionality
   including PHY layer aspects. It then performs selective degrees of
   processing for different destinations, i.e., for STBs, RoF antennas,
   and other devices. The controller is also responsible for overall
   network management including client authentication and channel
   adaption.

   STBs process IEEE802.11 PHY layer functionality and IEEE802.11 MAC
   layer association services for all transmissions. In addition, they
   implement proprietary MAC functionality for transmissions to other
   devices of this vendor like TVs. These functions are designed
   primarily for transmitting media to high-resolution displays. For
   transmissions to other client devices however, the STBs only perform
   IEEE802.11 PHY and IEEE802.11 MAC association services. The remaining
   IEEE802.11 MAC services are left to the central controller. .



Yang (Editor), et al.    Expires October 15, 2004              [Page 57]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   The antenna used for radio-over-fiber transmission is a very simple
   device. It merely performs optical to electrical conversions and
   transmits the resulting radio signals. This places the need for
   high-speed, fiber connectivity between the antenna and controller. As
   such, this requirement is being increasingly met in the residential
   market place..

   Mobility concerns in the residential environment are present albeit
   slightly. It is highly unlikely that clients will roam to neighboring
   residences for network access. As such, this is not dealt with in
   great detail in the Broadnow+ architecture. However, it is necessary
   to ensure that rogue clients do not take advantage of legitimate
   customers by exploiting their subscriptions. Appropriate
   authentication mechanisms between client devices and the controller
   are used to avoid this.

   3. WLAN Functions Supported

   The controller is a powerful device capable of processing complete
   IEEE802.11 functionality which are then selectively performed for
   STBs and radio-over-fiber transmissions. It includes support for QoS,
   security and control. The various functionalities are realized as a
   combination of individual components of fine granularity. Such an
   implementation ensures that the controller can accurately provide
   complementary functions to the end-devices. Algorithms and procedures
   for transmit power control, channel selection and interference
   management are performed at the controller and the resulting control
   signals are forwarded to the STBs and antennas. In terms of security,
   the controller terminates MAC layer encryption for both proprietary
   and other end-devices of the STBs.

   Authentication requirements in the residential environment are as
   stringent as those in enterprises. It is important that rogue clients
   do not take advantage of legitimate consumers, i.e., no free riders.
   As such, authentication is performed at the controller for all
   clients accessing the STBs and RoF antennas.

   The STBs include full fledged capabilities (MAC + PHY) for
   transferring content to products such as TVs and display consoles.
   However, they feature only light weight wireless capabilities for
   transmissions to other client devices, leaving the bulk of operations
   to the controller. Overall the STBs are capable of channel
   measurements, feedback to the controller, transmit power adjustments
   etc. In general the STBs are able to process IEEE802.11 PHY and
   IEEE802.11 MAC association services. They also include proprietary
   MAC aspects for transmissions to other devices from this vendor.

   4. Functional Architecture



Yang (Editor), et al.    Expires October 15, 2004              [Page 58]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   The STBs combine two different WLAN functional architectures for the
   transmissions to proprietary and other clients, respectively. For
   proprietary clients, the architecture consists of IEEE802.11 PHY and
   IEEE802.11 MAC association services. The remaining MAC
   functionalities are proprietary. For other clients, STBs only process
   IEEE802.11 PHY IEEE802.11 MAC association services, leaving the
   remaining IEEE802.11 MAC operations to the controller. For both types
   of transmissions, control aspects are handled by the controller based
   on feedback sent by the STBs.

   In addition to these two functional architectures, Broadnow+ also
   includes radio-over-fiber capabilities. As such, the end-device is a
   simple antenna capable of making optical to electrical conversions
   and broadcasting the resulting radio signals. The RoF antenna also
   includes logic to sense channel conditions and to send this back to
   the controller for analysis and further action.

   The controller, at a central location, accommodates these three
   functional architectures. It includes the complete WLAN functionality
   based on IEEE802.11 standards. For transmissions to proprietary
   clients, it merely acts as authenticator and channel manager. For
   other clients, it processes the remaining IEEE802.11 MAC
   functionality after having the STBs process IEEE802.11 MAC
   association and IEEE802.11 PHY services. And for RoF transmissions,
   the controller performs complete IEEE802.11 MAC and PHY processing
   before making the electrical to optical conversions. In all three
   cases, the controller is responsible for overall control and
   management.

   Based on these descriptions, the degree of wireless functional
   implementation in this architecture is different for the type of end-
   devices. In terms of CAPWAP, these constitute three different types
   of functional architectures/splits.

   5. AP-AC Protocol

   This is a proprietary protocol.

   6. Topological Assumptions

   The connection between the controller and STBs is high-speed and
   dedicated. This includes coax, ADSL and fiber. As such, the topology
   is that of direct connection.

   7. Security Threat Analysis

   When fiber is used for the dedicated connections, it allows for
   strong physical security. In addition to this, Broadnow+ incorporates



Yang (Editor), et al.    Expires October 15, 2004              [Page 59]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   cryptographic security for exchanges between the controller and STBs.
   The STBs are hard-coded with a seed with which session keys are
   generated. These keys are then used to encrypt transmissions between
   the controller and STBs. The cryptography mechanism also uses SD card
   based seeds for session key generation. So in addition to strong
   physical security, the architecture also includes another level of
   cryptographic security.

   8. Architectural Analysis

   The primary advantage of implementing WLAN functionality in
   fine-grained components is to allow flexibility in the functional
   architecture. For now, this allows for the distinction of
   transmissions to proprietary and other clients. Additionally, it
   provides for integral management from the Broadnow+ controller.
   Broadnow+'s relatively light implementation for transmissions to
   other devices leads to lower costs for STBs. For the service
   provider, this architecture allows a management premium to be levied.
   As such, this architecture for wireless media content and data
   delivery offers increased benefits for both consumers and service
   providers.

   9. Conclusion

   This document has presented an architecture for residential WLANs. It
   combines wireless transmission functionality to proprietary and other
   client devices. For proprietary devices, STBs use standard IEEE802.11
   PHY and IEEE802.11 MAC association services in addition to a
   proprietary MAC, optimized primarily for transmissions to proprietary
   TVs and display consoles. For other devices, the STBs adopt a split
   where IEEE802.11 PHY and IEEE802.11 MAC association services are
   handled locally while the remaining IEEE802.11 MAC services are left
   to the controller. And for radio-over-fiber transmissions, Broadnow+
   consolidates all IEEE802.11 processing at the controller without
   using any split. The secure, low-latency connection between the
   controller, STBs and RoF antennas blur any distinction in WLAN
   functionality based on real-time requirements.














Yang (Editor), et al.    Expires October 15, 2004              [Page 60]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix G.  Survey Contribution For Architecture 6

   (1) Design considerations and requirements:

   This Wireless Switch Architecture consists of Thin APs and
   Controllers. It has been designed with the following considerations:

   - Thin APs should be cheap. This leads to a requirement that the thin
   AP be as simple as possible, with very low flash and ram
   requirements.

   - There will be many Thin APs in the network, so to reduce
   installation and maintenance cost they should require zero
   configuration. This leads to a requirement that configuration be
   served from the Controller or some other entity, and that some method
   for auto-discovery must exist where possible. In addition
   configuration of the RF parameters should be automatic.

   - The widely physically distributed nature of Thin APs leads to a
   frequent requirement that thin APs may be used in physically insecure
   environments. This leads to a requirement that user data not be
   encrypted/unencrypted on the thin AP but rather at the Controller.
   This allows the network's trust boundary to be placed at a physically
   secure location. In addition this allows novel new deployment
   scenarios - such as placing an AP in tele-commuters home without any
   VPN setup.

   - Thin APs and controllers should be deployable as simply as possible
   on top of the current legacy network infrastructure. This leads to a
   requirement that all communications be at Layer 3 rather than Layer 2
   or direct. In addition the use of a VLAN aware infrastructure is
   precluded, and some method of cross-subnet discovery must be
   specified.

   - Rogue APs should not pose a security problem. This leads to a
   requirement that rogue APs be remotely detectable by Thin APs, and
   that Rogue APs may be remotely investigated and secured by Thin APs.

   - Wireless clients should be able to roam seamlessly between thin
   APs. This leads to a requirement that wireless clients retain their
   IP addresses, which in turn leads to a requirement that something
   equivalent to Mobile IP be used in large scale deployments.

   - Redundancy and load sharing. Both Thin APs and Controllers should
   be configured in redundant and load balanced configurations to
   provide maximum uptime and throughput.

   - Theft of thin APs should not pose a security problem. This leads to



Yang (Editor), et al.    Expires October 15, 2004              [Page 61]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   a requirement that thin APs should have no encryption keys in
   non-volatile memory. In addition since thin APs cannot work as
   standalone APs they are less likely to be stolen individually.

   (2) WLAN functions supported:

   ****All functions are supported:

   - Wireless client association and authentication

   - Radio Resource Management and Control

   - Load balancing of wireless clients between thin APs

   - Load balancing of thin APs across Controllers

   - EAP user authentication

   - WEP, WPA and IEEE 802.11i encryption, including TKIP and AES-

   CCM for wireless frames

   - Seamless wireless client roaming between thin APs

   - DS services via the thin AP Controllers

   - Detection of authorized APs

   - Authentication and encryption of all control traffic between APs
   and Controllers

   (3) Functional Architecture

   ****The architecture uses a split MAC, with the thin APs and
   Controllers communicating over a Layer 3 cloud.

   Only the most timing sensitive functions are performed at the Thin
   APs  - All PHY layer functions, and these parts of the MAC -
   transmission and reception of MPDUs, CRC generation and checking, ACK
   generation, NAV, retries and the EDCA, priority queuing. TSF (Beacon
   and Probe response timestamp insertion). Multicast Power-save frame
   delivery. Raw MPDUs as seen on the wireless medium are exchanged with
   the controller encapsulated within UDP. Note - these MPDUs are not
   decrypted at the Thin AP and so any user data remains protected by
   whatever encryption mechanism is in use over the wireless network.

   The Controller can also act as a Mobile IP proxy on behalf of the
   wireless client (according to configuration). This allows seamless



Yang (Editor), et al.    Expires October 15, 2004              [Page 62]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   roaming across thin APs connected to different controllers.

   (4) The protocol used in between AP and AC.

   ****Each thin AP has one master controller and may have many backup
   Controllers. These are discovered during Boot and Discovery. On boot,
   the thin AP uses DHCP or static configuration to get its IP address
   and DNS server addresses. We specify 4 methods for discovering the IP
   address of the master Controller: DHCP, DNS, local subnet discovery
   and manual configuration. Once the master Controller is detected, the
   thin AP downloads a signed firmware image by TFTP.

   From then on Control messages are exchanged using SSL. A set of
   control messages has been defined using an ASCII format.

   User data is covered in (3) above.

   (5) The topological assumptions between AP and AC (is it directly
   connected, L2 switched, or L3 routed?) -- this also helps us to
   understand the deployment scenarios.

   ****L3 routed. This allows us to deploy one or more controllers
   anywhere on the user's LAN and the thin APs to be on distant subnets.
   The only limitation is the capabilities of the user's LAN and LAN
   switches: if the APs are too far from the controllers then traffic
   will be crossing multiple switches which is inefficient. In addition
   any broadcast traffic destined to the wireless network may have to be
   multicast across many subnets.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that are addressed.

   Our security architecture significantly reduces security threats - by
   moving the trust boundary to the Controller - which may be placed in
   a physically secure location, and protected by firewalls. In
   traditional 'fat AP' architectures anyone with access to the network
   behind the 'fat APs' may inspect or tamper with traffic. In our
   architecture since the raw 802.11 frames that are seen over the air
   are transported to the controller this threat is significantly
   reduced. These frames are protected by whatever wireless security
   policy and mechanism has been selected. Our controllers implement WPA
   and 802.11e to provide a high level of security.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   **** We address all 4 problems:



Yang (Editor), et al.    Expires October 15, 2004              [Page 63]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   - Management and Control: The Controllers serve firmware and
   configuration to the thin APs and the thin APs require zero manual
   configuration, so the only entities that need to be managed are the
   Controllers themselves.

   - Configuration Consistency: Since the Controllers automatically
   control configuration across all thin APs, configuration consistency
   is maintained across the entire WLAN deployment

   - RRM to optimize WLAN efficiency: Again, since the Controllers see
   all 802.11 MAC traffic they know the instantaneous load on each thin
   AP, and can perform load balancing.

   - Unauthorized APs: Controllers are aware of any Unauthorized APs and
   can detect and prevent their use.




































Yang (Editor), et al.    Expires October 15, 2004              [Page 64]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix H.  Survey Contribution For Architecture 7

   (1) Design considerations and requirements:

   Goal: Offer an easy-to-use solution for large installations of APs in
   terms of provisioning, controlling, scalability, plug&play, and
   mobility across subnets/vlans.

   In a nutshell, the 802.11 protocol suite terminate at the AP, which
   translates 802.11 data frames to 802.3 frames and send them to the
   AC. All STA traffic hit the AC. AC provision and control AP. WLAN
   "control" capabilities are embedded at the AC.

   (2) WLAN functions supported:

   All 802.11 services are supported:

   AP responsibilities:

   - 802.11 MAC

   - WEP/WPA Encryption/Decryption

   AC responsibilities:

   - STA services (authentication, association, etc.)

   - Integration

   - Distribution

   - Load Balancing

   - Rogue AP detection

   - Managing and controlling APs

   - Mobility

   - ACL/QoS policies.

   (4) The protocol used in between AP and AC.

   The AC and the APs communicate using a proprietary UDP transport,
   which is encrypted.

   (5) The topological assumptions between AP and AC




Yang (Editor), et al.    Expires October 15, 2004              [Page 65]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   At present only direct connection is supported. The next step would
   be to support connections across layer 2 and 3.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture,and how that are addressed.

   Several aspects of security threats were addressed:

   STA traffic Over the Air - AP responsibility (WEP, WPA, etc')

   AC to AP control/provision - communication is authenticated and
   encrypted over a private UDP communication channel.

   AC to AC - Authentication and encryption over private UDP
   communication channel.

   AC to AAA - Standard.

   AC to Management station - Security over standard management tool
   such as SSH.

   (7) Pros and Cons of this architecture

   Problem 1: Each AP is an IP-addressable device requiring management,
   monitoring, and control - AC serves as a proxy for managing large
   scale APs.

   Problem 2: Maintaining a consistent configuration throughout the
   entire set of access points in the WLAN - Central management
   application to configure all AC in a wireless domain.

   Problem 3: Parameters controlling the wireless medium on each AP must
   be monitored frequently ... - partially supported, ACs monitoring
   connected APs to provide information to central management station.

   Problem 4: Securing access to the network and preventing installation
   of unauthorized access points & Mutual authentication of AC and AP.
   Supplementary functionality in the shape of Rogue AP detection.













Yang (Editor), et al.    Expires October 15, 2004              [Page 66]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix I.  Survey Contribution For Architecture 8

   (1) Design considerations and requirements:

   The operational and network management challenges for large scale
   (thousands of APs) wireless LANs encompass both the 802.11 layer as
   well as the wired side topological interactions.  The considerations
   and requirements for the architecture presented below are:

   - true layer 3 mobility for wireless mobile clients as they move from
   one AP to another

   - WLAN system scalability - A single AC should be able to control and
   manage a large number of APs (100's of APs)

   - near real time RF management

   - centralized traffic policy management and enforcement

   - centralized control and management of the APs

   - centralized user management

   - architecture must be extensible to other radio technologies

   - architecture must be able to facilitate mobility between different
   MAC architectures (e.g.,. work being done in IEEE 802.21 and IRTF
   MOBOPTS)

   Also, because of the requirement for the deployment of very large
   scale WLANs and the fact that these WLANs must integrate into
   existing wired infrastructures, there should be no consideration (or
   full flexibility) on the topological deployment of ACs and APs.

   (2) WLAN functions supported:

   Access Point:
      - All 802.11 services including
         - association/disassociation/reassociation
         - authentication
         - integration
         - distribution
         - Robust Security (802.11i)
         - QOS (802.11e)
      - radio resource management including load balancing and RF
      management
      - bridging (802.11 to 802.3)




Yang (Editor), et al.    Expires October 15, 2004              [Page 67]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      - link state transition notification to the AC(s)

   Access Controller:
      - centralized forwarding (routing), authentication, encryption and
      policy enforcement of mobile client traffic
      - control and configuration of AP
      - QOS policy enforcement and management
      - user access control

   (3) Functional architecture:
      - AC manages and controls APs
      - L3 state and user sessions are maintained and managed at the AC
      - L2 state and user sessions maintained at the AP and all state
      information is mirrored at the AC
      - The 802.11 MAC is "not" split.  However, it is controlled
      centrally at the AC

   (4) The protocol used in between AP and AC:

   A UDP based tunnelling protocol that has a control channel and a data
   channel.  The control channel carries AP configuration and state
   commands from the AC.  Also, it carries information regarding AP
   state transitions and statistics from the AP to the AC. The data path
   is simply the encapsulation of 802.3 bridged data.  The data-path
   channel is optional. IE., if configured, the data path can be bridged
   locally from the AP and the data does not necessarily have to go
   through the AC.

   (5) The topological assumptions between AP and AC:

   The AC and AP can be directly connected to each other, could be
   connected through L2 switches or any arbitrary L3 cloud.  The
   architecture is tolerant to higher latency between AP and AC.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how those are addressed.

   Since the AP and AC can be separated over any arbitrary L3 cloud,
   first and foremost there is a need for a secure binding between the
   AC and AP.  A control channel security association is required
   between the AC and AP.  The AC and AP must go through a mutual
   authentication phase during a discovery and registration process and
   form a security association.  The traffic is confined to control,
   configuration and management traffic between the AC and AP.

   There is an optional data path security association that can also be
   created.  It is believed that for security sensitive applications and
   deployments there will always be an end to end encrypted tunnel.



Yang (Editor), et al.    Expires October 15, 2004              [Page 68]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   Therefore, a data path encryption mechanism is considered optional
   and configurable based on security policy.

   STA authentication and security policy enforcement is done centrally
   in the AC.

   Over the air privacy and authentication between the STAs and APs is
   accomplished by standard 802.11 privacy methods.  The RSN service is
   the recommended method for over the air privacy and authentication.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   Pros:

   - In this centralized architecture, the AC and AP can be separated by
   an arbitrary L3 cloud which in turn enables large geographic
   distribution of APs within the cloud.

   - This architecture is agnostic to the underlying wired medium
   connecting the AP and AC.

   - This architecture is agnostic to the AP MAC and radio technology.

   - Since the MAC is not split, this architecture supports a deployment
   where the data path is not required to travel through the AC.  This
   may be useful in the "branch office" scenario where the AC may reside
   in a data center and the AP connects to it over a slow WAN link.
   However, the operational control and management of the AP is done by
   the AC.

   - The problems defined in draft-ietf-capwap-problem-statement-00.txt
   are also addressed by this architecture.

















Yang (Editor), et al.    Expires October 15, 2004              [Page 69]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix J.  Survey Contribution For Architecture 9

   (1) Design considerations and requirements: please briefly describe
   your design principles for this architecture.

   The goals are

   1. Simplify WLAN life-cycle management - including design,
   deployment, and management.

   2. Similar user experience on WLAN and Ethernet - WLAN should provide
   same level of networking services as Ethernet. User should feel no
   difference when running application on wired V.S. wireless network.
   Also, network administrators should be able to manage WLAN the same
   way as managing wired network.

   In this architecture, AC performs WLAN configuration, monitoring, and
   policy management function. It controls and manages APs. AC also
   collects information from  APs and, based on configuration, push down
   policies into individual APs. It also serves as proxy for interacting
   with all external networking components(e.g. RADIUS server).

   AP implement all the 802.11 access point function, including all the
   PLME, MLME, STA services, DS, and bridging functions.

   (2) WLAN functions supported:

   Please list the functions supported in this WLAN briefly, but please
   do not send us the entire data sheet. Examples of WLAN functions
   includes all the STA services, Distributed System Services (as
   defined by 802.11), radio resource management and control, load
   balancing, mobility support, WLAN network wide security functions
   (including authentication, encryption for privacy and integrity,
   etc.) and any others not listed here but deemed important in your
   design.

   All 802.11 AP functions are provided. That includes

   1. Distribution System Services.

   2. Radio resources management - channel selection, interference
   detection and avoidance, cell-size control.

   3. Load balancing.

   4. Security.

   5. Power save mode.



Yang (Editor), et al.    Expires October 15, 2004              [Page 70]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   6. QoS.

   7. Station services.

   8. Bridging.

   Besides the list above, this WLAN system provides the following
   functions:

   1. Rogue AP/Ad-hoc network detection and containment.

   2. Location based authentication control.

   3. Dynamic VLAN assignment based on authentication ID.

   4. QoS

   5. ACL

   6. L2/L3.

   7. Multiple VLAN per radio.

   8. Multiple SSID per AP.

   9. Dynamic 802.1p/q tag assignment based on user/location/
   application.

   (3) The functional architecture to implement the functions described
   above: whether it is by autonomous AP architecture, or "split"
   architecture. For split architecture, please provide the functional
   mapping of WLAN functions onto the AP and AC -- with just enough
   details that help us understand the kinds of functional interface
   necessary between the two.

   This WLAN system is a split architecture system.

   AC includes the following functions:

   1. Configuration interface.

   2. Management.

   3. Policy control.

   4. L2/L3.

   5. Proxy RADIUS.



Yang (Editor), et al.    Expires October 15, 2004              [Page 71]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   6. ACL.

   7. AP/AC image and configuration management.

   8. RF monitoring - correlation between APs.

   AP includes the following functions:

   1. 802.11 MAC.

   2. Multiple SSID

   3. Power management.

   4. RF monitoring - data collection.

   5. 802.11 security - including WEP and 802.11i draft.

   6. Integration service.

   7. Location service.

   (4) The protocol used in between AP and AC.

   The following standard protocols are used:

   1. Agent-X : control and management.

   2. LLDP/EDP(Proprietary discovery protocol) : AP/AC discovery.

   3. TFTP : image transfer from AC to AP.

   (5) The topological assumptions between AP and AC (is it directly
   connected, L2 switched, or L3 routed?) -- this also helps us to
   understand the deployment scenarios.

   The system supports L1(direct connect), L2, and L3 connection between
   AP and AC.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that are addressed.

   1. AP does not store runtime image and configuration. Both are pushed
   down from AC. AC takes full control over AP.

   2. Control traffic between AP and AC can be encrypted using SSL.

   3. AP can be authenticated based on identity, that includes MAC, IP,



Yang (Editor), et al.    Expires October 15, 2004              [Page 72]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   serial number, or digital certificate. AC can be authenticated via
   X509 certificate.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   Instead of managing APs, this architecture allows user to deploy,
   control, and manage wireless networks. With distributed data
   forwarding, it maintains the scalability of the autonomous AP
   architecture. It also provides same networking services between
   Ethernet and Wireless network in Layer 2, Layer 3, and beyond.







































Yang (Editor), et al.    Expires October 15, 2004              [Page 73]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix K.  Survey Contribution For Architecture 10

   (1) Design considerations and requirements:

   - Access Controller manages one or more Access Points. Access
   Controllers control and provision the various access points.

   - Access Controller and Access Points can reside in physically
   separated regions (across buildings/oceans).

   - Access Controller and Access Points communicate over a Secure
   Channel and provide facility for mutual authentication.

   - Roaming among Access Points within the domain of one Access
   Controller is possible without any new protocol support. All state
   information is maintained in Access Controller.

   - Bridging within a given SSID. Routing among different SSIDs.

   - If 802.1x/WEP security is employed, it is between wireless stations
   and AP. But AC maintains the keys.

   - AC supports L2TPoIPSEC, if one wants security between end station
   to the Corporate network.

   - Two sessions are maintained between AP and AC, which can be secured
   using IPsec. TCP based session is used to transfer control
   information such as provisioning of APs, events from APs.  UDP
   session is used to transfer the data.

   (2) WLAN functions supported:

   - Radio Resource Management: Access Controllers can configure Access
   Points using the Control Channel. A Request-Response Protocol is used
   on the control channel.

   - DSS: The Access Point shall handle traffic between all stations
   associated with it. For traffic that is targeted to another AP, the
   traffic shall be sent to the Access Controller. The Access Controller
   shall bridge the traffic appropriately, across the appropriate
   bridge/bridge port.

   - 802.1x Functionality: Access Points shall encapsulate 802.1x frames
   to EAPOL frames and transmit to Access Controller. Access Controller
   is responsible for initiating Radius Authentication.

   - WEP Encryption/Decryption of data: Access Points shall handle
   encryption/decryption of data. The Access Controller will maintain



Yang (Editor), et al.    Expires October 15, 2004              [Page 74]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   and program the keys in AP.

   - Handle Roaming Clients: Access Point shall send events of
   Association/Dis-association/Re-association to Access Controller
   through Control Channel. Access Controller maintains session key
   information for every wireless access point association (802.1x),
   Hence when a roaming client moves from one AP to another AP, the
   Access Controller can push the session key information to the Access
   Point through the Control Channel.

   (3) The functional architecture to implement the functions described
   above:

   - Handled in AP: All Radio Functionality/WEP Encryption and
   Decryption; Traffic between Wireless Stations in the same BSS.

   - Handled in AC: Routing/Bridging to another BSS; Maintaining Session
   Keys for each wireless station (to support roaming), initiating
   Radius Authentication.

   - The Control Channel can be used to configure any parameter or read
   any MIB from the Access Point.

   (4) The protocol used in between AP and AC.

   - Control Channel: TCP Transport can be used for Control Frames. The
   Access Point establishes a TCP session with the Access Controller
   when it comes up. When the TCP connection is established the AC and
   AP authenticate each other. Upon successful authentication the Access
   Controller assigns a Unique ID for the AP.

   The control channel shall be used to exchange control information
   between AC and AP.  Control Information is inclusive of image update,
   provisioning, reset, radio management and any MIBs that may be sent
   by Access Point to Access Controller. The AP shall send all 802.1x
   packets from End Wireless Station as EAPOL Packets through the
   Control Channel. The AC shall send the 802.1x responses as EAPOL
   Packets to the AP through the Control Channel. In addition AC can use
   the control channel to push session keys.

   The Access Point shall establish as many control channels as the
   number of radios it supports. For each control channel it
   establishes, the Access Controller shall assign a unique ID. This ID
   will be used in data channel communication between AC and AP.

   The communication between AP and AC shall be in the form of command
   and Response. The AC or AP shall send a command and the recipient of
   the command shall issue a response. This approach can be extended to



Yang (Editor), et al.    Expires October 15, 2004              [Page 75]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   any kind of deployment. (Dumb AP or fully functional AP).

   - Data Channel: The Data Frames can be transmitted using Mac Over UDP
   Encapsulation Mechanism. The MAC frames are encapsulated with UDP/IP
   headers at the transmitting end and de-capsulated at the receiving
   end.

   (5) The topological assumptions between AP and AC: L3 Routed

   (6) Security threat analysis: The AC and AP can mutually authenticate
   themselves through the control channel.

   Both Control and Data Channels are over Transport Layer. This enables
   the possible usage of IPsec, hence provides a secure channel for
   communication.

   Wireless Stations to AP communication can be secure through existing
   mechanisms such as 802.1x

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   - The Control Channel provides a flexible/extensible method to
   support any type of Access Point; i.e. doing management at the Access
   Point itself and/or controlling the management from the Access
   Controller. Hence it can address different market segments.

   - The control channel on TCP allows for easy adoption of IPsec and
   hence addresses the security issues over an otherwise insecure
   channel.




















Yang (Editor), et al.    Expires October 15, 2004              [Page 76]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix L.  Survey Contribution For Architecture 11

   (1) Design considerations and requirements: please briefly describe
   your design principles for this architecture.

   DIRAC is designed to enable efficient implementation of many emerging
   wireless services implemented on the access router. These services
   will be highly adaptive along the following three dimensions:

   a) adaptation to wireless channel dynamics: several services (e.g.,
   schedulers) require knowledge on the channel dynamics (current rate,
   error pattern) and link quality perceived by each mobile host.

   b) adaptation to host mobility: information on host mobility from one
   cell to a neighboring one is required by micro-mobility management
   protocols (e.g., Fast Handovers)

   c) coordinated adaptation across multiple cells: applications such as
   VoIP, admission control, fast handoffs require coordination among
   multiple cells and resource management.

   DIRAC also enables coordination spanning multiple layers in the
   protocol stack, and across multiple geographically adjacent cells. In
   the PHY layer, RF management and collaborative power control over
   multiple neighboring cells can minimize interferences, load balancing
   and MAC filtering in the link-layer can increase performance and
   security, while fast handover at the network-layer can minimize
   transient packet loss. Instead of designing fully distributed
   coordination protocols, a centralized router assisted by router
   agents can serve this purpose, while simplifying the design approach
   and minimizing management overhead at the same time.

   Another design consideration for DIRAC is the separation of protocols
   among the physical entities of the network. DIRAC adopts a generic
   design at the access router, while leaving technology-specific
   functions to the router agent at the AP. This decision leads to a
   lean design, non-intrusive to the IP protocol, and readily extensible
   to other wireless network access technologies such as Bluetooth, 3G/
   4G, 802.11n. Specifically, the access router remains unaware of the
   specifics of the wireless Link-layer/MAC currently used (802.11b) and
   does not directly handle/process link layer-specific frames. Instead,
   the latter is taken care of by the AP.

   Finally, another requirement for the architecture was to be
   economically cost effective along the following dimensions: a)
   complexity of implementation, b) cost of deployment, and c) cost of
   management/operational expenses (OpEx). These requirements lead to a
   centralized design for the access router, supported by a number of



Yang (Editor), et al.    Expires October 15, 2004              [Page 77]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   lightweight, software agents that run at each access point, monitor
   the wireless cell, and expose link-layer mechanisms to higher layers,
   in order to enforce system-wide policies.

   (2) WLAN functions supported: Please list the functions supported in
   this WLAN briefly, but please do not send us the entire data sheet.

   Examples of WLAN functions includes all the STA services, Distributed
   System Services (as defined by 802.11), radio resource management and
   control, load balancing, mobility support, WLAN network wide security
   functions (including authentication, encryption for privacy and
   integrity, etc.) and any others not listed here but deemed important
   in your design.

   DIRAC aims to provide the necessary hooks and systems framework for
   easily enabling as many new wireless services as possible on the
   access router. To this end, the following WLAN functions are
   implemented by the system:

   a) STA services: Authentication, De-authentication, MSDU delivery

   b) Distribution System Services: Association, Disassociation,
   Distribution, Integration, Reassociation

   c) L2 Mobility Support (link-layer handoff)

   d) L3 Mobility Support (network-layer fast Handoff integrated with
   Mobile IPv6)

   e) IP-layer, packet-level, Forward Error Correction and Deficit Round
   Robin scheduling that addresses the Head-of-Line blocking problem

   f) Policing of aggressive flows through MAC-layer (802.11b) filtering

   g) Multi-layer firewalls

   h) Channel statistics for STAs centrally collected

   i) Registration of APs to AR

   (3) The functional architecture to implement the functions described
   above: whether it is by autonomous AP architecture, or "split"
   architecture. For split architecture, please provide the functional
   mapping of WLAN functions onto the AP and AC -- with just enough
   details that help us understand the kinds of functional interface
   necessary between the two.

   The architecture followed by DIRAC can be described as "split",



Yang (Editor), et al.    Expires October 15, 2004              [Page 78]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   although this description is irrelevant to the 802.11 MAC; the latter
   is implemented fully at the AP, while its management and monitoring
   functionality is _exposed_ to (and controlled by) the access router.
   The Access Router runs a link-layer specific software agent on the
   AP, instead of having part of the MAC implemented at the AR.

   In that sense, the mapping between the WLAN functions described above
   is as follows:

   AP : (a), (b), (c)

   AC : (d), (e), (f), (g), (h)

   The interface exposed (and further implemented by the AR-AP
   communication protocol) revolves around three types of information:

   a) Events: occurrence of asynchronous link-layer activity in the
   cell, detected by the access point and reported back to the access
   router control engine. Examples are: new host (association), host
   leaves (disassociation), security binding (authentication), roaming
   host (reassociation), dead cell detection (heartbeat).

   b) Statistics: latest information on channel quality that each host
   perceives, which is location-dependent. Examples of channel
   statistics are: signal-noise ration (dB), frame retransmits (frame
   loss %), CommTallies (detailed statistics), channel quality variation
   (transmission rates), etc.

   c) Actions: mechanisms that are exposed and made available by the APs
   and can be used by the access router, in order to enforce its
   policies. Examples include tuning of the 802.11b MAC protocol
   parameters (e.g., deauthenticate a  client for security reasons),
   configuration settings of the driver (e.g., enter power saving mode,
   set number of retransmissions), PHY setting (e.g.,  adjustment of the
   transmission power), configuring the AP device itself (e.g., re-flash
   the image of the driver/device). In essence, an "action" is whatever
   aspect that can be thought of as a mechanism provided by the AP and
   can be controlled through some policy specified by the access router.

   (4) The protocol used in between AP and AC.

   The protocol used between the Access Router and the Access Points in
   DIRAC follows a basic TLV (Type-Length-Value with an addition of a
   Subtype) format, and its purpose is to deliver messages carrying
   information about events/statistics/actions as described in the
   previous section (3). This protocol runs over UDP.

   (5) The topological assumptions between AP and AC (is it directly



Yang (Editor), et al.    Expires October 15, 2004              [Page 79]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   connected, L2 switched, or L3 routed?) -- this also helps us to
   understand the deployment scenarios.

   The access point is IP-addressable therefore it is in principle
   accessible over any L2-switched, or L3-routed "cloud". However, for
   the purpose of delivering meaningful per-host statistics over
   fine-time scales to capture long-term fading, and channel coherence
   time of the wireless medium, the "cloud" that connects the Access
   Points with the Access Router should have latency that is small
   enough to deliver statistics reports in a timely fashion. Therefore,
   either a direct connection, or a L2-switched "cloud" between the
   access point and the access router is recommended.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that are addressed.

   Possible threats:

   a) Threats TO the DIRAC architecture:

   i) protect the messages that deliver events/actions/statistics

   ii) authentication of APs to the AR (rogue APs)

   iii) Man-in-the-middle attack between APs --AR regarding
   control-traffic

   b) Threats TO the wireless traffic

   i) Mismatching levels of security strengths between STA--AP and
   AP--ARs

   ii) Denial-of-Service attacks (layer-2 and layer-3) in the wireless
   cell (protecting STAs from misbehaving wireless hosts)

   iii) Well-documented deficiencies of the 802.11 WEP (over the air
   protection)

   iv) Access control

   Threats (a).(i) and (a).(iii) can be addressed through encryption/
   tunneling of management messages. Threat (a).(ii) requires mutual
   authentication between AR and APs

   Threat (b).(ii) is addressed by the policing service implemented at
   the AR and enforced through L2 mechanisms at the AP. (b).(iii)
   requires additional authentication (ex. RADIUS) and end-to-end
   encryption, on top of WEP. (b).(iv) can be implemented both by access



Yang (Editor), et al.    Expires October 15, 2004              [Page 80]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   lists at the AR and MAC filtering at the AP.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   Management, Monitoring and Control (1st problem), Consistent
   (network-wide) configuration (2nd problem), and RF Management (3rd
   problem) are addressed by the fact that policies are centralized on
   the AR, while mechanisms for enforcing them are distributed among all
   APs.

   Security, and in particular rogue APs, can be addressed (although not
   currently implemented on DIRAC) through mutual authentication of the
   APs to the AR and vice-versa.




































Yang (Editor), et al.    Expires October 15, 2004              [Page 81]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix M.  Survey Contribution For Architecture 12

   (1) Design considerations and requirements:

   The access controller (AC) is a bridge.  Multiple access points are
   aggregated by a bridge that supports a MAC-layer security protocol
   between itself and an 802.11 end station. The same MAC-layer security
   protocol is used between bridges on a wired LAN and between a bridge
   and an 802.11 end station.  The security protocol is a service that
   sits above the MAC and makes 802.11i MAC security encapsulation
   unnecessary.  Contrast this with the situation in the near future
   where 802.11i will secure the link between an end station and an AP,
   and 802.1ae might secure the link between the AP and a bridge.

   To the extent that an AP can be architected as a bridge, AP
   management falls within the scope of bridge management and is handled
   within the 802.1 control layer along with existing bridge management
   protocols such as 802.1AB link-layer connectivity and 802.1af
   discovery of bridges that support MAC-layer security. These 802.1
   protocols are broad enough in scope to meet the requirements of the
   802.11 mesh networking PAR.

   No 802.11 frames of any type are recognized by an AC.

   (2) WLAN functions supported:

   An AC never routes packets.  It only bridges them except when reverse
   tunneling is required. An AC supports layer-3 mobility for a station
   that is associated with an AP attached to it, by reverse tunneling
   Ethernet from the station to an AC on that station's home subnet.
   The roaming station retains the same IP address and the limited
   broadcast domain of its home subnet regardless of AP association as
   long as the AP is within the same ESS. Therefore, no AC operations
   are required for a BSS transition unless that transition is to
   another subnet or ESS.

   Every handoff between access controllers is authenticated using state
   derived from an initial mutual authentication. No AC ever bridges, or
   reverse tunnels, any traffic from a station unless the user of that
   station can be authenticated. Re-authentication does not require user
   involvement.

   The MAC-layer security protocol provides privacy, integrity and
   replay protection of Ethernet frames between a bridge and an end
   station, or between two bridges.

   (3) Functional architecture: autonomous AP.




Yang (Editor), et al.    Expires October 15, 2004              [Page 82]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   (4) The protocol used in between AP and AC. none.

   (5) The topological assumptions between AP and AC. L2 switched.

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that (sic) are addressed.

   The architecture is NOT split, nor is it advantageous to do so.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   It is difficult to keep the "analysis" technical when the first and
   third "problems" of the four stated in
   draft-ietf-capwap-problem-statement-00.txt are expressed in
   subjective terms, specifically, "burden" and "difficulty in dealing
   effectively".  These are indeed at a marketing level. Therefore, one
   cannot objectively comment or provide "analysis".

   Further, the second and fourth "problems" presume a particular AP
   architecture that stores dynamic attributes, namely "embedded
   secrets" and "security parameters".  So the "problems", except for
   dynamic provisioning of RF, are actually threats that arise due to a
   particular choice of architecture, one that stores sensitive
   information in an AP. With the architecture above, an AP does not
   store secrets and therefore AP theft is not a security threat.
   Installation of unauthorized access points is a threat if they cannot
   be aggregated by an AC, otherwise it doesn't matter because the AC
   ultimately controls access to the LAN.  Further, a station will not
   connect to an AC that it cannot authenticate. Therefore an intruder
   is prevented from masquerading as an authorized AP and creating a
   MAC-layer security association with an end station.  An unauthorized
   AP that is not attached directly or indirectly to an AC is a threat
   to LAN access but not to an end station.
















Yang (Editor), et al.    Expires October 15, 2004              [Page 83]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix N.  Survey Contribution For Architecture 13

   (1) Design considerations and requirements:

   The Mesh architecture allows each AP to autonomously keep status of
   the pertinent information of the other APs, especially as it relates
   to back-hauling traffic between APs. Each AP may assume the role of
   providing access both to stations or to other APs for back-hauling
   traffic. This way we have an OSPF-like system of weighing paths
   through the network for load-balancing and fault-tolerance. The only
   requirement is IP connectivity between APs.

   (2) WLAN functions supported:

   Please list the functions supported in this WLAN briefly, but please
   do not send us the entire data sheet. Examples of WLAN functions
   includes the STA services, Distributed System Services (as defined by
   802.11), radio resource management and control, AP load balancing,
   mobility support, WLAN network wide security functions (including
   authentication, encryption for privacy and integrity, etc.) and any
   others not listed here but deemed important in your design.

   Yes to all of the above through much the same functions as the
   others. 802.1x, AES, WPA, TKIP, EAP-blah, blah, blah. Other than load
   balancing and dynamic radio resource management, I don't think much
   else matters in terms of our work.

   (3) The functional architecture to implement the functions described
   above: whether it is by autonomous AP architecture, or "split"
   architecture. For split architecture, please provide the functional
   mapping of WLAN functions onto the AP and AC -- with just enough
   details that help us understand the kinds of functional interface
   necessary between the two.

   See my answer to 4. The functional relationship between Mesh nodes is
   that they keep each other synced up with their resources and
   capabilities. They also keep each other in sync with the state of the
   whole network which allows each AP to make intelligent choices of
   where to back-haul traffic to.

   (4) The protocol used in between AP and AC.

   (What is an AP and AC? I don't think we've defined those in the terms
   that we will ultimately use. So I'll leave that one for now.

   (5) The topological assumptions between AP and AC (is it directly
   connected, L2 switched, or L3 routed?) -- this also helps us to
   understand the deployment scenarios.



Yang (Editor), et al.    Expires October 15, 2004              [Page 84]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   APs are connected Wired or wireless using L2 802.11

   (6) Security threat analysis: what kinds of threat introduced by the
   split architecture, and how that are addressed.

   We encrypt automatically each link using AES and 152-bit key with KM.

   (7) Pros and Cons of this architecture, esp. in relation to the four
   problems described in the CAPWAP problem statement. Please keep the
   analysis at technical instead of marketing level.

   Problem 1. Since each node is fully aware of the network, you don't
   need to manage each node. Just one will do and it can update the
   entire network. That's one of the main values of Mesh.

   Problem 2. Kind of the same answer as above. By using multicast IP
   protocols to keep everything in sync, we don't run into the problems
   mentioned in 2.

   Problem 3. Mesh really solves this one quite well, again by keeping
   everyone in sync and using multicast IP.

   Problem 4. By declaring a Cloud entity consisting of multiple wired
   or wirelessly connected APs, complete with full security, only
   legitimate APs are admitted to the network. Rogues cannot participate
   and may be hunted down using radio techniques.

























Yang (Editor), et al.    Expires October 15, 2004              [Page 85]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix O.  Survey Contribution For Architecture 14

   This architecture requires a control channel between wireless access
   points and a logical wireless switch device to exchange
   configuration, radio control, status and certain 802.11 specific
   messages. As explained below the logical wireless switch
   functionality may optionally be distributed between more than one
   physical device by separating certain logical functions.

   Topological requirements

   1. The AP and the AC are IP hosts that may be separated by L2 and/or
   L3 devices. They are not required to either be directly attached or
   in the same Layer-2 broadcast domain.

   2. There must be IP-connectivity between the AP and the AC.

   Transport attributes:

   1. The control channel is an IP connection that may use UDP or TCP
   transport mechanisms.

   2. Some control channel attributes may be statically configured. In
   particular, encryption and/or authentication may be enabled on the
   channel.

   3. The channel carries messages that may be categorized by various
   functions such as provisioning, monitoring, radio management and
   mobile node registration. These may be multiplexed over the same
   channel by the use of TLVs/opcodes or distributed over multiple IP
   connections. The first option allows co-locating all wireless switch
   functionality in the same device while the latter allows for switch
   entity be hosted on different devices each performing a different set
   of functions.

   4. APs initiate connection to the AC on a well-known UDP or TCP port.
   Discovery of the AC may be via manual configuration on the AP or
   through initial DHCP signaling exchange between the AP and a DHCP
   server.

   Contents of Protocol:

   1) APs discover the AC and initiate a UDP or TCP connection.

   2) The AP and the AC perform mutual authentication using EAP.

   3) The AP and the AC optionally negotiate security association for
   securing the channel.



Yang (Editor), et al.    Expires October 15, 2004              [Page 86]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   4) The AP is initially provisioned by the AC via a central
   configuration database.

   4) The AC does .11/.1X authentication mediation when the AP
   authenticates mobile nodes. Inserting the AC between the AP and the
   authentication server can be used for maintaining a central database
   of mobile nodes.

   4) Radio reports are sent from the AP to the AC as necessary.

   5) Radio control messages are sent from the AC to the AP
   asynchronously.







































Yang (Editor), et al.    Expires October 15, 2004              [Page 87]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Yang (Editor), et al.    Expires October 15, 2004              [Page 88]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Yang (Editor), et al.    Expires October 15, 2004              [Page 89]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/