[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 4, 2004                                       P. Zerfos
                                                                    UCLA
                                                                E. Sadot
                                                              Avaya, Inc
                                                           April 5, 2004


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

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 4, 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 4, 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 . . . . . . . . . . . . . . . . . . . . . . 11
   2.3   WLAN Architecture Proliferation  . . . . . . . . . . . . . . 12
   2.4   IEEE 802.11 WLAN Access Network Topology . . . . . . . . . . 13
   2.5   Taxonomy Methodology and Document Organization . . . . . . . 15
   3.    Autonomous Architecture  . . . . . . . . . . . . . . . . . . 17
   3.1   Security . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   4.    Split Architecture . . . . . . . . . . . . . . . . . . . . . 18
   4.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   4.1.1 Split MAC  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   4.1.2 Local MAC  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   4.1.3 Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . . 18
   4.2   Architecture Diagram . . . . . . . . . . . . . . . . . . . . 19
   4.3   Functionality Distribution Matrix  . . . . . . . . . . . . . 21
   4.3.1 Architecture Considerations  . . . . . . . . . . . . . . . . 21
   4.3.2 802.11 Management and Control Services . . . . . . . . . . . 23
   4.3.3 CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . . 25
   4.4   Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   4.5   Communication Interface between AP and AC  . . . . . . . . . 27
   4.6   Security . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   4.6.1 Client Data Security . . . . . . . . . . . . . . . . . . . . 28
   4.6.2 Security of control channel between WTP and AC . . . . . . . 28
   5.    Distributed Mesh Architecture  . . . . . . . . . . . . . . . 30
   5.1   Security . . . . . . . . . . . . . . . . . . . . . . . . . . 30
   6.    Summary and Conclusions  . . . . . . . . . . . . . . . . . . 31
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 32
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
         References . . . . . . . . . . . . . . . . . . . . . . . . . 36
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36
   A.    WLAN Architecture Survey Template  . . . . . . . . . . . . . 38
   B.    Survey Contribution For Architecture 1 . . . . . . . . . . . 39
   C.    Survey Contribution For Architecture 2 . . . . . . . . . . . 44
   D.    Survey Contribution For Architecture 3 . . . . . . . . . . . 48
   E.    Survey Contribution For Architecture 4 . . . . . . . . . . . 51
   F.    Survey Contribution For Architecture 5 . . . . . . . . . . . 56
   G.    Survey Contribution For Architecture 6 . . . . . . . . . . . 60
   H.    Survey Contribution For Architecture 7 . . . . . . . . . . . 64
   I.    Survey Contribution For Architecture 8 . . . . . . . . . . . 66
   J.    Survey Contribution For Architecture 9 . . . . . . . . . . . 70
   K.    Survey Contribution For Architecture 10  . . . . . . . . . . 74



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   L.    Survey Contribution For Architecture 11  . . . . . . . . . . 77
   M.    Survey Contribution For Architecture 12  . . . . . . . . . . 82
   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 4, 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 4, 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 motivation 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 4, 2004                [Page 5]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   enties 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. It is sometimes called
   "Hierarchical Architecture" or "Split Architecture"

   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.

   Hierarchical WLAN Architecture: same as  "Centralized WLAN
   Architecture", due to the hierarchy of the network entities in such
   architecture.

   Split WLAN Architecture: same as  "Centralized WLAN Architecture",
   due to the practice of splitting the logical functions between the
   Access Controller (AC) and the Wireless Termination Points (WTPs) by
   the vendors following such architecture.

   Access Controller (AC): The network entity in the WLAN architectures
   that control, configure and manage the entire 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.

   Mesh WTP: referred to the WTP in the distributed mesh WLAN
   architecture that is capable to form a peer-to-peer mesh network with
   the other WTPs in the network.



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   Split MAC Architecture: A sub-group of Split 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 Hierarchical
   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.

   Local MAC Architecture: A sub-group of the Hierarchical 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:

   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.

   Mesh Access Point: use Mesh WTP.

   Split AP Architecture: use Local MAC Architecture.

   Antenna AP Architecture: use Remote MAC Architecture.











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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


2. Introduction

   As IEEE 802.11 Wireless LAN (WLAN) technology enters the enterprise
   market, large scale deployment of WLAN networks becomes a technical
   challenge. As outlined in [2], management, monitoring and control of
   large number of Access Points (APs) in the network becomes 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 the interference and maximize network performance.
   Network security issues also become a central concern in enterprise
   markets.

   Recently many vendors have begun offering proprietary solutions to
   address some, or all of the aforementioned problems. Since
   interoperable solutions allow enterprises and service providers 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
   provides a taxonomy of the architectures employed in the existing
   WLAN products. Such a taxonomy document will provide a common
   understanding of the market practices for the standard bodies
   involved (including IETF and IEEE 802.11).  This taxonomy will 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.  A clearly defined WLAN functional architecture, including
   description of detailed functional blocks, interfaces, and
   information flow, will be reviewed by the IETF CAPWAP Working Group
   to determine if further work is needed to apply or develop standard
   protocols providing for multi-vendor interoperable implementations of
   WLAN access networks.

2.1 IEEE 802.11 WLAN Functions

   The IEEE 802.11 standard for wireless local area networks [1]
   specifies a MAC protocol, several PHYs, and a MAC management
   protocol. Each of these operates over the air, between two or more
   802.11 devices. 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. An SSID is an arbitrary byte string, up to 32 bytes
   long, though most implementations utilize ASCII strings for
   readability. 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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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.

   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, IEEE 802.11 specifies services. There are
   two categories of IEEE 802.11 service -- 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:

      Authentication

      Deauthentication

      Privacy

      MSDU Delivery

   Distribution system services consist of the following five services:

      Association

      Disassociation

      Reassociation

      Distribution

      Integration

   Distribution is the service of forwarding MSDUs for an associated
   station by an AP. This is the primary service used by IEEE 802.11
   STAs. It is conceptually invoked by every data message to or from an
   IEEE 802.11 STA operating in an ESS (when the frame is sent via the
   DS). As it is described in 802.11, distribution by an AP is to
   provide sufficient information to enable a frame received from an



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   associated station to be successfully delivered to its proper
   destination.

   If the distribution service determines that the intended recipient of
   a message is a member of an integrated LAN, the "output" point of the
   DS would be a portal instead of an AP. Messages that are distributed
   to a portal cause the DS to invoke the Integration function
   (conceptually after the distribution service). The portal is the
   single point at which the DS exchanges frames with the network
   outside of the ESS. The Integration function  is responsible for
   accomplishing whatever is needed to deliver a message from the DS
   Medium to the integrated LAN media (including any required media or
   address space translations).

   IEEE 802.11 also defines MAC services that must be implemented by the
   APs in the WLAN. For example:

      Beacon Generation

      Probe Response/Transmission

      Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK

      Synchronization

      Retransmissions

      Transmission Rate Adaptation

      Privacy: 802.11 Encryption/Decryption

   IEEE 802.11 does not exactly specify how all these functions get
   implemented, nor does it specifiy 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 architctures 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,



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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:

      RF monitoring, like Radar detection, noise and interference
      detection and measurement.

      RF configuration, e.g., for retransmission, channel, transmission
      power, etc.

      WTP configuration, e.g., for SSID, etc.

      WTP airmware loading, e.g., automatic loading and upgrading of WTP
      firmware for network wide consistency.

      Network-wide STA state information database, including the
      information needed to support value-added services, such as
      mobility, load balancing etc.

      Mutual authentication between network entities, e.g., for AC and
      WTP authentication in a hierarchical architecture; or peer to peer
      authentication between the mesh WTP in a dsitributed mesh
      architecture.

   Most of these functions are not explicitly specified by IEEE 802.11,
   but some of the functions are. For exmaple, control and management of
   the radio-related functions of an AP are described implicitly in the
   MIB, such as:

      Channel Assignment

      Transmit Power Control

      Clear Channel Assessment

      Radio Resource Measurement (work currently under way in IEEE
      802.11k)




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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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:

      RADAR detection

      Transmit Power Control

      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
   implementations, different architectures prolifereate 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 functonal 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 vendros' 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 Districution Systems that are
   employed to provide the 802.11 functions.

      Autonomous WLAN Architecture: The first architecture family is the
      traditional WLAN architcture, 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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      802.11 support is needed outside of the WTP. So the WTPs in this
      archtiecture are the traditional Access Points most people are
      familiar with. Sometimes such WTPs are referred to as "Fat APs" or
      "Standalone APs".

      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 refered 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. That is also why this architecture is also referred to as
      Centralized Architecture. 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 sevaral distinct characteristics that are
      worthnoting. First of all, the hierarchical architecture and the
      centralized AC afford much better manageability for the large
      scale networks. Secondly, since the IEEE 802.11 functions and the
      CAPWAP control functions are provided by the WTP devices and the
      AC together, the WTP devices themselves may not implement the full
      functions as defined in the 802.11 any more. Therefore, it can be
      said that the full functions as defined in the 802.11 are
      implemented across two physical network devices; such architecture
      family is also commonly referred to as "Split WLAN Architecture".
      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.

      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 xample 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 IEEE 802.11 WLAN Access Network Topology

   When the WLAN functions are implemented not by a single physical
   entity like WTP, but by a network, be it a centralized network or a
   distributed one, the topology connecting the two network entities
   becomes an architectural consideration as well. For example, in a



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   centralized architecture, how are the WTPs and their AC are
   connected? 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 1, Figure 2, and Figure 3.

                             -------+------ LAN
                                    |
                            +-------+-------+
                            |      AC       |
                            +----+-----+----+
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | AP  |       |  AP |
                          +--+--+       +--+--+

                      Figure 1: Directly Connected


                             -------+------ LAN
                                    |
                            +-------+-------+
                            |      AC       |
                            +----+-----+----+
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+    +-----+-----+
                          | AP  |    |   Switch  |
                          +--+--+    +---+-----+-+
                                         |     |
                                      +--+--+  +----+
                                      | AP  |       |
                                      +--+--+    +--+---+
                                                 | host |
                                                 +------+

                     Figure 2: Switched Connections











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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


                            +-------+-------+
                            |      AC       |
                            +-------+-------+
                                    |
                            --------+------ LAN
                                    |
                            +-------+-------+
                            |     router    |
                            +-------+-------+
                                    |
                            -----+--+--+--- LAN
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | AP  |       |  AP |
                          +--+--+       +--+--+

                      Figure 3: Routed Connections


2.5 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 "Split Architecture" (i.e., "Centralized
   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 the 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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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
   different aspects in various vendor's offerings. We classify the
   interesting aspects of these architectures into three main
   categories:

      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.

      802.11 Functions: as described in Section 2.1.

      CAPWAP Functions: as described in Section 2.2.

   The rows in the Functional Distribution Matrix represents the
   individual functions that are orgnized into the above mentioned three
   aspects, while each columns 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
   from survey.

   The rest of this document is organized around the three broad WLAN
   architecture families that were introduced ,Section 2.3. Each
   architecture family is discussed in a separate section. The section
   on Centralized Architecture (i.e., "Split Architecture") contains
   more in-depth details than the other two families, largely due to the
   overwhelming contration of the survey data collected falling into the
   "Split Architecture". (Out of the 14 contributions received, 11 of
   them fall into the "Split Architecture". )

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















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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


3. Autonomous Architecture

   The following Figure 4  shows an example network of Autonomous WLAN
   Architecture. In this sense, every WTP implements all the logical
   functions, and so is its own, isolated ESS. When a set of WTPs is
   connected together to create a WLAN, what is actually created is a
   set of independent ESSs that happen to communicate, in spite of the
   implementation. The switches in such an networks do not need to know
   anything about 802.11.

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


3.1 Security

           Figure 4: Example of Autonomous WLAN Architecture

   TBW





















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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


4. Split Architecture

4.1 Overview

   Split architectures 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". A mapping of these functions to physical network
   entities is needed and 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, Split MAC, Local MAC, and Remote MAC within this
   family of architectures, and also provide a mapping of the various
   services into the physical entities, for each vendor.

4.1.1 Split MAC

   The main idea behind the Split MAC architecture paradigm is to
   implement  part of the 802.11 MAC functionality on a centralized AC
   instead of just the WTP, in addition to the services required for
   managing and monitoring the WTP devices. Usually,  the decision of
   which function of the 802.11 MAC needs to be provided by the AC is
   based on the time-criticality of the service required, as elaborated
   in Section 4.2.

4.1.2 Local MAC

   The Local MAC architecture model attempts to offload STA's policies
   and management functions (CAPWAP functions described in Section 2.2
   to the AC, without necessarily splitting the 802.11 MAC functionality
   between WTP(s) and AC(s). The whole 802.11 MAC can reside on the WTP,
   however information related to management and configuration of the
   WTP device is communicated with a centralized AC, to facilitate
   management of the network, and maintain a consistent network-wide
   configuration for the WTP devices.

4.1.3 Remote MAC

   This approach has a goal to keep the WTP as light weight as possible
   by having only the radio interface and offloading the entire set of
   802.11 MAC functions (including delay-sensitive functions)  to the
   Access Controller. It thus keeps that all the complexities of the MAC
   and other CAPWAP control functions to the centralized controller and
   makes the WTP manageable. The WTP acts as only a communication means
   between the Wireless LAN clients (STA) and the controller, though



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   they have an additional silent 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.2 Architecture Diagram

   In the Split 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.

   The reasoning behind these approaches 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
   'lightweight' 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.

   Examples of real-time services of the 802.11 MAC that are implemented
   on the WTP are the following:

      Beacon Generation

      Probe Response/Transmission

      Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK

      Synchronization



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      Retransmissions

      Transmission Rate Adaptation

      Privacy: 802.11 Encryption/Decryption

      Fragmentation/Defragmentation

   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:

      Station Services: Authentication/Deauthentication

      Distribution System Services: Association/Disassociation/
      Reassociation/Distribution

      Integration Services: bridging between 802.11 and 802.3

   About the Integration Service, which essentially refers to bridging
   between 802.11 and 802.3 frames, an interesting consequence of the
   difference between the Split MAC and Local MAC is that Integration
   Service is implemented by the AC in the former case, but can be part
   of either the AC or WTP in the latter. As a second note, the
   Distribution Service, although usually provided by the AC, can also
   be implemented at the WTP in some Local AP architecture. The
   rationale behind this approach is to increase performance in
   delivering STA's data traffic by avoiding tunnelling it to the AC,
   and also relax the dependency of the WTP from the AC.





















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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   The following diagram shows schematically the architecture of the
   Split approach.  While examining the figure one should keep in mind
   the main difference between Split MAC and Local MAC: in the former
   case WTP terminates only the 802.11 Control frames, while in the
   latter may terminate all 802.11 frames. Also, designs of the Split
   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). As for the "interconnection topology" that
   connects the WTP devices with the AC, it can be either a direct
   connection, a L2-switched, or L3-routed network (more details can be
   found in Section Section 4.4).

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

                                Figure 5


4.3 Functionality Distribution Matrix

   The various services and functions that are offered by the vendors
   that follow the Split architecture family are classified into three
   main categories, as described in Section 2.5 a) architecture
   considerations, b) 802.11 functions, and c) CAPWAP functions. For
   each one of these categories, the mapping to network entities
   implemented by each vendor is shown in tabular form.

