Request for Comments: 4564 H. Cheng
Category: Informational Panasonic
ZH. Yao
Huawei
WH. Zhou
China Mobile
L. Yang
Intel
July 2006
Objectives for
Control and Provisioning of Wireless Access Points (CAPWAP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents objectives for an interoperable protocol for
the Control and Provisioning of Wireless Access Points (CAPWAP). The
document aims to establish a set of focused requirements for the
development and evaluation of a CAPWAP protocol. The objectives
address architecture, operation, security, and network operator
requirements that are necessary to enable interoperability among
Wireless Local Area Network (WLAN) devices of alternative designs.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements Notation ...........................................4
4. Objectives Overview .............................................4
5. Objectives ......................................................5
5.1. Mandatory and Accepted Objectives ..........................5
5.1.1. Logical Groups ......................................5
5.1.2. Support for Traffic Separation ......................6
5.1.3. Wireless Terminal Transparency ......................8
5.1.4. Configuration Consistency ...........................8
5.1.5. Firmware Trigger ....................................9
5.1.6. Monitoring and Exchange of System-wide
Resource State .....................................10
5.1.7. Resource Control Objective .........................11
5.1.8. CAPWAP Protocol Security ...........................12
5.1.9. System-wide Security ...............................14
5.1.10. IEEE 802.11i Considerations .......................15
5.1.11. Interoperability Objective .......................17
5.1.12. Protocol Specifications ..........................18
5.1.13. Vendor Independence ..............................19
5.1.14. Vendor Flexibility ...............................19
5.1.15. NAT Traversal ....................................20
5.2. Desirable Objectives ......................................21
5.2.1. Multiple Authentication Mechanisms .................21
5.2.2. Support for Future Wireless Technologies ...........21
5.2.3. Support for New IEEE Requirements ..................22
5.2.4. Interconnection Objective ..........................23
5.2.5. Access Control ....................................24
5.3. Non-Objectives ............................................25
5.3.1. Support for Non-CAPWAP WTPs ........................25
5.3.2. Technical Specifications ...........................26
5.4. Operator Requirements .....................................27
5.4.1. AP Fast Handoff ....................................27
6. Summary and Conclusion .........................................27
7. Security Considerations ........................................28
8. Acknowledgements ...............................................29
9. Normative References ...........................................29
10. Informative References ........................................29
1. Introduction
The growth in large-scale Wireless Local Area Network (WLAN)
deployments has brought into focus a number of technical challenges.
Among them is the complexity of managing large numbers of Wireless
Termination Points (WTPs), which is further exacerbated by variations
in their design. Another challenge is the maintenance of consistent
configurations among the numerous WTPs of a system. The dynamic
nature of the wireless medium is also a concern together with WLAN
security. The challenges affecting large-scale WLAN deployments have
been highlighted in [RFC3990].
Many vendors have addressed these challenges by developing new
architectures and solutions. A survey of the various developments
was conducted to better understand the context of these challenges.
This survey is a first step towards designing interoperability among
the solutions. The Architecture Taxonomy [RFC4118] is a result of
this survey in which major WLAN architecture families are classified.
Broadly, these are the autonomous, centralized WLAN, and distributed
mesh architectures.
The Architecture Taxonomy identified the centralized WLAN
architecture as one in which portions of the wireless medium access
control (MAC) operations are centralized in a WLAN controller. This
centralized WLAN architecture is further classified into remote-MAC,
split-MAC, and local-MAC designs. Each differs in the degree of
separation of wireless MAC layer capabilities between WTPs and WLAN
controller.
This document puts forward critical objectives for achieving
interoperability in the CAPWAP framework. It presents requirements
that address the challenges of controlling and provisioning large-
scale WLAN deployments. The realization of these objectives in a
CAPWAP protocol will ensure that WLAN equipment of major design types
may be integrally deployed and managed.
2. Terminology
This document uses terminology defined in [RFC4118], [802.11],
[802.11i], and [802.11e]. Additionally, the following terms are
defined.
Centralized WLAN: A WLAN based on the centralized WLAN Architecture
[RFC4118].
Switching Segment: Those aspects of a centralized WLAN that primarily
deal with switching or routing of control and data information
between Wireless Termination Points (WTPs) and the WLAN controller.
Wireless Medium Segment: Those aspects of a centralized WLAN that
primarily deal with the wireless interface between WTPs and wireless
terminals. The Wireless Medium Segment is specific to layer 2
wireless technology, such as IEEE 802.11.
CAPWAP Framework: A term that covers the local-MAC and split-MAC
designs of the Centralized WLAN Architecture. Standardization
efforts are focused on these designs.
CAPWAP Protocol: The protocol between WLAN controller and WTPs in the
CAPWAP framework. It facilitates control, management, and
provisioning of WTPs in an interoperable manner.
Logical Group: A logical separation of a physical WTP is termed
logical group. So a single physical WTP will operate a number of
logical groups. Virtual access points (APs) are examples of logical
groups. Here, each Basic Service Set Identifier (BSSID) and
constituent wireless terminals’ radios are denoted as distinct
logical groups of a physical WTP. Logical groups are maintained
without conflicting with the CAPWAP objectives, particularly the
’Wireless Terminal Transparency’ objective.
3. Requirements Notation
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 [RFC2119].
4. Objectives Overview
The objectives for CAPWAP have been broadly classified to address
architecture, operation, and security requirements of managing
large-scale WLAN deployments.
Architecture objectives deal with system-level aspects of the CAPWAP
protocol. They address issues of protocol extensibility, diversity
in network deployments and architecture designs, and differences in
transport technologies.
Operational objectives address the control and management features of
the CAPWAP protocol. They deal with operations relating to WLAN
monitoring, resource management, Quality of Service (QoS), and access
control.
Security objectives address potential threats to WLANs and their
containment. In the CAPWAP context, security requirements cover the
protocol between the WLAN controller and WTPs and also the WLAN
system as a whole.
Additionally, a general classification is used for objectives
relating to the overall impact of the CAPWAP protocol specifications.
5. Objectives
The objectives described in this document have been prioritized based
on their immediate significance in the development and evaluation of
a control and provisioning protocol for large-scale WLAN deployments.
The priorities are:
i. Mandatory and Accepted Objectives
ii. Desirable Objectives
iii. Non-Objectives
The priorities have been assigned to individual objectives in
accordance with working group discussions.
Furthermore, a distinct category of objectives is provided based on
requirements gathered from network service operators. These are
specific needs that arise from operators’ experiences in deploying
and managing large-scale WLANs.
a. Operator Requirements
5.1. Mandatory and Accepted Objectives
Objectives prioritized as mandatory and accepted have been deemed
crucial for the control and provisioning of WTPs. They directly
address the challenges of large-scale WLAN deployments and MUST be
realized by a CAPWAP protocol.
5.1.1. Logical Groups
Classification: Architecture
Description:
Large WLAN deployments are complex and expensive. Furthermore,
enterprises deploying such networks are under pressure to improve the
efficiency of their expenditures.
Shared WLAN deployments, where a single physical WLAN infrastructure
supports a number of logical networks, are increasingly used to
address these two issues of large-scale WLANs. These are popular as
they allow deployment and management costs to be spread across
businesses.
In traditional WLANs, each physical WTP represents one complete
subset of a larger WLAN system. Shared WLANs differ in that each
physical WTP represents a number of logical subsets of possibly a
number of larger WLAN systems. Each logical division of a physical
WTP is referred to as a logical group (see definition in Section 2).
So WLANs are managed in terms of logical groups instead of physical
WTPs. Logical groups are based on BSSIDs and other types of virtual
APs.
Protocol Requirement:
The CAPWAP protocol MUST be capable of controlling and managing
physical WTPs in terms of logical groups including BSSID-based
groups.
For all operating modes, including those in which the WTP performs
local bridging and those in which the Access Controller (AC) performs
centralized bridging, the protocol MUST provide provisions for
configuring logical groups at the WTP.
Motivation and Protocol Benefits:
Commercial realities necessitate that WLANs be manageable in terms of
their logical groups. This allows separation of logical services and
underlying infrastructure management. A protocol that realizes this
need ensures simpler and cost-effective WLANs, which directly address
the requirements of network service operators.
Relation to Problem Statement:
This objective addresses the problem of management complexity in
terms of costs. Cost complexity is reduced by sharing WLAN
deployments. Consequently, deployment and management cost-
efficiencies are realized.
5.1.2. Support for Traffic Separation
Classification: Operations
Description:
The centralized WLAN architecture simplifies complexity associated
with large-scale deployments by consolidating portions of wireless
MAC functionality at a central WLAN controller and distributing the
remaining across WTPs. As a result, WTPs and WLAN controller
exchange control and data information between them. This objective
states that control and data aspects of the exchanges be mutually
separated for further simplicity. This will allow solutions for each
type of exchange to be independently optimized.
Furthermore, in the context of shared WLAN deployments, the mutual
separation of control and data also addresses security concerns. In
particular, given the likelihood of different logical groups, such as
those established by different virtual APs, being managed by
different administrators, separation of control and data is a first
step towards individually containing and securing the logical groups.
It is also important to ensure that traffic from each logical group
is mutually separated to maintain the integrity and independence of
the logical groups.
Protocol Requirement:
The CAPWAP protocol MUST define transport control messages such that
the transport of control messages is separate from the transport of
data messages.
Motivation and Protocol Benefits:
The aim of separating data and control aspects of the protocol is to
simplify the protocol. It also allows for the flexibility of
addressing each type of traffic in the most appropriate manner.
Furthermore, this requirement will help remotely located WTPs to
handle data traffic in alternative ways without the need for
forwarding them across a wide network to the WLAN controller.
Separation of WTP control and data also aids in the secure
realization of shared WLAN deployments.
Relation to Problem Statement:
Broadly, this objective relates to the challenge of managing
complexity in large-scale WLANs. The requirement for traffic
separation simplifies control as this is separated from the task of
data transport.
5.1.3. Wireless Terminal Transparency
Classification: Operations
Description:
The CAPWAP protocol is applicable between a centralized WLAN
controller and a number of WTPs; i.e., it affects only the switching
segment of the centralized WLAN architecture. Its operations should
therefore be independent of the wireless terminal. Wireless
terminals should not be required to be aware of the existence of the
CAPWAP protocol.
Protocol Requirement:
Wireless terminals MUST NOT be required to recognize or be aware of
the CAPWAP protocol.
Motivation and Protocol Benefits:
IEEE 802.11-based wireless terminals are mature and widely available.
It would be beneficial for CAPWAP not to impose new requirements on
these wireless terminals. In effect, this requirement ensures that
the setup cost of the protocol is reduced as the numerous existing
wireless terminals need not be altered.
Relation to Problem Statement:
The Problem Statement highlights the challenges faced by large WLANs
consisting of many WTPs. It does not refer to the operations of
wireless terminals and this objective emphasizes the independence.
5.1.4. Configuration Consistency
Classification: Operations
Description:
WLANs in the CAPWAP framework contain numerous WTPs, each of them
needing to be configured and managed in a consistent manner. The
main concern in ensuring consistency is availability of appropriate
information corresponding to WTP configuration states. So
configuration consistency can be achieved by providing the
centralized WLAN controller with regular updates on the state of WTP
operations. The centralized WLAN controller can in turn apply
information from the regular updates to ensure consistently among the
WTPs.
Protocol Requirement:
The CAPWAP protocol MUST include support for regular exchanges of
state information between WTPs and the WLAN controller. Examples of
state information include WTP processing load and memory utilization.
Motivation and Protocol Benefits:
A protocol that provides access to regular state information can in
turn be used to enhance WLAN configuration and performance. The
CAPWAP protocol will be better equipped to address configuration-
related problems with the regularly available state information. So
with greater state information, control and management operations can
be improved.
Relation to Problem Statement:
One of the major challenges described in the Problem Statement is
that of maintaining consistent configuration across the numerous WTPs
of a WLAN. This objective addresses the fundamental issue behind
this -- availability of timely state information.
5.1.5. Firmware Trigger
Classification: Operations
Description:
One specific aspect of configuration consistency is the firmware used
by various WTPs. The scale of large WLANs introduces possibilities
for variations in the firmware used among WTPs. This objective
highlights the need for the CAPWAP protocol to trigger the delivery
of appropriate versions of firmware to WTPs. The actual delivery of
firmware need not be inclusive to the protocol.
Protocol Requirement:
The CAPWAP protocol MUST support a trigger for delivery of firmware
updates.
Motivation and Protocol Benefits:
The CAPWAP protocol interfaces many WTPs to a centralized WLAN
controller. Firmware distribution allows these interfaces to be
compatible. This in turn results in consistent configuration and
simplified management. So the protocol benefits by including
triggers for the distribution of firmware updates.
Relation to Problem Statement:
Inconsistencies in the configuration of WTPs have been identified as
a major challenge for large-scale WTPs. This objective helps
overcome the challenge by providing a way for the CAPWAP protocol to
initiate delivery of firmware updates that are compatible among all
WTPs.
5.1.6. Monitoring and Exchange of System-wide Resource State
Classification: Operations
Description:
The centralized WLAN architecture is made up of a switching segment
and wireless medium segment. In the switching segment, network
congestion, WTP status, and firmware information have to be
monitored. In the wireless medium segment, the dynamic nature of the
medium itself has to be monitored. Overall, there are also various
statistics that need to be considered for efficient WLAN operation.
The CAPWAP protocol should be capable of monitoring the various
information sources and deliver the resulting information to the
relevant WLAN devices -- either WTPs or the WLAN controller.
Moreover, given the relationship among information sources, the
CAPWAP protocol should combine state information from them. For
example, statistics information and status signals from WTPs may be
merged before being exchanged.
Examples of statistics information that the CAPWAP protocol should
monitor and exchange include congestion state, interference levels,
loss rates, and various delay factors.
Protocol Requirement:
The CAPWAP protocol MUST allow for the exchange of statistics,
congestion, and other WLAN state information.
Motivation and Protocol Benefits:
The effectiveness of a protocol is based on the relevance of
information on which it operates. This requirement for resource
monitoring and exchange can provide the appropriate information to
the CAPWAP protocol.
Relation to Problem Statement:
The Problem Statement highlights the challenge of dealing with large
numbers of WTPs and the dynamic nature of the wireless medium.
Information on the state of WTPs and the medium is important to deal
with them effectively. So this objective relates to the problem of
managing consistency in large WLANs.
5.1.7. Resource Control Objective
Classification: Operations
Description:
Integral to the success of any wireless network system is the
performance and quality it can offer its subscribers. Since CAPWAP-
based WLANs combine a switching segment and a wireless medium
segment, performance and quality need to be coordinated across both
of these segments. So QoS performance must be enforced system-wide.
This objective highlights QoS over the entire WLAN system, which
includes the switching segment and the wireless medium segment.
Given the fundamental differences between the two, it is likely that
there are alternate QoS mechanisms between WTPs and wireless service
subscribers and between WTPs and WLAN controllers. For instance, the
former will be based on IEEE 802.11e, whereas the latter will be an
alternative. So resources need to be adjusted in a coordinated
fashion over both segments. The CAPWAP protocol should ensure that
these adjustments are appropriately exchanged between WLAN
controllers and WTPs.
In addition to IEEE 802.11e, there are a number of other IEEE 802.11
task groups that may affect network resources. These include IEEE
802.11 TGk, TGu, and TGv, which are currently in progress. CAPWAP
should therefore not be restricted to IEEE 802.11e-based mapping.
Protocol Requirement:
The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to
equivalent QoS priorities across the switching and wireless medium
segments.
Motivation and Protocol Benefits:
A protocol that addresses QoS aspects of WLAN systems will deliver
high performance thereby being beneficial for subscribers and for
resource utilization efficiency. Since CAPWAP deals with WTPs
directly and with the wireless medium indirectly, both of these must
be considered for performance.
For the wireless medium segment, QoS aspects in the protocol enable
high-quality communications within the domain of a WLAN controller.
Since each domain generally covers an enterprise or a group of
service providers, such protocol performance has wide-ranging
effects.
Within the switching segment of CAPWAP, a QoS-enabled protocol
minimizes the adverse effects of dynamic traffic characteristics so
as to ensure system-wide performance.
Relation to Problem Statement:
QoS control is critical to large WLANs and relates to a number of
aspects. In particular, this objective can help address the problem
of managing dynamic conditions of the wireless medium.
Furthermore, traffic characteristics in large-scale WLANs are
constantly varying. So network utilization becomes inefficient, and
user experience is unpredictable.
The interaction and coordination between the two aspects of system-
wide QoS are therefore critical for performance.
5.1.8. CAPWAP Protocol Security
Classification: Security
Description:
This objective addresses the security of the CAPWAP protocol.
The CAPWAP protocol MUST first provide for the participating entities
-- the WLAN controller and WTPs -- to be explicitly mutually
authenticated. This is to ensure that rogue elements do not gain
access to the WLAN system. Rogue WTPs should not be allowed to
breach legitimate WLANs, and at the same time rogue WLAN controllers
should not be allowed to gain control of legitimate WTPs. For
example, WTPs may need to regularly renew their authentication state
with the WLAN controller and similarly for WLAN controllers.
If authentication is performed via an authenticated key exchange,
future knowledge of derived keys is not sufficient for
authentication.
Any session keys used between the WLAN controller and WTPs MUST be
mutually derived using entropy contributed by both parties. This
ensures that no one party has control over the resulting session
keys.
Once WTPs and the WLAN controller have been mutually authenticated,
information exchanges between them must be secured against various
security threats. So the CAPWAP protocol MUST provide integrity
protection and replay protection. The protocol SHOULD provide
confidentiality through encryption. This should cover illegitimate