[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                                           B. O'Hara
Internet-Draft                                                 Airespace
Expires: August 8, 2004                                          L. Yang
                                                             Intel Corp.
                                                        February 8, 2004


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on August 8, 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 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, esp. between the access points and access
   controller.  This taxonomy will be utilized by the 802.11 Working
   Group as input to their task of defining the functional architecture
   of an access point.





O'Hara & Yang            Expires August 8, 2004                 [Page 1]

Internet-Draft                  CAPWAPA                    February 2004


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Conventions used in this document  . . . . . . . . . . . . .  3
   1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.3   CAPWAP Purpose and Scope . . . . . . . . . . . . . . . . . .  4
   1.4   Document Organization  . . . . . . . . . . . . . . . . . . .  4
   2.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1   The IEEE 802.11 in Brief . . . . . . . . . . . . . . . . . .  6
   2.2   CAPWAP Motivation  . . . . . . . . . . . . . . . . . . . . .  7
   2.3   AP-to-AC Topological Variants  . . . . . . . . . . . . . . .  8
   3.    CAPWAP Component Architecture  . . . . . . . . . . . . . . . 10
   3.1   WLAN functions and Services  . . . . . . . . . . . . . . . . 10
   3.1.1 Access Point Functions and Services  . . . . . . . . . . . . 12
   3.1.2 Access Controller Functions and Services . . . . . . . . . . 12
   3.1.3 Other Conventional WLAN Functions and Services . . . . . . . 13
   3.1.4 Architectural Trends . . . . . . . . . . . . . . . . . . . . 13
   3.2   CAPWAP Network Topology  . . . . . . . . . . . . . . . . . . 14
   3.2.1 Functional Distribution of WLAN Services . . . . . . . . . . 15
   3.2.2 AP to AR Topologies  . . . . . . . . . . . . . . . . . . . . 15
   3.3   Access Router Discovery  . . . . . . . . . . . . . . . . . . 17
   3.3.1 Access Router Availability . . . . . . . . . . . . . . . . . 17
   3.3.2 Capabilities Negotiation . . . . . . . . . . . . . . . . . . 18
   3.3.3 Access Point Service Management  . . . . . . . . . . . . . . 18
   3.3.4 AP Provisioning  . . . . . . . . . . . . . . . . . . . . . . 19
   3.3.5 CAPWAP Security  . . . . . . . . . . . . . . . . . . . . . . 20
   3.4   Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   4.    Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . 24
   4.1   DIRAC  . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   4.2   ForCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   4.2.1 Similarities in Objectives and Architectural
         Considerations . . . . . . . . . . . . . . . . . . . . . . . 25
   4.2.2 Overlap in Topology Considerations . . . . . . . . . . . . . 26
   4.2.3 Differences in Design Approach . . . . . . . . . . . . . . . 26
   4.2.4 Differences in the Functionality        Controlled . . . . . 26
   4.2.5 Similarities in Security Requirements  . . . . . . . . . . . 26
   4.2.6 Difference in Operation Scope  . . . . . . . . . . . . . . . 27
   4.2.7 Comparision in Protocols . . . . . . . . . . . . . . . . . . 27
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 28
   6.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
         References . . . . . . . . . . . . . . . . . . . . . . . . . 30
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
   A.    IEEE 802.11 - Details and Current Work . . . . . . . . . . . 32
   B.    Requirements . . . . . . . . . . . . . . . . . . . . . . . . 33
   B.1   Architectural  . . . . . . . . . . . . . . . . . . . . . . . 33
   B.2   Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   B.3   Security . . . . . . . . . . . . . . . . . . . . . . . . . . 33
         Intellectual Property and Copyright Statements . . . . . . . 34



O'Hara & Yang            Expires August 8, 2004                 [Page 2]

Internet-Draft                  CAPWAPA                    February 2004


1. Introduction

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

1.2 Terminology

      AB/AR: Access Bridges/Routers

      AC: Access Controllers

      AP: access point

      BSS: basic service set

      ESS: extended service set

      SSID: service set identifier

      WLAN: wireless local area network

      RSN: robust security network

      TSN: transition security network

      PMK: pair-wise master key

      PTK: pair-wise transient key

      TK: temporal key

      GMK: group master key

      GTK: group transient key

      KCK: key confirmation key

      KEK: key encryption key

      PSK: pre-shared key

      WEP: wired equivalent privacy

   Throughout the document the terminology AC (Access Controller) are
   used synonymously with the Access Bridge(AB) and Access Router(AR) in



O'Hara & Yang            Expires August 8, 2004                 [Page 3]

Internet-Draft                  CAPWAPA                    February 2004


   context of the functional CAPWAP backend, unless explicitly specified
   otherwise.

   At the outset AC is to be assumed the generic term for the entity
   with which an AP registers or associates - which term will be
   qualified later in the CAPWAP architecture sections (Section 3).

   The term AR is used in the context that the Access Controller that an
   AP associates with is over an L3 network cloud.

   The term AB is used in the context that the Access Bridge that an AP
   associates with is over an L2 network cloud.

   It may be observed in following sections that the proposed
   architecture chooses to stay agnostic and equivalent to either
   Network Protocol and focuses on the interface and generic
   encapsulation that shall allow for both. The Protocol MAY end up
   specifying merely for IP.

1.3 CAPWAP Purpose and Scope

   The purpose of CAPWAP work is to define the framework reflecting the
   architectural trend that delegates and aggregates selected WLAN
   functions and services from APs (Access Points) to ARs to enhance
   WLAN resource management. On the basis of such definition CAPWAP aims
   to provide a secure protocol to enable AP-to-AC communications and AP
   provisioning & management.

   Current implementations of large scale 802.11 networks utilizing
   large number of APs with centralized AC(s) are proprietary and not
   interoperable.  A taxonomy of the architectures employed in the
   existing products in the market will provide the basis of an output
   document to be provided to the IEEE 802.11 Working Group.  This
   taxonomy will be utilized by the 802.11 Working Group as input to
   their task of defining the functional architecture of an access
   point.  The functional architecture, including description of
   detailed functional blocks, interfaces, and information flow, will be
   reviewed by CAPWAP to determine if further work is needed to apply or
   develop standard protocols providing for multi-vendor interoperable
   implementations of WLANs built from devices that adhere to the newly
   appearing hierarchical architecture utilizing a functional split
   between an access point and an access controller.

1.4 Document Organization

   The overview section describes the IEEE 802.11 WLAN architecture and
   services in brief followed by AP-AC network topological
   considerations leading to CAPWAP motivation.



O'Hara & Yang            Expires August 8, 2004                 [Page 4]

Internet-Draft                  CAPWAPA                    February 2004


   The subsequent section describes architecture variants and the
   functional components.

   The section that follows discusses related research and standard
   work.

   The document concludes with Security Considerations which are also
   discussed in Architecture.











































O'Hara & Yang            Expires August 8, 2004                 [Page 5]

Internet-Draft                  CAPWAPA                    February 2004


2. Overview

   Prior to setting out on details, a snapshot of WLAN standards are in
   order to put the CAPWAP motivation and standardization benefits in
   perspective, particularly when the required interfaces appear in the
   landscape bordering L2 and L3 standards scope.

2.1 The IEEE 802.11 in Brief

   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. 802.11 also describes the functionality of a specific
   device, called an access point (AP), that translates frames between
   mobile 802.11 devices and hosts on a wired network. When more than
   one AP is connected via a broadcast layer 2 network and all are using
   the same SSID, an extended service set (ESS) is created. An ESS is
   also similar to a single broadcast domain, where a mobile device
   associated with one AP can successfully ARP for the address of a
   mobile device associated with any other AP in the ESS. Within an ESS,
   a mobile station can roam from one AP to another through only layer 2
   transitions coordinated by the 802.11 MAC management protocol. Higher
   layer protocols, including IP are unaware that the network attachment
   point of the mobile device has moved.

   Some definition of 802.11 terminology is in order, since it is unique
   to the 802.11 standard.

   *  "Distribution" is the service of forwarding MSDUs for an
      associated station by an AP. As it is described in 802.11,
      distribution by an AP is providing sufficient information to
      enable a frame received from an associated station to be
      successfully delivered to its proper destination. For the most
      part, this involves translating the frame format from 802.11 to
      Ethernet (typically) and removing any SNAP encapsulation that was
      applied to the 802.11 frame, due to its lack of an equivalent to
      the Ethertype field. This is similar to standard bridging, except
      that 802.11 APs are not 802.1D bridges. APs typically do not
      implement spanning tree protocols or algorithms. They are
      considered to be edge devices, connected only to leaf nodes with
      no further bridging taking place down stream from them. This is
      not always a valid assumption and can sometimes result in



O'Hara & Yang            Expires August 8, 2004                 [Page 6]

Internet-Draft                  CAPWAPA                    February 2004


      unanticipated bridging loops.

   *  "Integration" is a concept unique to 802.11 that is a result of
      the underlying architecture. 802.11 considers that the individual
      APs that make up a WLAN, an extended service set (ESS) in 802.11
      terminology, are connected by a closed system, called the
      distribution system. Only frames that are "within" the ESS are
      carried by the distribution system. This includes frames that are
      moving from one AP to another for delivery to a mobile station,
      frames received from outside the ESS for delivery to a mobile
      station, and frames from a mobile station to be delivered outside
      the ESS. Connecting the closed distribution system to the outside
      world is a "portal". The portal is the single point at which the
      distribution system exchanges frames with the network outside of
      the ESS.

   The problem with the 802.11 architecture, or maybe just with the AP
   implementations, is that AP implementations do not adhere to this
   architecture. An AP typically implements both the distribution and
   integration services, and the portal function, inside the skin of the
   AP. In this sense, every AP is its own, isolated ESS and no APs
   actually implement the architecture described in the standard. When a
   set of APs 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.

2.2 CAPWAP Motivation

   A new architecture is emerging in the 802.11 market that moves much
   of the functions that would reside in a traditional access point (AP)
   to a centralized access router (AR). Some of the benefits that come
   out of this new architecture include:

   o  Ease of Use: By centrally managing a WLAN as a system rather than
      as a series of discrete components, management and control of the
      WLAN is much easier

   o  Increased Security: Having a centralized AR enforce policies and
      be able to detect potential threats across all of much of a
      complete WLAN system increases the security of the network.

   o  Enhanced Mobility: By terminating the WLAN "management" protocol
      in the AR, these messages may be used as "mobility triggers",
      providing mobility across an RF domain without the need for any
      client software.

   o  Quality of Service: By allowing the centralized AR to manage the
      RF links, offers systemic perspective to perform efficient load



O'Hara & Yang            Expires August 8, 2004                 [Page 7]

Internet-Draft                  CAPWAPA                    February 2004


      balancing across multiple Access Points - thus increasing the
      efficiency of the wireless network. It also offers scope to have
      higher layer applications influence roaming and placement policies
      in a streamlined manner.

   All of the above can be provided by terminating the 802.11 management
   frames in the AR. This approach is commonly referred to as Split AP,
   where the real-time components of the 802.11 protocol are handled in
   the Access Point, while the access control components of the 802.11
   protocol terminate in the Access Router.

   Having a module in the AR that understands 802.11 management frames
   and 802.11 WLANs will provide much better control and optimization of
   the WLAN operation than will an abstract, protocol-agnostic control
   module. Adding support to CAPWAP for other wireless technologies then
   becomes a task of encapsulating the new frames and adding a new
   control module to the AR to handle the new technology. Presumably,
   the LWAPP protocol and CAPWAP architecture will need little change,
   if any.

2.3 AP-to-AC Topological Variants

   Some architectures require ACs to be the next-hop bridge/router and
   in some cases, be directly connected. Other architectures allow APs
   to connect through a cloud. Among such classifications are the
   following.

   1.  ARCH0: The "classic" AP interfacing to the Infrastructure Network
       cloud with no specific binding to a controller. In this case the
       AP can be considered to have a self-contained Access Controller,
       possibly communicating with other APs in the ESS to form a WLAN
       system.

   2.  ARCH1: APs which defer all WLAN functions other than real-time
       services (Section 3.1) create a different paradigm of vertical
       (real-time front-end AP and aggregated backend AC) functional
       distribution. (This leads to the need to establish a trust
       between the AP and AC associations between the two entities and a
       process of discovery of AC by AP).

   3.  ARCH2: Architecture that shifts some or most real-time functions
       as well to the AC, including termination of OTA (over-the-air)
       security path. This lets the 802.11 security to protect the
       client data through AP-AC path.

   4.  ARCH3: An extreme case of ARCH3 where the backend switch behaves
       as a single Access Point with multiple smart antennas. Within the
       range of the connected antennas clients roam without AP-AP



O'Hara & Yang            Expires August 8, 2004                 [Page 8]

Internet-Draft                  CAPWAPA                    February 2004


       handoff.

   While, at the outset, the architectures seem at wider variance, the
   varied market requirements of

   1.  deployment scope

   2.  scalability

   3.  performance and

   4.  end-end security demands

   seem to allow for all such architectures to play with varying scope
   and limitations. This underscores the need to provide a CAPWAP
   protocol that can work across these architecture classes.



































O'Hara & Yang            Expires August 8, 2004                 [Page 9]

Internet-Draft                  CAPWAPA                    February 2004


3. CAPWAP Component Architecture

   Given the preliminary outline of the three primary architecture types
   (and a fourth variant) in Section 2.3 the predominant architectural
   components are presented in three perspectives:

   1.  Functional & Service-based (WLAN standards)

   2.  Architectural Split

   3.  Topological

   This is required as a means to realize the inter-dependencies of
   these three aspects.

   The Figure 1 illustrates the basic outline of communications
   architecture between AP and AC.

       |                          _  |
       |    Control/Provisioning ( )-|----Security
       |<------------------------|-|>|
       |      Status/Download    (_) |
       |                             |
       |                          _  |
       |           Data          ( )-|----Security
       |<------------------------|-|>|
       |        Forwarding       (_) |
       |                             |
       |                             |
       |         Discovery           |
       |<--------------------------->|
       |                             |
       |                             |
       |                             |
    +------+                    +--------+
    |      |                    | Access |
    |      |                    | Router |
    |  AP  |                    |        |
    +------+                    +--------+

                Figure 1: Basic Communications Framework


3.1 WLAN functions and Services

   The IEEE 802.11 standard [1] says very little about the functionality
   required of an AP. There is some discussion of the AP at a block
   diagram level, in the General Description in clause 5 of the



O'Hara & Yang            Expires August 8, 2004                [Page 10]

Internet-Draft                  CAPWAPA                    February 2004


   standard. There, an AP is described as containing functional blocks
   for 802.11 station services and for distribution system services.
   Station services consist of the following four services:

   o  Authentication

   o  Deauthentication

   o  Privacy

   o  MSDU Delivery

   Distribution system services consist of the following five services:

   o  Association

   o  Disassociation

   o  Distribution

   o  Integration

   o  Reassociation

   There are additional services that are required of an AP, that are
   described in the MAC Layer Management Entity (MLME) in clause 11.
   These additional management services are

   o  Beaconing

   o  Synchronization

   o  Power Management

   Other functionality that is not described, except implicitly in the
   MIB, is control and management of the radio-related functions of an
   AP. These include:

   o  Channel Assignment

   o  Transmit Power Control

   o  Clear Channel Assessment

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

   The 802.11h [14] amendment to the base 802.11 standard specifies the



O'Hara & Yang            Expires August 8, 2004                [Page 11]

Internet-Draft                  CAPWAPA                    February 2004


   operation of a MAC management protocol to accomplish the requirements
   of some regulatory bodies (principally in Europe, but expanding to
   others) in these areas:

   o  RADAR detection

   o  Transmit Power Control

   o  Dynamic Channel Selection


3.1.1 Access Point Functions and Services

   The services that MUST be in an AP (front-end) are those that are
   directly related to the real-time aspects of the 802.11 MAC protocol
   and those related to the radio nature of an 802.11 AP. These
   functions are:

   o  Privacy

   o  MSDU Delivery

   o  Beaconing

   o  Synchronization

   o  Power Management

   o  Channel Assignment

   o  Transmit Power Control

   o  Clear Channel Assignment

   o  Radio Resource Measurement

   o  RADAR detection


3.1.2 Access Controller Functions and Services

   The functions that MAY be moved from the  AP and located in the AR
   are those dealing with the management and control aspects of an
   802.11 AP. These are the distribution system services,
   authentication, deauthentication, and control of the services added
   in 802.11h. These functions are:

   o  Authentication



O'Hara & Yang            Expires August 8, 2004                [Page 12]

Internet-Draft                  CAPWAPA                    February 2004


   o  Deauthentication

   o  Association

   o  Disassociation

   o  Reassociation

   o  Distribution

   o  Integration

   o  Dynamic Channel Selection

   o  Dynamic Control of transmit power


3.1.3 Other Conventional WLAN Functions and Services

   "Heavy" Access Points being the bridge to the wired world MAY (and
   normally do) also support various services and protocols that provide
   seamless connectivity of WLAN clients to the wired network such as

   o  Port and Protocol-based VLANs

   o  SNMP

   o  QoS (DiffServ and 802.1Q) mapping

   o  IP routing

   o  DHCP relay/server

   o  RADIUS client/proxy

   o  MobileIP (client proxy)

   Based on the above definition of  access points these services SHOULD
   qualify for offloading to the AR.

3.1.4 Architectural Trends

   As outlined in (Section 2.3), current WLAN system architectures vary
   widely in functional distribution, ranging from self-contained
   standalone AP-centric models to (W)LAN-centric controller models.
   Yet, the definitive need to provide domain-wide control, monitoring
   to provide optimal scalability and performance for Mobility and
   Roaming has driven a trend to



O'Hara & Yang            Expires August 8, 2004                [Page 13]

Internet-Draft                  CAPWAPA                    February 2004


   o  consolidate WLAN control functions and states of scope wider than
      the granularity of a base station (AP)

   o  amortize WLAN resource views (such as Radio Signal Strength)
      allowing

   o  effective response to  fluctuations in load and other temporal
      variations

   The summary outcome of the effort is  WLAN/LAN-bridging service
   separation and distributions discussed in Section 3.1.2 with a range
   of  varied architectures.

   The following is a broader summary of architectural variants.


                       +=================================================================+
                       |    AP    Complement          |     Switch/Controller Complement |
                       +=================================================================+
                       | Antenna & Lower PHY          |  Upper PHY and Above             |
                       +-----------------------------------------------------------------+
                       | Antenna & PHY                |  Common MAC for all PHYs &       |
                       |                              | above                            |
                       +-----------------------------------------------------------------+
                       | Antenna, PHY & MAC           | Upper PHY, User Authentication   |
                       | real-time (no IP, SNMP)      |  & Above (AP on same subnet)     |
                       +-----------------------------------------------------------------+
                       | Antenna, PHY & MAC           | 802.1X authentication & above    |
                       | (no IP, no SNMP agent)       | (AP can be on different subnet)  |
                       +-----------------------------------------------------------------+
                       | Antenna, PHY, MAC, 802.1X    | Filtering, Switch, Centralized   |
                       | authentication (IP & SNMP    | Management                       |
                       +-----------------------------------------------------------------+
                       | Antenna, PHY, MAC, 802.1X    | Switch, Centralized Mgmt.        |
                       | auth., Bridging (IP, SNMP),  |                                  |
                       +-----------------------------------------------------------------+


    The first two in above tend be out of CAPWAP scope, per guidelines
   of Section 3.1.2 with switches themselves mapping  'AP'-like
   functions.

3.2 CAPWAP Network Topology

   The WLAN network refers to the over-the-air IEEE 802.11 topologies
   and the AP-AC (or AP-AR) topology. The former (802.11) are as
   described in Overview section and invariant for CAPWAP purposes. The
   CAPWAP architecture deals with the latter (AP-AC topologies).



O'Hara & Yang            Expires August 8, 2004                [Page 14]

Internet-Draft                  CAPWAPA                    February 2004


3.2.1 Functional Distribution of WLAN Services

   Functional distribution of WLAN services described in earlier
   sub-sections are partly an artifact of the architecture types
   ARCH0-3. However, they may result in AP-AC topological constraints.
   Such constraints include direct connectivity to the AC being required
   and in most cases mandate L2 connectivity.

3.2.2 AP to AR Topologies

   CAPWAP assumes that the AR and AP are within the same administrative
   domain, i.e. they are owned/controlled by the same entity. CAPWAP
   makes no topological assumptions beyond these, meaning there are
   several topologies which must be considered for our purposes.

      ---------------------------------------------------------------------


                             -------+------ LAN
                                    |
                            +-------+-------+
                            |  + + AR  + +  |
                           +----+-----+----+
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | AP  |       |  AP |
                          +--+--+       +--+--+

      ---------------------------------------------------------------------

                      Figure 2: Directly Connected


















O'Hara & Yang            Expires August 8, 2004                [Page 15]

Internet-Draft                  CAPWAPA                    February 2004


      ---------------------------------------------------------------------


                             -------+------ LAN
                                    |
                            +-------+-------+
                            |  + + AR  + +  |
                            +----+-----+----+
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+    +-----+-----+
                          | AP  |    |   Switch  |
                          +--+--+    +---+-----+-+
                                         |     |
                                      +--+--+  +----+
                                      | AP  |       |
                                      +--+--+    +--+---+
                                                 | host |
                                                 +------+

      ---------------------------------------------------------------------


                     Figure 3: Switched Connections


























O'Hara & Yang            Expires August 8, 2004                [Page 16]

Internet-Draft                  CAPWAPA                    February 2004


      ---------------------------------------------------------------------


                            +-------+-------+
                            |  + + AR  + +  |
                            +-------+-------+
                                    |
                            --------+------ LAN
                                    |
                            +-------+-------+
                            |     router    |
                            +-------+-------+
                                    |
                            -----+--+--+--- LAN
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | AP  |       |  AP |
                          +--+--+       +--+--+

      ---------------------------------------------------------------------


                      Figure 4: Routed Connections


3.3 Access Router Discovery

   When a AP comes alive on a network it may authenticate and register
   with one or more ARs it detects on the network it is connected to. In
   some architectures today the ARs are the bridges they directly
   connect to. It performs a AR discovery procedure in its network
   neighborhood. Based on the Network Topology and Layering it MAY
   attempt a L2 or IP discovery of ACs. This will also depend partly on
   the architectural capabilities of the AP and of available ARs. The
   type of discovery protocol is also dependent on prior one-time
   Provisioning of AP (configuration). The identification of ARs is only
   dependent on the L2 or IP protocol used but is expected to be
   architecture-agnostic. It is the Capability Negotiation Phase
   (Section 3.3.2) that follows which resolves the mutual capabilities
   of AP and AC which lets them decide to AP register with one or more
   AC.

3.3.1 Access Router Availability

   CAPWAP discovery entails the ability of an AP to failover to another
   AR in the same domain (ESS) in the event of the failure of the



O'Hara & Yang            Expires August 8, 2004                [Page 17]

Internet-Draft                  CAPWAPA                    February 2004


   current AR.

   Failure detection and failover may use existing IP protocols such as
   VRRP or extensions thereof.

3.3.2 Capabilities Negotiation

   An AP performs AR discovery in its network neighborhood. Upon having
   discovered available ARs the AP enters into a capabilities exchange
   phase with the candidate ACs. If the architectural types match during
   the exchange - the AP registers with the AC and configures itself
   based on the policies it derives from the AC after mutually
   authenticating with the AC. The capabilities negotiated by
   architectural type match will decide the applicable API's between AP
   and AC.

3.3.3 Access Point Service Management

   In a large WLAN system with many APs, continuous management of those
   APs is necessary to enable quick reaction to changes in service
   capabilities caused by internal or external factors such as
   dynamically varying hotspot loads and time-variant fluctuations in RF
   interferences due to extraneous negihborhood devices. An adaptive RF
   management based on dynamic systemic monitoring, as well as power and
   frequency management is needed to be driven from ACs (or at times a
   hierarchy of ACs).

3.3.3.1 Monitoring

   Each AP in a WLAN must be monitored for a number of variables. This
   is needed to be able to assess the ability of the individual AP to
   meet the service demands placed upon it. Among the variables that
   need to be monitored are:

   o  instantaneous data load

   o  peak and average load over a configurable monitoring period

   o  Measurements of interference from neighboring BSS's

   o  number of mobile devices associated

   o  statistics for each associated mobile device

   o  Signal Strength of Received Frames

   o  RADAR detection




O'Hara & Yang            Expires August 8, 2004                [Page 18]

Internet-Draft                  CAPWAPA                    February 2004


3.3.3.2 Control

   Maintaining the operation of a large WLAN system at or near its peak
   capability requires that the individual APs that comprise that system
   must be controlled to adapt to changes in the internal or external
   factors that affect the performance of the system as a whole. In
   particular, the aspects of an AP that require control are the
   following:

   o  Access Controller to which the AP is connected

   o  enabling and disabling the operation of the AP

   o  Enabling and Disabling operation of individual radios at an AP

   o  establishment and update of session keys for protection of AC/AP
      communication

   o  Radio channel for transmission

   o  Transmit Power


3.3.4 AP Provisioning

   In order to create a trust model between the AP subsystem and AC
   subsystem for secure communications the APs need to be set up
   securely in the ACs' domain.

3.3.4.1 AP Configuration

   Configuration of an AP includes providing the parameters necessary
   for the AP to advertise and provide service for one or more WLANs.
   These parameters are both physical and logical.

   Physical parameters are related to the operation of the AP's radio
   interface. These include the channel on which the AP is to operate,
   the maximum power at which the AP is to transmit, antenna selections,
   the supported data rates, and the timing for the periodic
   announcements of the WLANs provisioned on the AP.

   Logical parameters are related to the individual WLANs that are
   provisioned on the AP. These include the SSID of the WLANs, the
   allowed authentication methods, the allowed privacy methods, values
   for the contention-free period and DTIM, VLAN associations, IP
   addresses and netmasks, authentication server addresses, any
   pre-shared keys for WLANs or authentication servers, regulatory
   (country) information, and other 802.11-specific capabilities to be



O'Hara & Yang            Expires August 8, 2004                [Page 19]

Internet-Draft                  CAPWAPA                    February 2004


   advertised for the WLANs.

3.3.4.2 Access Router Availability

   Also discussed earlier in Section 3.3 in discovery context, as part
   of provisioning the AP will be configured to register with one
   primary AC and may be allowed one or more secondary ACs. This ability
   will depend on the topology allowed by the architecture. Constrained
   architectures with limited AP-AR topologies may be unable to offer
   flexible redundancies and may require hardware supported
   alternatives.

3.3.5 CAPWAP Security

   The CAPWAP architecture spans more than the topology over the air.
   IEEE 802.11 (and now 802.11i) describes the single-hop security
   over-the-air. The resulting security scheme only protects the data
   frames (multicast, broadcast and unicast) between stations and AP.
   This leaves a security gap in the CAPWAP topology between AP and AC
   (AR).

   As discussed earlier, the security of control and management traffic
   between the AP and AR subsystem needs to be secured, failing which
   control of AP can be compromised.

   In addition there may be explicit requirements to secure the data
   flow between AP and AR segment. This is end-end traffic between WLAN
   stations and their WLAN/wireline destinations invariant to CAPWAP
   considerations. Protection of this traffic in this segment may
   incidentally ensue in architectures such as in ARCH2 and ACRH3.

3.3.5.1 WLAN Security

   802.11 provides layer 2 authentication and privacy services. Severe
   deficiencies have been documented in the mechanisms of the original
   standard. The current task group, 802.11i, is completing work on an
   amendment to the standard that addresses these deficiencies. The
   requirements for 802.11i are more difficult than simply providing the
   desired level of protection for the information carried by 802.11
   frames in new equipment. 802.11i must also provide a mechanism that
   can be used by equipment already deployed, to eliminate the
   deficiencies of the original standard to which the equipment was
   built.

   WLAN Security offers over-the-air single-hop MAC-layer frame security
   for data frames between Mobile Stations and AP's. This is built on
   top of 802.1X-based authentication and Session and Data-encryption
   Key Exchanges derived thereof.



O'Hara & Yang            Expires August 8, 2004                [Page 20]

Internet-Draft                  CAPWAPA                    February 2004


3.3.5.1.1 Authentication - EAP over LAN (802.1X)

   802.11i specifies an extensible authentication method, based on
   negotiation between the AP and mobile device that occurs during the
   association process. After successfully negotiating the particular
   authentication method to be used, the mobile device is allowed to
   associate, but must immediately complete the negotiated
   authentication before any data exchange will be permitted.

   The default mechanism for authentication defined by 802.11i is to
   piggyback on the 802.1X standard, using EAP to authenticate the
   mobile device or user after 802.11 association with an AP has
   completed. In the terms defined in 802.1X, an AP is an authenticator
   and a mobile device is a supplicant. The AP, as authenticator,
   proxies the supplicant's communications to an authentication system.
   An example authentication system is a RADIUS server. The AP
   communicates with the RADIUS server, as a RADIUS proxy for the
   client, using EAP. The AP is responsible for blocking the (logical)
   controlled port for the associated device until the successful
   completion of the 802.1X authentication. At the conclusion of the
   802.1X authentication, keying material is available to both the
   mobile device and AP that can be used for frame security.

3.3.5.1.2 Frame Security (802.11i)

   802.11i Frame Security offers Encryption, Message Integrity and
   Replay Protection services. To meet the requirements of improving
   security for both existing devices and new devices, 802.11i specifies
   two security mechanisms, the Transition Security Network (TSN) and
   the Robust Security Network (RSN). Both TSN and RSN utilize keying
   material derived from an 802.1X-based authentication exchange to
   deliver a pair-wise master key (PMK) to both the mobile device and
   AP. TSN can also use a preshared key (PSK) to derive a PMK without
   the use of an authentication exchange. From the PMK is derived a
   pair-wise transient key (PTK). The PTK is used to create a pair-wise
   temporal key (TK), an EAPOL key encryption key (KEK), and an EAPOL
   key confirmation key (KCK). An 802.1X exchange is also used to
   deliver the keying material to derive a group master key (GMK). From
   the GMK is derived a group transient key (GTK). The GTK is used to
   create a group temporal key (TK) used by the AP to encrypt multicast
   frames and by the mobile devices to decrypt multicast frames.

   TSN specifies a means to improve the security of equipment built with
   the original RC4-based wired equivalent privacy (WEP) cipher. TSN
   requires that the encryption key used with WEP be rotated on every
   packet. TSN specifies the algorithm for this key rotation, based on
   the pair-wise TK and the frame sequence counter. In addition, TSN
   specifies an algorithm for a keyed message integrity code (MIC) (more



O'Hara & Yang            Expires August 8, 2004                [Page 21]

Internet-Draft                  CAPWAPA                    February 2004


   often called message authentication code (MAC), but that acronym is
   already utilized in the 802.11 standard), called Michael. Michael is
   a compromise between strength and computational requirements, because
   this must operate on legacy equipment with fixed computational
   capabilities. As a result, TSN also specifies some rather severe
   countermeasures to be implemented when an attack against the MIC is
   suspected.

   RSN specifies an encapsulation and algorithm for new equipment that
   is significantly stronger than either WEP or TSN. The algorithm is an
   AES mode called Counter Mode with CBC-MAC (CCM)[3]. This AES mode
   provides data privacy, data integrity, and source integrity with low
   additional computational requirements beyond data privacy, alone.

3.3.5.2 Mutual Authentication of AP and AR

   As detailed in Section 3.3.5, the need to enforce secure
   communication requires a mutual strong authentication protocol and an
   associated Key Management protocol that derives from the trust
   established the authentication phase. The resulting key material is
   used to derive session keys and subsequent key agreement for setting
   up secure encapsulation of AP-AR meta-communications.

   The Key Management protocol choices are governed by the worst-case
   specification of Lightweight AP (LAP) capabilities.

3.3.5.3 Path Security of AP and AR

   The secure communications MUST support confidentiality, message
   authentication and replay protection. The choice of ciphers should
   consider the required strength and threat model as well as the
   compute capabilities, real-time nature and relative bandwidth of such
   traffic.

3.4 Summary

   The CAPWAP allows for a set of flexible architectures as described in
   Section 3.1.4 The architecture proposes the following set of CAPWAP
   services to achieve the Security, Ease of Management, Enhanced QoS
   and Mobility objectives across the WLAN domain:

   o  AC Discovery

   o  Capability Negotiation

   o  Mutual Authentication of AP and AC

   o  Secure Encapsulation Protocol based on Secure Key Management



O'Hara & Yang            Expires August 8, 2004                [Page 22]

Internet-Draft                  CAPWAPA                    February 2004


   o  Secure AP Configuration from AC

   o  Secure Encapsulation of Control and/or Data between AP & AC
















































O'Hara & Yang            Expires August 8, 2004                [Page 23]

Internet-Draft                  CAPWAPA                    February 2004


4. Prior Work

   Related work on such problems have been dealt with in Academia
   (Section 4.1) and standards (Section 4.2). The former is more
   directly related to the proposed CAPWAP architecture. The latter is a
   generic solution attempted to address distributed data-forwarding
   front-ends with highly available control-plane backends.

4.1 DIRAC

   DIRAC is a DIstributed Router ArChitecture for wireless networks,
   independently developed by a research group in UCLA. DIRAC [17]
   adopts a very similar distributed architecture to what is proposed
   here that is composed of a generic Router Core (RC) shared by the
   wireless subnets and a lightweight and network specific Router Agent
   (RA) at each access point/base station. The Router Core in DIRAC
   corresponds to AR in CAPWAP while the Router Agents are the APs.

   While the architecture and end goals of DIRAC are very similar to
   CAPWAP, there are several difference that are worth pointing out:

   o  The Router Core at DIRAC is intended to be generic and agnostic to
      the L2 radio technology being used between the Router Agent and
      the client terminals. This is achieved by terminating the radio
      specific L2 connection at the Router Agent while the statistics/
      actions(i.e.,control)/events messages that are exchanged between
      the Router Core and the Router Agent are abstracted into a
      different and generic packet format. CAPWAP, on the other hand,
      simply encapsulates the 802.11 management frames from APs to ARs
      so that ARs have to fully understand 802.11 frame format.

   o  No security is being considered in the DIRAC work which is
      probably ok for academic research but not ok for IETF standard.

   o  The DIRAC paper focuses less on the protocol between the RC and RA
      but a lot more on the architecture and implementation issues in
      this work. The protocol consists of three kinds of messages:
      statistics, actions (i.e., controls) and (asynchronous) events.
      DIRAC does not consider the issue of discovery and firmware image
      downloading etc.

   o  The DIRAC paper provides three prototype wireless services that
      are implemented within the DIRAC framework to demonstrate not only
      the potential performance gain but also the viability of these new
      wireless services being enabled by such a framework. These
      examples provide some nice academic data points for CAPWAP.





O'Hara & Yang            Expires August 8, 2004                [Page 24]

Internet-Draft                  CAPWAPA                    February 2004


4.2 ForCES

   The IETF ForCES (Forwarding and Control Element Separation) group was
   chartered to "define a framework and associated mechanisms for
   standardizing the exchange of information between the logically
   separate functionality of the control plane, including entities such
   as routing protocols, admission control, and signaling, and the
   forwarding plane, where per-packet activities such as packet
   forwarding, queuing, and header editing occur. By defining a set of
   standard mechanisms for control and forwarding separation, ForCES
   will enable rapid innovation in both the control and forwarding
   planes. A standard separation mechanism allows the control and
   forwarding planes to innovate in parallel while maintaining
   interoperability."

4.2.1 Similarities in Objectives and Architectural Considerations

   While ForCES aims to provide interoperability between CEs and FEs
   from different vendors, CAPWAP has a very similar goal in mind -- to
   allow APs and ARs from different vendors to interoperate when mixed
   and matched in the wireless access networks. Even though ForCES
   originally was heavily focused on routers to achieve interoperability
   between Forwarding Elements (FEs) and Control Elements (CEs) inside a
   router (i.e., Network Element -- NE), many similarities or analogies
   can be found between ForCES architecture and CAPWAP architecture:

   o  "The APs can be considered as remote RF interfaces, being
      controlled by the AR" [LWAPP spec] -- it is clear that APs in the
      CAPWAP architecture can be viewed as FEs in the ForCES
      architecture, or more precisely, APs can be viewed as a specific
      wireless port function (Logical Functional Block, LFB, using
      ForCES's terminology) that is part of the FEs.

   o  The LWAPP-related functionality of AR in the wireless access
      network is mostly control plane related and hence the AR can be
      considered a CE from the ForCES point of view. It should be noted
      that the AR also performs forwarding functions, and as such, could
      also be internally viewed as a CE/FE combination, although usage
      of ForCES to control APs by the AR would not necessitate usage of
      ForCES within the AR.

   o  "AR + multiple lite-weight APs" as a whole then can be considered
      as a distributed router with some parts of the FEs (APs)
      physically separated from the CEs.







O'Hara & Yang            Expires August 8, 2004                [Page 25]

Internet-Draft                  CAPWAPA                    February 2004


4.2.2 Overlap in Topology Considerations

   While it is possible to construct a NE out of CEs and FEs which are
   physically separated by a routed (L3) cloud, ForCES constrains itself
   to focussing on very close localities consisting of CE and FEs that
   are either components in the same physical box, or are separated at
   most by one local network (L3) hop. This topology overlaps with the
   three topologies -- directly connected, switched (L2), or routed (L3)
   -- considered by CAPWAP as well. But if CAPWAP support arbitrary
   routed cloud (with multiple L3 hops) between AP and AR, we need to
   carefully examine ForCES and see if it can accommodate such topology
   while still satisfying all the requirements including security.

4.2.3 Differences in Design Approach

   The general design behind ForCES is to separate the base protocol
   from the actual information elements that carry the control/
   configuration/monitoring/events messages between the CE and FE, due
   to the diversity of FE functions among data plane vendors. The
   information elements that are specific to any particular FE (e.g.,
   IPv4 forwarding, or DiffServ, or MPLS) are represented in the FE
   model. Such a design allows ForCES to be very flexible and extensible
   to accommodate a wide spectrum of data plane functions, possibly
   including IEEE 802.11 wireless AP functions. The current LWAPP
   protocol is taking a very different design approach. LWAPP is a very
   domain specific protocol. While the general domain for LWAPP can
   potentially include any wireless radio technologies, the current spec
   of LWAPP is very much IEEE 802.11 specific and many of the 802.11
   functions are assumed and built into the protocol directly.

4.2.4 Differences in the Functionality        Controlled

   The FE functions being controlled by CE via ForCES are mostly L3 and
   L4, but sometimes L2 (e.g., ARP). On the other hand, the AP functions
   that are being controlled by ARs are mostly L2 (IEEE 802.11MAC), but
   sometimes higher layer as well (if those functions reside on APs).

4.2.5 Similarities in Security Requirements

   The security requirements in both the CAPWAP and ForCES appear to
   overlap significantly, in terms of secure association,
   authentication, confidentiality, integrity, anti-replay, etc. Even
   though ForCES has not finalized on its protocol selection (among
   three proposals) yet, ForCES framework document recommends that
   ForCES adopt one of the standard security mechanisms (IPsec or TLS).
   More close examination of security requirements and mechanisms
   employed in ForCES and CAPWAP is needed here.




O'Hara & Yang            Expires August 8, 2004                [Page 26]

Internet-Draft                  CAPWAPA                    February 2004


4.2.6 Difference in Operation Scope

   Even though no specific discovery mechanism is specified in the
   current LWAPP spec, CAPWAP does consider AR discovery in scope; on
   the other hand, ForCES considers the process of CE and FE discovering
   each other out of scope. ForCES assumes CEs and FEs enter the
   post-association phase with knowledge of which corresponding entities
   they are authorized to communicate with, but ForCES itself does not
   address how pre-association is done.

4.2.7 Comparision in Protocols

   ForCES currently has three protocol proposals and the WG has just
   started the protocol evaluation and selection process. Therefore, it
   is difficult to compare LWAPP with ForCES at the moment from the
   protocol view-point, unless one compares LWAPP with all the three
   proposals first.

   But ForCES requirement draft [18] captures all the important
   requirements that ForCES protocol is supposed to support. Merely
   comparing LWAPP with this set of requirements can already provide
   some insight.

   The most obvious difference in the two protocols may very well be due
   to fundamentally different design philosophies behind the two as
   pointed out in Section 4.2.4. LWAPP is a domain specific protocol
   withsome messages assuming 802.11 sematics, while the base ForCES
   protocol only supports the general procedures involved for setting up
   association between the CE and FE, CE querying FE its capability and
   configuration state (if any), CE provisioning FE according to the
   basic capability leaned in the querying stage, and FE reporting
   statistics and asynchronous events to CE, etc. In the context of
   ForCES, the messages with 802.11 specific semantics would not appear
   in the base ForCES protocol. Instead, an 802.11 FE (or LFB) model
   would have to be specified to support all the 802.11 specific
   configuration, statistics, and events.

   Another major difference is on reliability requirement. The ForCES
   protocol is required to support strict reliability for mission
   critical payloads. On the other hand, LWAPP does not assume any
   reliability between the AR and AP, because it is built on top of L2
   or IP directly.

   One thing that LWAPP supports but none of the ForCES protocol
   proposals directly address is firmware image downloading.






O'Hara & Yang            Expires August 8, 2004                [Page 27]

Internet-Draft                  CAPWAPA                    February 2004


5. Security Considerations

   One of the major goals of the CAPWAP architecture is to ensure strong
   authentication of AP to the registered AR and secure communications
   between them as described in the preceding sections.

   AR-AP traffic can be classified into: data traffic (e.g. from or to
   an user), and control traffic which is strictly between the AR and
   AP. Since data traffic may be secured by end-to-end security
   mechanisms outside the scope of this work, we confine our solution to
   control traffic. The resulting security consists of two components:
   an authenticated key exchange, and control traffic security
   encapsulation. The security encapsulation may be accomplished using
   relatively lightweight mechanisms such as CCM, described in [2]. This
   encapsulation provides for strong AES-based message authentication
   and encryption. Detailed discussions of such possible security
   protocol alternatives are out of scope in this document.


































O'Hara & Yang            Expires August 8, 2004                [Page 28]

Internet-Draft                  CAPWAPA                    February 2004


6. Acknowledgements

   The authors wish to thank the timely inputs and discussions provided
   by Pat Calhoun. In no less measure we also thank Scott Kelly et al in
   consenting to let us adapt from their topological and architectural
   analysis in [5] that helped shorten the time to draft. The authors
   also wish to thank IESG & IAB for their feedback and discussions that
   has helped focus this draft objective. Thanks also to Herman Haisch
   for inputs on  various WLAN architectural types. The authors also
   thank Dorothy Stanley for the IEEE perspective.









































O'Hara & Yang            Expires August 8, 2004                [Page 29]

Internet-Draft                  CAPWAPA                    February 2004


References

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

   [2]   "Advanced Encryption Standard (AES)", November 2001, <FIPS PUB
         197>.

   [3]   "Counter with CBC-MAC (CCM)", September 2003, <RFC 3610>.

   [4]   "Light Weight Access Point Protocol (LWAPP)", June 2003,
         <http://www.ietf.org/internet-drafts/
         draft-calhoun-seamoby-lwapp-03.txt>.

   [5]   "Security Requirements for a Light Weight Access Point
         Protocol", August 2003, <http://www.ietf.org/internet-drafts/
         draft-kelly-ietf-lwapp-sec-00.txt>.

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

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

   [8]   "Mobility Related Terminology", April 2003, <ftp://ftp.isi.edu/
         internet-drafts/draft-ietf-seamoby-terminology-04.txt>.

   [9]   "Extensible Authentication Protocol (EAP)", September 2003,
         <http://www.ietf.org/internet-drafts/
         draft-ietf-eap-rfc2284bis-06.txt>.

   [10]  "WiFi Protected Access (WPA) ver 2.0", April 2003.

   [11]  "IEEE Std 802.11i/6.0: Specification for Enhanced Security",
         September 2003.

   [12]  "IEEE Std 802.11F: Recommended Practice for Multi-Vendor Access
         Point Interoperability via an Inter-Access Point Protocol
         across Distribution Systems Support 802.11 Operation", July
         2003.

   [13]  "IEEE Std 802.2: Logical Link Control", 1998.

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

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



O'Hara & Yang            Expires August 8, 2004                [Page 30]

Internet-Draft                  CAPWAPA                    February 2004


   [16]  "IEEE Std 802.1Q: Virtual Bridged Local Area Networks", May
         2003.

   [17]  "DIRAC: A Software-based Wireless Router System", 2003.

   [18]  "Requirements for Separation of IP Control and Forwarding",
         July 2003, <http://www.ietf.org/internet-drafts/
         draft-ietf-forces-requirements-10.txt>.


Authors' Addresses

   Bob O'Hara
   Airespace
   110 Nortech Parkway
   San Jose, CA  95134

   Phone: +1 408-635-2025
   EMail: bob@airespace.com


   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























O'Hara & Yang            Expires August 8, 2004                [Page 31]

Internet-Draft                  CAPWAPA                    February 2004


Appendix A. IEEE 802.11 - Details and Current Work

   The 802.11 working group is currently proceeding on work related to
   layer 2 security and quality of service. The 802.11i task group is
   addressing the security issues of the original 802.11 standard in the
   areas of authentication and encryption. This work refers to other
   standards, including 802.1X Port Based Access Control [15] and the
   Extensible Authentication Protocol [9]. The 802.11e task group is
   addressing layer 2 quality of service items through extending the
   access method, frame definitions, and MAC management protocol of the
   original standard. This work refers to the 802.1Q [16] standard.

   802.11 PHYs are wireless, by definition, and principally use radio
   technology for communication. An aspect of an 802.11 WLAN that is not
   addressed by the standard is the necessity to manage the
   self-interference of one AP when operating on a radio channel equal
   to or near the radio channel of another AP within reception range.
   Managing self-interference within the WLAN involves both measurement
   of the level of interference, as well as control of the transmit
   power and transmitting channel in each of the APs. Work currently in
   process in the 802.11k task group is addressing the issue of radio
   resource measurement, which will provide the information on level of
   interference, among other things.

   In addition to the 802.11 standard, the 802.11 working group produced
   a recommended practice for inter-AP communication, 802.11F [12]. The
   recommended practice describes the use of a new application protocol,
   the Inter-AP Protocol (IAPP), carried on UDP or TCP. It permits APs
   to exchange information about roaming mobile devices, including an
   envelope for general context transfer purposes, and to push layer 2
   keying information to neighboring APs in preparation for the roaming
   of mobile devices to those neighboring APs. The recommended practice
   specifies the use of 802.2 [13] XID frames for updating layer 2
   devices when a mobile device's point of attachment to the network has
   changed due to a roaming event. 802.11F also specifies the use of
   RADIUS for the authentication of one AP to another and, along with
   portions of the IAPP protocol, to establish a secure means to
   exchange IAPP packets between participating APs.

   The IAPP is not applicable to this architecture, though it may be
   implemented in the access controller for communication with other
   access controllers as 802.11 intended it to be used between
   individual APs. It is not applicable within the CAPWAP architecture
   because, presumably, the communications defined by CAPWAP would be
   internal to the access controller and not require such a protocol to
   be utilized.





O'Hara & Yang            Expires August 8, 2004                [Page 32]

Internet-Draft                  CAPWAPA                    February 2004


Appendix B. Requirements

B.1 Architectural

   o  AP-AC Interconnect

   o  AP-AC Interconnect


B.2 Protocol

B.3 Security







































O'Hara & Yang            Expires August 8, 2004                [Page 33]

Internet-Draft                  CAPWAPA                    February 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



O'Hara & Yang            Expires August 8, 2004                [Page 34]

Internet-Draft                  CAPWAPA                    February 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.











































O'Hara & Yang            Expires August 8, 2004                [Page 35]


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