4.3.1 Architecture Considerations

   Figure 6 offers a tabular representation of the design choices made
   by the six vendors that follow the Split  MAC design with respect to
   the achitecture considerations. Figure 7 has similar information for



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   implementations of the Local MAC model (data from five vendors).

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


   WTP-AC
   topology       L3             N/A     L3     L3      L3

   mgmt
   termination    AC                            STB/AC

   control
   termination    WTP                           STB

   data
   aggregation                                  AC


                                Figure 6



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



   WTP-AC
   topology           L3               L3      L3      L3

   mgmt
   termination        WTP     WTP      WTP     WTP     WTP

    control
   termination        WTP     WTP      WTP     WTP     WTP

   data
   aggregation        AC      AC       WTP     AC      WTP


                                Figure 7

   By '802.11 mngmnt termination', and '802.11 control termination' we
   denote the physical device (termination point) on which processing of
   the 802.11 management, and control frames respectively is done. The
   last row of the table in Figure 6 and Figure 7, '802.11 data
   aggregation', refers to the device on which delivery of messages from



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   one STA to another (possibly through a DS) is performed.

4.3.2 802.11 Management and Control Services

   The services and functions that belong to the second category, along
   with their respective mapping to the physical devices on which they
   are implemented by each vendor, is shown in Figure 8, and Figure 9,
   for Split MAC and Local MAC respectively.


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

   Distribution
   Services      AC        AC      AC      AC      AC      AC

   Integration
   Services      AC        AC      AC      AC      AC

   Beacon
   Generation    WTP       WTP             WTP     STB

   Probe
   Response      WTP       AC/WTP          WTP     STB

   Power mgmt
   Packet
   Buffering     WTP       WTP             AC      AC/STB

   Fragmentation
   Defragment.   WTP                               AC

   Association
   Disassoc.
   Reassociation AC        AC      AC      AC      STB

   WME/11e
   -------
   classifying   WME/Oth           WME/Oth AC/AP   WME/802.11e

   scheduling    WTP/AC    AC      AC      AC      AC

   queuing       WTP/AC    WTP     WTP     AC      STB

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




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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   802.1x/EAP    AC        AC      AC      AC      AC

   Keys
   Management    AC        AC      AC      AC      AC

   802.11
   Encryption/
   Decryption    WTP       AC      WTP     AC      AC

                                Figure 8



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

      Distribution
      Services      AC     AC       WTP      AC      WTP

      Integration
      Services      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

      scheduling    WTP    AC/WTP   WTP      WTP

      queuing       WTP             WTP      WTP

      Authentication



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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

      Keys
      Management    AC      AC      WTP      AC

      802.11
      Encryption/
      Decryption    WTP     WTP     WTP      WTP

                                Figure 9

   The first column of the above tables lists the 802.11 services, as
   specified in [1]. Two subclasses within this category, 'WME/11e' and
   'Authentication and Privacy' refer to the 802.11 standards for
   Quality of Service and Security respectively

