networks are also supported by all vendors. By ’802.11 mgmt
termination’, and ’802.11 control termination’, we denote the
physical network device on which processing of the 802.11 management
and control frames is done respectively. All the vendors here choose
to terminate 802.11 management and control frames at the WTPs. The
last row of the table, ’802.11 data aggregation’, refers to the
device on which aggregation and delivery of 802.11 data frames from
one STA to another (possibly through a DS) is performed. As shown by
the table, vendors make different choices as to whether all the
802.11 data traffic is aggregated and routed through the AC. The
survey data shows that some vendors choose to tunnel or encapsulate
all the station traffic to or from the ACs, implying that the AC also
acts as the access router for this WLAN access network. Other
vendors choose to separate the control and data plane by letting the
station traffic be bridged or routed locally, while keeping the
centralized control at the AC.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
WTP-AC
connectivity L3 L3 L3 L3 L3
802.11 mgmt
termination WTP WTP WTP WTP WTP
802.11 control
termination WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC WTP AC WTP
Figure 7: Architecture Considerations for Local MAC Architecture
Figure 8 reveals that most of the CAPWAP functions, as described in
Section 1.2, are implemented at the AC with help from WTPs to monitor
RF channels, and collect statistics and state information from the
STAs, as the AC offers the advantages of network-wide visibility,
which is essential for many of the control, configuration, and
value-added services.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
RF
Monitoring WTP WTP AC/WTP WTP WTP
RF
Config. AC AC AC AC AC
WTP config. AC AC AC AC AC
WTP
Firmware AC AC AC AC AC
STA state
info
database AC AC/WTP AC/WTP AC/WTP AC
AC/WTP
mutual
authent. AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP
Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture
The matrix in Figure 9 shows that most of the 802.11 functions are
implemented at the WTPs for Local MAC Architecture, with some minor
differences among the vendors regarding distribution service, 802.11e
scheduling, and 802.1X/EAP authentication. The difference in
distribution service is consistent with that described earlier
regarding "802.11 data aggregation" in Figure 7.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
Distribution
Service AC AC WTP AC WTP
Integration
Service WTP WTP WTP WTP WTP
Beacon
Generation WTP WTP WTP WTP WTP
Probe
Response WTP WTP WTP WTP WTP
Power mgmt
Packet
Buffering WTP WTP WTP WTP WTP
Fragmentation/
Defragment. WTP WTP WTP WTP WTP
Association
Disassoc.
Reassociation AC WTP WTP WTP WTP
WME/11e
--------------
classifying AC WTP
scheduling WTP AC/WTP WTP WTP WTP
queuing WTP WTP WTP WTP
Authentication
and Privacy
--------------
802.1X/EAP AC AC AC/WTP AC AC/WTP
Keys
Management AC AC WTP AC AC
802.11
Encryption/
Decryption WTP WTP WTP WTP WTP
Figure 9: Mapping of 802.11 Functions for Local MAC Architecture
From Figures 7, 8, and 9, it is clear that differences among vendors
in the Local MAC Architecture are relatively minor, and most of the
functional mapping appears to be common across vendors.
5.4. Split MAC
As depicted in Figure 6 (b), the main idea behind the Split MAC
architecture is to implement part of the 802.11 MAC functionality on
a centralized AC instead of the WTPs, in addition to providing the
required services for managing and monitoring the WTP devices.
Usually, the decision of which functions of the 802.11 MAC need to be
provided by the AC is based on the time-criticality of the services
considered.
In the Split MAC architecture, the WTP terminates the infrastructure
side of the wireless physical link, provides radio-related
management, and also implements time-critical functionality of the
802.11 MAC. In addition, the non-realtime management functions are
handled by a centralized AC, along with higher level services, such
as configuration, QoS, policies for load balancing, and access
control lists. The key distinction between Local MAC and Split MAC
relates to non-realtime functions: in Split MAC architecture, the AC
terminates 802.11 non realtime functions, whereas in Local MAC
architecture, the WTP terminates the 802.11 non-realtime functions
and consequently sends appropriate messages to the AC.
There are several motivations for taking the Split MAC approach. The
first is to offload functionality that is specific and relevant only
to the locality of each BSS to the WTP, in order to allow the AC to
scale to a large number of ’light weight’ WTP devices. Moreover,
realtime functionality is subject to latency constraints and cannot
tolerate delays due to transmission of 802.11 control frames (or
other realtime information) over multiple-hops. The latter would
limit the available choices for connectivity between the AC and the
WTP. Therefore, the realtime criterion is usually employed to
separate MAC services between the devices. Another consideration is
cost reduction of the WTP to make it as cheap and simple as possible.
Finally, moving functions like encryption and decryption to the AC
reduces vulnerabilities from a compromised WTP, since user encryption
keys no longer reside on the WTP. As a result, any advancements in
security protocol and algorithm designs do not necessarily obsolete
the WTPs; the ACs implement the new security schemes instead, which
simplifies the management and update task. Additionally, the network
is protected against LAN-side eavesdropping.
Since there is no clear definition in the 802.11 specification as to
which 802.11 MAC functions are considered "realtime", each vendor
interprets this in their own way. Most vendors agree that the
following services of 802.11 MAC are examples of realtime services,
and are chosen to be implemented on the WTPs.
o Beacon Generation
o Probe Response/Transmission
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o Synchronization
o Retransmissions
o Transmission Rate Adaptation
The following list includes examples of non-realtime MAC functions as
interpreted by most vendors:
o Authentication/De-authentication
o Association/Disassociation/Reassociation/Distribution
o Integration Services: Bridging between 802.11 and 802.3
o Privacy: 802.11 Encryption/Decryption
o Fragmentation/Defragmentation
However, some vendors may choose to classify some of the above "non-
realtime" functions as realtime functions in order to support
specific applications with strict QoS requirements. For example,
Reassociation is sometimes implemented as a "realtime" function to
support VoIP applications.
The non-realtime aspects of the 802.11 MAC are handled by the AC
through the processing of raw 802.11 management frames (Split MAC).
The following matrix in Figure 10 offers a tabular representation of
the design choices made by the six vendors that follow the Split MAC
design regarding the architecture considerations. While most vendors
support L3 connectivity between WTPs and ACs, some can only support
L2 switched connections due to the tighter delay constraint resulting
from splitting MAC between two physical entities across a network.
In Figure 7, it is clear that the WTP processes the 802.11 control
frames in both the Split MAC and Local MAC. The difference between
the two lies in the termination point for 802.11 management frames.
Local MAC terminates 802.11 management frames at WTP, while at least
some of the 802.11 management frames are terminated at the AC for the
Split MAC Architecture. Since in most cases WTP devices are IP-
addressable, any of the direct connection, L2-switched, or L3-routed
connections of Section 1.2 can be used. If only Ethernet-
encapsulation is performed (e.g., as in Architecture 4), then only
direct connection and L2-switched connections are supported.
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
WTP-AC
connectivity L3 L3 L3 L2 L3 L3
802.11 mgmt
termination AC AC AC AC AC/WTP AC
802.11 control
termination WTP WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC AC AC AC AC
Figure 10: Architecture Considerations for Split MAC Architecture
Similar to the Local MAC Architecture, the matrix in Figure 11 shows
that most of the CAPWAP control functions are implemented at the AC.
The exception is RF monitoring, and in some cases RF configuration,
which are performed locally at the WTPs.
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
RF
Monitoring WTP WTP WTP WTP WTP WTP
RF
Config. AC/WTP AC/WTP AC AC AC
WTP config. AC AC AC AC AC
WTP
Firmware AC AC AC AC AC
STA state
info
database AC AC AC AC AC
AC/WTP
mutual
authent. AC/WTP AC/WTP AC/WTP AC/WTP
Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture
The most interesting matrix for Split MAC Architecture is the
Functional Distribution Matrix for 802.11 functions, as shown below
in Figure 12. Vendors map the functions onto the WTPs and AC with a
certain regularity. For example, all vendors choose to implement
Distribution, Integration Service at the AC, along with 802.1X/EAP
authentication and keys management. All vendors also choose to
implement beacon generation at WTPs. On the other hand, vendors
sometimes choose to map many of the other functions differently.
Therefore, Split MAC Architectures are not consistent regarding the
exact way the MAC is split.
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ------ ----- -----
Distribution
Service AC AC AC AC AC AC
Integration
Service AC AC AC AC AC AC
Beacon
Generation WTP WTP WTP WTP WTP WTP
Probe
Response WTP AC/WTP WTP WTP WTP WTP
Power mgmt
Packet
Buffering WTP WTP WTP AC AC/WTP WTP
Fragmentation
Defragment. WTP WTP AC AC AC
Association
Disassoc.
Reassociation AC AC AC AC WTP AC
WME/11e
--------------
classifying AC AC AC AC
scheduling WTP/AC AC WTP AC AC WTP/AC
queuing WTP/AC WTP WTP AC WTP WTP
Authentication
and Privacy
--------------
802.1X/EAP AC AC AC AC AC AC
Keys
Management AC AC AC AC AC AC
802.11
Encryption/
Decryption WTP AC WTP AC AC AC
Figure 12: Mapping of 802.11 Functions for Split MAC Architecture
5.5. Remote MAC
One of the main motivations for the Remote MAC Architecture is to
keep the WTPs as light weight as possible, by having only the radio
interfaces on the WTPs and offloading the entire set of 802.11 MAC
functions (including delay-sensitive ones) to the Access Controller.
This leaves all the complexities of the MAC and other CAPWAP control
functions to the centralized controller.
The WTP acts only as a pass-through between the Wireless LAN clients
(STA) and the AC, though they may have an additional feature to
convert the frames from one format (802.11) to the other (i.e.,
Ethernet, TR, Fiber). The centralized controller provides network
monitoring, management and control, an entire set of 802.11 AP
services, security features, resource management, channel selection
features, and guarantees Quality of Service to the users. Because
the MAC is separated from the PHY, we call this the "Remote MAC
Architecture". Typically, such architecture is deployed with special
attention to the connectivity between the WTPs and AC so that the
delay is minimized. The Radio over Fiber (RoF) from Architecture 5
is an example of Remote MAC Architecture.
5.6. Comparisons of Local MAC, Split MAC, and Remote MAC
Two commonalities across all three Centralized Architectures (Local
MAC, Split MAC, and Remote MAC) are:
o Most of the CAPWAP functions related to network control and
configuration reside on the AC.
o IEEE 802.11 PHY resides on the WTP.
There is a clear difference between Remote MAC and the other two
Centralized Architectures (namely, Local MAC and Split MAC), as the
802.11 MAC is completely separated from the PHY in the former, while
the other two keep some portion of the MAC functions together with
PHY at the WTPs. The implication of PHY and MAC separation is that
it severely limits the kind of interconnection between WTPs and ACs,
so that the 802.11 timing constraints are satisfied. As pointed out
earlier, this usually results in tighter constraint over the
interconnection between WTP and AC for the Remote MAC Architecture.
The advantage of Remote MAC Architecture is that it offers the
lightest possible WTPs for certain deployment scenarios.
The commonalities and differences between Local MAC and Split MAC are
most clearly seen by comparing Figure 7 to Figure 10. The
commonality is that 802.11 control frames are terminated at WTPs in
both cases. The main difference between Local MAC and Split MAC is
that the WTP terminates only the 802.11 control frames in the Split
MAC, while the WTP may terminate all 802.11 frames in the Local MAC.
An interesting consequence of this difference is that the Integration
Service, which essentially refers to bridging between 802.11 and
802.3 frames, is implemented by the AC in the Split MAC and by the
WTP in the Local MAC, as shown in Figures 9 and 12, respectively.
As a second note, the Distribution Service, although usually provided
by the AC, can also be implemented at the WTP in some Local MAC
architectures. This approach is meant to increase performance in
delivering STAs data traffic by avoiding tunneling it to the AC, and
relaxing the dependency of the WTP from the AC. Therefore, it is
possible for the data and control planes to be separated in the Local
MAC Architecture.
Even though all the 802.11 traffic is aggregated at ACs in the case
of Split MAC Architecture, the data and control planes can still be
separated by employing multiple ACs. For example, one AC can
implement most of the CAPWAP functions (control plane), while other
ACs can be used for 802.11 frames bridging (data plane).
Each of the three architectural variants may be advantageous for
certain deployment scenarios. While the Local MAC retains most of
the STA’s state information at the local WTPs, Remote MAC centralizes
most of the state into the back-end AC. Split MAC sits somewhat in
the middle of this spectrum, keeping some state information locally
at the WTPs, and the rest centrally at the AC. Many factors should
be taken into account to determine the exact balance desired between
the centralized and decentralized state. The impact of such balance
on network manageability is currently a matter of dispute within the
technical community.
5.7. Communication Interface between WTPs and ACs
Before any messages can be exchanged between an AC and WTP, the WTP
needs to discover, authenticate, and register with the AC first, then
download the firmware and establish a control channel with the AC.
Message exchanges between the WTP and AC for control and
configuration can happen after that. The following list outlines the
basic operations that are typically performed between the WTP and the
AC in their typical order:
1. Discovery: The WTPs discover the AC with which they will be bound
to and controlled by. The discovery procedure can employ either
static or dynamic configuration. In the latter case, a protocol
is used in order for the WTP to discover candidate AC(s).
2. Authentication: After discovery, the WTP device authenticates
itself with the AC. However, mutual authentication, in which the
WTP also authenticates the AC, is not always supported since some
vendors strive for zero-configuration on the WTP side. This is
not necessarily secure as it leaves the possible vulnerability of
the WTP being attached to a rogue AC.
3. WTP Association: After successful authentication, a WTP registers
with the AC in order to start receiving management and
configuration messages.
4. Firmware Download: After successful association, the WTP may
pull, or the AC may push, the WTPs firmware, which may be
protected in some manner, such as digital signatures.
5. Control Channel Establishment: The WTP establishes either an IP-
tunnel or performs Ethernet encapsulation with the AC in order to
transfer data traffic and management frames.
6. Configuration Download: Following the control channel
establishment process, the AC may push configuration parameters
to the WTPs.
5.8. Security
Given the varied distribution of functionalities for the Centralized
Architecture, as surveyed in Section 4.3, it is obvious that an extra
network binding is created between the WTP and the AC. This brings
new and unique security issues and subsequent requirements.
5.8.1. Client Data Security
The survey shows clearly that the termination point for "over the
air" 802.11 encryption [4] can be implemented either in the WTP or in
the AC. Furthermore, the 802.1X/EAP [6] functionality is distributed
between the WTP and the AC where, in most cases, the AC performs the
necessary functions as the authenticator in the 802.1X exchange.
If the STA and AC are the parties in the 4-way handshake (defined in
[4]), and 802.11i traffic encryption terminates at the WTP, then the
Pairwise Transient Key (PTK) has to be transferred from the AC to the
WTP. Since the keying material is part of the control and
provisioning of the WTPs, a secure encrypted tunnel for control
frames is employed to transport the keying material.
The centralized model encourages AC implementations to use one PMK
for many different WTPs. This practice facilitates speedy transition
by an STA from one WTP to another that is connected to the same AC
without establishing a separate PMK. However, this leaves the STA in
a difficult position, as the STA cannot distinguish between a
compromised PMK and one that is intentionally being shared. This
issue must be resolved, but the resolution is beyond the scope of the
CAPWAP working group. The venue for this resolution is to be
determined by the IEEE 802 and IETF liaisons.
When the 802.11i encryption/decryption is performed in the AC, the
key exchange and state transitions occur between the AC and the STA.
Therefore, there is no need to transfer any crypto material between
the AC and the WTP.
Regardless of where the 802.11i termination point occurs, the
Centralized WLAN Architecture records two practices for "over the
wire" client data security. In some cases there is an encrypted
tunnel (IPsec or SSL) between the WTP and AC, which assumes that the