CAPWAP Working Group L. Yang (Editor)
Internet-Draft Intel Corp.
Expires: January 30, 2005 P. Zerfos
UCLA
E. Sadot
Avaya
Aug 2004
Architecture Taxonomy for Control and Provisioning of Wireless Access
Points(CAPWAP)
draft-ietf-capwap-arch-05
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 30, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document provides a taxonomy of the architectures employed in
the existing IEEE 802.11 products in the market, by analyzing WLAN
(Wireless LAN) functions and services and describing the different
Yang (Editor), et al. Expires January 30, 2005 [Page 1]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
variants in distributing these functions and services among the
architectural entities.
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions used in this document . . . . . . . . . . . . 3
1.2 IEEE 802.11 Definitions . . . . . . . . . . . . . . . . . 3
1.3 Terminology Used in this Document . . . . . . . . . . . . 4
1.4 Terminology Used Historically but Not Recommended . . . . 6
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . . . 7
2.2 CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . 9
2.3 WLAN Architecture Proliferation . . . . . . . . . . . . . 10
2.4 Taxonomy Methodology and Document Organization . . . . . . 12
3. Autonomous Architecture . . . . . . . . . . . . . . . . . . . 14
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Centralized WLAN Architecture . . . . . . . . . . . . . . . . 16
4.1 Interconnection between WTPs and ACs . . . . . . . . . . . 17
4.2 Overview of Three Centralized WLAN Architecture
Variants . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Local MAC . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Split MAC . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Comparisons of Local MAC, Split MAC and Remote MAC . . . . 29
4.7 Communication Interface between WTPs and ACs . . . . . . . 30
4.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.8.1 Client Data Security . . . . . . . . . . . . . . . . . 31
4.8.2 Security of control channel between the WTP and AC . . 32
4.8.3 Physical Security of WTPs and ACs . . . . . . . . . . 32
5. Distributed Mesh Architecture . . . . . . . . . . . . . . . . 33
5.1 Common Characteristics . . . . . . . . . . . . . . . . . . 33
5.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . 42
Yang (Editor), et al. Expires January 30, 2005 [Page 2]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
1. Definitions
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
1.2 IEEE 802.11 Definitions
Station (STA): Any device that contains an IEEE 802.11 conformant
medium access control (MAC) and physical layer (PHY) interface to the
wireless medium (WM).
Access Point (AP): Any entity that has station functionality and
provides access to the distribution services, via the wireless medium
(WM) for associated stations.
Basic Service Set (BSS): A set of stations controlled by a single
coordination function.
Station Service (SS): The set of services that support transport of
medium access control (MAC) service data units (MSDUs) between
stations within a basic service set (BSS).
Distribution System (DS): A system used to interconnect a set of
basic service sets (BSSs) and integrated local area networks (LANs)
to create an extended service set (ESS).
Extended Service Set (ESS): A set of one or more interconnected basic
service sets (BSSs) with the same SSID and integrated local area
networks (LANs) that appears as a single BSS to the logical link
control layer at any station associated with one of those BSSs.
Portal: The logical point at which medium access control (MAC)
service data units (MSDUs) from a non-IEEE 802.11 local area network
(LAN) enter the distribution system (DS) of an extended service set
(ESS).
Distribution System Service (DSS): The set of services provided by
the distribution system (DS) that enable the medium access control
(MAC) to transport MAC service data units (MSDUs) between stations
that are not in direct communication with each other over a single
instance of the wireless medium (WM). These services include
transport of MSDUs between the access points (APs) of basic service
sets (BSSs) within an extended service set (ESS), transport of MSDUs
between portals and BSSs within an ESS, and transport of MSDUs
between stations in the same BSS in cases where the MSDU has a
Yang (Editor), et al. Expires January 30, 2005 [Page 3]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
multicast or broadcast destination address or where the destination
is an individual address, but the station sending the MSDU chooses to
involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs.
Integration: The service that enables delivery of medium access
control (MAC) service data units (MSDUs) between the distribution
system (DS) and an existing, non-IEEE 802.11 local area network (via
a portal).
Distribution: The service that, by using association information,
delivers medium access control (MAC) service data units (MSDUs)
within the distribution system (DS).
1.3 Terminology Used in this Document
One of the motivations in defining new terminology in this document
is to clarify some of the ambiguity and confusion surrounding some
conventional terms. One of such terms is "Access Point (AP)".
Typically ,when people talk about "AP", they refer to the physical
entity (box) that has an antenna, implements 802.11 PHY and receives/
transmits the station (STA) traffic over the air. However, the
802.11 Standard [1] describes the AP mostly as a logical entity that
implements a set of logical services so that station traffic can be
received and transmitted effectively over the air. So when people
talk about "AP functions", they usually mean the logical functions
the whole WLAN access networks support, not just the part of the
functions supported by the physical entity (box) that the STAs
communicate to directly. Such confusion can be especially profound
when the logical functions is implemented across a network instead of
within a single physical entity. So to avoid further confusion, we
define the following terminology used in this document:
CAPWAP: Control and Provisioning of Wireless Access Points.
IEEE 802.11 WLAN Functions: a set of logical functions defined by
IEEE 802.11 Working Group, including all the MAC services, Station
Services, and Distribution Services. These logical functions are
required to be implemented in the IEEE 802.11 Wireless LAN (WLAN)
access networks by the IEEE 802.11 Standard[1].
CAPWAP Functions: a set of WLAN control functions that are not
directly defined by IEEE 802.11 Standards, but deemed essential for
effective control, configuration and management of 802.11 WLAN access
networks.
Wireless Termination Point (WTP): the physical or network entity that
contains RF antenna and 802.11 PHY to transmit and receive station
traffics for the IEEE 802.11 WLAN access networks. Such physical
Yang (Editor), et al. Expires January 30, 2005 [Page 4]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
entities are often called "Access Points" (AP) previously, but "AP"
can also be used to refer to logical entity that implements 802.11
services. So we recommend using "WTP" instead to explicitly refer to
the physical entity.
Autonomous WLAN Architecture: the WLAN access network architecture
family in which all the logical functions, including both IEEE 802.11
and CAPWAP functions (wherever applicable), are implemented within
each Wireless Termination Point (WTP) in the network. The WTPs in
such networks are also called standalone APs, or fat APs, because
these devices implement the full set of functions that enable the
devices to operate without any other support from the network.
Centralized WLAN Architecture: the WLAN access network architecture
family in which the logical functions, including both IEEE 802.11 and
CAPWAP functions (wherever applicable), are implemented across a
hierarchy of network entities. At the low level of such hierarchy
are the WTPs while at the higher level are the Access Controllers
(ACs), which are responsible to control, configure and manage the
entire WLAN access networks.
Distributed WLAN Architecture: the WLAN access network architecture
family in which some of the control functions (e.g., CAPWAP
functions) are implemented across a distributed network consisting of
peer entities. A wireless mesh network can be considered as an
example of such an architecture.
Access Controller (AC): The network entity in the Centralized WLAN
architectures that provide WTPs access to the centralized
hierarchical network infrastructure, either in the data plane,
control plane, or management plane, or a combination therein.
Standalone WTP: referred to the WTP in Autonomous WLAN Architecture.
Controlled WTP: referred to the WTP in Centralized WLAN Architecture.
Split MAC Architecture: A sub-group of the Centralized WLAN
Architecture, with the characteristic that WTPs in such WLAN access
networks only implement the delay sensitive MAC services (including
all control frames and some management frames) for IEEE 802.11, while
tunneling all the remaining management and data frames to AC for
centralized processing. The IEEE 802.11 MAC as defined by IEEE
802.11 Standards in [1] is effectively split between the WTP and AC.
Remote MAC Architecture: A sub-group of the Centralized WLAN
Architecture, where the entire set of 802.11 MAC functions (including
delay-sensitive functions) are implemented at the AC. The WTP
terminates the 802.11 PHY functions.
Yang (Editor), et al. Expires January 30, 2005 [Page 5]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
Local MAC Architecture: A sub-group of the Centralized WLAN
Architecture, where the majority or entire set of 802.11 MAC
functions (including most of the 802.11 management frame processing)
are implemented at the WTP. Therefore, the 802.11 MAC stays intact
and local in the WTP, along with PHY.
1.4 Terminology Used Historically but Not Recommended
While some terminology has been used by vendors historically to
describe "Access Points", we recommend to defer its use, in order to
avoid further confusion. A list of such terms and the recommended
new terminology are provided below:
Split WLAN Architecture: use Centralized WLAN Architecture.
Hierarchical WLAN Architecture: use Centralized WLAN Architecture.
Standalone Access Point: use WTP or Standalone WTP.
Fat Access Point: the same as Standalone Access Point. Use WTP or
Standalone WTP.
Thin Access Point: use WTP, or Controlled WTP.
Light weight Access Point: the same as Thin Access Point, use WTP, or
Controlled WTP.
Split AP Architecture: use Local MAC Architecture.
Antenna AP Architecture: use Remote MAC Architecture.
Yang (Editor), et al. Expires January 30, 2005 [Page 6]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
2. Introduction
As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale
deployment of WLAN networks is highlighting certain technical
challenges. As outlined in [2], management, monitoring and control
of large number of Access Points (APs) in the network may prove to be
a significant network administration burden. Distributing and
maintaining a consistent configuration throughout the entire set of
APs in the WLAN is a difficult task. The shared and dynamic nature
of the wireless medium also demands effective coordination among the
APs to minimize radio interference and maximize network performance.
Network security issues, which have always been a concern in WLAN's,
present even more challenges in large deployments and new
architectures.
Recently many vendors have begun offering partially proprietary
solutions to address some or all of the above mentioned problems.
Since interoperable solutions allow for a broader choice, a
standardized interoperable solution addressing the aforementioned
problems is desirable. As the first step toward establishing
interoperability in the market place, this document attempts to
provide a taxonomy of the architectures employed in existing WLAN
products. We hope to provide a cohesive understanding of the market
practices for the standard bodies involved (including the IETF and
IEEE 802.11). This document may be reviewed and utilized by the IEEE
802.11 Working Group as input to their task of defining the
functional architecture of an access point.
2.1 IEEE 802.11 WLAN Functions
The IEEE 802.11 specifications are wireless standards that specify an
"over-the-air" interface between a wireless client (STA) and an
Access Point (AP), and also among wireless clients. 802.11 also
describes how mobile devices can associate together into a basic
service set (BSS). A BSS is identified by a basic service set
identifier (BSSID) or name. The WLAN architecture can be considered
as a type of 'cell' architecture where each cell is the Basic Service
Set (BSS) and each BSS is controlled by the Access Point (AP). When
more than one AP are connected via a broadcast layer 2 network and
all are using the same SSID, an extended service set (ESS) is
created.
The architectural component used to interconnect BSSs is the
distribution system (DS). An access point (AP) is a STA that
provides access to the DS by providing DS services in addition to
acting as a STA. Another logical architectural component -- portal
-- is introduced to integrate the IEEE 802.11 architecture with a
traditional wired LAN. It is possible for one device to offer both
Yang (Editor), et al. Expires January 30, 2005 [Page 7]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
the functions of an AP and a portal.
IEEE 802.11 explicitly does not specify the details of DS
implementations. Instead, the 802.11 standard defines services that
provide the functions that the LLC layer requires for sending MAC
Service Data Units (MSDUs) between two entities on the network.
These services can be classified into two categories: the station
service (SS) and the distribution system service (DSS). Both
categories of service are used by the IEEE 802.11 MAC sublayer.
Station services consist of the following four services:
o Authentication: The service used to establish the identity of one
station as a member of the set of stations authorized to associate
with another station.
o Deauthentication: The service that voids an existing
authentication relationship.
o Confidentiality: The service used to prevent the content of
messages from being read by other than the intended recipients.
o MSDU Delivery: The service to deliver the MAC service data unit
(MSDU) for the Stations.
Distribution system services consist of the following five services:
o Association: The service used to establish access point/station
(AP/STA) mapping and enable STA invocation of the distribution
system services.
o Disassociation: The service that removes an existing association.
o Reassociation: The service that enables an established association
[between access point (AP) and station (STA)] to be transferred
from one AP to another (or the same) AP.
o Distribution: The service that provides MSDU forwarding by APs for
the STAs associated with them. MSDUs can be either forwarded to
the Wireless destination or to the Wired (Ethernet) destination
(or both) using the "Distribution System" concept of 802.11.
o Integration: The service that is used to translate the MSDU
received from the Distribution System to a non-802.11 format and
vice versa. Any MSDU that is received from the DS invokes the
"Integration" services of the DSS before the 'Distribution'
services are invoked. The point of connection of the DS to the
wired LAN is termed as 'portal'.
Apart from these services the IEEE 802.11 also defines additional MAC
services that must be implemented by the APs in the WLAN. For
example:
o Beacon Generation
o Probe Response/Transmission
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o Synchronization
o Retransmissions
Yang (Editor), et al. Expires January 30, 2005 [Page 8]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
o Transmission Rate Adaptation
o Privacy: 802.11 Encryption/Decryption
In addition to the services offered by the 802.11, the IEEE 802.11 WG
is also developing technologies to support Quality of Service
(802.11e), Security Algorithms (802.11i), Inter-AP Protocol (IAPP, or
802.11F -- recommended practice) to update APs when a STA roams from
one BSS to the other, Radio Resource Management (802.11k) etc.
IEEE 802.11 does not exactly specify how all these functions get
implemented, nor does it specify that these functions be implemented
all in one physical device (e.g., the WTP). Conceptually, all it
requires is that the WTPs and the rest of the DS together implements
all these services. Typically, vendors implement not only the
services defined in the IEEE 802.11 standard, they also implement a
variety of value-added services or functions, like load balancing
support, QoS, station mobility support, rogue AP detection, etc.
What will become clear from the rest of this document is that vendors
do take advantage of the flexibility in the 802.11 architecture, and
have come up with many different flavors of architectures and
implementations of the WLAN services.
Because many vendors choose to implement these WLAN services across
multiple network elements, we want to make a clear distinction
between the logical WLAN access network functions, and the individual
physical devices. Each of these physical devices may implement only
part of the logical functions. But the DS including all the physical
devices as a whole implements all, or most of the functions.
2.2 CAPWAP Functions
In order to address the four problems identified in the [2]
(management, consistent configuration, RF control, security)
additional functions, especially in the control plane and management
plane, are typically offered by vendors to assist better coordination
and control across the entire ESS network. Such functions are
especially important when the IEEE 802.11 WLAN functions are
implemented across a large scale network of multiple entities,
instead of within a single entity. Such functions are:
o RF monitoring, like Radar detection, noise and interference
detection and measurement.
o RF configuration, e.g., for retransmission, channel selection,
transmission power adjustment, etc.
o WTP configuration, e.g., for SSID, etc.
o WTP firmware loading, e.g., automatic loading and upgrading of WTP
firmware for network wide consistency.
o Network-wide STA state information database, including the
information needed to support value-added services, such as
Yang (Editor), et al. Expires January 30, 2005 [Page 9]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
mobility, load balancing etc.
o Mutual authentication between network entities, e.g., for AC and
WTP authentication in a Centralized WLAN Architecture.
The services listed are concerned with configuration and control of
the radio resource ('RF Monitoring' and 'RF Configuration'),
management and configuration of the WTP device ('WTP Configuration',
'WTP Firmware upgrade'), and also security regarding the registration
of the WTP to an AC ('AC/WTP mutual authentication'). Moreover, the
device from which other services such as mobility management across
subnets, and load balancing can obtain state information regarding
the STA(s) associated with the wireless network, is also reported as
a service ('STA state info database').
The above list of CAPWAP functions does not attempt to be an
exhaustive enumeration of all additional services offered by vendors.
Instead, we included only those functions that are commonly
represented in the survey data, and are also pertinent to the
understanding of the central problem of interoperability.
Most of these functions are not explicitly specified by IEEE 802.11,
but some of the functions are. For example, control and management
of the radio-related functions of an AP are described implicitly in
the MIB, such as:
o Channel Assignment
o Transmit Power Control
o Radio Resource Measurement (work currently under way in IEEE
802.11k)
The 802.11h [6] amendment to the base 802.11 standard specifies the
operation of a MAC management protocol to accomplish the requirements
of some regulatory bodies (principally in Europe, but expanding to
others) in these areas:
o RADAR detection
o Transmit Power Control
o Dynamic Channel Selection
2.3 WLAN Architecture Proliferation
This document provides a taxonomy of the WLAN network architectures
developed by the vendor community in an attempt to address some or
all of the problems outlined in [2]. As the IEEE 802.11 standard
purposely avoids to specify the details of DS implementations,
different architectures have proliferated in the market. While all
these different architectures conform to the IEEE 802.11 standard as
a whole, their individual functional components are not standardized.
The interfaces between the network architecture components are mostly
proprietary, and there is no guarantee of cross-vendor
Yang (Editor), et al. Expires January 30, 2005 [Page 10]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
interoperability of products, even within the same architecture
family.
In order to achieve interoperability in the market place, the IETF
CAPWAP working group is taking on the first logical task of
documenting both the functions and the network architectures offered
by the existing WLAN vendors today. The end result of this task is
this taxonomy document.
After analyzing more than a dozen different vendors' architectures,
we believe that the existing 802.11 WLAN access network architectures
can be broadly categorized into three distinct families, based on the
characteristics of the Distribution Systems that are employed to
provide the 802.11 functions.
o Autonomous WLAN Architecture: The first architecture family is the
traditional autonomous WLAN architecture, where each WTP is a
single physical device that implements all the 802.11 services,
including both the distribution and integration services, and the
portal function. Such an AP architecture is called Autonomous
WLAN Architecture because each WTP is autonomous in its
functionality, and no explicit 802.11 support is needed from
devices other than the WTP. The WTP in such architecture is
typically configured and controlled individually, and can be
monitored and managed via typical network management protocols
like SNMP. The WTPs in this architecture are the traditional
Access Points most people are familiar with. Sometimes such WTPs
are referred to as "Fat APs" or "Standalone APs".
o Centralized WLAN Architecture: The second WLAN architecture family
is an emerging hierarchical architecture utilizing one or more
centralized controllers for managing a large number of WTP
devices. The centralized controller is commonly referred to as an
Access Controller (AC), whose main function is to manage, control
and configure the WTP devices that are present in the network. In
addition to being a centralized entity for the control and
management plane, it may also become a natural aggregation point
for the data plane, since it is typically situated in a
centralized location in the wireless access network. The AC is
often co-located with an L2 bridge, a switch, or an L3 router, and
hence may be referred to as Access Bridge, or Access Router in
those particular cases. Therefore, an Access Controller could be
either an L3 or L2 device, and Access Controller is the generic
terminology we use throughout this document. It is also possible
that multiple ACs are present in a network for purposes of
redundancy, load balancing, etc. This architecture family has
several distinct characteristics that are worth noting. First of
all, the hierarchical architecture and the centralized AC afford
much better manageability for the large scale networks. Secondly,
since the IEEE 802.11 functions and the CAPWAP control functions
Yang (Editor), et al. Expires January 30, 2005 [Page 11]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
are provided by the WTP devices and the AC together, the WTP
devices themselves may not implement the full 802.11 functions as
defined in the standards any more. Therefore, it can be said that
the full 802.11 functions are implemented across multiple physical
network devices, namely, the WTPs and ACs. Since the WTP devices
only implement a portion of the functions that standalone APs
implement, WTP devices in this architecture are sometimes referred
to as light weight or thin APs by some vendors.
o Distributed WLAN Architecture: The third emerging WLAN
architecture family is the distributed architecture in which the
participating wireless nodes are capable of forming a distributed
network among themselves, via either wired or wireless media. A
wireless mesh network is one example in the distributed
architecture family, where the nodes themselves form a mesh
network, and connect with neighboring mesh nodes via 802.11
wireless links. Some of these nodes also have wired Ethernet
connections, acting as gateways to the external network.
2.4 Taxonomy Methodology and Document Organization
Before the IETF CAPWAP working group started documenting the various
WLAN architectures, we conducted an open survey soliciting WLAN
architecture description contributions via the IETF CAPWAP mailing
list. We provided the interested parties with a common template that
included a number of questions about their WLAN architectures. We
received 16 contributions in the form of short text descriptions
answering those questions.. 15 of them are from WLAN vendors
(AireSpace, Aruba, Avaya, Chantry Networks, Cisco, Cranite Systems,
Extreme Networks, Intoto, Janusys Networks, Nortel, Panasonic,
Trapeze, Instant802, Strix Systems, Symbol) and one from academic
research community (UCLA). Out of the 16 contributions, one
described an Autonomous WLAN Architecture, three Distributed Mesh
Architectures, while the rest twelve entries represent architectures
that fall into the family of Centralized WLAN Architecture.
The main objective of this survey is to identify the general
categories and trends in WLAN architecture evolution, discover their
common characteristics, determine what is performed differently among
them, and why. In order to represent the survey data in a compact
format, a "Functional Distribution Matrix" is used in this document,
mostly in the Centralized WLAN architecture section, to tabulate the
various services and functions in the vendors' offerings. These
services and functions are classified into three main categories:
o Architecture Considerations: the choice of the connectivity
between the AC and the WTP; the design choices regarding the
physical device on which processing of management, control, and
data frames of the 802.11 takes place.
Yang (Editor), et al. Expires January 30, 2005 [Page 12]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
o 802.11 Functions: as described in Section 2.1.
o CAPWAP Functions: as described in Section 2.2.
For each one of these categories, the mapping of each individual
function to network entities implemented by each vendor is shown in
tabular form. The rows in the Functional Distribution Matrix
represent the individual functions that are organized into the above
mentioned three categories, while each column of the Matrix
represents one vendor's architecture offering in the survey data.
See Figure 7 as an example of the Matrix.
This Functional Distribution Matrix is intended for the sole purpose
of organizing the architecture taxonomy data, and represents the
contributors' view of their architectures, from an engineering
perspective. It does not necessarily imply an existing product,
shipping or not, nor an intent by the vendor to build such a product.
The rest of this document is organized around the three broad WLAN
architecture families that were introduced in Section 2.3. Each
architecture family is discussed in a separate section. The section
on Centralized Architecture contains more in-depth details than the
other two families, largely due to the large number of the survey
data (11 out of 16) collected falling into the Centralized
Architecture category.
Summary and conclusions are provided at the end of the document to
highlight the basic findings from this taxonomy exercise.
Yang (Editor), et al. Expires January 30, 2005 [Page 13]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
3. Autonomous Architecture
3.1 Overview
Figure 1 shows an example network of the Autonomous WLAN
Architecture. This architecture implements all the 802.11
functionality in a single physical device, the Wireless Termination
Point (WTP). A common embodiment of this architecture is a WTP that
translates between 802.11 frames to/from its radio interface and
802.3 frames to/from an Ethernet interface. An 802.3 infrastructure
that interconnects the Ethernet interfaces of different WTPs together
provides the distribution system. It can also provide portals for
integrated 802.3 LAN segments.
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-----+ | | +-----+ | | +-----+ |
+----| WTP |----+ +----| WTP |----+ +----| WTP |----+
+--+--+ +--+--+ +--+--+
|Ethernet | |
+------------------+ | +------------------+
| | |
+---+--+--+---+
| Ethernet |
802.3 LAN --------------+ Switch +-------------- 802.3 LAN
segment 1 | | segment 2
+------+------+
Figure 1: Example of Autonomous WLAN Architecture
A single physical WTP can optionally be provisioned as multiple
virtual WTPs by supporting multiple SSIDs to which 802.11 clients may
associate. In some cases, this will also involve putting a
corresponding 802.1Q VLAN tag on each packet forwarded to the
Ethernet infrastructure and removal of 802.1Q tags prior to
forwarding the packets to the wireless medium.
The scope of the ESS(s) created by interconnecting the WTPs will be
confined by the constraints imposed by the Ethernet infrastructure.
Authentication of 802.11 clients may be performed locally by the WTP
or by using a centralized authentication server.
3.2 Security
Since both the 802.11 and CAPWAP functionality is tightly integrated
into a single physical device, the security issues with this
Yang (Editor), et al. Expires January 30, 2005 [Page 14]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
architecture are confined to the WTP. There are no extra
implications from the client authentication and encryption/decryption
perspective as the AAA interface is integrated into the WTP, so is
the key generation mechanisms required for 802.11i encryption/
decryption.
One of the security issues in this architecture is the need for
mutual authentication between the WTP and the Ethernet
infrastructure. This can be ensured by existing mechanisms such as
802.1x between the WTP and the Ethernet switch it plugs into.
Another critical security issue with this architecture is the very
fact that the WTP is most likely not under lock and key, but does
contain secret information in order to communicate with the backend
systems, such as AAA, SNMP, etc. Due to the common management method
used by IT personnel of pushing a "template" to all devices, theft of
such a device would potentially compromise the wired network.
Yang (Editor), et al. Expires January 30, 2005 [Page 15]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
4. Centralized WLAN Architecture
Centralized WLAN Architecture is an emerging architecture family in
the WLAN market. Contrary to the Autonomous WLAN Architecture where
the 802.11 functions and network control functions are all
implemented within each Wireless Termination Point (WTP), the
Centralized WLAN Architecture employs one or multiple centralized
controllers, called Access Controller(s), to enable network-wide
monitoring, improve management scalability, and facilitate dynamic
configurability.
The following figure shows schematically the Centralized WLAN
Architecture network diagram, where the Access Controller (AC)
connects to multiple Wireless Termination Points (WTPs) via a certain
interconnection. This can be either a direct connection, an
L2-switched, or an L3-routed network as described in Section 4.1.
The AC exchanges configuration and control information with the WTP
devices, allowing the management of the network from a centralized
point. Also, designs of the Centralized WLAN Architecture family do
not presume (as the diagram might suggest to some readers) that the
AC necessarily intercedes in the data plane to/from the WTP(s). More
details are provided later in this section.
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-------+ | | +-------+ | | +-------+ |
+----| WTP |--+ +----| WTP |--+ +----| WTP |--+
+---+---+ +---+---+ +---+---+
| | |
+------------------+ | +-----------------+
| |...|
+----+--+---+--------+
| Interconnection |
+-------+------------+
|
|
+-----+----+
| AC |
+----------+
Figure 2: Centralized WLAN Architecture Diagram
In the diagram above, the AC is shown as a single physical entity
that provides all of the CAPWAP functions listed in section 2.2. But
that may not be always the case. Closer examination of the functions
reveals that their different resource requirements (e.g. CPU,
memory, storage) may lend themselves to being distributed across
Yang (Editor), et al. Expires January 30, 2005 [Page 16]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
different devices. For instance, complex radio control algorithms
can be CPU intensive. Storing and downloading images and
configurations can be storage intensive. Therefore different CAPWAP
functions might be implemented on different physical devices due to
the different nature of their resource requirements. The network
entity marked 'AC' in the diagram above should accordingly be thought
of as a multiplicity of logical functions, and not necessarily as a
single physical device. The AC(s) may also choose to implement some
of the control functions locally while providing interfaces to access
other global network management functions which are typically
implemented on separate boxes, such as a SNMP Network Management
Station and an AAA backend server (e.g., Radius Authentication
Server).
4.1 Interconnection between WTPs and ACs
There are several connectivity options which can be considered
between the AC(s) and the WTPs, including direct connection, L2
switched connection, or L3 routed connection, as shown in Figure 3,
Figure 4, and Figure 5.
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP |
+--+--+ +--+--+
Figure 3: Directly Connected
Yang (Editor), et al. Expires January 30, 2005 [Page 17]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +-----+-----+
| WTP | | Switch |
+--+--+ +---+-----+-+
| |
+-----+ +-----+
| WTP | | WTP |
+-----+ +-----+
Figure 4: Switched Connections
+-------+-------+
| AC |
+-------+-------+
|
--------+------ LAN
|
+-------+-------+
| router |
+-------+-------+
|
-----+--+--+--- LAN
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP|
+--+--+ +--+--+
Figure 5: Routed Connections
4.2 Overview of Three Centralized WLAN Architecture Variants
While dynamic and consistent network management is one of the primary
motivations for the Centralized Architecture, the survey data from
vendors also shows that different varieties of this architecture
family have emerged to meet a complex set of different requirements
for possibly different deployment scenarios. This is also a direct
result of the inherent flexibility in the 802.11 standard [1]
Yang (Editor), et al. Expires January 30, 2005 [Page 18]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
regarding the implementation of the logical functions that are
broadly described under the term "Access Point (AP)". As there is no
standard mapping of these AP functions to physical network entities,
several design choices have been made by vendors that offer related
products. Moreover, the increased demand for monitoring and
consistent configuration of large wireless networks has resulted into
a set of 'value-added' services provided by the various vendors, most
of which share common design properties and service goals.
In the following, we describe the three main variants observed from
the survey data within the family of Centralized WLAN Architecture,
namely the Local MAC, Split MAC, and Remote MAC approaches. For
each approach we provide the mapping characteristics of the various
functions into the network entities from each vendor. The naming of
Local MAC, Split MAC and Remote MAC reflects how the functions, and
especially the 802.11 MAC functions, are mapped onto the network
entities. Local MAC indicates that the MAC functions stay intact and
local to WTPs, while Remote MAC denotes that the MAC is moved away
from the WTP to a remote AC in the network. Split MAC shows the MAC
being split between the WTPs and ACs, largely along the line of real
time sensitivity. Typically, Split MAC vendors choose to put real
time functions on the WTPs while leaving non-real time functions to
the ACs. 802.11 does not clearly specify what constitutes real-time
functions versus non-real-time functions, and so there does not exist
such a clear and definitive line among them. As shown in Section
4.4, each vendor has its own interpretation on this and so there
exists some discrepancy in where to draw the line between real time
However, vendors also manage to agree on the characterization of the
majority of the MAC functions. For example, every vendor classifies
the DCF as a real-time function.
Yang (Editor), et al. Expires January 30, 2005 [Page 19]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
The differences among Local MAC, Split MAC and Remote MAC
architectures are shown graphically in the following figure:
+--------------+--- +---------------+--- +--------------+---
| CAPWAP | | CAPWAP | | CAPWAP |
| functions |AC | functions |AC | functions |
|==============|=== |---------------| |--------------|
| | | non RT MAC | | |AC
| 802.11 MAC | |===============|=== | 802.11 MAC |
| |WTP | Real Time MAC | | |
|--------------| |---------------|WTP |==============|===
| 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP
+--------------+--- +---------------+--- +--------------+---
(a) "Local MAC" (b) "Split MAC" (c) "Remote MAC"
Figure 6: Three Architectural Variants within Centralized WLAN
Architecture Family
4.3 Local MAC
The main motivation of Local MAC architecture model, as shown in
Figure 6.(a), is to offload network access policies and management
functions (CAPWAP functions described in Section 2.2) to the AC,
without splitting the 802.11 MAC functionality between WTPs and AC.
The whole 802.11 MAC resides on the WTPs locally, including all the
802.11 management and control frame processing for the STAs; on the
other hand, information related to management and configuration of
the WTP devices is communicated with a centralized AC, to facilitate
management of the network, and maintain a consistent network-wide
configuration for the WTP devices.
Figure 7 offers a tabular representation of the design choices made
by the six vendors in the survey that follow the Local MAC approach
with respect to the aforementioned architecture considerations.
"WTP-AC connectivity" shows the kind of connectivity between WTPs and
AC each vendor's architecture can support. It is clear that all the
vendors can support L3 routed network connectivity between WTPs and
AC, which implies that direct connections and L2 switched networks
are also supported by all vendors. By '802.11 mgmt termination', and
'802.11 control termination' we denote the physical network device on
which processing of the 802.11 management and control frames is done
respectively. All the vendors here choose to terminate 802.11
management and control frames at the WTPs. The last row of the
table, '802.11 data aggregation', refers to the device on which
aggregation and delivery of 802.11 data frames from one STA to
another (possibly through a DS) is performed. As we can see from the
Yang (Editor), et al. Expires January 30, 2005 [Page 20]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
table, vendors make different choices as whether or not all the
802.11 data traffic is aggregated and routed through the AC. The
survey data shows that some vendors choose to tunnel or encapsulate
all the station traffic to or from the ACs, implying the AC also acts
as the access router for this WLAN access network; other vendors
choose to separate the control plane and data plane by letting the
station traffic being bridged or routed locally while keeping the
centralized control at the AC.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
WTP-AC
connectivity L3 L3 L3 L3 L3
802.11 mgmt
termination WTP WTP WTP WTP WTP
802.11 control
termination WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC WTP AC WTP
Figure 7: Architecture Considerations for Local MAC Architecture
Figure 8 shows that most of the CAPWAP functions as described in
Section 2.2 are implemented at the AC, with help from WTPs to monitor
RF channels, and collect statistics and state information from the
STAs, as the AC offers the advantages of network-wide visibility,
which is essential for many of the control, configuration and
value-added services.
Yang (Editor), et al. Expires January 30, 2005 [Page 21]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
RF
Monitoring WTP WTP AC/WTP WTP WTP
RF
Config. AC AC AC AC AC
WTP config. AC AC AC AC AC
WTP
Firmware AC AC AC AC AC
STA state
info
database AC AC/WTP AC/WTP AC/WTP AC
AC/WTP
mutual
authent. AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP
Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture
The matrix shown in Figure 9 shows that most of the 802.11 functions
are implemented at the WTPs for Local MAC Architecture, with some
minor differences among the vendors with regard to distribution
service, 802.11e scheduling and 802.1x/EAP authentication. The
difference in distribution service is consistent with the difference
described earlier with regard to "802.11 data aggregation" in the
Figure 7.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
Distribution
Service AC AC WTP AC WTP
Integration
Service WTP WTP WTP WTP WTP
Beacon
Generation WTP WTP WTP WTP WTP
Probe
Response WTP WTP WTP WTP WTP
Yang (Editor), et al. Expires January 30, 2005 [Page 22]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
Power mgmt
Packet
Buffering WTP WTP WTP WTP WTP
Fragmentation/
Defragment. WTP WTP WTP WTP WTP
Association
Disassoc.
Reassociation AC WTP WTP WTP WTP
WME/11e
--------------
classifying AC WTP
scheduling WTP AC/WTP WTP WTP WTP
queuing WTP WTP WTP WTP
Authentication
and Privacy
--------------
802.1x/EAP AC AC AC/WTP AC AC/WTP
Keys
Management AC AC WTP AC AC
802.11
Encryption/
Decryption WTP WTP WTP WTP WTP
Figure 9: Mapping of 802.11 Functions for Local MAC Architecture
From Figure 7, Figure 8 and Figure 9, it is clear that differences
among vendors in the Local MAC Architecture are relatively minor, and
most of the functional mapping appears to be common across vendors.
4.4 Split MAC
As shown in Figure 6.(b), the main idea behind the Split MAC
architecture is to implement part of the 802.11 MAC functionality on
a centralized AC instead of the WTPs, in addition to the services
required for managing and monitoring the WTP devices. Usually, the
decision of which functions of the 802.11 MAC need to be provided by
the AC is based on the time-criticality of the services considered.
In the Split MAC architecture, the WTP terminates the infrastructure
side of the wireless physical link, provides radio-related
Yang (Editor), et al. Expires January 30, 2005 [Page 23]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
management, and also implements all time-critical functionality of
the 802.11 MAC. In addition, the non real-time management functions
are handled by a centralized AC, along with higher-level services,
such as configuration, QoS, policies for load-balancing, access
control lists, etc. The subtle but key distinction between Local MAC
and Split MAC relates to the non real-time functions: in Split MAC
architecture, the AC terminates 802.11 non real-time functions,
whereas in Local MAC architecture the WTP terminates the 802.11 non
real-time functions and consequently sends appropriate messages to
the AC.
There are several motivations for taking the Split MAC approach. The
first is to offload to the WTP functionality that is specific and
relevant only to the locality of each BSS, in order to allow the AC
to scale to a large number of 'light weight' WTP devices. Moreover,
real-time functionality is subject to latency constraints and cannot
tolerate delays due to transmission of 802.11 Control frames (or
other real-time information) over multiple-hops. The latter would
limit the available choices for the connectivity between the AC and
the WTP, hence the real-time criterion is usually employed to
separate MAC services between the devices. Another consideration is
cost reduction of the WTP to make it as cheap and simple as possible.
Last but not least, moving functions like encryption and decryption
to the AC reduces vulnerabilities from a compromised WTP, since user
encryption keys no longer reside on the WTP. As a result, any
advancements in security protocols and algorithms design do not
necessarily obsolete the WTPs; the ACs implement the new security
schemes instead, and the management and update task is therefore
simplified. Additionally, the network is protected against LAN-side
eavesdropping.
Since there is no clear definition in the 802.11 specification as to
which 802.11 MAC functions are considered "real time", each vendor
has taken the liberty to interpret that in his own way. Most vendors
agree that the following services of 802.11 MAC are examples of real
time services and so are chosen to be implemented on the WTPs.
o Beacon Generation
o Probe Response/Transmission
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o Synchronization
o Retransmissions
o Transmission Rate Adaptation
The following list includes examples of non-real-time MAC functions
as interpreted by most vendors:
o Authentication/Deauthentication
o Association/Disassociation/Reassociation/Distribution
Yang (Editor), et al. Expires January 30, 2005 [Page 24]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
o Integration Services: bridging between 802.11 and 802.3
o Privacy: 802.11 Encryption/Decryption
o Fragmentation/Defragmentation
However, some vendors may choose to classify some of the above
"non-real time" functions as real-time functions, in order to support
specific applications with strict QoS requirements. For example
Reassociation is sometimes implemented as "real-time" function in
order to support VoIP applications.
The non-real-time aspects of the 802.11 MAC are handled by the AC,
through the processing of raw 802.11 management frames (Split MAC).
The following matrix in Figure 10 offers a tabular representation of
the design choices made by the six vendors that follow the Split MAC
design with respect to the architecture considerations. While most
vendors support L3 connectivity between WTPs and ACs, some vendors
can only support L2 switched connections, due to the tighter delay
constraint resulting from splitting MAC between two physical entities
across a network. Comparing to Figure 7, it is clear that the
commonality between Split MAC and Local MAC is that the 802.11
control frames are all processed by the WTP, while the difference
lies in the termination point for 802.11 management frames. Local
MAC terminates 802.11 management frames at WTP, while at least some
of the 802.11 management frames are terminated at the AC for the
Split MAC Architecture. In most cases, since WTP devices are
IP-addressable, any of the direct connection, L2-switched, or
L3-routed connections of Section 2.2 can be used. In the case where
only Ethernet-encapsulation is performed (e.g., as in Architecture 4)
then only direct connection and L2-switched connections are
supported.
Yang (Editor), et al. Expires January 30, 2005 [Page 25]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
WTP-AC
connectivity L3 L3 L3 L2 L3 L3
802.11 mgmt
termination AC AC AC AC AC/WTP AC
802.11 control
termination WTP WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC AC AC AC AC
Figure 10: Architecture Considerations for Split MAC Architecture
Similar to the Local MAC Architecture, the following matrix in Figure
11 shows that most of the CAPWAP control functions are implemented at
the AC, with the exception of RF monitoring and in some cases RF
configuration being done locally at the WTPs.
Yang (Editor), et al. Expires January 30, 2005 [Page 26]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
RF
Monitoring WTP WTP WTP WTP WTP WTP
RF
Config. AC/WTP AC/WTP AC AC AC
WTP config. AC AC AC AC AC
WTP
Firmware AC AC AC AC AC
STA state
info
database AC AC AC AC AC
AC/WTP
mutual
authent. AC/WTP AC/WTP AC/WTP AC/WTP
Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture
The most interesting matrix for Split MAC Architecture is the
Functional Distribution Matrix for 802.11 functions, as shown below
in Figure 12. There exists certain regularity in how the vendors map
the functions onto the WTPs and AC. For example, all vendors choose
to implement Distribution, Integration Service at the AC, along with
802.1x/EAP authentication and keys management. All vendors also
choose to implement beacon generation at WTPs. On the other hand, it
is also clear that vendors choose to map many of the other functions
differently. Therefore, Split MAC Architectures are not consistent
regarding the exact way the MAC is split.
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ------ ----- -----
Distribution
Service AC AC AC AC AC AC
Integration
Service AC AC AC AC AC AC
Beacon
Generation WTP WTP WTP WTP WTP WTP
Yang (Editor), et al. Expires January 30, 2005 [Page 27]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
Probe
Response WTP AC/WTP WTP WTP WTP WTP
Power mgmt
Packet
Buffering WTP WTP WTP AC AC/WTP WTP
Fragmentation
Defragment. WTP WTP AC AC AC
Association
Disassoc.
Reassociation AC AC AC AC WTP AC
WME/11e
--------------
classifying AC AC AC AC
scheduling WTP/AC AC WTP AC AC WTP/AC
queuing WTP/AC WTP WTP AC WTP WTP
Authentication
and Privacy
--------------
802.1x/EAP AC AC AC AC AC AC
Keys
Management AC AC AC AC AC AC
802.11
Encryption/
Decryption WTP AC WTP AC AC AC
Figure 12: Mapping of 802.11 Functions for Split MAC Architecture
4.5 Remote MAC
One of the main motivations for the Remote MAC Architecture is to
keep the WTPs as light weight as possible, by having only the radio
interfaces on the WTPs and offloading the entire set of 802.11 MAC
functions (including delay-sensitive ones) to the Access Controller.
This leaves all the complexities of the MAC and other CAPWAP control
functions to the centralized controller.
The WTP acts only as a pass-through between the Wireless LAN clients
Yang (Editor), et al. Expires January 30, 2005 [Page 28]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
(STA) and the AC, though they may have an additional feature to
convert the frames from one format (802.11) to the other (Ethernet,
TR, Fiber etc.). The centralized controller provides network
monitoring, management and control, entire set of the 802.11 AP
services, security features, resource management, channel selection
features, guarantees of Quality of Service to the users, etc.
Because the MAC is separated from the PHY, we call this the "Remote
MAC Architecture". Typically such architecture is deployed with
special attention to the connectivity between the WTPs and AC so that
the delay is minimized. The RoF (Radio over Fiber) from Architecture
5 is such an example of Remote MAC Architecture.
4.6 Comparisons of Local MAC, Split MAC and Remote MAC
Two commonalities across all the three Centralized Architectures
(Local MAC, Split MAC and Remote MAC) are:
o Most of the CAPWAP functions related to network control and
configuration reside on the AC.
o IEEE 802.11 PHY resides on the WTP.
The difference between Remote MAC and the other two Centralized
Architectures (namely, Local MAC and Split MAC) is pretty clear, as
the 802.11 MAC is completely separated from the PHY in the former,
while the other two at least keep some portion of the MAC functions
together with PHY at the WTPs. So the implication of PHY and MAC
separation is that it severely limits the kind of interconnection
between WTPs and ACs, so that the 802.11 timing constraints are
satisfied. As pointed out earlier, this usually results in tighter
constraint over the interconnection between WTP and AC for the Remote
MAC Architecture. The advantage of Remote MAC Architecture is that
it offers the lightest possible WTPs for certain deployment
scenarios.
The commonalities and differences between Local MAC and Split MAC are
most clearly seen by comparing Figure 7 and Figure 10. The
commonality between the two is that 802.11 control frames are
terminated at WTPs in both cases. The main difference between Local
MAC and Split MAC is that in the latter the WTP terminates only the
802.11 control frames, while in the former the WTP may terminate all
802.11 frames. An interesting consequence of this difference is that
the Integration Service, which essentially refers to bridging between
802.11 and 802.3 frames, is implemented by the AC in the Split MAC,
but can be part of either the AC or WTP in the Local MAC.
As a second note, the Distribution Service, although usually provided
by the AC, can also be implemented at the WTP in some Local MAC
architectures. The rationale behind this approach is to increase
performance in delivering STAs data traffic by avoiding tunnelling it
Yang (Editor), et al. Expires January 30, 2005 [Page 29]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
to the AC, and also relax the dependency of the WTP from the AC.
Therefore, it is possible that the data and control planes are
separated in the Local MAC Architecture.
Even though all the 802.11 traffic is aggregated at ACs in the case
of Split MAC Architecture, the data plane and control plane can still
be separated by employing multiple ACs. For example, one AC can
implement most of the CAPWAP functions (control plane), while other
ACs can be used for 802.11 frames bridging (data plane).
Each of the three architectural variants may be advantageous in
certain aspects for certain deployment scenarios. While Local MAC
retains most of the STAs state information at the local WTPs, Remote
MAC centralizes most of the state into the backend AC. Split MAC
sits somewhat in the middle of that spectrum, keeping some state
information locally at the WTPs, and the rest centrally at the AC.
Many factors should be taken into account to determine the exact
balance desired between centralized v.s. decentralized state. The
impact of such balance on network manageability is currently a matter
of dispute within the technical community.
4.7 Communication Interface between WTPs and ACs
Before any messages can be exchanged between an AC and WTP, the WTP
needs to discover, authenticate and register with the AC first, then
download the firmware and establish control channel with the AC.
Message exchanges between the WTP and AC for control and
configuration can happen after that. The following list outlines the
basic operations that are typically performed between the WTP and the
AC in the typical order:
1. Discovery : The WTPs discover the AC with which they will be
bound to and controlled by. The discovery procedure can employ
either static or dynamic configuration. In the latter case, a
protocol is used in order for the WTP to discover candidate
AC(s).
2. Authentication: After discovery, the WTP device authenticates
itself with the AC. However, mutual authentication, in which the
WTP also authenticates the AC, is not always supported since some
vendors strive for zero-configuration on the WTP side. This is
not necessarily secure as it leaves the possible vulnerability of
the WTP being attached to a rogue AC.
3. WTP Association: After successful authentication, an WTP
registers with the AC, in order to start receiving management and
configuration messages.
4. Firmware Download: After successful association, the WTP may
pull, or the AC may push the WTPs firmware, which may be
protected by some manner, such as digital signatures.
Yang (Editor), et al. Expires January 30, 2005 [Page 30]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
5. Control Channel Establishment: The WTP establishes either an
IP-tunnel or performs Ethernet encapsulation with the AC, in
order to transfer data traffic and management frames.
6. Configuration Download: Following the control channel
establishment process, the AC may push configuration parameters
to the WTPs.
4.8 Security
Given the varied distribution of functionalities for the Centralized
Architecture as surveyed in Section 4.3, it is obvious that an extra
network binding is created between the WTP and the AC. This brings
along new and unique security issues and subsequent requirements.
4.8.1 Client Data Security
The survey shows clearly that the termination point for "over the
air" 802.11 encryption [5] can be implemented either in the WTP or in
the AC. Furthermore, the 802.1X/EAP [7] functionality is also
distributed between the WTP and the AC where, in almost all cases,
the AC performs the necessary functions as the authenticator in the
802.1x exchange.
If the STA and AC are the parties in the 4-way handshake (defined in
[5]), and the encryption/decryption happens at the WTP, then the PTK
(Pairwise Transient Key) has to be transferred from the AC to the
WTP. If the PMK (Pairwise Master Key) is reused across multiple
WTPs, then requiring a 4-way handshake for each WTP that the station
associates to, followed by the transfer of that PTK from the AC to
the WTP, would ensure that a different PTK is used at each WTP.
Since the 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 key exchange and state transitions occur between the AC
and STA. Therefore, there is no need to transfer any crypto material
between the AC and the WTP.
Regardless of 802.11i termination point, the Centralized WLAN
Architecture assumes two possibilities for "over the wire" client
data security. In some cases there is an encrypted tunnel (IPsec or
SSL) between the WTP and AC which assumes the security boundary to be
in the AC. In other cases an end-to-end mutually authenticated
secure VPN tunnel is assumed between the client and AC, other
security gateway or end host entity.
Yang (Editor), et al. Expires January 30, 2005 [Page 31]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
4.8.2 Security of control channel between the WTP and AC
In order for the CAPWAP functions to be implemented in the
Centralized WLAN Architecture it is necessary for a control channel
to exist between the WTP and AC.
In order to address potential security threats against the control
channel, existing implementations feature one or more of the
following security mechanisms:
1. Secure discovery of WTP and AC.
2. Authentication of the WTPs to the ACs (and possibly mutual
authentication).
3. Confidentiality, integrity and replay protection of control
channel frames.
4. Secure management of WTPs and ACs, including mechanisms for
securely setting and resetting secrets and state.
Discovery and authentication of WTPs are addressed in the submissions
by implementing authentication mechanisms that range from X.509
certificates, AAA authentication to pre-shared credential
authentication. In all cases, the issues of confidentiality,
integrity and of protection against man-in-the-middle attacks of the
control frames are addressed by a secure encrypted tunnel between WTP
and AC(s) utilizing keys derived from the varied authentication
methods mentioned previously. Finally, one of the motivations for
the Centralized WLAN Architecture is to minimize the storage of
cryptographic and security sensitive information, in addition to
operational configuration parameters within the WTPs. It is for that
reason that the majority of the submissions under the Centralized
Architecture category have employed a post WTP authenticated
discovery phase of configuration provisioning, which in turn protects
against the theft of WTPs.
4.8.3 Physical Security of WTPs and ACs
In order to provide comprehensive radio coverage, WTPs are often
installed in locations that are difficult to secure physically; while
it is relatively easier to secure the AC physically. If high-value
secrets, such as a RADIUS shared secret, are stored in the AC instead
of WTPs, then the physical loss of an WTP does not compromise these
secrets. Hence, the Centralized Architecture may reduce the security
consequences of a stolen WTP.
On the other hand, concentrating all of the high-value secrets in one
place makes the AC an attractive target, so strict physical,
procedural and technical controls are needed to protect the secrets.
Yang (Editor), et al. Expires January 30, 2005 [Page 32]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
5. Distributed Mesh Architecture
Out of the 16 architecture survey submissions, 3 belong to the
Distributed Mesh Architecture family. An example of the Distributed
Mesh Architecture is shown in Figure 13, which reflects some of the
common characteristics found in these 3 submissions.
+-----------------+ +-----------------+
| 802.11 BSS 1 | | 802.11 BSS 2 |
| ... | | ... |
| +---------+ | | +---------+ |
+----|mesh node|--+ +----|mesh node|--+
+-+---+---+ +-+-+-----+
| | | |
| | | | +----------+
| +-----------------------+ | Ethernet | Ethernet |
| 802.11 wireless links | +--------+ Switch |
| +-----------------------+ | | | |
| | | | | +----------+
+-+---+---+ +-+--+----+
+----|mesh node|--+ +----|mesh node|--+
| +---------+ | | +---------+ |
| ... | | ... |
| 802.11 BSS 4 | | 802.11 BSS 3 |
+-----------------+ +-----------------+
Figure 13: Example of Distributed Mesh Architecture
5.1 Common Characteristics
One of the main characteristics of these mesh architecture
submissions is that the mesh nodes in the network may act as APs to
the client stations in their respective BSS, as well as traffic
relays to neighboring mesh nodes via 802.11 wireless links, in order
to provide wider wireless coverage. It is also possible that some of
the mesh nodes in the network may serve only as wireless traffic
relays for other mesh nodes, but not as APs for any client stations.
Instead of pulling Ethernet cable connections to each AP, wireless
mesh networks provide an attractive alternative to relaying backhaul
traffic.
Another key characteristic of these mesh architecture submissions is
that mesh nodes can keep track of the state of their neighboring
nodes, or even nodes beyond their immediate neighborhood, by
exchanging information periodically amongst them; this way, mesh
nodes can be fully aware of the dynamic network topology and RF
conditions around them. Such peer-to-peer communication model allows
Yang (Editor), et al. Expires January 30, 2005 [Page 33]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
the mesh nodes to actively coordinate among themselves to achieve
self-configuration and self-healing. This is the major distinction
between this Distributed Architecture family and the Centralized
Architecture -- much of the CAPWAP functions can be implemented
across the mesh nodes in a distributed fashion, without a centralized
entity making all the control decisions.
On the other hand, it is worthwhile to point out that mesh networks
do not necessarily preclude the use of centralized control. It is
possible that a combination of centralized and distributed control
co-exists in the mesh networks. Some global configuration or policy
change may be better served in a coordinated fashion if some form of
Access Controller (AC) exists in the mesh network, even if not the
full blown version of the AC as defined in the Centralized WLAN
Architecture. For example, a centralized management entity can be
used to update every mesh node's default configuration; it may also
be more desirable to leave certain functions such as user
authentication to a single centralized end point (such as a RADIUS
server), but mesh networks allows the possibility of each mesh AP to
directly talk to the RADIUS server. This reduces single point of
failure and takes advantage of the client distribution in the
network.
The backhaul transport network of the mesh network can be either an
L2 or L3 networking technology. Currently, vendors are using
proprietary mesh technologies on top of standard 802.11 wireless
links to enable peer-to-peer communication between the mesh nodes,
and hence no interoperability exists among mesh nodes from different
vendors. IEEE 802.11 WG has recently started a new Task Group (TGs)
to define the mesh standard for 802.11.
5.2 Security
Similar security concerns for client data security as described in
Section 4.8.1 also apply to the Distributed Mesh Architecture.
Additionally, one important security consideration for the mesh
networks is that the mesh nodes must authenticate each other within
the same administrative domain, and data transmission among
neighboring nodes must be secured. Each node that is part of the
mesh must be fully trusted for the mesh to be secure. It is often
recommended that all communication between mesh nodes be secured by
some mechanism of confidentiality, integrity and replay protection,
since they may carry user traffic that is not. For this reason, the
operator should always encrypt and protect mesh links, in order to
fully secure the network.Ç¥
Yang (Editor), et al. Expires January 30, 2005 [Page 34]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
6. Summary and Conclusions
We requested existing WLAN vendors and other interested parties to
submit a short description of existing or desired WLAN access network
architectures to define a taxonomy of possible WLAN access network
architectures. The information from the 16 submissions was condensed
and summarized in this document.
New terminology has been defined wherever existing terminology was
found to be either insufficient or ambiguous in describing the WLAN
architectures and supporting functions listed in the document. For
example, the broad set of Access Point functions has been divided
into two categories - 802.11 functions which include those that are
required by the IEEE 802.11 standards, and CAPWAP functions which
include those that are not required by the IEEE 802.11, but are
deemed essential for control, configuration, and management of 802.11
WLAN access networks. Another term that has caused considerable
ambiguity is "Access Point" which was usually tied to reflect a
physical box that has the antennas, but did not have a uniform set of
externally verifiable behavior across all the submissions. To remove
this ambiguity, we have re-defined the AP to be the set of 802.11 and
CAPWAP functions, while the physical box that terminates the 802.11
PHY is called the Wireless Termination Point.
Based on the submissions during the architectural survey phase, we
have classified the existing WLAN architectures into three broad
classes:
1. Autonomous WLAN Architecture indicates a family of architectures
where all the 802.11 functions and, where applicable, CAPWAP
functions are implemented in the WTPs.
2. Centralized WLAN Architecture indicates a family of architectures
where the AP functions are split between the WTPs and the AC with
the AC, typically, acting as a centralized control point for
multiple WTPs.
3. Distributed WLAN Architecture indicates a family of architectures
where part of the control functions are implemented across a
distributed network of peer entities.
Within the Centralized WLAN Architecture, there are a few
sub-categories that are visible depending on how one maps the MAC
functions, at a high-level, between the WTP and the AC. Three
prominent ones emerged from the information present in the
submissions:
1. Split MAC Architecture, where the 802.11 MAC functions are split
between the WTP and the AC. This subgroup includes all
architectures that split the 802.11 MAC functions even though
individual submissions differed on the specifics of the split.
Yang (Editor), et al. Expires January 30, 2005 [Page 35]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
2. Local MAC Architecture, where the entire set of 802.11 MAC
functions is implemented on the WTP.
3. Remote MAC Architecture, where the entire set of 802.11 MAC
functions is implemented on the AC.
The following tree diagram summarizes the architectures documented in
this taxonomy.
+----------------+
|Autonomous |
+---------->|Architecture |
| |Family |
| +----------------+
| +--------------+
| |Local |
| +---->|MAC |
| | |Architecture |
| | +--------------+
| |
| +----------------+ | +--------------+
| |Centralized | | |Split |
+---------->|Architecture |--+---->|MAC |
| |Family | | |Architecture |
| +----------------+ | +--------------+
| |
| | +--------------+
| | |Remote |
| +---->|MAC |
| |Architecture |
| +--------------+
| +----------------+
| |Distributed Mesh|
+---------->|Architecture |
|Family |
+----------------+
A majority of the submitted WLAN access network architectures (12 out
of 16) followed the Centralized WLAN Architecture. All but one of
the centralized WLAN architecture submissions were grouped into
either a Split MAC architecture or a Local MAC architecture. There
was one submission that followed the Autonomous WLAN Architecture.
There were three submissions under the Distributed WLAN Architecture.
The WLAN access network architectures in the submissions indicated
that the connectivity assumptions were:
o Direct connection between the WTP and the AC.
Yang (Editor), et al. Expires January 30, 2005 [Page 36]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
o L2 switched connection between the WTP and the AC.
o L3 routed connection between the WTP and the AC.
o Wireless connection between the mesh nodes in the distributed mesh
architecture.
Interoperability between equipment from different vendors is one of
the fundamental problems in the WLAN market today. In order to
achieve interoperability via open standard development, the following
next steps are suggested for IETF and IEEE 802.11.
Using this taxonomy, a functional model of an Access Point should be
defined, by the new study group recently formed within the IEEE
802.11. The functional model will consist of defining functional
elements of an 802.11 access point that are considered atomic, i.e.
not subject to further splitting across multiple network elements.
Such a functional model should serve as a common foundation to
support the existing WLAN architectures as outlined in this taxonomy,
and any further architecture development either within or outside of
IEEE 802.11 group. It is possible, or even recommended, that the
work on the functional model definition may also include impact
analysis of implementing each functional element on either the WTP or
the AC.
As part of the functional model definition, interfaces must be
defined in the form of primitives between these functional elements.
If a pair of functional elements that have an interface defined
between them is subject to being implemented on two different network
entities, then a protocol specification between such pair of network
elements is required to be defined, and should be developed by IETF.
Yang (Editor), et al. Expires January 30, 2005 [Page 37]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
7. Security Considerations
A comprehensive threat analysis of all of the security issues with
the different WLAN architectures is not a goal of this document.
Nevertheless, in addition to documenting the architectures employed
in the existing IEEE 802.11 products in the market, this taxonomy
document also catalogs, in a non-exhaustive manner, the security
issues that arise and the manner in which vendors address these
security threats. The WLAN architectures are broadly categorized
into three families: Autonomous Architecture, Centralized
Architecture, and Distributed Architecture. While Section 3, Section
4 and Section 5 are devoted to each of these three architecture
families, respectively, each section also contains a subsection to
address the security issues within each architecture family.
In summary, the main security concern in the Autonomous Architecture
is the mutual authentication between WTP and the wired (Ethernet)
infrastructure equipment. Physical security of the WTPs is also a
network security concern because the WTPs contain secret information
and theft of these devices could potentially compromise even the
wired network.
In the Centralized Architecture there are a few new security concerns
because of the introduction of a new network binding between WTP and
AC. The following security concerns are raised for this architecture
family: keying material for mobile client traffic may need to be
securely transported from AC to WTP; secure discovery of WTP and AC
is required, mutual authentication of WTPs and AC is needed,
man-in-the-middle attacks to the control channel between WTP and AC,
confidentiality, integrity and replay protection of control channel
frames, and theft of WTPs for extraction of embedded secrets within.
Each of the survey results for this broad architecture category have
presented a variety of mechanisms to address these security issues.
The new secuirty issue in the Distributed mesh architecture is the
needs for the mesh nodes to authenticate each other before forming a
secure mesh network. It is also recommended that all communication
between mesh nodes be encrypted to protect both the control and user
data.
Yang (Editor), et al. Expires January 30, 2005 [Page 38]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
8. Acknowledgements
This taxonomy is truly a collaborative effort with contributions from
a large group of people. First of all, we want to thank all the
CAPWAP Architecture Design Team members who have spent many hours in
the teleconference calls, over emails and in writing and reviewing
the draft. The full Design Team is listed here:
o Peyush Agarwal
STMicroelectronics
Plot# 18, Sector 16A
Noida, U.P 201301
India
Phone: +91-120-2512021
EMail: peyush.agarwal@st.com
o Dave Hetherington
Roving Planet
4750 Walnut St., Suite 106
Boulder, CO 80027
United States
Phone: +1-303-996-7560
EMail: Dave.Hetherington@RovingPlanet.com
o Matt Holdrege
Strix Systems
26610 Agoura Road
Calabasas, CA 91302
Phone: +1 818-251-1058
EMail: matt@strixsystems.com
o Victor Lin
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051
Phone: +1 408-579-3383
EMail: vlin@extremenetworks.com
o James M. Murphy
Trapeze Networks
5753 W. Las Positas Blvd.
Pleasanton, CA 94588
Phone: +1 925-474-2233
EMail: jmurphy@trapezenetworks.com
o Partha Narasimhan
Aruba Wireless Networks
180 Great Oaks Blvd
San Jose, CA 95119
Phone: +1 408-754-3018
EMail: partha@arubanetworks.com
o Bob O'Hara
Airespace
Yang (Editor), et al. Expires January 30, 2005 [Page 39]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
110 Nortech Parkway
San Jose, CA 95134
Phone: +1 408-635-2025
EMail: bob@airespace.com
o Emek Sadot (see Authors' Addresses)
o Ajit Sanzgiri
Cisco Systems
170 W Tasman Drive
San Jose, CA 95134
Phone: +1 408-527-4252
EMail: sanzgiri@cisco.com
o Singh
Chantry Networks
1900 Minnesota Court
Mississauga, Ontario L5N 3C9
Canada
Phone: +1 905-567-6900
EMail: isingh@chantrynetworks.com
o L. Lily Yang (Editor, see Authors' Addresses)
o Petros Zerfos (see Authors' Addresses)
In addition, we would also like to acknowledge the contributions from
the following individuals who participated in the architecture
survey, and provided detailed input data in preparation of the
taxonomy: Parviz Yegani, Cheng Hong, Saravanan Govindan, Bob Beach,
Dennis Volpano, Shankar Narayanaswamy, Simon Barber, Srinivasa Rao
Addepalli, Subhashini A. Venkataramanan, Kue Wong, Kevin Dick, Ted
Kuo, and Tyan-shu Jou. It is simply impossible to write this
taxonomy without the large set of representative data points that
they provided us. We would also like to thank our CAPWAP WG
co-chairs, Mahalingam Mani and Dorothy Gellert, and our Area
Director, Bert Wijnen, for their unfailing support.
9 References
[1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, <IEEE
802.11-99>.
[2] "CAPWAP Problem Statement", May 2004,
<http://www.ietf.org/internet-drafts/
draft-ietf-capwap-problem-statement-01.txt>.
[3] "The Internet Standards Process Revision 3", October 1996,
<ftp://ftp.isi.edu/in-notes/rfc2026>.
[4] "Key words for use in RFCs to Indicate Requirement Levels",
March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.
Yang (Editor), et al. Expires January 30, 2005 [Page 40]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
[5] "IEEE Std 802.11i/D10.0: Medium Access Control (MAC) Security
Enhancements", April 2004.
[6] "IEEE Std 802.11h: Spectrum and Transmit Power Management
Extensions in the 5 GHz Band in Europe", October 2003.
[7] "IEEE Std 802.1X: Port-based Network Access Control", June 2001.
Authors' Addresses
L. Lily Yang
Intel Corp.
MS JF3 206, 2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: +1 503-264-8813
EMail: lily.l.yang@intel.com
Petros Zerfos
UCLA - Computer Science Department
4403 Boelter Hall
Los Angeles, CA 90095
Phone: +1 310-206-3091
EMail: pzerfos@cs.ucla.edu
Emek Sadot
Avaya
Atidim Technology Park, Building #3
Tel-Aviv 61131
Israel
Phone: +972-3-645-7591
EMail: esadot@avaya.com
Yang (Editor), et al. Expires January 30, 2005 [Page 41]
Internet-Draft CAPWAP Arch. Taxonomy Aug 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yang (Editor), et al. Expires January 30, 2005 [Page 42]