4.3.3 CAPWAP Functions

   The last category includes the CAPWAP-related functions, and also
   features value-added services offered by vendors to ease management,
   configuration and control of the WLAN network, as well as increase
   security. As such, and since they are relevant to the four problems
   of the CAPWAP problem statement, interoperability among the
   implementations of different vendors is also highly desirable.

   In Figure 10 we show the functionality distribution matrix for the
   vendors of Split MAC products, and in Figure 11 for those of Local
   MAC solutions.





















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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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

   RF
   Config.       WTP/AC                          AC

   WTP config.   AC                              AC

   WTP
   Firmware      AC                      AC      AC        AC

   STA state
   info
   database      AC                              AC

   AC/WTP
   mutual
   authent.      X.509                           X

                 certs

                               Figure 10



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

      RF
      Monitoring    WTP     WTP    AC/WTP    WTP     WTP

      RF
      Config.       AC                       AC      AC

      WTP config.   AC                       AC      AC

      WTP
      Firmware      AC                       AC      AC

      STA state
      info
      database      AC                      AC/WTP   AC

      AC/WTP
      mutual
      authent.      X                         X       X



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


                               Figure 11

   As one can note from the tables of Figure 10 and Figure 11, 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').

4.4 Topology

   Management frames of the 802.11 MAC, as well as configuration and
   control information, is exchanged between WTP devices and the AC
   usually through IP-tunnels, or through some actual protocol exchange,
   implemented over TCP/UDP . In Split MAC architectures 802.11
   management frames received by the WTP from the STA(s) are tunneled to
   the AC, whereas in the Local MAC paradigm they are first converted to
   some other format, which in turn is tunneled to the AC.

   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.

