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