CAPWAP Working Group L. Yang (Editor)
Internet-Draft Intel Corp.
Expires: October 15, 2004 P. Zerfos
UCLA
E. Sadot
Avaya
April 16, 2004
Architecture Taxonomy for Control and Provisioning of Wireless Access
Points(CAPWAP)
draft-ietf-capwap-arch-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 15, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document provides a taxonomy of the architectures employed in
the existing IEEE 802.11 products in the market, by analyzing WLAN
(Wireless LAN) functions and services and describing the different
variants in distributing these functions and services among the
architectural entities. This taxonomy may be utilized by the IEEE
802.11 Working Group as input to their task of defining the Access
Point (AP) functional architecture.
Yang (Editor), et al. Expires October 15, 2004 [Page 1]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Conventions used in this document . . . . . . . . . . . . 4
1.2 IEEE 802.11 Definitions . . . . . . . . . . . . . . . . . 4
1.3 Terminology Used in this Document . . . . . . . . . . . . 5
1.4 Terminology Used Historically but Not Recommended . . . . 7
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . . . 8
2.2 CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . 10
2.3 WLAN Architecture Proliferation . . . . . . . . . . . . . 11
2.4 Taxonomy Methodology and Document Organization . . . . . . 13
3. Autonomous Architecture . . . . . . . . . . . . . . . . . . . 15
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Centralized WLAN Architecture . . . . . . . . . . . . . . . . 17
4.1 Interconnection Topology between WTPs and ACs . . . . . . 18
4.2 Overview of Three Centralized WLAN Architectures . . . . . 19
4.3 Local MAC . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Split MAC . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Comparisons of Local MAC, Split MAC and Remote MAC . . . . 28
4.7 Communication Interface between WTPs and ACs . . . . . . . 29
4.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8.1 Client Data Security . . . . . . . . . . . . . . . . . 30
4.8.2 Security of control channel between WTP and AC . . . . 31
5. Distributed Mesh Architecture . . . . . . . . . . . . . . . . 32
5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 33
6.1 Taxonomy Summary . . . . . . . . . . . . . . . . . . . . . 33
6.2 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
A. WLAN Architecture Survey Template . . . . . . . . . . . . . . 40
B. Survey Contribution For Architecture 1 . . . . . . . . . . . . 41
C. Survey Contribution For Architecture 2 . . . . . . . . . . . . 46
D. Survey Contribution For Architecture 3 . . . . . . . . . . . . 50
E. Survey Contribution For Architecture 4 . . . . . . . . . . . . 53
F. Survey Contribution For Architecture 5 . . . . . . . . . . . . 57
G. Survey Contribution For Architecture 6 . . . . . . . . . . . . 61
H. Survey Contribution For Architecture 7 . . . . . . . . . . . . 65
I. Survey Contribution For Architecture 8 . . . . . . . . . . . . 67
J. Survey Contribution For Architecture 9 . . . . . . . . . . . . 70
K. Survey Contribution For Architecture 10 . . . . . . . . . . . 74
L. Survey Contribution For Architecture 11 . . . . . . . . . . . 77
M. Survey Contribution For Architecture 12 . . . . . . . . . . . 82
Yang (Editor), et al. Expires October 15, 2004 [Page 2]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
N. Survey Contribution For Architecture 13 . . . . . . . . . . . 84
O. Survey Contribution For Architecture 14 . . . . . . . . . . . 86
Intellectual Property and Copyright Statements . . . . . . . . 88
Yang (Editor), et al. Expires October 15, 2004 [Page 3]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
1. Definitions
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
1.2 IEEE 802.11 Definitions
Station (STA): Any device that contains an IEEE 802.11 conformant
medium access control (MAC) and physical layer (PHY) interface to the
wireless medium (WM).
Access Point (AP): Any entity that has station functionality and
provides access to the distribution services, via the wireless medium
(WM) for associated stations.
Basic Service Set (BSS): A set of stations controlled by a single
coordination function.
Station Service (SS): The set of services that support transport of
medium access control (MAC) service data units (MSDUs) between
stations within a basic service set (BSS).
Distribution System (DS): A system used to interconnect a set of
basic service sets (BSSs) and integrated local area networks (LANs)
to create an extended service set (ESS).
Extended Service Set (ESS): A set of one or more interconnected basic
service sets (BSSs) and integrated local area networks (LANs) that
appears as a single BSS to the logical link control layer at any
station associated with one of those BSSs.
Portal: The logical point at which medium access control (MAC)
service data units (MSDUs) from a non-IEEE 802.11 local area network
(LAN) enter the distribution system (DS) of an extended service set
(ESS).
Distribution System Service (DSS): The set of services provided by
the distribution system (DS) that enable the medium access control
(MAC) to transport MAC service data units (MSDUs) between stations
that are not in direct communication with each other over a single
instance of the wireless medium (WM). These services include
transport of MSDUs between the access points (APs) of basic service
sets (BSSs) within an extended service set (ESS), transport of MSDUs
between portals and BSSs within an ESS, and transport of MSDUs
between stations in the same BSS in cases where the MSDU has a
Yang (Editor), et al. Expires October 15, 2004 [Page 4]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
multicast or broadcast destination address or where the destination
is an individual address, but the station sending the MSDU chooses to
involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs.
Integration: The service that enables delivery of medium access
control (MAC) service data units (MSDUs) between the distribution
system (DS) and an existing, non-IEEE 802.11 local area network (via
a portal).
Distribution: The service that, by using association information,
delivers medium access control (MAC) service data units (MSDUs)
within the distribution system (DS).
1.3 Terminology Used in this Document
One of the motivations in defining new terminology in this document
is to clarify some of the ambiguity and confusion surrounding some
conventional terms. One of such terms is "Access Point (AP)".
Typically ,when people talk about "AP", they refer to the physical
entity (box) that has an antenna, implements 802.11 PHY and receives/
transmits the station (STA) traffic over the air. However, 802.11
Standards [1] describes AP mostly as a logical entity that implements
a set of logical services so that station traffic can be received and
transmitted effectively over the air. So when people talk about "AP
functions", they usually mean the logical functions the whole WLAN
access networks support, not just the part of the functions supported
by the physical entity (box) that the STAs communicate to directly.
Such confusion can be especially profound when the logical functions
is implemented across a network instead of within a single physical
entity. So to avoid further confusion, we define the following
terminology used in this document:
CAPWAP: Control and Provisioning of Wireless Access Points.
IEEE 802.11 WLAN Functions: a set of logical functions defined by
IEEE 802.11 Working Group, including all the MAC services, Station
Services, and Distribution Services. These logical functions are
required to be implemented in the IEEE 802.11 Wireless LAN (WLAN)
access networks by IEEE 802.11 Standards [1].
CAPWAP Functions: a set of WLAN control functions that are not
directly defined by IEEE 802.11 Standards, but deemed essential for
effective control, configuration and management of the 802.11 WLAN
access networks.
Wireless Termination Point (WTP): the physical or network entity that
contains RF antenna and 802.11 PHY to transmit and receive station
traffics for the IEEE 802.11 WLAN access networks. Such physical
Yang (Editor), et al. Expires October 15, 2004 [Page 5]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
entities are often called "Access Points" (AP) previously, but "AP"
can also be used to refer to logical entity that implements 802.11
services. So we recommend using "WTP" instead to explicitly refer to
the physical entity.
Autonomous WLAN Architecture: the WLAN access network architecture
family in which all the logical functions including both IEEE 802.11
functions and CAPWAP functions (wherever applicable) are implemented
within each Wireless Termination Point (WTP) in the network. The WTPs
in such networks are also called the standalone APs, or fat APs,
because these devices implement the full functions that enable the
devices to function without any other support from the network.
Centralized WLAN Architecture: the WLAN access network architecture
family in which the logical functions including both IEEE 802.11
functions and CAPWAP functions (wherever applicable) are implemented
across a hierarchy of network entities. At the low level of such
hierarchy are the WTPs while at the higher level are the Access
Controllers (ACs) which are responsible to control, configure and
manage the entire WLAN access networks.
Distributed WLAN Architecture: the WLAN access network architecture
family in which the logical functions including both IEEE 802.11
functions and CAPWAP functions (wherever applicable) are implemented
across a distributed network consisting of peer entities. A mesh
network of WTPs can be considered as an example of such architecture.
Access Controller (AC): The network entity in the Centralized WLAN
architectures that control, configure and manage the entire 802.11
wireless access network including the WTPs.
Standalone WTP: referred to the WTP in Autonomous WLAN Architecture.
Controlled WTP: referred to the WTP in Centralized WLAN Architecture.
Split MAC Architecture: A sub-group of the Centralized WLAN
Architecture, with the characteristic that WTPs in such WLAN access
networks only implement the delay sensitive MAC services (like the
control frame processing) for IEEE 802.11, while tunnel all the
management and data frames to AC for centralized processing. The IEEE
802.11 MAC as defined by IEEE 802.11 Standards in [1] is effectively
split between the WTP and AC.
Remote MAC Architecture: A sub-group of the Centralized WLAN
Architecture, where the entire set of 802.11 MAC functions (including
delay-sensitive functions) are implemented at the AC. The WTP
terminates the 802.11 PHY functions.
Yang (Editor), et al. Expires October 15, 2004 [Page 6]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Local MAC Architecture: A sub-group of the Centralized WLAN
Architecture, where the majority or entire set of 802.11 MAC
functions (including most of the 802.11 management frame processing)
are implemented at the WTP. Therefore, the 802.11 MAC stays intact
and local in the WTP, along with PHY.
1.4 Terminology Used Historically but Not Recommended
We recognize that some terminology have been used by vendors
historically, but we recommend stop using to avoid further confusion,
mostly around the term of "AP". We provide a list of such terms here
with the recommended new terminology:
Split WLAN Architecture: use Centralized WLAN Architecture.
Hierachical WLAN Architcture: use Centralized WLAN Architecture.
Standalone Access Point: use WTP or Standalone WTP.
Fat Access Point: the same as Standalone Access Point, relatively to
Thin Access Points. use WTP or Standalone WTP.
Thin Access Point: use WTP, or Controlled WTP.
Light Weight Access Point: the same as Thin Access Point, use WTP, or
Controlled WTP.
Split AP Architecture: use Local MAC Architecture.
Antenna AP Architecture: use Remote MAC Architecture.
Yang (Editor), et al. Expires October 15, 2004 [Page 7]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
2. Introduction
As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale
deployment of WLAN networks is highlighting certain technical
challenges. As outlined in [2], management, monitoring and control of
large number of Access Points (APs) in the network may prove to be a
significant network administration burden. Distributing and
maintaining a consistent configuration throughout the entire set of
APs in the WLAN is a difficult task. The shared and dynamic nature of
the wireless medium also demands effective coordination among the APs
to minimize radio interference and maximize network performance.
Network security issues which have always been a concern in WLAN's,
have even more challenges in large deployments and new architectures.
Recently many vendors have begun offering partially proprietary
solutions to address some or all of the above mentioned problems.
Since interoperable solutions allow a broader choice, a standardized
interoperable solution addressing the above mentioned problems is
desirable. As the first step toward establishing interoperability in
the market place, this document attempts to provide a taxonomy of the
architectures employed in existing WLAN products. We hope to provide
a cohesive understanding of the market practices for the standard
bodies involved (including the IETF and IEEE 802.11). This document
may be reviewed and utilized by the IEEE 802.11 Working Group as
input to their task of defining the functional architecture of an
access point.
2.1 IEEE 802.11 WLAN Functions
The IEEE 802.11 specifications are wireless standards that specify an
"over-the-air" interface between a wireless client (STA) and an
Access Point (AP), as well as among wireless clients. 802.11 also
describes how mobile devices can associate together into a basic
service set (BSS), the rough equivalent of a single broadcast domain
or a segment of a bridged Ethernet LAN. A BSS is identified by a
common service set identifier (SSID) or name. The WLAN architecture
can be considered as a sort of the 'cell' architecture where each
cell is the Basic Service Set (BSS) and each BSS is controlled by the
Access Point (AP). When more than one AP is connected via a broadcast
layer 2 network and all are using the same SSID, an extended service
set (ESS) is created. An ESS is also similar to a single broadcast
domain, where a mobile device associated with one AP can successfully
ARP for the address of a mobile device associated with any other AP
in the ESS. Within an ESS, a mobile station can roam from one AP to
another through only layer 2 transitions coordinated by the 802.11
MAC management protocol. Higher layer protocols, including IP are
unaware that the network attachment point of the mobile device has
moved.
Yang (Editor), et al. Expires October 15, 2004 [Page 8]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
The architectural component used to interconnect BSSs is the
distribution system (DS). An access point (AP) is a STA that provides
access to the DS by providing DS services in addition to acting as a
STA. Another logical architectural component -- portal -- is
introduced to integrate the IEEE 802.11 architecture with a
traditional wired LAN. It is possible for one device to offer both
the functions of an AP and a portal.
IEEE 802.11 explicitly does not specify the details of DS
implementations. Instead, the 802.11 standard defines services that
provide the functions that the LLC layer requires for sending MAC
Service Data Units (MSDUs) between two entities on the network. These
services can be classified into two categories: the station service
(SS) and the distribution system service (DSS). Both categories of
service are used by the IEEE 802.11 MAC sublayer. Station services
consist of the following four services:
o Authentication: The service used to establish the identity of one
station as a member of the set of stations authorized to associate
with another station.
o Deauthentication: The service that voids an existing
authentication relationship.
o Privacy: The service used to prevent the content of messages from
being read by other than the intended recipients.
o MSDU Delivery: The service to deliver the MAC service data unit
(MSDU) for the Stations.
Distribution system services consist of the following five services:
o Association: The service used to establish access point/station
(AP/STA) mapping and enable STA invocation of the distribution
system services.
o Disassociation: The service that removes an existing association.
o Reassociation: The service that enables an established association
[between access point (AP) and station (STA)] to be transferred
from one AP to another (or the same) AP.
o Distribution: The service that provides MSDU forwarding by APs for
the STAs associated with them. MSDUs can be either forwarded to
the Wireless destination or to the Wired (Ethernet) destination
using the "Distribution System" concept of 802.11.
o Integration: The service to translate the MSDU received from the
Distribution System to the non-802.11 format and vice versa. Any
MSDU that is received from the DS invokes the "Integration"
services of the DSS before the 'Distribution' services are
invoked. The point of connection of the DS to the wired LAN is
termed as 'portal'.
Apart from these services the IEEE 802.11 also defines MAC services
that must be implemented by the APs in the WLAN. For example:
Yang (Editor), et al. Expires October 15, 2004 [Page 9]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
o Beacon Generation
o Probe Response/Transmission
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o Synchronization
o Retransmissions
o Transmission Rate Adaptation
o Privacy: 802.11 Encryption/Decryption
In addition to the services offered by the 802.11, the IEEE 802.11 WG
also designs the technique to support the Quality of Service
(802.11e), Security Algorithms (802.11i), mobility of the STA from
one BSS to the other (802.11f), Radio Resource Management (802.11f)
etc.
IEEE 802.11 does not exactly specify how all these functions get
implemented, nor does it specify that these functions be implemented
all in one physical device (e.g., the WTP). Conceptually, all it
requires is that the WTPs and the rest of the DS together implements
all these services. Typically, vendors implement not only the
services defined in the IEEE 802.11 standard, they also implement a
variety of value-added services or functions, like load balancing
support, QoS, station mobility support, rogue AP detection, etc. What
will become clear from the rest of this document is that vendors do
take advantage of the flexibility in the 802.11 architecture, and
have come up with many different flavors of architectures and
implementations of the WLAN services.
Because many vendors choose to implement these WLAN services across
multiple network elements, we want to make a clear distinction
between the logical WLAN access network functions, and the physical
devices that are typically referred to as AP (or thin AP, or mesh AP,
depends on the architecture family as described below). Each of these
physical devices may implement only part of the logical functions.
But the DS including all the physical devices as a whole implements
all, or most of the functions.
2.2 CAPWAP Functions
In order to address the four problems identified in the [2]
(management, consistent configuration, RF control, security)
additional functions are typically required. Such functions are
especially important when the IEEE 802.11 WLAN functions are
implemented across a large scale of network of multiple entities,
instead of within one single entity. Such functions are:
o RF monitoring, like Radar detection, noise and interference
detection and measurement.
o RF configuration, e.g., for retransmission, channel, transmission
power, etc.
Yang (Editor), et al. Expires October 15, 2004 [Page 10]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
o WTP configuration, e.g., for SSID, etc.
o WTP firmware loading, e.g., automatic loading and upgrading of WTP
firmware for network wide consistency.
o Network-wide STA state information database, including the
information needed to support value-added services, such as
mobility, load balancing etc.
o Mutual authentication between network entities, e.g., for AC and
WTP authentication in a Centralized WLAN Architecture.
The services listed are concerned with configuration and control of
the radio resource ('RF Monitoring' and 'RF Configuration'),
management and configuration of the WTP device ('WTP Configuration',
'WTP Firmware upgrade'), and also security regarding the registration
of the WTP to an AC ('AC/WTP mutual authentication'). Moreover, the
device from which other services such as mobility management across
subnets, and load balancing can obtain state information regarding
the STA(s) associated with the wireless network, is also reported as
a service ('STA state info database').
The above list of CAPWAP functions does not attempt to be an
exhaustive enumeration of all additional services offered by vendors.
Instead, we included only those functions that were frequently
encountered in the survey data, and are also pertinent to the
understanding of the central problem of interoperability.
Most of these functions are not explicitly specified by IEEE 802.11,
but some of the functions are. For example, control and management of
the radio-related functions of an AP are described implicitly in the
MIB, such as:
o Channel Assignment
o Transmit Power Control
o Radio Resource Measurement (work currently under way in IEEE
802.11k)
The 802.11h [6] amendment to the base 802.11 standard specifies the
operation of a MAC management protocol to accomplish the requirements
of some regulatory bodies (principally in Europe, but expanding to
others) in these areas:
o RADAR detection
o Transmit Power Control
o Dynamic Channel Selection
2.3 WLAN Architecture Proliferation
This document brings into light the different WLAN network
architectures that have been followed so far by different vendors, in
an attempt to address some or all of the problems outlined in [2].
As IEEE 802.11 standard explicitly does not specify the details of DS
Yang (Editor), et al. Expires October 15, 2004 [Page 11]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
implementations, different architectures proliferate in the market.
While these different architectures all conform to the IEEE 802.11
standard as a whole, the individual functional components in these
architectures are not standardized, and the interfaces between the
network architecture components are mostly proprietary, hence there
is no guarantee of cross-vendor interoperability even within similar
architecture family.
In order to achieve interoperability in the market place, the IETF
CAPWAP working group is taking on the first logical task of
documenting both the functional and the network architectures offered
by the existing WLAN vendors today. The end result of this task is
this taxonomy document.
After analyzing about a dozen different vendors' architectures, we
believe that the existing 802.11 WLAN access network architectures
can be broadly categorized into three distinct architecture families
based on the characteristics of the Distribution Systems that are
employed to provide the 802.11 functions.
o Autonomous WLAN Architecture: The first architecture family is the
traditional WLAN architecture, where each WTP is one physical
device that implements all the 802.11 services, including both the
distribution and integration services, and the portal function.
Such AP architecture is called Autonomous WLAN Architecture,
because each WTP is autonomous in its functionality, and it does
not require 802.11 specific support from any other network
elements. The WTP in such architecture is typically configured and
controlled individually and can be monitored and managed via
typical network management protocols like SNMP. But no explicit
802.11 support is needed outside of the WTP. So the WTPs in this
architecture are the traditional Access Points most people are
familiar with. Sometimes such WTPs are referred to as "Fat APs" or
"Standalone APs".
o Centralized WLAN Architecture: The second WLAN architecture family
is a newly emerging hierarchical architecture utilizing one or
multiple centralized controller for large number of WTP devices.
The centralized controller is commonly referred to as Access
Controller (AC), whose main function in the network is to control,
manage and monitor the WTP devices that are present in the
network. Access Controller could be a L3 or L2 device, and it
could also be co-located with a L2 bridge (switch) or a L3 router,
and hence may be referred to as Access Bridge, or Access Router in
those particular cases. But Access Controller is the generic
terminology we use through this document. This architecture family
has several distinct characteristics that are worth noting. First
of all, the hierarchical architecture and the centralized AC
afford much better manageability for the large scale networks.
Secondly, since the IEEE 802.11 functions and the CAPWAP control
Yang (Editor), et al. Expires October 15, 2004 [Page 12]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
functions are provided by the WTP devices and the AC together, the
WTP devices themselves may not implement the full 802.11 functions
as defined in the standards any more. Therefore, it can be said
that the full 802.11 functions are implemented across two physical
network devices, namely, the WTPs and ACs. Because the WTP devices
only implement a portion of the functions that standalone APs
implement, and such WTP devices in such architecture are sometimes
referred to as light weight or thin APs.
o Distributed WLAN Architecture: The third emerging WLAN
architecture family is distributed architectures in which the WTPs
are capable of forming a distributed network among themselves, via
either wired or wireless media. A wireless mesh network of WTPs is
one example in the distributed architecture family, where the APs
themselves form a mesh network connecting neighboring APs via
802.11 wireless links, and some of the APs also have wired
Ethernet connections to the gateway to the external network.
2.4 Taxonomy Methodology and Document Organization
Before the IETF CAPWAP working group started documenting the various
WLAN architectures, we conducted an open survey soliciting WLAN
architecture description contributions via the IETF CAPWAP mailing
list. We received 14 contributions in the form of short text
descriptions, 13 of them are from WLAN vendors (AireSpace, Aruba,
Avaya, Chantry Networks, Cisco, Cranite Systems, Extreme Networks,
Intoto, Panasonic, Trapeze, Instant802, Strix Systems, Symbol) and
one from an academic researcher (UCLA). Out of the 14 contributions,
one described an Autonomous WLAN Architecture, another a Distributed
Mesh Architecture, while the rest 12 entries represent architectures
that fall into the family of Centralized WLAN Architecture.
The 14 entries that were submitted for the architecture survey are
included in this document in its original form in the Appendix
sections. The information provided by each vendor for both the
"Functionality Distribution Matrix" in this document and the Appendix
is intended for the use of creating this architectural taxonomy only.
It represents the contributor's view of the architecture from an
engineering perspective and does not necessarily imply an existing
product, shipping or not, nor an intent by the vendor to build such a
product.
The interesting data we try to get out of these survey data is not
which vendor does what, but what are the general categories and
trends in WLAN architecture evolution, and what are the common
characteristics and what are being done differently, and why. In
order to represent the survey data in a compact format, a "Functional
Distribution Matrix" is used in this document to tabulate the
various services and functions in various vendor's offerings. These
Yang (Editor), et al. Expires October 15, 2004 [Page 13]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
services and functions are classified into three main categories:
o Architecture Considerations: the choice of the interconnection
topology between the AC and the AP is an architecture
consideration. Also, design choices regarding the physical device
on which processing of management, control, and data frames of the
802.11 takes place are also interesting to point out.
o 802.11 Functions: as described in Section 2.1.
o CAPWAP Functions: as described in Section 2.2.
For each one of these categories, the mapping of each individual
function to network entities implemented by each vendor is shown in
tabular form. The rows in the Functional Distribution Matrix
represent the individual functions that are organized into the above
mentioned three categories, while each column of the Matrix
represents one vendor's architecture offering in the survey data.
Such matrix will be used throughput the rest of the document to
represent the data set we have collected from the survey.
The rest of this document is organized around the three broad WLAN
architecture families that were introduced in Section 2.3. Each
architecture family is discussed in a separate section. The section
on Centralized Architecture contains more in-depth details than the
other two families, largely due to the large number of the survey
data (11 out of 14) collected falling into the Centralized
Architecture category.
Summary and conclusions are provided at the end of the document to
highlight the basic findings from this taxonomy exercise.
Yang (Editor), et al. Expires October 15, 2004 [Page 14]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
3. Autonomous Architecture
3.1 Overview
Figure 1 shows an example network of the Autonomous WLAN
Architecture. This architecture combines all the 802.11
functionality in a single physical device, the WTP. A common
embodiment of this architecture is a WTP that translates between
802.11 frames to/from its radio interface and 802.3 frames to/from an
Ethernet interface. An 802.3 infrastructure that interconnects the
Ethernet interfaces of different WTPs together provides the
distribution system. It can also provide portals for integrated 802.3
LAN segments.
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-----+ | | +-----+ | | +-----+ |
+----| WTP |----+ +----| WTP |----+ +----| WTP |----+
+--+--+ +--+--+ +--+--+
|Ethernet | |
+------------------+ | +------------------+
| | |
+---+--+--+---+
| Ethernet |
802.3 LAN --------------+ Switch +-------------- 802.3 LAN
segment 1 | | segment 2
+------+------+
Figure 1: Example of Autonomous WLAN Architecture
A single physical WTP can optionally be provisioned as multiple
virtual WTPs by supporting multiple SSIDs to which 802.11 clients may
associate. Usually this will also involve putting a corresponding
802.1Q tag on each packet forwarded to the Ethernet infrastructure.
The scope of the ESS(s) created by interconnecting the WTPs will be
confined by the constraints imposed by the Ethernet infrastructure.
Authentication of 802.11 clients may be performed locally by the WTP
or by using a centralized authentication server.
3.2 Security
Since both the 802.11 and CAPWAP functionality is tightly integrated
into a single physical device, the security issues with this
architecture are confined to the WTP. There are no extra
implications from the client authentication and encryption/decryption
Yang (Editor), et al. Expires October 15, 2004 [Page 15]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
perspective as the AAA interface is integrated into the WTP, as is
the key generation mechanisms required for 802.11i encryption/
decryption.
As per problem #4 in [2], the only security issue in this
architecture is mutual authentication between the WTP and the
Ethernet infrastructure to ensure that WTPs cannot be easily stolen
and deployed in unprotected networks. This can be ensured by existing
mechanisms such as, for instance, 802.1x between the WTP and the
Ethernet switch it plugs into.
Yang (Editor), et al. Expires October 15, 2004 [Page 16]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
4. Centralized WLAN Architecture
Centralized WLAN Architecture is a newly emerging architecture family
in the WLAN market. Contrary to the Autonomous WLAN Architecture
where the 802.11 functions and network control functions are all
implemented within each Wireless Termination Point, the Centralized
WLAN Architecture employs one or multiple centralized controller
called Access Controller(s) in the network to provide the network
wide visibility and improve management scalability and dynamic
configurability.
The following diagram shows schematically the Centralized WLAN
Architecture network diagram where the Access Controller (AC)
connects to multiple Wireless Termination Points (WTPs) via a certain
interconnection topology, which can be either a direct connection, a
L2-switched, or L3-routed network as described in Section 4.1. The
AC exchanges configuration, and control information with the AP
devices, allowing the management of the network from a centralized
point. Also, designs of the Centralied WLAN Architecture family do
not presume (as the diagram might suggest to some readers) that the
AC necessarily intercedes in the data plane to/from the WTP(s). More
details are provided later in this section.
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-------+ | | +-------+ | | +-------+ |
+----| WTP |--+ +----| WTP |--+ +----| WTP |--+
+---+---+ +---+---+ +---+---+
| | |
+------------------+ | +-----------------+
| |...|
+----+--+---+--------+
| Interconnection |
| Topology |
+-------+------------+
|
|
+-----+----+
| AC |
+----------+
Figure 2: Centralized WLAN Architecture Diagram
In the diagram above, the AC is shown as a single physical entity
that provides all of the CAPWAP functions listed in section 2.2.
Closer scrutiny of the functions reveals that their differing
resource requirements (e.g. CPU, memory, storage) may lend themselves
Yang (Editor), et al. Expires October 15, 2004 [Page 17]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
to being distributed across different devices. For instance, complex
radio control algorithms can be CPU intensive. Storing and
downloading images and configurations can be storage intensive. Data
plane services like mobility and load balancing may be better
supported in network devices that may be lacking in one or more of
these resources. The box marked 'AC' in the diagram above should
accordingly be thought of as a multiplicity of logical functions and
not necessarily as a single physical device.
4.1 Interconnection Topology between WTPs and ACs
There are several possible topologies which can be considered between
the AC(s) and the WTPs, including direct connection, L2 switched
connection, or L3 routed connection, as shown in Figure 3, Figure 4,
and Figure 5.
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP |
+--+--+ +--+--+
Figure 3: Directly Connected
Yang (Editor), et al. Expires October 15, 2004 [Page 18]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +-----+-----+
| WTP | | Switch |
+--+--+ +---+-----+-+
| |
+-----+ +-----+
| WTP | | WTP |
+-----+ +-----+
Figure 4: Switched Connections
+-------+-------+
| AC |
+-------+-------+
|
--------+------ LAN
|
+-------+-------+
| router |
+-------+-------+
|
-----+--+--+--- LAN
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP|
+--+--+ +--+--+
Figure 5: Routed Connections
4.2 Overview of Three Centralized WLAN Architectures
While dynamic and consistent network manageability is one of the
primary motivations for the Centralized Architecture, the survey data
from vendors also show that different varieties of this architecture
family have emerged as a result of the inherent flexibility in the
802.11 standard [1] regarding the implementation of the logical
functions that are broadly described under the term "Access Point".
Yang (Editor), et al. Expires October 15, 2004 [Page 19]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
As there is no standard mapping of these functions to physical
network entities, several design choices have been made by vendors
that offer related products. Moreover, the increased demand for
monitoring and consistent configuration of large wireless, enterprise
networks has resulted into a set of 'value-added' services provided
by the various vendors, most of which share common design properties
and service goals.
In the following, we describe the three main approaches vendors have
taken, namely, the Local MAC, Split MAC, and Remote MAC approaches
within this family of architectures, and provide the mapping
characteristics of the various functions into the network entities,
for each approach. The naming of Local MAC, Split MAC and Remote MAC
reflects how the functions, esp. the 802.11 MAC functions, are mapped
onto the network entities. Local MAP indicates that the MAC functions
stay intact and local to WTPs, while Split MAC shows the MAC being
split between the WTPs and ACs, and remote MAC signifies the MAC is
moved away from WTP to the remote AC in the network.
The differences among Local MAC, Split MAC and Remote MAC
architectures can be shown roughly in the following figure:
+--------------+--- +---------------+--- +--------------+---
| CAPWAP | | CAPWAP | | CAPWAP |
| functions |AC | functions |AC | functions |
|==============|=== |---------------| |--------------|
| | | non RT MAC | | |AC
| 802.11 MAC | |===============|=== | 802.11 MAC |
| |WTP | Real Time MAC | | |
|--------------| |---------------|WTP |==============|===
| 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP
+--------------+--- +---------------+--- +--------------+---
(a) "Local MAC" (b) "Split MAC" (c) "Remote MAC"
Figure 6: The Three Different Architectures within Centralized WLAN
Architecture Family
4.3 Local MAC
The Local MAC architecture model, as shown in Figure 6.(a), attempts
to offload network access policies and management functions (CAPWAP
functions described in Section 2.2) to the AC, without splitting the
802.11 MAC functionality between WTP(s) and AC(s). The whole 802.11
MAC resides on the WTP locally, including all the 802.11 management
and control frame processing for the STAs; however information
related to management and configuration of the WTP devices is
Yang (Editor), et al. Expires October 15, 2004 [Page 20]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
communicated with a centralized AC, to facilitate management of the
network, and maintain a consistent network-wide configuration for the
WTP devices.
Figure 7 offers a tabular representation of the design choices made
by the six vendors in the survey that follow the Local MAC approach
with respect to the architecture considerations. "WTP-AC topology"
shows the kind of topology between WTPs and AC each vendor's
architecture can support. It is clear that all the vendors can
support L3 routed network topology between WTPs and AC, which implies
that direct connections and L2 switched networks are also supported
by all vendors. By '802.11 mgmt termination', and '802.11 control
termination' we denote the physical network device on which
processing of the 802.11 management, and control frames is done
respectively. All the vendors here choose to terminate 802.11
management and control frames at WTPs. The last row of the table
'802.11 data aggregation', refers to the device on which aggregation
and delivery of 802.11 data frames from one STA to another (possibly
through a DS) is performed. As we can see from the table, vendors
make different choices as whether or not all the 802.11 data traffic
are aggregated and routed through the AC. The survey data shows that
some vendors choose to tunnel or encapsulate all the station traffic
to or from the ACs, implying the AC also acts as the access router
for this WLAN access network; while other vendors choose to separate
the control plane and data plane by letting the station traffic being
bridged or routed locally while keeping the control at the AC.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
WTP-AC
topology L3 L3 L3 L3 L3
802.11 mgmt
termination WTP WTP WTP WTP WTP
802.11 control
termination WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC WTP AC WTP
Figure 7: Architecture Considerations for Local MAC Architecture
Yang (Editor), et al. Expires October 15, 2004 [Page 21]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Below Figure 8 shows that most of the CAPWAP functions as described
in Section 2.2 are implemented at the AC, with help from WTPs to
monitor RF channels, and collect statistics and state information
from the STAs. Most vendors choose to do the similar mapping here as
the AC offers the advantages of network-wide visibility, which is
essential for many of the control, configuration and value-added
services.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
RF
Monitoring WTP WTP AC/WTP WTP WTP
RF
Config. AC AC AC AC AC
WTP config. AC AC AC AC AC
WTP
Firmware AC AC AC AC AC
STA state
info
database AC AC/WTP AC/WTP AC/WTP AC
AC/WTP
mutual
authent. X X X X X
Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture
The matrix shown in Figure 9 shows that most of the 802.11 functions
are implemented at the WTPs for Local MAC Architecture, with some
minor differences among the vendors with regard to distribution
service, 802.11e scheduling and 802.1x/EAP authentication. The
difference in distribution service is consistent with the difference
described earlier with regard to "802.11 data aggregation" in the
Figure 7.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
Distribution
Service AC AC WTP AC WTP
Yang (Editor), et al. Expires October 15, 2004 [Page 22]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Integration
Service WTP WTP WTP WTP WTP
Beacon
Generation WTP WTP WTP WTP WTP
Probe
Response WTP WTP WTP WTP WTP
Power mgmt
Packet
Buffering WTP WTP WTP WTP WTP
Fragmentation/
Defragment. WTP WTP WTP WTP WTP
Association
Disassoc.
Reassociation AC WTP WTP WTP WTP
WME/11e
--------------
classifying WME WME WME WTP
scheduling WTP AC/WTP WTP WTP WTP
queuing WTP WTP WTP WTP
Authentication
and Privacy
--------------
802.1x/EAP AC AC AC/WTP AC AC/WTP
Keys
Management AC AC WTP AC AC
802.11
Encryption/
Decryption WTP WTP WTP WTP WTP
Figure 9: Mapping of 802.11 Functions for Local MAC Architecture
From Figure 7, Figure 8 and Figure 9, it is clear that differences
between vendors in the Local MAC Architecture is relatively minor
while the most of the functional mapping appears to be common across
the vendors.
Yang (Editor), et al. Expires October 15, 2004 [Page 23]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
4.4 Split MAC
As shown in Figure 6.(b), the main idea behind the Split MAC
architecture is to implement part of the 802.11 MAC functionality on
a centralized AC instead of the WTPs, in addition to the services
required for managing and monitoring the WTP devices. Usually, the
decision of which functions of the 802.11 MAC need to be provided by
the AC is based on the time-criticality of the service required.
In Split MAC architecture, the WTP terminates the infrastructure side
of the wireless physical link, provides radio-related management, and
also implements all time-critical functionality of the 802.11 MAC. In
addition, the non real-time management functions are handled by a
centralized AC, along with higher-level services, such as
configuration, QoS, policies for load-balancing, access control
lists, etc. The subtle but key distinction between Local MAC and
Split MAC relates to the non real-time functions: in Split MAC
architecture, the AC terminates 802.11 non real-time functions,
whereas in Local MAC architecture the WTP terminates the 802.11 non
real-time functions and consequently sends appropriate messages to
the AC.
There are several motivations for taking the Split MAC approach. One
of the motivations is to offload to the WTP(s) functionality that is
specific and relevant only to the locality of each BSS in order to
allow the AC to scale to a large number of 'light weight' WTP
devices. Moreover, real-time functionality is subject to latency
constraints and cannot tolerate delays due to transmission of 802.11
Control frames (or other real-time information) over multiple-hops.
The latter would limit the available choices for the interconnection
topology between the AC and the WTP(s), so the real-time criterion is
usually employed to separate MAC services between the devices.
Another consideration is cost reduction in the WTP to make it as
cheap and simple as possible. Last but not least, moving functions
like encryption and decryption to the AC instead of WTPs help avoid
any risk from a compromised WTP by not having user encryption keys on
the WTP at all. A side effect of this architecture is that progress
in security protocols and algorithm does not obsolete the WTPs; the
ACs implement the new security schemes instead and the management
problem is therefore simplified. It can also protect from LAN-side
eavesdropping.
Examples of real-time services of the 802.11 MAC that are implemented
on the WTP are the following:
o Beacon Generation
o Probe Response/Transmission
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
Yang (Editor), et al. Expires October 15, 2004 [Page 24]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
o Synchronization
o Retransmissions
o Transmission Rate Adaptation
The non-real-time aspects of the 802.11 MAC are handled by the AC,
either directly through the processing of raw 802.11 management
frames (Split MAC), or after conversion to some other message format
(Local MAC). These include:
o Station Services: Authentication/Deauthentication
o Distribution System Services: Association/Disassociation/
Reassociation/Distribution
o Integration Services: bridging between 802.11 and 802.3
o Privacy: 802.11 Encryption/Decryption
o Fragmentation/Defragmentation
The following matrix in Figure 10 offers a tabular representation of
the design choices made by the six vendors that follow the Split MAC
design with respect to the architecture considerations. While most
vendors support L3 topology between WTPs and ACs, some vendors can
only support L2 switched connections, due to the tighter delay
constraint resulting from splitting MAC between two physical entities
across a network. Comparing to Figure 7, it is clear that the
commonality between Split MAC and Local MAC is that the 802.11
control frames are all processed by WTP, while the difference lies in
the termination point for 802.11 management frames. Local MAC
terminates 802.11 management frames at WTP, while at least some of
the 802.11 management frames are being terminated at the AC for Split
MAC Architecture. In most cases, since WTP devices are
IP-addressable, any of the direct connection, L2-switched, or
L3-routed topologies of Section 2.2 can be used. In the case where
only Ethernet-encapsulation is performed (ex. as in Architecture 4)
then only direct connection and L2-switched topologies are supported.
Yang (Editor), et al. Expires October 15, 2004 [Page 25]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
WTP-AC
topology L3 L3 L3 L2 L3 L3
802.11 mgmt
termination AC AC AC AC WTP/AC AC
802.11 control
termination WTP WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC AC AC AC AC
Figure 10: Architecture Considerations for Split MAC Architecture
Similar to the Local MAC Architecture, the following matrix in Figure
11 shows that the CAPWAP control functions are implemented at the AC.
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
RF
Monitoring WTP WTP WTP WTP WTP WTP
RF
Config. WTP/AC WTP/AC AC AC AC
WTP config. AC AC AC AC AC
WTP
Firmware AC AC AC AC AC
STA state
info
database AC AC AC AC AC
AC/WTP
mutual
authent. X X X X
Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture
The most interesting matrix for Split MAC Architecture is the
Yang (Editor), et al. Expires October 15, 2004 [Page 26]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Functional Distribution Matrix for 802.11 functions, as shown below
in Figure 12. It is clear that even within the Split MAC
Architecture, vendors choose to map many of the functions
differently. All vendors choose to implement Distribution,
Integration Service at the AC, along with 802.1x/EAP authentication
and keys management. All vendors also choose to implement beacon
generation at WTPs. But there exists wide spread difference among the
vendors for most other functions. So this clearly indicates that
Split MAC Architecture represents a category of architectures that
split the MAC somehow, but it does not represent a single way of
splitting at all.
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ------ ----- -----
Distribution
Service AC AC AC AC AC AC
Integration
Service AC AC AC AC AC AC
Beacon
Generation WTP WTP WTP WTP WTP WTP
Probe
Response WTP AC/WTP WTP WTP WTP WTP
Power mgmt
Packet
Buffering WTP WTP WTP AC AC/WTP WTP
Fragmentation
Defragment. WTP WTP AC AC AC
Association
Disassoc.
Reassociation AC AC AC AC WTP AC
WME/11e
--------------
classifying WME/Oth WME/Oth AC WME/802.11e WME/other
scheduling WTP/AC AC WTP AC AC WTP/AC
queuing WTP/AC WTP WTP AC WTP WTP
Authentication
Yang (Editor), et al. Expires October 15, 2004 [Page 27]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
and Privacy
--------------
802.1x/EAP AC AC AC AC AC AC
Keys
Management AC AC AC AC AC AC
802.11
Encryption/
Decryption WTP AC WTP AC AC AC
Figure 12: Mapping of 802.11 Functions for Split MAC Architecture
4.5 Remote MAC
One of the main motivation for Remote MAC Architecture is to keep the
WTPs as light weight as possible by having only the radio interface
on the WTPs and offloading the entire set of 802.11 MAC functions
(including delay-sensitive functions) to the Access Controller. It
thus keeps all the complexities of the MAC and other CAPWAP control
functions to the centralized controller and makes the WTP manageable.
The WTP acts only as a communication means between the Wireless LAN
clients (STA) and the AC, though they may have an additional feature
to convert the frames from one format (802.11) to the other
(Ethernet, TR, Fiber etc.). The centralized controller has a protocol
for network monitoring, management and control, entire set of the
802.11 AP services, the WLAN PHY concepts, security features,
resource management, channel adoption features, guarantying Quality
of Service to the users etc. Because MAC is separated from the PHY,
we call this "Remote MAC Architecture". Typically such architecture
is deployed with special attention to the topology between WTP and AC
so that the delay is minimized. The RoF (Radio over Fiber) from
Architecture 5 Appendix F is such an example of Remote MAC
Architecture.
4.6 Comparisons of Local MAC, Split MAC and Remote MAC
Two commonalities across all the three Centralized Architectures
(Local MAC, Split MAC and Remote MAC) are:
o All the CAPWAP functions related to network control and
configuration reside on the AC.
o IEEE 802.11 PHY resides on the WTP.
The difference between Remote MAC and the other two Centralized
Architectures (i.e., Local MAC and Split MAC) is pretty clear, as the
802.11 MAC is completely separated from the PHY in the former, while
Yang (Editor), et al. Expires October 15, 2004 [Page 28]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
the other two at least keep some portion of the MAC functions with
PHY at the WTPs. So the implication of PHY and MAC separation is that
it severely limits the interconnection topology between WTPs and ACs
so that 802.11 timing constraint is still satisfied. As pointed out
earlier, this usually results in tighter control over the
interconnection between WTP and AC for the Remote MAC Architecture.
The advantage of Remote MAC Architecture is that it offers the
lightest possible WTPs for certain deployment scenarios.
The commonalities and differences between Local MAC and Split MAC are
most clearly seen by comparing Figure 7 and Figure 10. The
commonality between the two is that 802.11 control frames are
terminated at WTPs in both cases. The main difference between Local
MAC and Split MAC is that in the latter WTP terminates only the
802.11 Control frames, while in the former WTP may terminate all
802.11 frames. An interesting consequence of this difference is that
Integration Service, which essentially refers to bridging between
802.11 and 802.3 frames, is implemented by the AC in the Split MAC,
but can be part of either the AC or WTP in the Local MAC.
As a second note, the Distribution Service, although usually provided
by the AC, can also be implemented at the WTP in some Local MAC
architecture. The rationale behind this approach is to increase
performance in delivering STAs data traffic by avoiding tunnelling it
to the AC, and also relax the dependency of the WTP from the AC.
Therefore, it is possible that data plane and control plane are
separated in the Local MAC Architecture.
Even though all the 802.11 traffic are aggregated at ACs in the case
of Split MAC Architecture, the data plane and control plane can still
be separated by employing multiple ACs. For example, one AC can
implement most of the CAPWAP functions (control plane), while other
ACs can be employed for 802.11 frames bridging (data plane).
4.7 Communication Interface between WTPs and ACs
Before any messages can be exchanged between the AC and WTP(s)
typically the following operations are first performed that lead to
the registration of an WTP with an AC:
1. Discovery : WTP(s) discover the AC with which they will
associate, and be controlled by. The discovery procedure can
employ either static configuration, or dynamic. In the latter
case, a protocol is used in order for the WTP to discover
candidate AC(s).
2. Authentication: after discovery, the WTP device authenticates
itself with the AC. The opposite is not always supported, since
some vendors strive for zero-configuration on the WTP side.
Yang (Editor), et al. Expires October 15, 2004 [Page 29]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
3. WTP Association: after successful authentication, an WTP
registers with the AC, in order to start receiving management and
configuration messages.
4. Firmware Download: after successful association, the WTP may
pull, or the AC may push the WTPs firmware , which is digitally
signed.
5. Control Channel Establishment: the WTP establishes either an
IP-tunnel (ex. Architecture 2 (Appendix C), Architecture 1
(Appendix B)) or performs Ethernet encapsulation (ex.
Architecture 4 (Appendix E)) with the AC, in order to transfer
data traffic and management frames.
6. Configuration Download: following the control channel
establishment process, the AC may push configuration parameters
to the WTP.
4.8 Security
Given the varied distribution of functionalities for the Centralized
Architecture as surveyed in Section 4.3, it is obvious that an extra
network binding is created between the WTP and the AC. This brings
along new and unique security issues and subsequent requirements.
4.8.1 Client Data Security
The survey shows clearly that the termination point for "over the
air" 802.11 encryption (802.11i) can be implemented either in the WTP
or in the AC. Furthermore, the 802.1x/EAP functionality is also
distributed between the WTP and the AC where, in almost all cases,
the AC performs the necessary functions as the authenticator in the
802.1x exchange. If the encryption is done at the WTPs, the
resultant cryptographic keys for the session are required to be
securely pushed from the AC to the WTP. Since this keying material
is part of the control and provisioning of the WTPs, a secure
encrypted tunnel for control frames is employed to transport the
keying material. In the case where the 802.11i encryption/decryption
is performed in the AC, the authentication and key management is also
fully performed in the AC.
Regardless of 802.11i termination point, the Centralized WLAN
Architecture assumes two possibilities for "over the wire" client
data security. In some cases there is an encrypted tunnel (IPsec or
SSL ) between the WTP and AC which assumes the security boundary to
be in the AC. In other cases an end-to-end mutually authenticated
secure VPN tunnel is assumed between the client and AC, other
security gateway or end host entity.
Yang (Editor), et al. Expires October 15, 2004 [Page 30]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
4.8.2 Security of control channel between WTP and AC
In order for the CAPWAP functions to be implemented in the
Centralized WLAN Architecture there is a requirement for a control
channel between WTP and AC. This is the link where security threats
may arise.
Threats to the Centralized WLAN Architecture as presented in the
submissions are:
1. Secure discovery of WTP and AC
2. Authentication of the WTPs to the ACs and vice versa
3. Man-in-the-middle attacks to the control channel between WTP and
AC.
4. Confidentiality and integrity of control channel frames
5. Theft of WTPs and extraction of embedded secrets within.
Discovery and authentication of WTPs are addressed in the submissions
by implementing authentication mechanisms that range from X.509
certificates, AAA authentication and pre-shared credential
authentication. In all cases, the issues of confidentiality,
integrity and of protection against man-in-the-middle attacks of the
control frames are addressed by a secure encrypted tunnel between WTP
and AC(s) utilizing keys derived from the varied authentication
methods mentioned previously. Finally, one of the motivations for
the Centralized WLAN Architecture is to minimize the storage of
cryptographic and security sensitive information in addition to
operational configuration parameters within the WTPs. It is for that
reason that majority of the submissions under the Centralized
Architecture category have employed a post WTP authenticated
discovery phase of configuration provisioning which, in turn protects
against the theft of WTPs.
Yang (Editor), et al. Expires October 15, 2004 [Page 31]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
5. Distributed Mesh Architecture
Editor's note: This section is only a place holder for now. We will
need to work on this soon.
An example of the Distributed Mesh Architecture is shown in Figure
13, The mesh nodes can keep track of the state of its neighboring
nodes or even nodes beyond, so that the mesh nodes can coordinate
among themselves to provide the necessary functions. The distinction
between this architecture family and the Centralized Architecture is
the classical distinction between a distributed architecture versus a
centralized one. Each can have certain advantages for certain
deployment scenarios.
+-----------------+ +-----------------+
| 802.11 BSS 1 | | 802.11 BSS 2 |
| ... | | ... |
| +---------+ | | +---------+ |
+----|mesh node|--+ +----|mesh node|--+
+-+---+---+ +-+-+-----+
| | | |
| | | | +----------+
| +-----------------------+ | Ethernet | Ethernet |
| 802.11 wireless links | +--------+ Switch |
| +-----------------------+ | | | |
| | | | | +----------+
+-+---+---+ +-+--+----+
+----|mesh node|--+ +----|mesh node|--+
| +---------+ | | +---------+ |
| ... | | ... |
| 802.11 BSS 4 | | 802.11 BSS 3 |
+-----------------+ +-----------------+
Figure 13: Example of Distributed Mesh Architecture
5.1 Security
TBW
Yang (Editor), et al. Expires October 15, 2004 [Page 32]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
6. Summary and Conclusions
We requested existing WLAN vendors and other interested parties to
submit a short description of existing or desired WLAN access network
architectures to define a taxonomy of possible WLAN access network
architectures. The information from the 14 submissions was condensed
and summarized in this document.
New terminology has been defined wherever existing terminology was
found to be either insufficient or ambiguous in describing the WLAN
architectures and supporting functions listed in the document. For
example, the broad set of Access Point functions has been devided
into two categories - 802.11 functions which includes those that are
required by the IEEE 802.11 standards, and CAPWAP functions which
includes those that are not required by the IEEE 802.11, but are
deemed essential for control, configuration, and management of 802.11
WLAN access networks. Another term that has caused considerable
ambiguity is "Access Point" which was usually tied to reflect a
physical box that has the antennas, but did not have a uniform set of
externally verifiable behavior across all the submissions. To remove
this ambiguity, we have re-defined the AP to be the set of 802.11 and
CAPWAP functions, while the physical box that terminates the 802.11
PHY is called the Wireless Termination Point.
6.1 Taxonomy Summary
Based on the submissions during the architectural survey phase, we
have classified the existing WLAN architectures into three broad
classes:
1. Autonomous WLAN architecture indicates a family of architectures
where all the 802.11 functions and, where applicable, CAPWAP
functions are implemented in the WTP.
2. Centralized WLAN architecture indicates a family of architectures
where the AP functions are split between the WTP and the AC with
the AC, typically, acting as a centralization control point for
multiple WTPs.
3. Distributed WLAN architecture indicates a family of architectures
where the AP functions are implemented across a distributed
network of peer entities.
Within the centralized WLAN architecture, there are a few subgroups
that are visible depending on how one splits the MAC functions, at a
high-level, between the WTP and the AC. Three prominent ones emerged
from the information present in the submissions:
1. Split MAC architecture, where the 802.11 MAC functions are split
between the WTP and the AC. This subgroup includes all
architectures that split the 802.11 MAC functions even though
individual submissions differed on the specifics of the split.
Yang (Editor), et al. Expires October 15, 2004 [Page 33]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
2. Local MAC architecture, where the entire set of 802.11 MAC
functions is implemented on the WTP.
3. Remote MAC architecture, where the entire set of 802.11 MAC
functions is implemented on the AC.
The following tree diagram summarizes the architectures documented in
this taxonomy.
+----------------+
|Autonomous |
+---------->|Architecture |
| |Family |
| +----------------+
| +--------------+
| |Local |
| +---->|MAC |
| | |Architecture |
| | +--------------+
| |
| +----------------+ | +--------------+
| |Centralized | | |Split |
+---------->|Architecture |--+---->|MAC |
| |Family | | |Architecture |
| +----------------+ | +--------------+
| |
| | +--------------+
| | |Remote |
| +---->|MAC |
| |Architecture |
| +--------------+
| +----------------+
| |Distributed Mesh|
+---------->|Architecture |
|Family |
+----------------+
A majority of the submitted WLAN access network architectures
followed the centralized WLAN architecture. All but one of the
centralized WLAN architecture submissions were grouped into either a
Split MAC architecture or a Local MAC architecture. There was one
submission that followed the Remote AP architecture. There was one
submission under the Distributed WLAN architecture.
The WLAN access network architectures in the submissions indicated
that the topological assumptions were:
o Direct connection between the WTP and the AC.
Yang (Editor), et al. Expires October 15, 2004 [Page 34]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
o L2 switched connectivity between the WTP and the AC.
o L3 routed connectivity between the WTP and the AC.
o Wireless links in the distributed WLAN architecture.
6.2 Next Steps
Interoperability between equipment from different vendors is one of
the problems listed in the CAPWAP problem statement. It is not very
surprising to see that the interoperability problem has arguably seen
more discussion under the centralized WLAN access network
architecture, given the number of submissions that seem to favor this
architecture.
In order to achieve the interoperability goal, the following are
possible next steps:
1. The CAPWAP taxonomy document needs to be reviewed by both the
IEEE 802.11 WG and the IETF.
2. Using the above taxonomy/terminology, a functional model of an
Access Point should be defined, possibly, by a group within the
IEEE 802.11. The functional model will consist of defining
functional elements of an 802.11 access point that are considered
atomic, i.e. not subject to further splitting across multiple
network elements. Such a functional model should serve as a
common foundation to support the existing WLAN architectures as
outlined in this taxonomy, and any further architecture
development either within or outside of IEEE 802.11 group. It is
possible, or even recommended, that the work on the functional
model definition may also include impact analysis of implementing
each functional element on either the WTP or the AC.
3. As part of the functional model definition, define interfaces in
the form of primitives between these functional elements.
4. If a pair of functional elements that have an interface defined
between them is subject to a split, i.e., subject to being
implemented on two different network entities, then a protocol
specification between such pairs of functional elements is
required to be defined.
Yang (Editor), et al. Expires October 15, 2004 [Page 35]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
7. Security Considerations
While this taxonomy documents the architectures employed in the
existing IEEE 802.11 products in the market, it also documents the
security issues that arise with the varied ways in which vendors have
chosen to employ these architectures. The WLAN architectures are
broadly categorized into three families: Autonomous Architecture,
Centralized Architecture, and Distributed Architecture. While
Section 3, Section 4 and Section 5 are devoted to each of these three
architecture families, respectively, each section also contains a
subsection to address the security issues within each architecture
family. Please refer to Section 3Section 3 and Section 3 for
detailed security considerations in each of these architecture
families.
In summary, the main security concern in the Autonomous Architecture
is the mutual authentication between WTP and the wired (Ethernet)
infrastructure equipment. The WTP physical entity contains all of
the 802.11 and CAPWAP functions which isolates it from over the wire
security issues between WTP and AC. In the Centralized Architecture
there are a few new security concerns because of the introduction of
a network binding between WTP and AC. The following security
concerns are raised for this architecture family: keying material for
mobile client traffic needs to be securely transported from AC to
WTP; secure discovery of WTP and AC is required, mutual
authentication of WTPs and AC is needed, man- in-the-middle attacks
to the control channel between WTP and AC, confidentiality and
integrity of control channel frames, and theft of WTPs for extraction
of embedded secrets within. Each of the survey results for this
broad architecture category have presented a variety of mechanisms to
address these security issues.
[Editor's note] Summary of the security issues and concerns
pertaining to the Distributed architecture needs to be written when
the description of that architecture is complete.
Yang (Editor), et al. Expires October 15, 2004 [Page 36]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
8. Acknowledgements
This taxonomy is truly a collaborative effort with contributions from
a large group of people. First of all, we want to thank all the
CAPWAP Architecture Design Team members who have spent many hours in
the teleconference calls, over emails and in writing and reviewing
the draft. The full Design Team is listed here:
o Peyush Agarwal
STMicroelectronics
Plot# 18, Sector 16A
Noida, U.P 201301
India
Phone: +91-120-2512021
EMail: peyush.agarwal@st.com
o Dave Hetherington
Roving Planet
4750 Walnut St., Suite 106
Boulder, CO 80027
United States
Phone: +1-303-996-7560
EMail: Dave.Hetherington@RovingPlanet.com
o Matt Holdrege
Strix Systems
26610 Agoura Road
Calabasas, CA 91302
Phone: +1 818-251-1058
EMail: matt@strixsystems.com
o Victor Lin
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051
Phone: +1 408-579-3383
EMail: vlin@extremenetworks.com
o James M. Murphy
Trapeze Networks
5753 W. Las Positas Blvd.
Pleasanton, CA 94588
Phone: +1 925-474-2233
EMail: jmurphy@trapezenetworks.com
o Partha Narasimhan
Aruba Wireless Networks
180 Great Oaks Blvd
San Jose, CA 95119
Phone: +1 408-754-3018
EMail: partha@arubanetworks.com
o Bob O'Hara
Airespace
Yang (Editor), et al. Expires October 15, 2004 [Page 37]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
110 Nortech Parkway
San Jose, CA 95134
Phone: +1 408-635-2025
EMail: bob@airespace.com
o Emek Sadot (see Authors' Addresses)
o Ajit Sanzgiri
Cisco Systems
170 W Tasman Drive
San Jose, CA 95134
Phone: +1 408-527-4252
EMail: sanzgiri@cisco.com
o Inderpreet Singh
Chantry Networks
1900 Minnesota Court
Mississauga, Ontario L5N 3C9
Canada
Phone: +1 905-567-6900
EMail: isingh@chantrynetworks.com
o L. Lily Yang (Editor, see Authors' Addresses)
o Petros Zerfos (see Authors' Addresses)
In addition, we would also like to acknowledge the contributions from
the following individuals who participated in the architecture survey
and provided detailed input data in preparation of the taxonomy:
Parviz Yegani, Cheng Hong, Saravanan Govindan, Bob Beach, Dennis
Volpano, Shankar Narayanaswamy, Simon Barber, Srinivasa Rao
Addepalli, Subhashini A. Venkataramanan. It is simply impossible to
write a taxonomy without a large representative data points that they
provided us. We would also like to thank our CAPWAP WG co-chairs,
Mahalingam Mani and Dorothy Gellert, and our Area Director, Bert
Wijnen, for their unfailing support.
9 References
[1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, <IEEE
802.11-99>.
[2] "CAPWAP Problem Statement", February 2004, <http://www.ietf.org/
internet-drafts/draft-ietf-capwap-problem-statement-00.txt>.
[3] "The Internet Standards Process Revision 3", October 1996,
<ftp://ftp.isi.edu/in-notes/rfc2026>.
[4] "Key words for use in RFCs to Indicate Requirement Levels",
March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.
[5] "IEEE Std 802.11i/6.0: Specification for Enhanced Security",
September 2003.
Yang (Editor), et al. Expires October 15, 2004 [Page 38]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
[6] "IEEE Std 802.11h: Spectrum and Transmit Power Management
Extensions in the 5 GHz Band in Europe", October 2003.
[7] "IEEE Std 802.1X: Port-based Network Access Control", June 2001.
Authors' Addresses
L. Lily Yang
Intel Corp.
MS JF3 206, 2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: +1 503-264-8813
EMail: lily.l.yang@intel.com
Petros Zerfos
UCLA - Computer Science Department
4403 Boelter Hall
Los Angeles, CA 90095
Phone: +1 310-206-3091
EMail: pzerfos@cs.ucla.edu
Emek Sadot
Avaya
Atidim Technology Park, Building #3
Tel-Aviv 61131
Israel
Phone: +972-3-645-7591
EMail: esadot@avaya.com
Yang (Editor), et al. Expires October 15, 2004 [Page 39]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix A. WLAN Architecture Survey Template
1. Design considerations and requirements: please briefly describe
your design principles for this architecture.
2. WLAN functions supported: Please list the functions supported in
this WLAN briefly, but please do not send us the entire data
sheet. Examples of WLAN functions includes the STA services,
Distributed System Services (as defined by 802.11), radio
resource management and control, AP load balancing, mobility
support, WLAN network wide security functions (including
authentication, encryption for privacy and integrity, etc.) and
any others not listed here but deemed important in your design.
3. The functional architecture to implement the functions described
above: whether it is by Autonomous WLAN Architecture, or
Centralized Architecture. For Centralized Architecture, please
provide the functional mapping of WLAN functions onto the AP and
AC -- with just enough details that help us understand the kinds
of functional interface necessary between the two.
4. The protocol used in between AP and AC.
5. The topological assumptions between AP and AC (is it directly
connected, L2 switched, or L3 routed?) -- this also helps us to
understand the deployment scenarios.
6. Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
7. Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep
the analysis at technical instead of marketing level.
Yang (Editor), et al. Expires October 15, 2004 [Page 40]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix B. Survey Contribution For Architecture 1
(1) Design considerations and requirements:
please briefly describe your design principles for this architecture.
Ease of deployment, flexibility to deploy in any network
architecture, simple, centralized management, secure deployments, and
automation of WLAN configuration, monitoring, and management
functions are the design goals of this architecture.
The system consists of three components, the access point (AP), the
switch or appliance (AC), and the Control System. For the purposes
of the CAPWAP work, the Control System can be ignored.
The AP is "lightweight" in its functionality, compared to traditional
APs. The AP implements the "real-time" portions of the 802.11 over
the air protocol, including RTS/CTS and ACK processing, Beacon
transmission, Probe Response construction and transmission. All
802.11 frames are transferred between the AP and AC in a tunnel. No
frames are bridged locally by the AP. The AP is capable of
presenting multiple WLANs simultaneously, appearing to be an
independent AP for each WLAN.
The AC performs the 802.11 MAC Management functions of authentication
and association. In addition, the AC provides the information to
each AP to configure the operation of each WLAN and to provision the
AP to operate as a cooperating component of a larger WLAN system.
The AC performs the bridging function for all data frames entering
and leaving the WLAN.
(2) WLAN functions supported:
Please list the functions supported in this WLAN briefly, but please
do not send us the entire data sheet. Examples of WLAN functions
includes all the STA services, Distributed System Services (as
defined by 802.11), radio resource management and control, load
balancing, mobility support, WLAN network wide security functions
(including authentication, encryption for privacy and integrity,
etc.) and any others not listed here but deemed important in your
design.
All 802.11 WLAN functions are provided by this vendor's WLAN system.
Station services are provided in part by the AP and in part by the
AC. Distribution services are provided by the AC. Integration
services are also provided by the AC.
a. Beyond those services currently in the 802.11 standard, this WLAN
Yang (Editor), et al. Expires October 15, 2004 [Page 41]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
system provides WLAN-wide coordinated radio resource management,
providing both dynamic channel assignment and transmit power control
in response to local noise and interference measurements at each AP,
as well as incorporating topology information of the APs in the WLAN
system.
b. Rogue detection and containment services are provided, detecting
both rogue APs (those not part of the WLAN system) and ad hoc
networks. Containment (prevention of use) is provided through several
manual and automated methods.
c. Location services are provided, allowing WLAN devices, both rogue
APs or ad hoc clients and authorized mobile devices in the WLAN to be
located to within 3m.
d. Local IPsec VPN termination in the AC is provided in the AC,
including forwarding of mobile device security context to other ACs
as the mobile device roams to APs serviced by those other ACs.
e. Cross-subnet mobility without any software on the mobile device
(such as mobile IP or other special client software) is provided by
the AC.
f. Access control lists are applied to all traffic from each mobile
device by the AC. Access control lists may be configured manually on
the AC or provided dynamically by AAA attributes for individual
users.
g. Dynamic QoS provided via configuration on the AC or from AAA
attributes for individual users.
(3) The functional architecture to implement the functions described
above: whether it is by autonomous AP architecture, or "split"
architecture. For split architecture, please provide the functional
mapping of WLAN functions onto the AP and AC -- with just enough
details that help us understand the kinds of functional interface
necessary between the two.
This architecture uses a "split MAC" architecture. The mapping of
WLAN functions to the AP and AC are as follows:
On the AP:
a. real-time frame exchange over the air (RTS/CTS, Data/ACK),
including retransmission and rate adaptation
b. time critical MAC Management (Beacon, Probe Response)
Yang (Editor), et al. Expires October 15, 2004 [Page 42]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
c. Virtual AP (multiple SSID)
d. power management packet buffering
e. RF monitoring (radar detection, noise measurement, interference
measurement)
f. LWAPP encapsulation/decapsulation of all frames to/from AC
g. L2 encryption
h. L2 QoS
On the AC:
a. LWAPP encapsulation/decapsulation of all frames to/from APs
b. MAC Management processing (authentication, association)
c. 802.1X/EAP processing
d. Bridging between 802.11 and 802.3 (integration services)
e. Configuration of RF parameters for all APs
f. Provisioning of multiple WLANs
g. Load balancing between APs
h. Mobility management between APs and between multiple ACs.
i. L3 encryption (IPsec VPN)
j. Access control lists for mobile devices
k. Location services
l. Proxy ARP
m. DoS detection and prevention
(4) The protocol used in between AP and AC.
LWAPP (draft-calhoun-seamoby-lwapp-03.txt), operating at either L2 or
L3.
(5) The topological assumptions between AP and AC (is it directly
connected, L2 switched, or L3 routed?) -- this also helps us to
Yang (Editor), et al. Expires October 15, 2004 [Page 43]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
understand the deployment scenarios.
There are no assumptions of network topology between AP and AC.
a. APs may be directly connected to an AC,
b. There may be an arbitrary L2 switching infrastructure between the
AP and AC,
c. There may be an arbitrary L3 network between the AP and AC.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
Security threats considered:
a. Interception of control traffic between AP and AC
b. Insertion of control traffic to AP or AC
c. Insertion of unauthorized AP
d. Theft of embedded secrets in APs
e. Access by unauthorized user
f. Masquerade as authorized user
g. DoS threats
h. ARP spoofing
Methods used to address security threats (letter of method
corresponds to same letter of threat, above)
a. All control traffic between AP and AC is encrypted using dynamic
session key negotiated using authenticated DH exchange
b. All control traffic is authenticated in encrypted LWAPP tunnel
c. APs include individual X.509 certificates to validate identity.
AAA authentication may also be used to validate individual APs.
d. There are no secrets in the AP that are in non-volatile memory.
e. Several user authentication methods are supported, including a
local authentication via web login, IPsec VPN, 802.1X, WPA, WPA2.
Yang (Editor), et al. Expires October 15, 2004 [Page 44]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
f. AC maintains address equivalence mappings to prevent masquerade
g. AC detects DoS attacks and provides system-wide black listing of
attacking device.
h. AC provides proxy ARP functions and black lists any device
spoofing ARP replies.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
All problems described in the problem statement are addressed with
this solution. In addition, significant additional functionality is
provided by the centralization of information in the ACs.
Yang (Editor), et al. Expires October 15, 2004 [Page 45]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix C. Survey Contribution For Architecture 2
There is considerable ambiguity in the use of the term AP within and
outside this group. I would like to propose a change in terminology
that the CAPWAP design team should use in the taxonomy draft.
I had sent an earlier email to this group on re-defining the term AP
to mean the set of functions that an access point is expected to
provide as defined in the 802.11 spec. The physical box that
terminates the infrastructure side of the wireless link is referred
to as the wireless termination point (WTP). For implementation
purposes, the set of AP functions MAY be split between the WTP and
the AC.
This document uses the terms "AP" and "WTP" according to the above
definitions.
(1) Design considerations and requirements: please briefly describe
your design principles for this architecture.
Secure, scalable, large-scale WLAN deployments.
The AC was designed to be much more than a manager of physical
Wireless Termination Points (WTPs). All 802.11 data traffic passes
through a stateful, per-user firewall at the AC before it is allowed
to enter the network beyond the AC. The AC offers termination of both
802.11 L2 security and L3 VPNs including configurations that support
simultaneous operation of both L2 and L3 encryption.
The WTPs are meant to terminate the infrastructure side of the
wireless physical link. They are meant to be very intelligent devices
from an RF perspective (monitor the RF environment around them to aid
radio resource management), but are very simple devices with user
state limited to rate adaptation, retransmissions, and power-save
buffering, no security state and no persistent configuration
information.
The connectivity between a WTP and an AC should be very flexible with
support for three modes - directly connected, connected across an L2
cloud, and connected across an L3 cloud.
All configuration is centralized at the AC. The WTPs discover one or
more ACs to home to and, after mutual authentication, setup multiple
tunnels that are routable over an L3 cloud to carry control/
configuration information and 802.11 mgmt/data frames. The control
tunnels are encrypted while the encryption on the tunnels carrying
802.11 traffic can be configured to be encrypted.
Yang (Editor), et al. Expires October 15, 2004 [Page 46]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
All user and security state is maintained at the AC, with the user
state at the WTP limited to rate adaptation, retransmissions, and
power-save management. The access control is based on a model of
assigning roles to users. The mapping of a user into a role is based
on a very flexible set of configuration options. A set of firewall
rules associated to each role, including bandwidth contracts and QoS,
control the traffic flow between a user the network behind the AC.
The ACs provide dynamic radio resource management aided by
measurements at the WTPs.
(2) WLAN functions supported : Please list the functions supported in
this WLAN briefly, but please do not send us the entire data sheet.
Examples of WLAN functions includes the STA services, Distributed
System Services (as defined by 802.11), radio resource management and
control, AP load balancing, mobility support, WLAN network wide
security functions (including authentication, encryption for privacy
and integrity, etc.) and any others not listed here but deemed
important in your design.
All of the AP functions as defined in the 802.11 spec
Load-balancing across WTPs is achieved by exploiting the wider view
of the RF network that an AC has than what is available at the WTP.
Intra-AC handoffs, where a station roams between two WTPs homed to
the same AC, are very quick with a simple table update at the AC.
Inter-AC handoffs requiring inter-VLAN mobility are supported with
proxy mobile IP.
Multiple authentication methods and multiple encryption ciphers (both
L2 and L3).
Flow classification and bandwidth contracts for QoS.
Virtual APs (multiple SSIDs per AP).
Radio resource management functions are handled by the AC based on
measurements at the WTPs.
(3) The functional architecture to implement the functions described
above: whether it is by autonomous AP architecture, or "split"
architecture. For split architecture, please provide the functional
mapping of WLAN functions onto the AP and AC -- with just enough
details that help us understand the kinds of functional interface
necessary between the two.
The set of AP functions is split between the WTP and the AC. All
Yang (Editor), et al. Expires October 15, 2004 [Page 47]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
real-time (RT) functions stay at the WTP, while all non-RT functions
are handled at the AC.
All 802.11 basic media access functions are performed at the WTP. All
802.11 control frames are generated and processed at the WTP.
A majority of 802.11 management frames are processed at the AC.
Beacon frames are generated at the WTP. Power-save management,
retransmissions, and rate adaptation are implemented at the WTP.
802.11 authentication and association frame processing is implemented
at the AC.
Translation of 802.11 data frames to 802.3 frames is implemented at
the AC. All 802.11 data frames are tunneled over to the AC in the
uplink direction while the AC tunnels 802.11 data frames to the WTP
in the downlink direction. Other 802.11 data frame processing
functions like encryption and fragmentation and reassembly are
performed at the AC.
(4) The protocol used in between WTP and AC.
Discovery: An WTP is able to discover one or more ACs to authenticate
with and home to using either static configuration or dynamic,
run-time discovery methods that work across L2/L3 boundaries.
Configuration: Configuration is transported through an encrypted
tunnel back to the AC. This uses a secure and proven architecture
while also allowing for each individual WTP to be accounted for and
monitored at a back-end Radius server. Each WTP can have its own set
of access information to differentiate itself from other WTPs. This
allows the AC to control access on a per WTP basis.
Transport: Tunnels (optionally encrypted) that are capable of
spanning L3 boundaries between an WTP and an AC carry all 802.11
frames. The 802.11 frames are terminated at the AC - so encryption,
fragmentation/reassembly, and 802.11-802.3 translation are moved to
the AC. This also means that if the 802.11 data frames are encrypted
on the air interface, they are encrypted on the tunnel even if the
encryption on the tunnel is not turned on.
(5) The topological assumptions between WTP and AC (is it directly
connected, L2 switched, or L3 routed?) -- this also helps us to
understand the deployment scenarios.
Supports all three of
- directly connected
Yang (Editor), et al. Expires October 15, 2004 [Page 48]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
- L2 connected
- L3 connected
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
Full control of the WTP may be gained through the proprietary
messaging for configuring the WTP. Addressed by encrypting the
tunnel carrying the configuration to protect this information.
If the WTP is stolen, a hacker may be able to extract the security
information required to setup the encrypted tunnel. Addressed by
protecting this security information with additional encryption.
If the WTP is stolen, it would still appear to be possible to connect
to the WTP from another wireless client and gain access to the
network. This is addressed by the stateful user firewall in the same
central location at the AC. The stolen WTP may connect to the AC,
but it will still be unable to pass meaningful traffic through the AC
until the client authenticates itself.
Possible to masquerade as a different user once a particular
authentication has passed through due to having several devices being
involved. Addressed by keeping all encryption and firewalling at the
AC to prevent any type of masquerading.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
Problem #1, #2, and #3 are addressed by keeping all configuration and
dynamic information in one central location. Problem #4 is protected
by an encrypted tunnel created between the WTP and AC. Security
threats discussed in question #6.
Yang (Editor), et al. Expires October 15, 2004 [Page 49]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix D. Survey Contribution For Architecture 3
(1) Design considerations and requirements:
- Secure mobility that scales.
- User based subnet membership independent of AP association.
- No client specific code.
- AP requires no configuration.
- AP is not capable of autonomous function.
- Split MAC (ARCH2).
(2) WLAN functions supported:
- WPA.
- WME.
- AP Load Balancing.
- Inter-subnet Mobility support.
- Multiple Authentication Types: MAC-AUTH, WEB-AUTH, DOT1X. AC speaks
EAP or forwards to RADIUS server.
- Subnet Membership determined through AAA.
- Multiple subnets per SSID.
- Multiple SSIDs/BSSIDs per radio.
- Multiple Encryption types per radio WEP, TKIP, AES(CCMP).
- Rouge AP detection, location and countermeasures.
- Auto or Static RF configuration.
(3) The functional architecture to implement the functions described
above:
- Split MAC (ARCH2).
- AP:
Yang (Editor), et al. Expires October 15, 2004 [Page 50]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
+ Per packet QoS.
+ Encryption.
+ 802.11 Control Frames.
- AC:
+ 802.11 Management.
+ QoS Classification.
+ 802.1x.
+ All Configuration/Management and Image Control.
+ L2 forwarding (could be moved to AP).
(4) The protocol used in between AP and AC.
- IP tunnels.
(5) The topological assumptions between AP and AC (is it directly
connected, L2 switched, or L3 routed?)
- All of the above.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
- PTK/GTK transmitted between the AC and AP and must be encrypted.
- 802.11 station data is transmitted between the AC and AP and may be
encrypted.
- AP authentication. AP is authenticated by the AC. It is not
required that the AC is authenticated by the AP as it would violate
the zero configuration requirement. An unauthenticated AC reduces to
a rogue AP and there are other techniques to deal with that.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement.
- Cons:
+ Assumes the AC is in a trusted network.
- Pros:
+ Scaling configuration and management.
+ Fast roaming.
+ Encryption processing is distributed to APs but centrally
controlled.
+ Zero configuration AP - a lost or stolen AP has no sensitive
information.
Yang (Editor), et al. Expires October 15, 2004 [Page 51]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
+ Extends wired subnet partitioning to wireless network based on
user not location.
Yang (Editor), et al. Expires October 15, 2004 [Page 52]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix E. Survey Contribution For Architecture 4
(1) Design Considerations and Requirements
The following is a short list of our major technical requirements
that were used to drive the design of products in this architecture:
Full functionality and compatibility for current and future 802.11
standards
Keep the set of functions in the AR to the absolute minimum while
pushing as much functionality up to the AC.
Allow existing, installed Access Points (APs) to be converted into
an AR with a simple firmware change. This allows many new
functions to be added to legacy infrastructures since most of the
new functionality is in the AC.
Ensure the system provides as much security as the Access Point
Model
Provide a platform for "mobility" and other added value functions
(2) WLAN Functions Supported
All current 802.11 standards (a,b,e,i,g,....)
Multiple BSS/ESS operation on both the AC and AR
802.1p/q support
Enhanced QoS services
Support for enhanced WLAN functions to support
Fast Roaming / Fast Handoff
Voice over IP support
Enhanced Power Management for Clients
Load Balancing and other Mobility Features
(3) Functional Architecture
The basic operation is as follows: System operation begins with the
boot and adoption process. The AR contains only a small boot loader
that does not include any RF code and must downloaded with runtime
code from the AC. Once the code is downloaded from the AC into the
AR, the AR is configured with the runtime parameters by the AC. This
involves some initial packets that contain channel, power,
addressing, number of supported BSSs, beacon times, etc.. It also
involves an ongoing process that updates the AR with beacon
information, such as the content of the TIM field as well as load
information. Hence configuration is both a one-time event and a
continuing event. Once the AR is configured it is ready to begin
beaconing and respond to packets from MUs. Fully formatted 802.11
packets are encapsulated and sent over the L2 network from the AC to
the AR for transmission. Each packet sent by the AC to the AR
generates a status result back to the AC from the AR. Sequence
numbers are used to ensure delivery. Packets received by the AR from
the radio(s) are encapsulated and forwarded over the L2 network to
Yang (Editor), et al. Expires October 15, 2004 [Page 53]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
the AC. A key concept is that the ARs are stateless insofar as Mobile
Units (MUs) are concerned. The AR really does not know about Mobile
Units. If a packet is addressed to the AR, it will accept it,
generate an acknowledgement packet, and then forward the packet to
the AC in an encapsulated Ethernet frame of an EtherType allocated to
this vendor.
The functions performed by the AR once it is loaded, configured, and
running consist of:
Basic RF packet transmit tasks such as: Preamble selection, PHY
interface, Packet CRC, and Sequence number generation
RF Packet reliability mechanisms such as: Retransmission timers,
retries, ACK packets and reception
RF Channel Access and exchange timings (SIFS, etc.). This includes
RF QoS queuing
RF Packet reception including: checking PLCP headers, address
filtering, basic address checking, and packet CRC checking
Generation of Beacons and DTIM broadcast packet transmission
Handling of Probe/probe response and RTS/CTS sequences
Interface to the wired network.
Status reporting to the AC including per packet results and as
well as global counters
Packet Buffering for immediate RF transmit scheduling purposes
The functions performed by the AC include:
Association and authentication
Key management, key mixing, etc.
Packet format conversion between 802.11 and 802.3
Encryption/MIC using multiple algorithms WEP, WPA, AES, etc..
Packet/user level buffering and QoS scheduling
Address filtering (collecting packets off the wired/wireless
network for Mobile Units)
802.1 p/q mapping to 802.11 priority classes
Support for QoS mechanisms
Communication between different ACs
Management and configuration utilities like Telnet, HTML, SNMP,
etc.
(4/5) Topological Assumptions/encapsulation protocol
This implementation currently uses an L2 protocol in an EtherType
frame allocated to this vendor. This allows the AR and the AC to
either be directly connected or connected via one or more L2
switches. Since this AC supports multiple VLANs, the ARs may be on
one or more different VLANs and these VLANs may be different than
those upon which the Mobile Units logically reside.
We chose the L2 operation as the best model for AC and AR
Yang (Editor), et al. Expires October 15, 2004 [Page 54]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
connectivity for several reasons.
The first is that it is consistent with the goal of keeping the AR as
simple as possible. The AR does not require an IP address, subnet
mask, or default gateway nor does it need DHCP, SNMP, ICMP, UDP,
etc.. In addition, there is no need to pre-configure the AR prior to
installation. The AR is truly a zero configuration device. The
configuration of the AR takes place entirely at load time. If the AR
had to support additional networking protocols the AR would have to
become much like a regular "fat" Access Point and most of the
management advantages of the AR/AC model are seriously diluted.
The second reason is that current Access Points are L2 devices. Since
the AC/AR model represents a different partitioning of access point
functionality, it seemed reasonable that the combined AC/AR should
also be L2 device.
The third reason is that L2 operation is more secure than L3
operation. More discussion of this issue follows in section 6.
(6) Security Threat Analysis
The security concerns with a split architecture can be divided into
two general areas: User data security and system management security.
User data security is concerned with both unauthorized access to the
wired network as well as privacy of the user data. Both are
automatically taken care of in our model since the user data from MUs
remains encrypted using the "over the air" security mechanisms used
by 802.11. The AR-AC is essentially treated as another RF "hop" and
hence is as secure as the AR-MU link. In addition all 802.11 packets
are encapsulated in Ethernet frames and are addressed only to either
the AR or the AC. Such packets cannot "escape" onto or from the
wired network since they are always inside properly addressed
Ethernet packets. Given these two mechanisms, nothing else is
required to ensure both secure network access and user privacy.
System management security is essentially concerned with "hijacking"
of the AR by "a rogue AC." The worry here is that another station on
the network may pretend to be the AC and take control of the AR. If
this happens the AR may be mis-configured or taken control of
entirely to become part of a virtual "rogue" AP.
In this architecture system management attacks are unlikely to take
place and can be easily detected. Given the communication between the
AR and AC takes place at L2, any attacker would need to be on the
same subnet (or VLAN) as the AR and AC. This implies the user already
has physical access to the network and so the network is already
Yang (Editor), et al. Expires October 15, 2004 [Page 55]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
compromised. Attacking an AR when one already has physical access to
the network is pointless.
Should an attacker still try to mis-configure a working AR by
pretending to be the actual AC, it must send a packet with the same
source address as the actual AC since the AR verifies the source
address of all frames it receives. If this occurred the L2 switch
would reconfigure itself to direct all traffic for the actual AC to
the rogue AC and essentially isolate the actual AC. That AC would
quickly detect this and notify an administrator as well as shut down
the WLAN.
Boot time attacks will also be detected by the actual AC since it
will see the boot request and also respond to the AR.
It should be noted that a rogue AR and rogue AC do not present any
threat to Mobile Units provided the Mobile Units follow the proper
standards for mutual authentication. From a Mobile Unit perspective
a rogue AP/AC combination is equivalent to a rogue Access Point.
Hence our split network model introduces no new security issues over
a conventional Access Point model and in fact offers greater
security.
(7) Pros and Cons of Architecture
Overall we are quite satisfied with our current architecture. The
basic model has been implemented on a number of AR and AC devices
without any problems. We have also successfully upgraded old 802.11
Access Points to support the latest encryption protocols like WPA and
AES.
There are of course areas of enhancement. One is the location of the
transmit side of the encryption process. Some of our current ARs are
built with chips that did not support all desired encryption
algorithms but going forward the chips we use to build future ARs
will likely include such functionality. It would be nice to be able
to take advantage of this capability on new ARs while also supporting
the older ARs.
Yang (Editor), et al. Expires October 15, 2004 [Page 56]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix F. Survey Contribution For Architecture 5
Abstract
This document describes an architecture for residential WLAN
deployments. It presents simple equipment for consumers while
complexity and overall network management are left to service
providers. Additionally, it also integrates radio-over-fiber (RoF)
technology to provide network services to common areas outside
individual residences.
1. Introduction
This architecture includes a set-top box (STB) at the consumer's
residence, a radio-over-fiber (RoF) antenna in common areas around a
number of residences and a controller at the service provider's
premises. The STB wirelessly streams data and media content to other
products like TVs and display consoles. It is also capable of PHY
layer and partial MAC layer processing for wireless transmissions to
other client devices. An antenna structure outside individual
residences provides network access to common areas. This is in
conjunction with the service provider's controller by means of
radio-over-fiber transmissions.
This document describes the Broadnow+ WLAN architecture with respect
to the needs of the CAPWAP Architecture Taxonomy document.
2. Design Considerations and Requirements
Broadnow+ is based on a high-speed, dedicated backbone between STBs,
RoF antennas and the central controller. This allows for flexibility
in the physical location of various processing requirements.
The central controller realizes complete IEEE802.11 functionality
including PHY layer aspects. It then performs selective degrees of
processing for different destinations, i.e., for STBs, RoF antennas,
and other devices. The controller is also responsible for overall
network management including client authentication and channel
adaption.
STBs process IEEE802.11 PHY layer functionality and IEEE802.11 MAC
layer association services for all transmissions. In addition, they
implement proprietary MAC functionality for transmissions to other
devices of this vendor like TVs. These functions are designed
primarily for transmitting media to high-resolution displays. For
transmissions to other client devices however, the STBs only perform
IEEE802.11 PHY and IEEE802.11 MAC association services. The remaining
IEEE802.11 MAC services are left to the central controller. .
Yang (Editor), et al. Expires October 15, 2004 [Page 57]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
The antenna used for radio-over-fiber transmission is a very simple
device. It merely performs optical to electrical conversions and
transmits the resulting radio signals. This places the need for
high-speed, fiber connectivity between the antenna and controller. As
such, this requirement is being increasingly met in the residential
market place..
Mobility concerns in the residential environment are present albeit
slightly. It is highly unlikely that clients will roam to neighboring
residences for network access. As such, this is not dealt with in
great detail in the Broadnow+ architecture. However, it is necessary
to ensure that rogue clients do not take advantage of legitimate
customers by exploiting their subscriptions. Appropriate
authentication mechanisms between client devices and the controller
are used to avoid this.
3. WLAN Functions Supported
The controller is a powerful device capable of processing complete
IEEE802.11 functionality which are then selectively performed for
STBs and radio-over-fiber transmissions. It includes support for QoS,
security and control. The various functionalities are realized as a
combination of individual components of fine granularity. Such an
implementation ensures that the controller can accurately provide
complementary functions to the end-devices. Algorithms and procedures
for transmit power control, channel selection and interference
management are performed at the controller and the resulting control
signals are forwarded to the STBs and antennas. In terms of security,
the controller terminates MAC layer encryption for both proprietary
and other end-devices of the STBs.
Authentication requirements in the residential environment are as
stringent as those in enterprises. It is important that rogue clients
do not take advantage of legitimate consumers, i.e., no free riders.
As such, authentication is performed at the controller for all
clients accessing the STBs and RoF antennas.
The STBs include full fledged capabilities (MAC + PHY) for
transferring content to products such as TVs and display consoles.
However, they feature only light weight wireless capabilities for
transmissions to other client devices, leaving the bulk of operations
to the controller. Overall the STBs are capable of channel
measurements, feedback to the controller, transmit power adjustments
etc. In general the STBs are able to process IEEE802.11 PHY and
IEEE802.11 MAC association services. They also include proprietary
MAC aspects for transmissions to other devices from this vendor.
4. Functional Architecture
Yang (Editor), et al. Expires October 15, 2004 [Page 58]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
The STBs combine two different WLAN functional architectures for the
transmissions to proprietary and other clients, respectively. For
proprietary clients, the architecture consists of IEEE802.11 PHY and
IEEE802.11 MAC association services. The remaining MAC
functionalities are proprietary. For other clients, STBs only process
IEEE802.11 PHY IEEE802.11 MAC association services, leaving the
remaining IEEE802.11 MAC operations to the controller. For both types
of transmissions, control aspects are handled by the controller based
on feedback sent by the STBs.
In addition to these two functional architectures, Broadnow+ also
includes radio-over-fiber capabilities. As such, the end-device is a
simple antenna capable of making optical to electrical conversions
and broadcasting the resulting radio signals. The RoF antenna also
includes logic to sense channel conditions and to send this back to
the controller for analysis and further action.
The controller, at a central location, accommodates these three
functional architectures. It includes the complete WLAN functionality
based on IEEE802.11 standards. For transmissions to proprietary
clients, it merely acts as authenticator and channel manager. For
other clients, it processes the remaining IEEE802.11 MAC
functionality after having the STBs process IEEE802.11 MAC
association and IEEE802.11 PHY services. And for RoF transmissions,
the controller performs complete IEEE802.11 MAC and PHY processing
before making the electrical to optical conversions. In all three
cases, the controller is responsible for overall control and
management.
Based on these descriptions, the degree of wireless functional
implementation in this architecture is different for the type of end-
devices. In terms of CAPWAP, these constitute three different types
of functional architectures/splits.
5. AP-AC Protocol
This is a proprietary protocol.
6. Topological Assumptions
The connection between the controller and STBs is high-speed and
dedicated. This includes coax, ADSL and fiber. As such, the topology
is that of direct connection.
7. Security Threat Analysis
When fiber is used for the dedicated connections, it allows for
strong physical security. In addition to this, Broadnow+ incorporates
Yang (Editor), et al. Expires October 15, 2004 [Page 59]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
cryptographic security for exchanges between the controller and STBs.
The STBs are hard-coded with a seed with which session keys are
generated. These keys are then used to encrypt transmissions between
the controller and STBs. The cryptography mechanism also uses SD card
based seeds for session key generation. So in addition to strong
physical security, the architecture also includes another level of
cryptographic security.
8. Architectural Analysis
The primary advantage of implementing WLAN functionality in
fine-grained components is to allow flexibility in the functional
architecture. For now, this allows for the distinction of
transmissions to proprietary and other clients. Additionally, it
provides for integral management from the Broadnow+ controller.
Broadnow+'s relatively light implementation for transmissions to
other devices leads to lower costs for STBs. For the service
provider, this architecture allows a management premium to be levied.
As such, this architecture for wireless media content and data
delivery offers increased benefits for both consumers and service
providers.
9. Conclusion
This document has presented an architecture for residential WLANs. It
combines wireless transmission functionality to proprietary and other
client devices. For proprietary devices, STBs use standard IEEE802.11
PHY and IEEE802.11 MAC association services in addition to a
proprietary MAC, optimized primarily for transmissions to proprietary
TVs and display consoles. For other devices, the STBs adopt a split
where IEEE802.11 PHY and IEEE802.11 MAC association services are
handled locally while the remaining IEEE802.11 MAC services are left
to the controller. And for radio-over-fiber transmissions, Broadnow+
consolidates all IEEE802.11 processing at the controller without
using any split. The secure, low-latency connection between the
controller, STBs and RoF antennas blur any distinction in WLAN
functionality based on real-time requirements.
Yang (Editor), et al. Expires October 15, 2004 [Page 60]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix G. Survey Contribution For Architecture 6
(1) Design considerations and requirements:
This Wireless Switch Architecture consists of Thin APs and
Controllers. It has been designed with the following considerations:
- Thin APs should be cheap. This leads to a requirement that the thin
AP be as simple as possible, with very low flash and ram
requirements.
- There will be many Thin APs in the network, so to reduce
installation and maintenance cost they should require zero
configuration. This leads to a requirement that configuration be
served from the Controller or some other entity, and that some method
for auto-discovery must exist where possible. In addition
configuration of the RF parameters should be automatic.
- The widely physically distributed nature of Thin APs leads to a
frequent requirement that thin APs may be used in physically insecure
environments. This leads to a requirement that user data not be
encrypted/unencrypted on the thin AP but rather at the Controller.
This allows the network's trust boundary to be placed at a physically
secure location. In addition this allows novel new deployment
scenarios - such as placing an AP in tele-commuters home without any
VPN setup.
- Thin APs and controllers should be deployable as simply as possible
on top of the current legacy network infrastructure. This leads to a
requirement that all communications be at Layer 3 rather than Layer 2
or direct. In addition the use of a VLAN aware infrastructure is
precluded, and some method of cross-subnet discovery must be
specified.
- Rogue APs should not pose a security problem. This leads to a
requirement that rogue APs be remotely detectable by Thin APs, and
that Rogue APs may be remotely investigated and secured by Thin APs.
- Wireless clients should be able to roam seamlessly between thin
APs. This leads to a requirement that wireless clients retain their
IP addresses, which in turn leads to a requirement that something
equivalent to Mobile IP be used in large scale deployments.
- Redundancy and load sharing. Both Thin APs and Controllers should
be configured in redundant and load balanced configurations to
provide maximum uptime and throughput.
- Theft of thin APs should not pose a security problem. This leads to
Yang (Editor), et al. Expires October 15, 2004 [Page 61]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
a requirement that thin APs should have no encryption keys in
non-volatile memory. In addition since thin APs cannot work as
standalone APs they are less likely to be stolen individually.
(2) WLAN functions supported:
****All functions are supported:
- Wireless client association and authentication
- Radio Resource Management and Control
- Load balancing of wireless clients between thin APs
- Load balancing of thin APs across Controllers
- EAP user authentication
- WEP, WPA and IEEE 802.11i encryption, including TKIP and AES-
CCM for wireless frames
- Seamless wireless client roaming between thin APs
- DS services via the thin AP Controllers
- Detection of authorized APs
- Authentication and encryption of all control traffic between APs
and Controllers
(3) Functional Architecture
****The architecture uses a split MAC, with the thin APs and
Controllers communicating over a Layer 3 cloud.
Only the most timing sensitive functions are performed at the Thin
APs - All PHY layer functions, and these parts of the MAC -
transmission and reception of MPDUs, CRC generation and checking, ACK
generation, NAV, retries and the EDCA, priority queuing. TSF (Beacon
and Probe response timestamp insertion). Multicast Power-save frame
delivery. Raw MPDUs as seen on the wireless medium are exchanged with
the controller encapsulated within UDP. Note - these MPDUs are not
decrypted at the Thin AP and so any user data remains protected by
whatever encryption mechanism is in use over the wireless network.
The Controller can also act as a Mobile IP proxy on behalf of the
wireless client (according to configuration). This allows seamless
Yang (Editor), et al. Expires October 15, 2004 [Page 62]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
roaming across thin APs connected to different controllers.
(4) The protocol used in between AP and AC.
****Each thin AP has one master controller and may have many backup
Controllers. These are discovered during Boot and Discovery. On boot,
the thin AP uses DHCP or static configuration to get its IP address
and DNS server addresses. We specify 4 methods for discovering the IP
address of the master Controller: DHCP, DNS, local subnet discovery
and manual configuration. Once the master Controller is detected, the
thin AP downloads a signed firmware image by TFTP.
From then on Control messages are exchanged using SSL. A set of
control messages has been defined using an ASCII format.
User data is covered in (3) above.
(5) The topological assumptions between AP and AC (is it directly
connected, L2 switched, or L3 routed?) -- this also helps us to
understand the deployment scenarios.
****L3 routed. This allows us to deploy one or more controllers
anywhere on the user's LAN and the thin APs to be on distant subnets.
The only limitation is the capabilities of the user's LAN and LAN
switches: if the APs are too far from the controllers then traffic
will be crossing multiple switches which is inefficient. In addition
any broadcast traffic destined to the wireless network may have to be
multicast across many subnets.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
Our security architecture significantly reduces security threats - by
moving the trust boundary to the Controller - which may be placed in
a physically secure location, and protected by firewalls. In
traditional 'fat AP' architectures anyone with access to the network
behind the 'fat APs' may inspect or tamper with traffic. In our
architecture since the raw 802.11 frames that are seen over the air
are transported to the controller this threat is significantly
reduced. These frames are protected by whatever wireless security
policy and mechanism has been selected. Our controllers implement WPA
and 802.11e to provide a high level of security.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
**** We address all 4 problems:
Yang (Editor), et al. Expires October 15, 2004 [Page 63]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
- Management and Control: The Controllers serve firmware and
configuration to the thin APs and the thin APs require zero manual
configuration, so the only entities that need to be managed are the
Controllers themselves.
- Configuration Consistency: Since the Controllers automatically
control configuration across all thin APs, configuration consistency
is maintained across the entire WLAN deployment
- RRM to optimize WLAN efficiency: Again, since the Controllers see
all 802.11 MAC traffic they know the instantaneous load on each thin
AP, and can perform load balancing.
- Unauthorized APs: Controllers are aware of any Unauthorized APs and
can detect and prevent their use.
Yang (Editor), et al. Expires October 15, 2004 [Page 64]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix H. Survey Contribution For Architecture 7
(1) Design considerations and requirements:
Goal: Offer an easy-to-use solution for large installations of APs in
terms of provisioning, controlling, scalability, plug&play, and
mobility across subnets/vlans.
In a nutshell, the 802.11 protocol suite terminate at the AP, which
translates 802.11 data frames to 802.3 frames and send them to the
AC. All STA traffic hit the AC. AC provision and control AP. WLAN
"control" capabilities are embedded at the AC.
(2) WLAN functions supported:
All 802.11 services are supported:
AP responsibilities:
- 802.11 MAC
- WEP/WPA Encryption/Decryption
AC responsibilities:
- STA services (authentication, association, etc.)
- Integration
- Distribution
- Load Balancing
- Rogue AP detection
- Managing and controlling APs
- Mobility
- ACL/QoS policies.
(4) The protocol used in between AP and AC.
The AC and the APs communicate using a proprietary UDP transport,
which is encrypted.
(5) The topological assumptions between AP and AC
Yang (Editor), et al. Expires October 15, 2004 [Page 65]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
At present only direct connection is supported. The next step would
be to support connections across layer 2 and 3.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture,and how that are addressed.
Several aspects of security threats were addressed:
STA traffic Over the Air - AP responsibility (WEP, WPA, etc')
AC to AP control/provision - communication is authenticated and
encrypted over a private UDP communication channel.
AC to AC - Authentication and encryption over private UDP
communication channel.
AC to AAA - Standard.
AC to Management station - Security over standard management tool
such as SSH.
(7) Pros and Cons of this architecture
Problem 1: Each AP is an IP-addressable device requiring management,
monitoring, and control - AC serves as a proxy for managing large
scale APs.
Problem 2: Maintaining a consistent configuration throughout the
entire set of access points in the WLAN - Central management
application to configure all AC in a wireless domain.
Problem 3: Parameters controlling the wireless medium on each AP must
be monitored frequently ... - partially supported, ACs monitoring
connected APs to provide information to central management station.
Problem 4: Securing access to the network and preventing installation
of unauthorized access points & Mutual authentication of AC and AP.
Supplementary functionality in the shape of Rogue AP detection.
Yang (Editor), et al. Expires October 15, 2004 [Page 66]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix I. Survey Contribution For Architecture 8
(1) Design considerations and requirements:
The operational and network management challenges for large scale
(thousands of APs) wireless LANs encompass both the 802.11 layer as
well as the wired side topological interactions. The considerations
and requirements for the architecture presented below are:
- true layer 3 mobility for wireless mobile clients as they move from
one AP to another
- WLAN system scalability - A single AC should be able to control and
manage a large number of APs (100's of APs)
- near real time RF management
- centralized traffic policy management and enforcement
- centralized control and management of the APs
- centralized user management
- architecture must be extensible to other radio technologies
- architecture must be able to facilitate mobility between different
MAC architectures (e.g.,. work being done in IEEE 802.21 and IRTF
MOBOPTS)
Also, because of the requirement for the deployment of very large
scale WLANs and the fact that these WLANs must integrate into
existing wired infrastructures, there should be no consideration (or
full flexibility) on the topological deployment of ACs and APs.
(2) WLAN functions supported:
Access Point:
- All 802.11 services including
- association/disassociation/reassociation
- authentication
- integration
- distribution
- Robust Security (802.11i)
- QOS (802.11e)
- radio resource management including load balancing and RF
management
- bridging (802.11 to 802.3)
Yang (Editor), et al. Expires October 15, 2004 [Page 67]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
- link state transition notification to the AC(s)
Access Controller:
- centralized forwarding (routing), authentication, encryption and
policy enforcement of mobile client traffic
- control and configuration of AP
- QOS policy enforcement and management
- user access control
(3) Functional architecture:
- AC manages and controls APs
- L3 state and user sessions are maintained and managed at the AC
- L2 state and user sessions maintained at the AP and all state
information is mirrored at the AC
- The 802.11 MAC is "not" split. However, it is controlled
centrally at the AC
(4) The protocol used in between AP and AC:
A UDP based tunnelling protocol that has a control channel and a data
channel. The control channel carries AP configuration and state
commands from the AC. Also, it carries information regarding AP
state transitions and statistics from the AP to the AC. The data path
is simply the encapsulation of 802.3 bridged data. The data-path
channel is optional. IE., if configured, the data path can be bridged
locally from the AP and the data does not necessarily have to go
through the AC.
(5) The topological assumptions between AP and AC:
The AC and AP can be directly connected to each other, could be
connected through L2 switches or any arbitrary L3 cloud. The
architecture is tolerant to higher latency between AP and AC.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how those are addressed.
Since the AP and AC can be separated over any arbitrary L3 cloud,
first and foremost there is a need for a secure binding between the
AC and AP. A control channel security association is required
between the AC and AP. The AC and AP must go through a mutual
authentication phase during a discovery and registration process and
form a security association. The traffic is confined to control,
configuration and management traffic between the AC and AP.
There is an optional data path security association that can also be
created. It is believed that for security sensitive applications and
deployments there will always be an end to end encrypted tunnel.
Yang (Editor), et al. Expires October 15, 2004 [Page 68]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Therefore, a data path encryption mechanism is considered optional
and configurable based on security policy.
STA authentication and security policy enforcement is done centrally
in the AC.
Over the air privacy and authentication between the STAs and APs is
accomplished by standard 802.11 privacy methods. The RSN service is
the recommended method for over the air privacy and authentication.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
Pros:
- In this centralized architecture, the AC and AP can be separated by
an arbitrary L3 cloud which in turn enables large geographic
distribution of APs within the cloud.
- This architecture is agnostic to the underlying wired medium
connecting the AP and AC.
- This architecture is agnostic to the AP MAC and radio technology.
- Since the MAC is not split, this architecture supports a deployment
where the data path is not required to travel through the AC. This
may be useful in the "branch office" scenario where the AC may reside
in a data center and the AP connects to it over a slow WAN link.
However, the operational control and management of the AP is done by
the AC.
- The problems defined in draft-ietf-capwap-problem-statement-00.txt
are also addressed by this architecture.
Yang (Editor), et al. Expires October 15, 2004 [Page 69]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix J. Survey Contribution For Architecture 9
(1) Design considerations and requirements: please briefly describe
your design principles for this architecture.
The goals are
1. Simplify WLAN life-cycle management - including design,
deployment, and management.
2. Similar user experience on WLAN and Ethernet - WLAN should provide
same level of networking services as Ethernet. User should feel no
difference when running application on wired V.S. wireless network.
Also, network administrators should be able to manage WLAN the same
way as managing wired network.
In this architecture, AC performs WLAN configuration, monitoring, and
policy management function. It controls and manages APs. AC also
collects information from APs and, based on configuration, push down
policies into individual APs. It also serves as proxy for interacting
with all external networking components(e.g. RADIUS server).
AP implement all the 802.11 access point function, including all the
PLME, MLME, STA services, DS, and bridging functions.
(2) WLAN functions supported:
Please list the functions supported in this WLAN briefly, but please
do not send us the entire data sheet. Examples of WLAN functions
includes all the STA services, Distributed System Services (as
defined by 802.11), radio resource management and control, load
balancing, mobility support, WLAN network wide security functions
(including authentication, encryption for privacy and integrity,
etc.) and any others not listed here but deemed important in your
design.
All 802.11 AP functions are provided. That includes
1. Distribution System Services.
2. Radio resources management - channel selection, interference
detection and avoidance, cell-size control.
3. Load balancing.
4. Security.
5. Power save mode.
Yang (Editor), et al. Expires October 15, 2004 [Page 70]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
6. QoS.
7. Station services.
8. Bridging.
Besides the list above, this WLAN system provides the following
functions:
1. Rogue AP/Ad-hoc network detection and containment.
2. Location based authentication control.
3. Dynamic VLAN assignment based on authentication ID.
4. QoS
5. ACL
6. L2/L3.
7. Multiple VLAN per radio.
8. Multiple SSID per AP.
9. Dynamic 802.1p/q tag assignment based on user/location/
application.
(3) The functional architecture to implement the functions described
above: whether it is by autonomous AP architecture, or "split"
architecture. For split architecture, please provide the functional
mapping of WLAN functions onto the AP and AC -- with just enough
details that help us understand the kinds of functional interface
necessary between the two.
This WLAN system is a split architecture system.
AC includes the following functions:
1. Configuration interface.
2. Management.
3. Policy control.
4. L2/L3.
5. Proxy RADIUS.
Yang (Editor), et al. Expires October 15, 2004 [Page 71]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
6. ACL.
7. AP/AC image and configuration management.
8. RF monitoring - correlation between APs.
AP includes the following functions:
1. 802.11 MAC.
2. Multiple SSID
3. Power management.
4. RF monitoring - data collection.
5. 802.11 security - including WEP and 802.11i draft.
6. Integration service.
7. Location service.
(4) The protocol used in between AP and AC.
The following standard protocols are used:
1. Agent-X : control and management.
2. LLDP/EDP(Proprietary discovery protocol) : AP/AC discovery.
3. TFTP : image transfer from AC to AP.
(5) The topological assumptions between AP and AC (is it directly
connected, L2 switched, or L3 routed?) -- this also helps us to
understand the deployment scenarios.
The system supports L1(direct connect), L2, and L3 connection between
AP and AC.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
1. AP does not store runtime image and configuration. Both are pushed
down from AC. AC takes full control over AP.
2. Control traffic between AP and AC can be encrypted using SSL.
3. AP can be authenticated based on identity, that includes MAC, IP,
Yang (Editor), et al. Expires October 15, 2004 [Page 72]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
serial number, or digital certificate. AC can be authenticated via
X509 certificate.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
Instead of managing APs, this architecture allows user to deploy,
control, and manage wireless networks. With distributed data
forwarding, it maintains the scalability of the autonomous AP
architecture. It also provides same networking services between
Ethernet and Wireless network in Layer 2, Layer 3, and beyond.
Yang (Editor), et al. Expires October 15, 2004 [Page 73]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix K. Survey Contribution For Architecture 10
(1) Design considerations and requirements:
- Access Controller manages one or more Access Points. Access
Controllers control and provision the various access points.
- Access Controller and Access Points can reside in physically
separated regions (across buildings/oceans).
- Access Controller and Access Points communicate over a Secure
Channel and provide facility for mutual authentication.
- Roaming among Access Points within the domain of one Access
Controller is possible without any new protocol support. All state
information is maintained in Access Controller.
- Bridging within a given SSID. Routing among different SSIDs.
- If 802.1x/WEP security is employed, it is between wireless stations
and AP. But AC maintains the keys.
- AC supports L2TPoIPSEC, if one wants security between end station
to the Corporate network.
- Two sessions are maintained between AP and AC, which can be secured
using IPsec. TCP based session is used to transfer control
information such as provisioning of APs, events from APs. UDP
session is used to transfer the data.
(2) WLAN functions supported:
- Radio Resource Management: Access Controllers can configure Access
Points using the Control Channel. A Request-Response Protocol is used
on the control channel.
- DSS: The Access Point shall handle traffic between all stations
associated with it. For traffic that is targeted to another AP, the
traffic shall be sent to the Access Controller. The Access Controller
shall bridge the traffic appropriately, across the appropriate
bridge/bridge port.
- 802.1x Functionality: Access Points shall encapsulate 802.1x frames
to EAPOL frames and transmit to Access Controller. Access Controller
is responsible for initiating Radius Authentication.
- WEP Encryption/Decryption of data: Access Points shall handle
encryption/decryption of data. The Access Controller will maintain
Yang (Editor), et al. Expires October 15, 2004 [Page 74]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
and program the keys in AP.
- Handle Roaming Clients: Access Point shall send events of
Association/Dis-association/Re-association to Access Controller
through Control Channel. Access Controller maintains session key
information for every wireless access point association (802.1x),
Hence when a roaming client moves from one AP to another AP, the
Access Controller can push the session key information to the Access
Point through the Control Channel.
(3) The functional architecture to implement the functions described
above:
- Handled in AP: All Radio Functionality/WEP Encryption and
Decryption; Traffic between Wireless Stations in the same BSS.
- Handled in AC: Routing/Bridging to another BSS; Maintaining Session
Keys for each wireless station (to support roaming), initiating
Radius Authentication.
- The Control Channel can be used to configure any parameter or read
any MIB from the Access Point.
(4) The protocol used in between AP and AC.
- Control Channel: TCP Transport can be used for Control Frames. The
Access Point establishes a TCP session with the Access Controller
when it comes up. When the TCP connection is established the AC and
AP authenticate each other. Upon successful authentication the Access
Controller assigns a Unique ID for the AP.
The control channel shall be used to exchange control information
between AC and AP. Control Information is inclusive of image update,
provisioning, reset, radio management and any MIBs that may be sent
by Access Point to Access Controller. The AP shall send all 802.1x
packets from End Wireless Station as EAPOL Packets through the
Control Channel. The AC shall send the 802.1x responses as EAPOL
Packets to the AP through the Control Channel. In addition AC can use
the control channel to push session keys.
The Access Point shall establish as many control channels as the
number of radios it supports. For each control channel it
establishes, the Access Controller shall assign a unique ID. This ID
will be used in data channel communication between AC and AP.
The communication between AP and AC shall be in the form of command
and Response. The AC or AP shall send a command and the recipient of
the command shall issue a response. This approach can be extended to
Yang (Editor), et al. Expires October 15, 2004 [Page 75]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
any kind of deployment. (Dumb AP or fully functional AP).
- Data Channel: The Data Frames can be transmitted using Mac Over UDP
Encapsulation Mechanism. The MAC frames are encapsulated with UDP/IP
headers at the transmitting end and de-capsulated at the receiving
end.
(5) The topological assumptions between AP and AC: L3 Routed
(6) Security threat analysis: The AC and AP can mutually authenticate
themselves through the control channel.
Both Control and Data Channels are over Transport Layer. This enables
the possible usage of IPsec, hence provides a secure channel for
communication.
Wireless Stations to AP communication can be secure through existing
mechanisms such as 802.1x
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
- The Control Channel provides a flexible/extensible method to
support any type of Access Point; i.e. doing management at the Access
Point itself and/or controlling the management from the Access
Controller. Hence it can address different market segments.
- The control channel on TCP allows for easy adoption of IPsec and
hence addresses the security issues over an otherwise insecure
channel.
Yang (Editor), et al. Expires October 15, 2004 [Page 76]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix L. Survey Contribution For Architecture 11
(1) Design considerations and requirements: please briefly describe
your design principles for this architecture.
DIRAC is designed to enable efficient implementation of many emerging
wireless services implemented on the access router. These services
will be highly adaptive along the following three dimensions:
a) adaptation to wireless channel dynamics: several services (e.g.,
schedulers) require knowledge on the channel dynamics (current rate,
error pattern) and link quality perceived by each mobile host.
b) adaptation to host mobility: information on host mobility from one
cell to a neighboring one is required by micro-mobility management
protocols (e.g., Fast Handovers)
c) coordinated adaptation across multiple cells: applications such as
VoIP, admission control, fast handoffs require coordination among
multiple cells and resource management.
DIRAC also enables coordination spanning multiple layers in the
protocol stack, and across multiple geographically adjacent cells. In
the PHY layer, RF management and collaborative power control over
multiple neighboring cells can minimize interferences, load balancing
and MAC filtering in the link-layer can increase performance and
security, while fast handover at the network-layer can minimize
transient packet loss. Instead of designing fully distributed
coordination protocols, a centralized router assisted by router
agents can serve this purpose, while simplifying the design approach
and minimizing management overhead at the same time.
Another design consideration for DIRAC is the separation of protocols
among the physical entities of the network. DIRAC adopts a generic
design at the access router, while leaving technology-specific
functions to the router agent at the AP. This decision leads to a
lean design, non-intrusive to the IP protocol, and readily extensible
to other wireless network access technologies such as Bluetooth, 3G/
4G, 802.11n. Specifically, the access router remains unaware of the
specifics of the wireless Link-layer/MAC currently used (802.11b) and
does not directly handle/process link layer-specific frames. Instead,
the latter is taken care of by the AP.
Finally, another requirement for the architecture was to be
economically cost effective along the following dimensions: a)
complexity of implementation, b) cost of deployment, and c) cost of
management/operational expenses (OpEx). These requirements lead to a
centralized design for the access router, supported by a number of
Yang (Editor), et al. Expires October 15, 2004 [Page 77]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
lightweight, software agents that run at each access point, monitor
the wireless cell, and expose link-layer mechanisms to higher layers,
in order to enforce system-wide policies.
(2) WLAN functions supported: Please list the functions supported in
this WLAN briefly, but please do not send us the entire data sheet.
Examples of WLAN functions includes all the STA services, Distributed
System Services (as defined by 802.11), radio resource management and
control, load balancing, mobility support, WLAN network wide security
functions (including authentication, encryption for privacy and
integrity, etc.) and any others not listed here but deemed important
in your design.
DIRAC aims to provide the necessary hooks and systems framework for
easily enabling as many new wireless services as possible on the
access router. To this end, the following WLAN functions are
implemented by the system:
a) STA services: Authentication, De-authentication, MSDU delivery
b) Distribution System Services: Association, Disassociation,
Distribution, Integration, Reassociation
c) L2 Mobility Support (link-layer handoff)
d) L3 Mobility Support (network-layer fast Handoff integrated with
Mobile IPv6)
e) IP-layer, packet-level, Forward Error Correction and Deficit Round
Robin scheduling that addresses the Head-of-Line blocking problem
f) Policing of aggressive flows through MAC-layer (802.11b) filtering
g) Multi-layer firewalls
h) Channel statistics for STAs centrally collected
i) Registration of APs to AR
(3) The functional architecture to implement the functions described
above: whether it is by autonomous AP architecture, or "split"
architecture. For split architecture, please provide the functional
mapping of WLAN functions onto the AP and AC -- with just enough
details that help us understand the kinds of functional interface
necessary between the two.
The architecture followed by DIRAC can be described as "split",
Yang (Editor), et al. Expires October 15, 2004 [Page 78]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
although this description is irrelevant to the 802.11 MAC; the latter
is implemented fully at the AP, while its management and monitoring
functionality is _exposed_ to (and controlled by) the access router.
The Access Router runs a link-layer specific software agent on the
AP, instead of having part of the MAC implemented at the AR.
In that sense, the mapping between the WLAN functions described above
is as follows:
AP : (a), (b), (c)
AC : (d), (e), (f), (g), (h)
The interface exposed (and further implemented by the AR-AP
communication protocol) revolves around three types of information:
a) Events: occurrence of asynchronous link-layer activity in the
cell, detected by the access point and reported back to the access
router control engine. Examples are: new host (association), host
leaves (disassociation), security binding (authentication), roaming
host (reassociation), dead cell detection (heartbeat).
b) Statistics: latest information on channel quality that each host
perceives, which is location-dependent. Examples of channel
statistics are: signal-noise ration (dB), frame retransmits (frame
loss %), CommTallies (detailed statistics), channel quality variation
(transmission rates), etc.
c) Actions: mechanisms that are exposed and made available by the APs
and can be used by the access router, in order to enforce its
policies. Examples include tuning of the 802.11b MAC protocol
parameters (e.g., deauthenticate a client for security reasons),
configuration settings of the driver (e.g., enter power saving mode,
set number of retransmissions), PHY setting (e.g., adjustment of the
transmission power), configuring the AP device itself (e.g., re-flash
the image of the driver/device). In essence, an "action" is whatever
aspect that can be thought of as a mechanism provided by the AP and
can be controlled through some policy specified by the access router.
(4) The protocol used in between AP and AC.
The protocol used between the Access Router and the Access Points in
DIRAC follows a basic TLV (Type-Length-Value with an addition of a
Subtype) format, and its purpose is to deliver messages carrying
information about events/statistics/actions as described in the
previous section (3). This protocol runs over UDP.
(5) The topological assumptions between AP and AC (is it directly
Yang (Editor), et al. Expires October 15, 2004 [Page 79]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
connected, L2 switched, or L3 routed?) -- this also helps us to
understand the deployment scenarios.
The access point is IP-addressable therefore it is in principle
accessible over any L2-switched, or L3-routed "cloud". However, for
the purpose of delivering meaningful per-host statistics over
fine-time scales to capture long-term fading, and channel coherence
time of the wireless medium, the "cloud" that connects the Access
Points with the Access Router should have latency that is small
enough to deliver statistics reports in a timely fashion. Therefore,
either a direct connection, or a L2-switched "cloud" between the
access point and the access router is recommended.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
Possible threats:
a) Threats TO the DIRAC architecture:
i) protect the messages that deliver events/actions/statistics
ii) authentication of APs to the AR (rogue APs)
iii) Man-in-the-middle attack between APs --AR regarding
control-traffic
b) Threats TO the wireless traffic
i) Mismatching levels of security strengths between STA--AP and
AP--ARs
ii) Denial-of-Service attacks (layer-2 and layer-3) in the wireless
cell (protecting STAs from misbehaving wireless hosts)
iii) Well-documented deficiencies of the 802.11 WEP (over the air
protection)
iv) Access control
Threats (a).(i) and (a).(iii) can be addressed through encryption/
tunneling of management messages. Threat (a).(ii) requires mutual
authentication between AR and APs
Threat (b).(ii) is addressed by the policing service implemented at
the AR and enforced through L2 mechanisms at the AP. (b).(iii)
requires additional authentication (ex. RADIUS) and end-to-end
encryption, on top of WEP. (b).(iv) can be implemented both by access
Yang (Editor), et al. Expires October 15, 2004 [Page 80]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
lists at the AR and MAC filtering at the AP.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
Management, Monitoring and Control (1st problem), Consistent
(network-wide) configuration (2nd problem), and RF Management (3rd
problem) are addressed by the fact that policies are centralized on
the AR, while mechanisms for enforcing them are distributed among all
APs.
Security, and in particular rogue APs, can be addressed (although not
currently implemented on DIRAC) through mutual authentication of the
APs to the AR and vice-versa.
Yang (Editor), et al. Expires October 15, 2004 [Page 81]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix M. Survey Contribution For Architecture 12
(1) Design considerations and requirements:
The access controller (AC) is a bridge. Multiple access points are
aggregated by a bridge that supports a MAC-layer security protocol
between itself and an 802.11 end station. The same MAC-layer security
protocol is used between bridges on a wired LAN and between a bridge
and an 802.11 end station. The security protocol is a service that
sits above the MAC and makes 802.11i MAC security encapsulation
unnecessary. Contrast this with the situation in the near future
where 802.11i will secure the link between an end station and an AP,
and 802.1ae might secure the link between the AP and a bridge.
To the extent that an AP can be architected as a bridge, AP
management falls within the scope of bridge management and is handled
within the 802.1 control layer along with existing bridge management
protocols such as 802.1AB link-layer connectivity and 802.1af
discovery of bridges that support MAC-layer security. These 802.1
protocols are broad enough in scope to meet the requirements of the
802.11 mesh networking PAR.
No 802.11 frames of any type are recognized by an AC.
(2) WLAN functions supported:
An AC never routes packets. It only bridges them except when reverse
tunneling is required. An AC supports layer-3 mobility for a station
that is associated with an AP attached to it, by reverse tunneling
Ethernet from the station to an AC on that station's home subnet.
The roaming station retains the same IP address and the limited
broadcast domain of its home subnet regardless of AP association as
long as the AP is within the same ESS. Therefore, no AC operations
are required for a BSS transition unless that transition is to
another subnet or ESS.
Every handoff between access controllers is authenticated using state
derived from an initial mutual authentication. No AC ever bridges, or
reverse tunnels, any traffic from a station unless the user of that
station can be authenticated. Re-authentication does not require user
involvement.
The MAC-layer security protocol provides privacy, integrity and
replay protection of Ethernet frames between a bridge and an end
station, or between two bridges.
(3) Functional architecture: autonomous AP.
Yang (Editor), et al. Expires October 15, 2004 [Page 82]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
(4) The protocol used in between AP and AC. none.
(5) The topological assumptions between AP and AC. L2 switched.
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that (sic) are addressed.
The architecture is NOT split, nor is it advantageous to do so.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
It is difficult to keep the "analysis" technical when the first and
third "problems" of the four stated in
draft-ietf-capwap-problem-statement-00.txt are expressed in
subjective terms, specifically, "burden" and "difficulty in dealing
effectively". These are indeed at a marketing level. Therefore, one
cannot objectively comment or provide "analysis".
Further, the second and fourth "problems" presume a particular AP
architecture that stores dynamic attributes, namely "embedded
secrets" and "security parameters". So the "problems", except for
dynamic provisioning of RF, are actually threats that arise due to a
particular choice of architecture, one that stores sensitive
information in an AP. With the architecture above, an AP does not
store secrets and therefore AP theft is not a security threat.
Installation of unauthorized access points is a threat if they cannot
be aggregated by an AC, otherwise it doesn't matter because the AC
ultimately controls access to the LAN. Further, a station will not
connect to an AC that it cannot authenticate. Therefore an intruder
is prevented from masquerading as an authorized AP and creating a
MAC-layer security association with an end station. An unauthorized
AP that is not attached directly or indirectly to an AC is a threat
to LAN access but not to an end station.
Yang (Editor), et al. Expires October 15, 2004 [Page 83]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix N. Survey Contribution For Architecture 13
(1) Design considerations and requirements:
The Mesh architecture allows each AP to autonomously keep status of
the pertinent information of the other APs, especially as it relates
to back-hauling traffic between APs. Each AP may assume the role of
providing access both to stations or to other APs for back-hauling
traffic. This way we have an OSPF-like system of weighing paths
through the network for load-balancing and fault-tolerance. The only
requirement is IP connectivity between APs.
(2) WLAN functions supported:
Please list the functions supported in this WLAN briefly, but please
do not send us the entire data sheet. Examples of WLAN functions
includes the STA services, Distributed System Services (as defined by
802.11), radio resource management and control, AP load balancing,
mobility support, WLAN network wide security functions (including
authentication, encryption for privacy and integrity, etc.) and any
others not listed here but deemed important in your design.
Yes to all of the above through much the same functions as the
others. 802.1x, AES, WPA, TKIP, EAP-blah, blah, blah. Other than load
balancing and dynamic radio resource management, I don't think much
else matters in terms of our work.
(3) The functional architecture to implement the functions described
above: whether it is by autonomous AP architecture, or "split"
architecture. For split architecture, please provide the functional
mapping of WLAN functions onto the AP and AC -- with just enough
details that help us understand the kinds of functional interface
necessary between the two.
See my answer to 4. The functional relationship between Mesh nodes is
that they keep each other synced up with their resources and
capabilities. They also keep each other in sync with the state of the
whole network which allows each AP to make intelligent choices of
where to back-haul traffic to.
(4) The protocol used in between AP and AC.
(What is an AP and AC? I don't think we've defined those in the terms
that we will ultimately use. So I'll leave that one for now.
(5) The topological assumptions between AP and AC (is it directly
connected, L2 switched, or L3 routed?) -- this also helps us to
understand the deployment scenarios.
Yang (Editor), et al. Expires October 15, 2004 [Page 84]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
APs are connected Wired or wireless using L2 802.11
(6) Security threat analysis: what kinds of threat introduced by the
split architecture, and how that are addressed.
We encrypt automatically each link using AES and 152-bit key with KM.
(7) Pros and Cons of this architecture, esp. in relation to the four
problems described in the CAPWAP problem statement. Please keep the
analysis at technical instead of marketing level.
Problem 1. Since each node is fully aware of the network, you don't
need to manage each node. Just one will do and it can update the
entire network. That's one of the main values of Mesh.
Problem 2. Kind of the same answer as above. By using multicast IP
protocols to keep everything in sync, we don't run into the problems
mentioned in 2.
Problem 3. Mesh really solves this one quite well, again by keeping
everyone in sync and using multicast IP.
Problem 4. By declaring a Cloud entity consisting of multiple wired
or wirelessly connected APs, complete with full security, only
legitimate APs are admitted to the network. Rogues cannot participate
and may be hunted down using radio techniques.
Yang (Editor), et al. Expires October 15, 2004 [Page 85]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Appendix O. Survey Contribution For Architecture 14
This architecture requires a control channel between wireless access
points and a logical wireless switch device to exchange
configuration, radio control, status and certain 802.11 specific
messages. As explained below the logical wireless switch
functionality may optionally be distributed between more than one
physical device by separating certain logical functions.
Topological requirements
1. The AP and the AC are IP hosts that may be separated by L2 and/or
L3 devices. They are not required to either be directly attached or
in the same Layer-2 broadcast domain.
2. There must be IP-connectivity between the AP and the AC.
Transport attributes:
1. The control channel is an IP connection that may use UDP or TCP
transport mechanisms.
2. Some control channel attributes may be statically configured. In
particular, encryption and/or authentication may be enabled on the
channel.
3. The channel carries messages that may be categorized by various
functions such as provisioning, monitoring, radio management and
mobile node registration. These may be multiplexed over the same
channel by the use of TLVs/opcodes or distributed over multiple IP
connections. The first option allows co-locating all wireless switch
functionality in the same device while the latter allows for switch
entity be hosted on different devices each performing a different set
of functions.
4. APs initiate connection to the AC on a well-known UDP or TCP port.
Discovery of the AC may be via manual configuration on the AP or
through initial DHCP signaling exchange between the AP and a DHCP
server.
Contents of Protocol:
1) APs discover the AC and initiate a UDP or TCP connection.
2) The AP and the AC perform mutual authentication using EAP.
3) The AP and the AC optionally negotiate security association for
securing the channel.
Yang (Editor), et al. Expires October 15, 2004 [Page 86]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
4) The AP is initially provisioned by the AC via a central
configuration database.
4) The AC does .11/.1X authentication mediation when the AP
authenticates mobile nodes. Inserting the AC between the AP and the
authentication server can be used for maintaining a central database
of mobile nodes.
4) Radio reports are sent from the AP to the AC as necessary.
5) Radio control messages are sent from the AC to the AP
asynchronously.
Yang (Editor), et al. Expires October 15, 2004 [Page 87]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Yang (Editor), et al. Expires October 15, 2004 [Page 88]
Internet-Draft CAPWAP Arch. Taxonomy April 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yang (Editor), et al. Expires October 15, 2004 [Page 89]