4.5 Communication Interface between AP and AC

   Before any messages can be exchanged between the AC and WTP(s)
   typically  the following operations are first perfomed that lead to
   the registration of an WTP with an AC:

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

      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.

      WTP Association: after successful authentication, an WTP registers
      with the AC, in order to start receiving management and
      configuration messages.




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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      Firmware Download: after successful association, the WTP may pull,
      or the AC may push the WTP's firmware , which is digitally signed.

      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.

      Configuration Download: following the tunnel establishment
      process, the AC may push configuration parameters to the WTP.


4.6 Security

   Given the varied distribution of functionalities for the Split
   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.6.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.  In such cases, 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 Split Architecture
   assumes two possibilities for "over the wire" client data security.
   In some cases there is an encrypted tunnel (IPsec, SSL, or AES-CCM)
   between the WTP and AC which assumes the security boundary to be in
   the AC.  In other cases an end-to-end mutually authenticated secure
   VPN tunnel is assumed between the client and AC, other security
   gateway or end host entity.

4.6.2 Security of control channel between WTP and AC

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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   Threats to the Split Architecture as presented in the submissions
   are:

      Secure discovery of WTP and AC

      Authentication of the WTPs to the ACs and vice versa

      Man-in-the-middle attacks to the control channel between WTP and
      AC.

      Confidentiality and integrity of control channel frames

      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 Split 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 Split 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 4, 2004               [Page 29]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


5. Distributed Mesh Architecture

   An example of the Distributed Mesh Architecture is shown in Figure
   12, The mesh WTP devices can keep track of the state of its
   neighboring nodes or even nodes beyond, so that the mesh WTP devices
   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 |
    |  ...          |           |  ...          |
    |    +-------+  |           |    +-------+  |
    +----|meshWTP|--+           +----|meshWTP|--+
         +-+---+-+                   +-+-+---+
           |   |                       | |
           |   |                       | |           +----------+
           |   +-----------------------+ |  Ethernet | Ethernet |
           |    802.11 wireless links    |  +--------+ Switch   |
           |   +-----------------------+ |  |        |          |
           |   |                       | |  |        +----------+
         +-+---+-+                   +-+-+--++
    +----|meshWTP|--+           +----|meshWTP|--+
    |    +-------+  |           |    +-------+  |
    |  ...          |           |  ...          |
    |  802.11 BSS 4 |           |  802.11 BSS 3 |
    +---------------+           +---------------+

          Figure 12: Example of Distributed Mesh Architecture

   TBW

5.1 Security
















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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


6. Summary and Conclusions

   TBW
















































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

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 threats that the WLAN customers face today with each
   architecture family. The WLAN architecrures are broadly categoried
   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 3.1, Section 4.6 and Section 5.1 for detailed
   security considerations in each of these architecture families.






































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

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:

      Peyush Agarwal

         STMicroelectronics

         Plot# 18, Sector 16A

         Noida, U.P  201301

         India

         Phone: +91-120-2512021

         EMail: peyush.agarwal@st.com

      Dave Hetherington

         Roving Planet

         4750 Walnut St., Suite 106

         Boulder, CO  80027

         United States

         Phone: +1-303-996-7560

         EMail: Dave.Hetherington@RovingPlanet.com

      Matt Holdrege

         Strix Systems

         26610 Agoura Road

         Calabasas, CA  91302

         Phone: +1 818-251-1058

         EMail: matt@strixsystems.com




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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      Victor Lin

         Extreme Networks

         3585 Monroe Street

         Santa Clara, CA  95051

         Phone: +1 408-579-3383

         EMail: vlin@extremenetworks.com

      James M. Murphy

         Trapeze Networks

         5753 W. Las Positas Blvd.

         Pleasanton, CA  94588

         Phone: +1 925-474-2233

         EMail: jmurphy@trapezenetworks.com

      Partha Narasimhan

         Aruba Wireless Networks

         180 Great Oaks Blvd

         San Jose, CA  95119

         Phone: +1 408-754-3018

         EMail: partha@arubanetworks.com

      Bob O'Hara

         Airespace

         110 Nortech Parkway

         San Jose, CA  95134

         Phone: +1 408-635-2025

         EMail: bob@airespace.com




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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


      Emek Sadot (see Authors' Addresses)

      Ajit Sanzgiri

         Cisco Systems

         170 W Tasman Drive

         San Jose, CA  95134

         Phone: +1 408-527-4252

         EMail: sanzgiri@cisco.com

      Inderpreet Singh

         Chantry Networks

         1900 Minnesota Court

         Mississauga, Ontario  L5N 3C9

         Canada

         Phone: +1 905-567-6900

         EMail: isingh@chantrynetworks.com

      L. Lily Yang (Editor, see Authors' Addresses)

      Petros Zerfos (see Authors' Addresses)

   In addtion, we would also like to acknowlege 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.









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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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.

   [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










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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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

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











































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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


Appendix A. WLAN Architecture Survey Template

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

      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.

      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 protocol used in between AP and AC.

      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.

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

      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 4, 2004               [Page 38]

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 simultaineously, 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 4, 2004               [Page 39]

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 4, 2004               [Page 40]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   c. Virtual AP (multiple SSID)

   d. power management packet buffering

   e. RF monitoring (radar detection, noise measurement, interfereince
   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 mangement 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 4, 2004               [Page 41]

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 mehtod
   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 4, 2004               [Page 42]

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 4, 2004               [Page 43]

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 4, 2004               [Page 44]

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 4, 2004               [Page 45]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   realtime (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 backend 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 4, 2004               [Page 46]

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 4, 2004               [Page 47]

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 4, 2004               [Page 48]

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 the AC is in a trusted network.

   - Pros:



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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

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







































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

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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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 BSSes, 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
   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 queueing

      RF Packet reception including: checking PLCP headers, address
      filtering, basic ddress 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:



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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 misconfigured 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
   compromised. Attacking an AR when one already has physical access to
   the network is pointless.

   Should an attacker still try to misconfigure 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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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 4, 2004               [Page 55]

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 4, 2004               [Page 56]

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
   neighbouring 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 envi ronment 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 4, 2004               [Page 57]

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 4, 2004               [Page 58]

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 4, 2004               [Page 59]

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 telecommuters 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 4, 2004               [Page 60]

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 queueing. TSF (Beacon
   and Probe response timestamp insertion). Multicast Powersave 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 4, 2004               [Page 61]

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 4, 2004               [Page 62]

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 4, 2004               [Page 63]

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 4, 2004               [Page 64]

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 4, 2004               [Page 65]

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 AP's (100's of AP's)

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




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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


         - Robust Security (802.11i)

         - QOS (802.11e)

      - radio resource management including load balancing and RF
      management

      - bridging (802.11 to 802.3)

      - 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 maintainted 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 encapsulatation of 802.3 bridged data.  The datapath
   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



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   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 senstive applications and
   deployments there will always be an end to end encrypted tunnel.
   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 AP's 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.



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

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


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

















































Yang (Editor), et al.    Expires October 4, 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 lifecycle 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 4, 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 4, 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 4, 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 4, 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 4, 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 4, 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 4, 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 coordinations 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 4, 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 4, 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 retxmits (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., reflash
   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 4, 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 4, 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 4, 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 4, 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 4, 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 AP's, especially as it relates
   to backhauling traffic between AP's. Each AP may assume the role of
   providing access both to stations or to other AP's for backhauling
   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 AP's.

   (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 backhaul 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 4, 2004               [Page 84]

Internet-Draft           CAPWAP Arch. Taxonomy                April 2004


   AP's 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 AP's, complete with full security, only
   legitimate AP's are admistted to the network. Rogues cannot
   participate and may be hunted down using radio techniques.

























Yang (Editor), et al.    Expires October 4, 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 4, 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 4, 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 4, 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 4, 2004               [Page 89]


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