draft-ietf-capwap-objectives-04.txt   rfc4564.txt 
Network Working Group S. Govindan (Editor) Network Working Group S. Govindan, Ed.
Internet-Draft Panasonic Request for Comments: 4564 H. Cheng
Expires: April 1, 2006 ZH. Yao Category: Informational Panasonic
ZH. Yao
Huawei Huawei
WH. Zhou WH. Zhou
China Mobile China Mobile
L. Yang L. Yang
Intel Intel
H. Cheng Objectives for
Panasonic Control and Provisioning of Wireless Access Points (CAPWAP)
September 28, 2005
Objectives for Control and Provisioning of Wireless Access Points
(CAPWAP)
draft-ietf-capwap-objectives-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2006. 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 Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document presents objectives for an interoperable protocol for This document presents objectives for an interoperable protocol for
the Control and Provisioning of Wireless Access Points (CAPWAP). The the Control and Provisioning of Wireless Access Points (CAPWAP). The
document aims to establish a set of focused requirements for the document aims to establish a set of focused requirements for the
development and evaluation of a CAPWAP protocol. The objectives development and evaluation of a CAPWAP protocol. The objectives
address Architecture, Operation, Security and Network Operator address architecture, operation, security, and network operator
Requirements that are necessary to enable interoperability among requirements that are necessary to enable interoperability among
wireless local area network (WLAN) devices of alternative designs. Wireless Local Area Network (WLAN) devices of alternative designs.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Notation ...........................................4
4. Objectives Overview . . . . . . . . . . . . . . . . . . . . . 7 4. Objectives Overview .............................................4
5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Objectives ......................................................5
5.1. Mandatory and Accepted Objectives . . . . . . . . . . . . 8 5.1. Mandatory and Accepted Objectives ..........................5
5.1.1. Logical Groups . . . . . . . . . . . . . . . . . . . . 8 5.1.1. Logical Groups ......................................5
5.1.2. Support for Traffic Separation . . . . . . . . . . . . 9 5.1.2. Support for Traffic Separation ......................6
5.1.3. Wireless Terminal Transparency . . . . . . . . . . . . 10 5.1.3. Wireless Terminal Transparency ......................8
5.1.4. Configuration Consistency . . . . . . . . . . . . . . 11 5.1.4. Configuration Consistency ...........................8
5.1.5. Firmware Trigger . . . . . . . . . . . . . . . . . . . 12 5.1.5. Firmware Trigger ....................................9
5.1.6. Monitoring and Exchange of System-wide Resource 5.1.6. Monitoring and Exchange of System-wide
State . . . . . . . . . . . . . . . . . . . . . . . . 12 Resource State .....................................10
5.1.7. Resource Control Objective . . . . . . . . . . . . . . 13 5.1.7. Resource Control Objective .........................11
5.1.8. CAPWAP Protocol Security . . . . . . . . . . . . . . . 15 5.1.8. CAPWAP Protocol Security ...........................12
5.1.9. System-wide Security . . . . . . . . . . . . . . . . . 16 5.1.9. System-wide Security ...............................14
5.1.10. IEEE 802.11i Considerations . . . . . . . . . . . . . 17 5.1.10. IEEE 802.11i Considerations .......................15
5.1.11. Interoperability Objective . . . . . . . . . . . . . . 19 5.1.11. Interoperability Objective .......................17
5.1.12. Protocol Specifications . . . . . . . . . . . . . . . 20 5.1.12. Protocol Specifications ..........................18
5.1.13. Vendor Independence . . . . . . . . . . . . . . . . . 21 5.1.13. Vendor Independence ..............................19
5.1.14. Vendor Flexibility . . . . . . . . . . . . . . . . . . 21 5.1.14. Vendor Flexibility ...............................19
5.1.15. NAT Traversal . . . . . . . . . . . . . . . . . . . . 22 5.1.15. NAT Traversal ....................................20
5.2. Desirable Objectives . . . . . . . . . . . . . . . . . . . 23 5.2. Desirable Objectives ......................................21
5.2.1. Multiple Authentication Mechanisms . . . . . . . . . . 23 5.2.1. Multiple Authentication Mechanisms .................21
5.2.2. Support for Future Wireless Technologies . . . . . . . 23 5.2.2. Support for Future Wireless Technologies ...........21
5.2.3. Support for New IEEE Requirements . . . . . . . . . . 24 5.2.3. Support for New IEEE Requirements ..................22
5.2.4. Interconnection Objective . . . . . . . . . . . . . . 25 5.2.4. Interconnection Objective ..........................23
5.2.5. Access Control . . . . . . . . . . . . . . . . . . . . 26 5.2.5. Access Control ....................................24
5.3. Non-Objectives . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Non-Objectives ............................................25
5.3.1. Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 27 5.3.1. Support for Non-CAPWAP WTPs ........................25
5.3.2. Technical Specifications . . . . . . . . . . . . . . . 28 5.3.2. Technical Specifications ...........................26
5.4. Operator Requirements . . . . . . . . . . . . . . . . . . 28 5.4. Operator Requirements .....................................27
5.4.1. AP Fast Handoff . . . . . . . . . . . . . . . . . . . 28 5.4.1. AP Fast Handoff ....................................27
6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 30 6. Summary and Conclusion .........................................27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations ........................................28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements ...............................................29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Normative References ...........................................29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Informative References ........................................29
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. 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].
2. Terminology
This document follows the terminologies of [RFC4118]. 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 focussed 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 APs are examples of logical groups. Here,
each 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 'Wireles Terminal Transparency' Objective.
3. Introduction 1. Introduction
The growth in large-scale wireless local area network (WLAN) The growth in large-scale Wireless Local Area Network (WLAN)
deployments has brought to focus a number of technical challenges. deployments has brought into focus a number of technical challenges.
Among them is the complexity of managing large numbers of wireless Among them is the complexity of managing large numbers of Wireless
termination points (WTPs), which is further exacerbated by variations Termination Points (WTPs), which is further exacerbated by variations
in their design. Another challenge is the maintenance of consistent in their design. Another challenge is the maintenance of consistent
configurations among the numerous WTPs of a system. The dynamic configurations among the numerous WTPs of a system. The dynamic
nature of the wireless medium is also a concern together with WLAN nature of the wireless medium is also a concern together with WLAN
security. The challenges affecting large-scale WLAN deployments have security. The challenges affecting large-scale WLAN deployments have
been highlighted in [RFC3990]. been highlighted in [RFC3990].
Many vendors have addressed these challenges by developing new Many vendors have addressed these challenges by developing new
architectures and solutions. A survey of the various developments architectures and solutions. A survey of the various developments
was conducted to better understand the context of these challenges. was conducted to better understand the context of these challenges.
This survey is a first step towards designing interoperability among This survey is a first step towards designing interoperability among
the solutions. The Architecture Taxonomy [RFC4118] is a result of the solutions. The Architecture Taxonomy [RFC4118] is a result of
this survey in which major WLAN architecture families are classified. this survey in which major WLAN architecture families are classified.
Broadly, these are the autonomous, centralized WLAN and distributed Broadly, these are the autonomous, centralized WLAN, and distributed
mesh architectures. mesh architectures.
The Architecture Taxonomy identified the centralized WLAN The Architecture Taxonomy identified the centralized WLAN
architecture as one in which portions of the wireless medium access architecture as one in which portions of the wireless medium access
control (MAC) operations are centralized in a WLAN controller. This control (MAC) operations are centralized in a WLAN controller. This
centralized WLAN architecture is further classified into remote-MAC, centralized WLAN architecture is further classified into remote-MAC,
split-MAC and local-MAC designs. Each differs in the degree of split-MAC, and local-MAC designs. Each differs in the degree of
separation of wireless MAC layer capabilities between WTPs and WLAN separation of wireless MAC layer capabilities between WTPs and WLAN
controller. controller.
This document puts forward critical objectives for achieving This document puts forward critical objectives for achieving
interoperability in the CAPWAP framework. It presents requirements interoperability in the CAPWAP framework. It presents requirements
that address the challenges of controling and provisioning large- that address the challenges of controlling and provisioning large-
scale WLAN deployments. The realization of these objectives in a scale WLAN deployments. The realization of these objectives in a
CAPWAP protocol will ensure that WLAN equipment of major design types CAPWAP protocol will ensure that WLAN equipment of major design types
may be integrally deployed and managed. 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 4. Objectives Overview
The objectives for CAPWAP have been broadly classified to address The objectives for CAPWAP have been broadly classified to address
architecture, operation and security requirements of managing large- architecture, operation, and security requirements of managing
scale WLAN deployments. large-scale WLAN deployments.
Architecture objectives deal with system level aspects of the CAPWAP Architecture objectives deal with system-level aspects of the CAPWAP
protocol. They address issues of protocol extensibility, diversity protocol. They address issues of protocol extensibility, diversity
in network deployments and architecture designs and differences in in network deployments and architecture designs, and differences in
transport technologies. transport technologies.
Operational objectives address the control and management features of Operational objectives address the control and management features of
the CAPWAP protocol. They deal with operations relating to WLAN the CAPWAP protocol. They deal with operations relating to WLAN
monitoring, resource management, QoS and access control. monitoring, resource management, Quality of Service (QoS), and access
control.
Security objectives address potential threats to WLANs and their Security objectives address potential threats to WLANs and their
containment. In the CAPWAP context, security requirements cover both containment. In the CAPWAP context, security requirements cover the
the protocol between WLAN controller and WTPs and also the WLAN protocol between the WLAN controller and WTPs and also the WLAN
system as a whole. system as a whole.
Additionally, a general classification is used for objectives Additionally, a general classification is used for objectives
relating to the overall impact of the CAPWAP protocol specifications. relating to the overall impact of the CAPWAP protocol specifications.
5. Objectives 5. Objectives
The objectives described in this document have been prioritized based The objectives described in this document have been prioritized based
on their immediate significance in the development and evaluation of on their immediate significance in the development and evaluation of
a control and provisioning protocol for large-scale WLAN deployments. a control and provisioning protocol for large-scale WLAN deployments.
Additionally, one category is provided for requirements gathered from The priorities are:
network service operators. These are specific need that arise from
operators' experiencese in deploying and managing large-scale WLANs.
The priorities are;
i. Mandatory and Accepted Objectives i. Mandatory and Accepted Objectives
ii. Desirable Objectives ii. Desirable Objectives
iii. Non-Objectives iii. Non-Objectives
iv. Operator Requirements
The priorities have been assigned to individual objectives in The priorities have been assigned to individual objectives in
accordance with working group discussions. 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 5.1. Mandatory and Accepted Objectives
Objectives prioritized as Mandatory and Accepted have been deemed Objectives prioritized as mandatory and accepted have been deemed
crucial for the control and provisioning of WTPs. They directly crucial for the control and provisioning of WTPs. They directly
address the challenges of large-scale WLAN deployments and must be address the challenges of large-scale WLAN deployments and MUST be
realized by a CAPWAP protocol. realized by a CAPWAP protocol.
5.1.1. Logical Groups 5.1.1. Logical Groups
Classification: Architecture Classification: Architecture
Description: Description:
Large WLAN deployments are complex and expensive. Furthermore, Large WLAN deployments are complex and expensive. Furthermore,
enterprises deploying such networks are under pressure to improve the enterprises deploying such networks are under pressure to improve the
skipping to change at page 8, line 50 skipping to change at page 6, line 9
Shared WLAN deployments, where a single physical WLAN infrastructure Shared WLAN deployments, where a single physical WLAN infrastructure
supports a number of logical networks, are increasingly used to supports a number of logical networks, are increasingly used to
address these two issues of large-scale WLANs. These are popular as address these two issues of large-scale WLANs. These are popular as
they allow deployment and management costs to be spread across they allow deployment and management costs to be spread across
businesses. businesses.
In traditional WLANs, each physical WTP represents one complete In traditional WLANs, each physical WTP represents one complete
subset of a larger WLAN system. Shared WLANs differ in that each subset of a larger WLAN system. Shared WLANs differ in that each
physical WTP represents a number of logical subsets of possibly a physical WTP represents a number of logical subsets of possibly a
number of larger WLAN systems. Each logical division of a physical number of larger WLAN systems. Each logical division of a physical
WTP is referred to as a logical group [Section 2]. So WLANs are WTP is referred to as a logical group (see definition in Section 2).
managed in terms of logical groups instead of physical WTPs. Logical So WLANs are managed in terms of logical groups instead of physical
groups are based on BSSIDs and other types of virtual APs. WTPs. Logical groups are based on BSSIDs and other types of virtual
APs.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST be capable of controlling and managing The CAPWAP protocol MUST be capable of controlling and managing
physical WTPs in terms of logical groups including BSSID-based physical WTPs in terms of logical groups including BSSID-based
groups. groups.
For all operating modes, including those in which the WTP performs For all operating modes, including those in which the WTP performs
local bridging and those in which the AC performs centralized local bridging and those in which the Access Controller (AC) performs
bridging, the protocol MUST provide provisions for configuring centralized bridging, the protocol MUST provide provisions for
logical groups at the WTP. configuring logical groups at the WTP.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
Commercial realities necessitate that WLANs be manageable in terms of Commercial realities necessitate that WLANs be manageable in terms of
its logical groups. This allows separation of logical services and their logical groups. This allows separation of logical services and
underlying infrastructure management. A protocol that realizes this underlying infrastructure management. A protocol that realizes this
need ensures simlper and cost effective WLANs, which directly address need ensures simpler and cost-effective WLANs, which directly address
the requirements of network service operators. the requirements of network service operators.
Relation to Problem Statement: Relation to Problem Statement:
This objective addresses the problem of management complexity in This objective addresses the problem of management complexity in
terms of costs. Cost complexity is reduced by sharing WLAN terms of costs. Cost complexity is reduced by sharing WLAN
deployments. Consequently, deployment and management cost- deployments. Consequently, deployment and management cost-
efficiencies are realized. efficiencies are realized.
5.1.2. Support for Traffic Separation 5.1.2. Support for Traffic Separation
skipping to change at page 10, line 6 skipping to change at page 7, line 16
type of exchange to be independently optimized. type of exchange to be independently optimized.
Furthermore, in the context of shared WLAN deployments, the mutual Furthermore, in the context of shared WLAN deployments, the mutual
separation of control and data also addresses security concerns. In separation of control and data also addresses security concerns. In
particular, given the likelihood of different logical groups, such as particular, given the likelihood of different logical groups, such as
those established by different virtual APs, being managed by those established by different virtual APs, being managed by
different administrators, separation of control and data is a first different administrators, separation of control and data is a first
step towards individually containing and securing the logical groups. step towards individually containing and securing the logical groups.
It is also important to ensure that traffic from each logical group It is also important to ensure that traffic from each logical group
be mutually separated to maintain the integrity and independence of is mutually separated to maintain the integrity and independence of
the logical groups. the logical groups.
Protocol Requirement: Protocol Requirement:
The CAPWAP Protocol MUST define transport control messages such that The CAPWAP protocol MUST define transport control messages such that
the transport of control messages is separate from the transport of the transport of control messages is separate from the transport of
data messages. data messages.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The aim of separating data and control aspects of the protocol is to The aim of separating data and control aspects of the protocol is to
simplify the protocol. It also allows for the flexibility of simplify the protocol. It also allows for the flexibility of
addressing each type of traffic in the most appropriate manner. addressing each type of traffic in the most appropriate manner.
Furthermore, this requirement will help remotely located WTPs to Furthermore, this requirement will help remotely located WTPs to
skipping to change at page 10, line 42 skipping to change at page 8, line 12
separation simplifies control as this is separated from the task of separation simplifies control as this is separated from the task of
data transport. data transport.
5.1.3. Wireless Terminal Transparency 5.1.3. Wireless Terminal Transparency
Classification: Operations Classification: Operations
Description: Description:
The CAPWAP protocol is applicable between a centralized WLAN The CAPWAP protocol is applicable between a centralized WLAN
controller and a number of WTPs, i.e. it affects only the switching controller and a number of WTPs; i.e., it affects only the switching
segment of the centralized WLAN architecture. Its operations should segment of the centralized WLAN architecture. Its operations should
therefore be independent of the wireless terminal. Wireless therefore be independent of the wireless terminal. Wireless
terminals should not be required to be aware of the existence of the terminals should not be required to be aware of the existence of the
CAPWAP protocol. CAPWAP protocol.
Protocol Requirement: Protocol Requirement:
Wireless terminals MUST NOT be required to recognize or be aware of Wireless terminals MUST NOT be required to recognize or be aware of
the CAPWAP protocol. the CAPWAP protocol.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
IEEE 802.11 based wireless terminals are mature and widely available. IEEE 802.11-based wireless terminals are mature and widely available.
It would be beneficial for CAPWAP not to impose new requirements on It would be beneficial for CAPWAP not to impose new requirements on
these wireless terminals. In effect, this requirement ensures that these wireless terminals. In effect, this requirement ensures that
the setup cost of the protocol is reduced as the numerous existing the setup cost of the protocol is reduced as the numerous existing
wireless terminals need not be altered. wireless terminals need not be altered.
Relation to Problem Statement: Relation to Problem Statement:
The Problem Statement highlights the challenges faced by large WLANs The Problem Statement highlights the challenges faced by large WLANs
consisting of many WTPs. It does not refer to the operations of consisting of many WTPs. It does not refer to the operations of
wireless terminals and this objective emphasizes the independence. wireless terminals and this objective emphasizes the independence.
5.1.4. Configuration Consistency 5.1.4. Configuration Consistency
Classification: Operations Classification: Operations
Description: Description:
WLANs in the CAPWAP framework contain numerous WTPs, each of which WLANs in the CAPWAP framework contain numerous WTPs, each of them
need to be configured and managed in a consistent manner. The main needing to be configured and managed in a consistent manner. The
concern in ensuring consistency is availability of appropriate main concern in ensuring consistency is availability of appropriate
information corresponding to WTP configuration states. So information corresponding to WTP configuration states. So
configuration consistency can be achieved by providing the configuration consistency can be achieved by providing the
centralized WLAN controller with regular updates on the state of WTP centralized WLAN controller with regular updates on the state of WTP
operations. The centralized WLAN controller can in turn apply operations. The centralized WLAN controller can in turn apply
information from the regular updates to ensure consistently among the information from the regular updates to ensure consistently among the
WTPs. WTPs.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST include support for regular exchanges of The CAPWAP protocol MUST include support for regular exchanges of
state information between WTPs and WLAN controller. Examples of state information between WTPs and the WLAN controller. Examples of
state information include WTP processing load and memory utilization. state information include WTP processing load and memory utilization.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
A protocol that provides access to regular state information can in A protocol that provides access to regular state information can in
turn be used to enhance WLAN configuration and performance. The turn be used to enhance WLAN configuration and performance. The
CAPWAP protocol will be better equipped to address configuration CAPWAP protocol will be better equipped to address configuration-
related problems with the regularly available state information. So related problems with the regularly available state information. So
with greater state information, control and management operations can with greater state information, control and management operations can
be improved. be improved.
Relation to Problem Statement: Relation to Problem Statement:
One of the major challenges described in the Problem Statement is One of the major challenges described in the Problem Statement is
that of maintaining consistent configuration across the numerous WTPs that of maintaining consistent configuration across the numerous WTPs
of a WLAN. This objective addresses the fundamental issue behind of a WLAN. This objective addresses the fundamental issue behind
this - availability of timely state information. this -- availability of timely state information.
5.1.5. Firmware Trigger 5.1.5. Firmware Trigger
Classification: Operations Classification: Operations
Description: Description:
One specific aspect of configuration consistency is the firmware used One specific aspect of configuration consistency is the firmware used
by various WTPs. The scale of large WLANs introduces possibilities by various WTPs. The scale of large WLANs introduces possibilities
for variations in the firmware used among WTPs. This objective for variations in the firmware used among WTPs. This objective
skipping to change at page 12, line 36 skipping to change at page 10, line 7
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The CAPWAP protocol interfaces many WTPs to a centralized WLAN The CAPWAP protocol interfaces many WTPs to a centralized WLAN
controller. Firmware distribution allows these interfaces to be controller. Firmware distribution allows these interfaces to be
compatible. This in turn results in consistent configuration and compatible. This in turn results in consistent configuration and
simplified management. So the protocol benefits by including simplified management. So the protocol benefits by including
triggers for the distribution of firmware updates. triggers for the distribution of firmware updates.
Relation to Problem Statement: Relation to Problem Statement:
Inconsistencies in the configuration of WTPs has been identified as a Inconsistencies in the configuration of WTPs have been identified as
major challenge for large-scale WTPs. This objectives helps overcome a major challenge for large-scale WTPs. This objective helps
the challenge by providing for a way for the CAPWAP protocol to overcome the challenge by providing a way for the CAPWAP protocol to
initiate delivery of firmware updates that are compatible among all initiate delivery of firmware updates that are compatible among all
WTPs. WTPs.
5.1.6. Monitoring and Exchange of System-wide Resource State 5.1.6. Monitoring and Exchange of System-wide Resource State
Classification: Operations Classification: Operations
Description: Description:
The centralized WLAN architecture is made up of a switching segment The centralized WLAN architecture is made up of a switching segment
and wireless medium segment. In the switching segment, network and wireless medium segment. In the switching segment, network
congestion, WTP status and firmware information have to be monitored. congestion, WTP status, and firmware information have to be
In the wireless medium segment, the dynamic nature of the medium monitored. In the wireless medium segment, the dynamic nature of the
itself has to be monitored. Overall, there are also various medium itself has to be monitored. Overall, there are also various
statistics need to be considered for efficient WLAN operation. statistics that need to be considered for efficient WLAN operation.
The CAPWAP protocol should be capable of monitoring the various The CAPWAP protocol should be capable of monitoring the various
information sources and deliver the resulting information to the information sources and deliver the resulting information to the
relevant WLAN devices - either WTPs or WLAN controller. Moreover, relevant WLAN devices -- either WTPs or the WLAN controller.
given the relationship among information sources, the CAPWAP protocol Moreover, given the relationship among information sources, the
should combine state information from them. For example, statistics CAPWAP protocol should combine state information from them. For
information and status signals from WTPs may be merged before being example, statistics information and status signals from WTPs may be
exchanged. merged before being exchanged.
Examples of statistics information that the CAPWAP protocol should Examples of statistics information that the CAPWAP protocol should
monitor and exchange include; congestion state, interference levels, monitor and exchange include congestion state, interference levels,
loss rates and various delay factors. loss rates, and various delay factors.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST allow for the exchange of statistics, The CAPWAP protocol MUST allow for the exchange of statistics,
congestion and other WLAN state information. congestion, and other WLAN state information.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The effectivness of a protocol is based on the relevance of The effectiveness of a protocol is based on the relevance of
information on which it operates. This requirement for resource information on which it operates. This requirement for resource
monitoring and exchange can provide the appropriate information to monitoring and exchange can provide the appropriate information to
the CAPWAP protocol. the CAPWAP protocol.
Relation to Problem Statement: Relation to Problem Statement:
The Problem Statement highlights the challenge of dealing with large The Problem Statement highlights the challenge of dealing with large
numbers of WTPs and the dynamic nature of the wireless medium. numbers of WTPs and the dynamic nature of the wireless medium.
Information on the state of WTPs and the medium is important to deal Information on the state of WTPs and the medium is important to deal
with them effectively. So this objective relates to the problem of with them effectively. So this objective relates to the problem of
managing consistency in large WLANs. managing consistency in large WLANs.
5.1.7. Resource Control Objective 5.1.7. Resource Control Objective
Classification: Operations Classification: Operations
Description: Description:
Integral to the success of any wireless network system is the Integral to the success of any wireless network system is the
performance and quality it can offer its subscribers. Since CAPWAP performance and quality it can offer its subscribers. Since CAPWAP-
based WLANs combine a switching segment and a wireless medium based WLANs combine a switching segment and a wireless medium
segment, performance and quality need to be coordinated across both segment, performance and quality need to be coordinated across both
of these segments. So QoS performance must be enforced system-wide. of these segments. So QoS performance must be enforced system-wide.
This objective highlights QoS over the entire WLAN system which This objective highlights QoS over the entire WLAN system, which
includes the switching segment and the wireless medium segment. includes the switching segment and the wireless medium segment.
Given the fundamental differences between the two, it is likely that Given the fundamental differences between the two, it is likely that
there are alternate QoS mechanisms between WTPs and wireless service there are alternate QoS mechanisms between WTPs and wireless service
subscribers and between WTPs and WLAN controllers. For instance, the subscribers and between WTPs and WLAN controllers. For instance, the
former will be based on IEEE 802.11e while the latter will be an former will be based on IEEE 802.11e, whereas the latter will be an
alternative. So resources need to be adjusted in a coordinated alternative. So resources need to be adjusted in a coordinated
fashion over both segments. The CAPWAP protocol should ensure that fashion over both segments. The CAPWAP protocol should ensure that
these adjustments are appropriately exchanged between WLAN these adjustments are appropriately exchanged between WLAN
controllers and WTPs. controllers and WTPs.
In addition to IEEE 802.11e, there are a number of other IEEE 802.11 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 task groups that may affect network resources. These include IEEE
802.11 TGk, TGu and TGv, which are currently under progress. CAPWAP 802.11 TGk, TGu, and TGv, which are currently in progress. CAPWAP
should therefore not be restricted to IEEE 802.11e based mapping. should therefore not be restricted to IEEE 802.11e-based mapping.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to
equivalent QoS priorities across the switching and wireless medium equivalent QoS priorities across the switching and wireless medium
segments segments.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
A protocol that addresses QoS aspects of WLAN systems will deliver A protocol that addresses QoS aspects of WLAN systems will deliver
high performance thereby being beneficial for subscribers and for high performance thereby being beneficial for subscribers and for
resource utilization efficiency. Since CAPWAP deals with WTPs resource utilization efficiency. Since CAPWAP deals with WTPs
directly and with the wireless medium indirectly, both of these must directly and with the wireless medium indirectly, both of these must
be considered for performance. be considered for performance.
For the wireless medium segment, QoS aspects in the protocol enable For the wireless medium segment, QoS aspects in the protocol enable
high quality communications within the domain of a WLAN controller. high-quality communications within the domain of a WLAN controller.
Since each domain generally covers an enterprise or a group of Since each domain generally covers an enterprise or a group of
service providers, such protocol performance has wide-ranging service providers, such protocol performance has wide-ranging
effects. effects.
Within the switching segment of CAPWAP, a QoS-enabled protocol Within the switching segment of CAPWAP, a QoS-enabled protocol
minimizes the adverse effects of dynamic traffic characteristics so minimizes the adverse effects of dynamic traffic characteristics so
as to ensure system-wide performance. as to ensure system-wide performance.
Relation to Problem Statement: Relation to Problem Statement:
QoS control is critical to large WLANs and relates to a number of QoS control is critical to large WLANs and relates to a number of
aspects. In particular, this objective can help address the problem aspects. In particular, this objective can help address the problem
of managing dynamic conditions of the wireless medium. of managing dynamic conditions of the wireless medium.
Furthermore, traffic characteristics in large scale WLANs are Furthermore, traffic characteristics in large-scale WLANs are
constantly varying. So network utilization becomes inefficient and constantly varying. So network utilization becomes inefficient, and
user experience is unpredictable. user experience is unpredictable.
The interaction and coordination between the two aspects of system- The interaction and coordination between the two aspects of system-
wide QoS is therefore critical for performance. wide QoS are therefore critical for performance.
5.1.8. CAPWAP Protocol Security 5.1.8. CAPWAP Protocol Security
Classification: Security Classification: Security
Description: Description:
This objective addresses the security of the CAPWAP protocol. This objective addresses the security of the CAPWAP protocol.
The CAPWAP protocol MUST first provide for the participating entities The CAPWAP protocol MUST first provide for the participating entities
- WLAN controller and WTPs - to be explicitly mutually authenticated. -- the WLAN controller and WTPs -- to be explicitly mutually
This is to ensure that rogue elements do not gain access to the WLAN authenticated. This is to ensure that rogue elements do not gain
system. Rogue WTPs should not be allowed to breach legitimate WLANs access to the WLAN system. Rogue WTPs should not be allowed to
and at the same time rogue WLAN controllers should not be allowed to breach legitimate WLANs, and at the same time rogue WLAN controllers
gain control of legitimate WTPs. For example, WTPs may need to should not be allowed to gain control of legitimate WTPs. For
regularly renew their authentication state with the WLAN controller example, WTPs may need to regularly renew their authentication state
and similarly for WLAN controllers. with the WLAN controller and similarly for WLAN controllers.
If authentication is performed via an authenticated key exchange, If authentication is performed via an authenticated key exchange,
future knowledge of derived keys is not sufficient for future knowledge of derived keys is not sufficient for
authentication. authentication.
Any session keys used between the WLAN controller and WTP MUST be Any session keys used between the WLAN controller and WTPs MUST be
mutually derived using entropy contributed by both parties. This mutually derived using entropy contributed by both parties. This
ensures that no one party has control over the resulting session ensures that no one party has control over the resulting session
keys. keys.
Once WTPs and WLAN controller have been mutually authenticated, Once WTPs and the WLAN controller have been mutually authenticated,
information exchanges between them must be secured against various information exchanges between them must be secured against various
security threats. This should cover illegitimate modifications to security threats. So the CAPWAP protocol MUST provide integrity
protocol exchanges, eavesdropping and DoS attacks, among other protection and replay protection. The protocol SHOULD provide
potential compromises. So the protocol must be provide confidentiality through encryption. This should cover illegitimate
confidentiality, integrity and authenticity for those exchanges. modifications to protocol exchanges, eavesdropping, and Denial of
Service (DoS) attacks, among other potential compromises. So the
protocol must provide confidentiality, integrity, and authenticity
for those exchanges.
As a result of realizing this objective it should not be possible for As a result of realizing this objective, it should not be possible
individual WTP breaches to affect the security of the WLAN as a for individual WTP breaches to affect the security of the WLAN as a
whole. So WTP mis-use will be protected against. whole. So WTP misuse will be protected against.
Additionally, the key establishment protocol for authentication and Additionally, the key establishment protocol for authentication and
securing CAPWAP exchanges must be designed to minimize the securing CAPWAP exchanges must be designed to minimize the
possibility of future compromises after the keys are established. possibility of future compromises after the keys are established.
CAPWAP MUST NOT prevent the use of asymmetric authentication. The CAPWAP MUST NOT prevent the use of asymmetric authentication. The
security considerations of such asymmetric authentication are security considerations of such asymmetric authentication are
described in the Security Considerations section. described in the Security Considerations section.
If the CAPWAP protocol meets the criteria to require automated key
management per BCP 107 [RFC4107], then mutual authentication MUST be
accomplished via an authenticated key exchange.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST support mutual authentication of WTPs and The CAPWAP protocol MUST support mutual authentication of WTPs and
the centralized controller. It must also ensure that information the centralized controller. It also MUST ensure that information
exchanges between them are secured. exchanges are integrity protected and SHOULD ensure confidentiality
through encryption.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
WLANs are increasingly deployed in critical aspects of enterprise and WLANs are increasingly deployed in critical aspects of enterprise and
consumer networks. In these contexts, protocol security is crucial consumer networks. In these contexts, protocol security is crucial
to assure the privacy and integrity expected from network to ensure the privacy and integrity expected from network
administrators and end-users. So securing the CAPWAP protocol has administrators and end-users. So securing the CAPWAP protocol has
direct benefits in addressing these concerns. direct benefits in addressing these concerns.
In many cases, the network path between a WTP and WLAN controller In many cases, the network path between a WTP and WLAN controller
contains untrusted links. Such links could be leveraged by rogue contains untrusted links. Such links could be leveraged by rogue
WTPs to gain access to the WLAN system. They could also be used by WTPs to gain access to the WLAN system. They could also be used by
rogue WLAN controllers to gain control of legitimate WTPs and their rogue WLAN controllers to gain control of legitimate WTPs and their
associated terminals to either redirect or compromise terminal associated terminals to either redirect or compromise terminal
traffic. These security concerns can be mitigated with this traffic. These security concerns can be mitigated with this
objective. objective.
Relation to Problem Statement: Relation to Problem Statement:
Security problems in large-scale WLANs are detailed in the Problem Security problems in large-scale WLANs are detailed in the Problem
Statement. These include complications arising from rogue WTPs and Statement. These include complications arising from rogue WTPs and
compromised interfaces between WTPs and WLAN controller. The compromised interfaces between WTPs and the WLAN controller. The
requirement for protocol security addresses these problems and requirement for protocol security addresses these problems and
highlights the importance of protecting against them. highlights the importance of protecting against them.
5.1.9. System-wide Security 5.1.9. System-wide Security
Classification: Security Classification: Security
Description: Description:
The emphasis of this objective is on the security threats external to The emphasis of this objective is on the security threats external to
the centralized CAPWAP segment of a WLAN system. The focus is the centralized CAPWAP segment of a WLAN system. The focus is
therefore on rogue wireless clients and other illegitimate wireless therefore on rogue wireless clients and other illegitimate wireless
interferences. There are a number of specific external threats that interferences. There are a number of specific external threats that
need to be addressed within the CAPWAP framework. need to be addressed within the CAPWAP framework.
i. PMK Sharing i. PMK Sharing
One aspect of this objective relates to recent discussions on PMK One aspect of this objective relates to recent discussions on
sharing in the CAPWAP framework. This objective highlights the need Pairwise Master Key (PMK) sharing in the CAPWAP framework. This
to prevent exploitation of this ambiguity by rogue wireless clients. objective highlights the need to prevent exploitation of this
It is to ensure that any ambiguities arising from the CAPWAP ambiguity by rogue wireless clients. It is to ensure that any
framework are not cause for security breaches. ambiguities arising from the CAPWAP framework are not cause for
security breaches.
Protocol Requirement: Protocol Requirement:
The design of the CAPWAP protocol MUST NOT allow for any compromises The design of the CAPWAP protocol MUST NOT allow for any compromises
to the WLAN system by external entities. to the WLAN system by external entities.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The external threats to the centralized WLAN architecture become The external threats to the centralized WLAN architecture become
increasingly crucial given the low cost of wireless clients. Since increasingly crucial given the low cost of wireless clients. Since
skipping to change at page 17, line 38 skipping to change at page 15, line 37
to the Problem Statement. to the Problem Statement.
5.1.10. IEEE 802.11i Considerations 5.1.10. IEEE 802.11i Considerations
Classification: Operations Classification: Operations
Description: Description:
The CAPWAP protocol must support authentication in the centralized The CAPWAP protocol must support authentication in the centralized
WLAN architecture in which the authenticator and encryption points WLAN architecture in which the authenticator and encryption points
can be located on distinct entities, i.e. WLAN controller or WTP. can be located on distinct entities, i.e., WLAN controller or WTP.
The Architecture Taxonomy illustrates a number of variants, in both The Architecture Taxonomy illustrates a number of variants, in both
local-MAC and split-MAC designs, in which the authenticator is local-MAC and split-MAC designs, in which the authenticator is
located at the WLAN controller and the encryption points are at the located at the WLAN controller and the encryption points are at the
WTPs. The CAPWAP protocol must be applicable to these variants and WTPs. The CAPWAP protocol must be applicable to these variants and
allow authentication mechanisms and their consistituent processes to allow authentication mechanisms and their constituent processes to be
be operable in these cases. operable in these cases.
An important issue to consider in this case is the exchange of key An important issue to consider in this case is the exchange of key
information when authenticator and encryption points are located on information when authenticator and encryption points are located on
distinct entities. For example, consider the case where IEEE 802.11i distinct entities. For example, consider the case where IEEE 802.11i
is used in a WLAN in which the WLAN controller realizes the is used in a WLAN in which the WLAN controller realizes the
authenticator, some WTPs realize encryption (possibly local-MAC WTPs) authenticator, some WTPs realize encryption (possibly local-MAC
and other WTPs rely on the WLAN controller for encryption (possibly WTPs), and other WTPs rely on the WLAN controller for encryption
split-MAC WTPs). (possibly split-MAC WTPs).
Here, CAPWAP will first need to identify the location of the Here, CAPWAP will first need to identify the location of the
authenticator and encryption points between each WLAN controller-WTP authenticator and encryption points between each WLAN controller-WTP
pair. This will likely be part of the initial WTP configuration. pair. This will likely be part of the initial WTP configuration.
Subsequently, the WTPs which realize encryption will need CAPWAP to Subsequently, the WTPs that realize encryption will need CAPWAP to
exchange key information with the authenticator at the WLAN exchange key information with the authenticator at the WLAN
controller. For the WTPs which do not realize encryption, CAPWAP controller. For the WTPs that do not realize encryption, CAPWAP
need to adapt its control to bypass the key exchange phase. needs to adapt its control to bypass the key exchange phase.
Clearly, the centralized WLAN architecture presents a different Clearly, the centralized WLAN architecture presents a different
platform for authentication mechanisms compared to legacy WLANs in platform for authentication mechanisms compared to legacy WLANs in
which a WTP realized both authenticator and encryption roles. So which a WTP realized both authenticator and encryption roles. So
this objective highlights the need for CAPWAP to support this objective highlights the need for CAPWAP to support
authentication and key management in the centralized WLAN authentication and key management in the centralized WLAN
architecture. architecture.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST determine the exact structure of the The CAPWAP protocol MUST determine the exact structure of the
centralized WLAN architecture in which authentication needs to be centralized WLAN architecture in which authentication needs to be
supported, i.e. the location of major authentication components. supported, i.e., the location of major authentication components.
This may be achieved during WTP initialization where major This may be achieved during WTP initialization where major
capabilities are distinguished. capabilities are distinguished.
The protocol must allow for the exchange of key information when The protocol MUST allow for the exchange of key information when
authenticator and encryption roles are located in distinct entities. authenticator and encryption roles are located in distinct entities.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The immediate focus of CAPWAP is on supporting IEEE 802.11 based The immediate focus of CAPWAP is on supporting IEEE 802.11-based
WLANs. As such, it is necessary for the protocol to recognize the WLANs. As such, it is necessary for the protocol to recognize the
major distinction in WLAN design with respect to IEEE 802.11i major distinction in WLAN design with respect to IEEE 802.11i
authenticator and encryption points. This represents a significant authenticator and encryption points. This represents a significant
variation that has been highlighted in the Architecture Taxonomy. variation that has been highlighted in the Architecture Taxonomy.
The CAPWAP protocol benefits by accommodating such a major The CAPWAP protocol benefits by accommodating such a major
consideration fro IEEE 802.11i. consideration from IEEE 802.11i.
These requirements will be common for all authentication mechanisms These requirements will be common for all authentication mechanisms
over the centralized WLAN architecture. So they are applicable to over the centralized WLAN architecture. So they are applicable to
IEEE 802.11i, UMA and other mechanisms. IEEE 802.11i, Universal Access Method (UAM), and other mechanisms.
Relation to Problem Statement: Relation to Problem Statement:
The Problem Statement highlights the availability of different WTP The Problem Statement highlights the availability of different WTP
designs and the need to ensure interoperability among them. In this designs and the need to ensure interoperability among them. In this
regard, operational changes occuring due to the separation of the regard, operational changes occurring due to the separation of the
IEEE 802.11i authenticator and encryption points need to be IEEE 802.11i authenticator and encryption points need to be
accommated within the CAPWAP protocol. accommodated within the CAPWAP protocol.
5.1.11. Interoperability Objective 5.1.11. Interoperability Objective
Classification: Architecture Classification: Architecture
Description: Description:
Two major designs of the centralized WLAN architecture are local-MAC Two major designs of the centralized WLAN architecture are local-MAC
and split-MAC. With the focusing of standardization efforts on these and split-MAC. With the focusing of standardization efforts on these
two designs, it is crucial to ensure mutual interoperation among two designs, it is crucial to ensure mutual interoperation among
skipping to change at page 19, line 28 skipping to change at page 17, line 27
local-MAC and split-MAC architecture designs are capable of local-MAC and split-MAC architecture designs are capable of
interoperation within a single WLAN. Consequently, a single WLAN interoperation within a single WLAN. Consequently, a single WLAN
controller will be capable of controlling both types of WTPs using a controller will be capable of controlling both types of WTPs using a
single CAPWAP protocol. Integral support for these designs comprises single CAPWAP protocol. Integral support for these designs comprises
a number of protocol aspects. a number of protocol aspects.
i. Capability negotiations between WLAN controller and WTPs i. Capability negotiations between WLAN controller and WTPs
WTP designs differ in the degree of IEEE 802.11 MAC functionalities WTP designs differ in the degree of IEEE 802.11 MAC functionalities
that each type of WTP realizes. The major distinctions, split-MAC that each type of WTP realizes. The major distinctions, split-MAC
and local-MAC differ in the processing of IEEE 802.11 MAC frames. In and local-MAC, differ in the processing of IEEE 802.11 MAC frames.
this regard, the CAPWAP protocol should include functionality that In this regard, the CAPWAP protocol should include functionality that
allows for negotiationg of significant capabilities between WTPs and allows for negotiations of significant capabilities between WTPs and
WLAN controller. the WLAN controller.
As a first step, such negotiations could cover the type of WTP - As a first step, such negotiations could cover the type of WTP,
split-MAC or local-MAC - as this provides substantial information on split-MAC or local-MAC, as this provides substantial information on
their respective capabilities. their respective capabilities.
ii. Establishment of alternative interfaces ii. Establishment of alternative interfaces
The capability differences among different WTPs essentially equates The capability differences among different WTPs essentially equate to
to alternative interfaces with a WLAN controller. So the CAPWAP alternative interfaces with a WLAN controller. So the CAPWAP
protocol should be capable of adapting its operations to the major protocol should be capable of adapting its operations to the major
different interfaces. In a first case, this would include different interfaces. In a first case, this would include
accommodating capability differences between local-MAC and split-MAC accommodating capability differences between local-MAC and split-MAC
WTPs. WTPs.
The definition of these interfaces in terms of finer granularity of The definition of these interfaces in terms of finer granularity of
functionalities will be based on AP functionality documents produced functionalities will be based on AP functionality documents produced
by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee. by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee.
Protocol Requirement: Protocol Requirement:
skipping to change at page 20, line 32 skipping to change at page 18, line 29
alternative interfaces is marginal. Consequently, the benefits of alternative interfaces is marginal. Consequently, the benefits of
this objective will far outweigh any cost of realizing it. this objective will far outweigh any cost of realizing it.
Relation to Problem Statement: Relation to Problem Statement:
The objective for supporting both local-MAC and split-MAC WTPs is The objective for supporting both local-MAC and split-MAC WTPs is
fundamental to addressing the Problem Statement. It forms the basis fundamental to addressing the Problem Statement. It forms the basis
for those problems to be uniformly addressed across the major WLAN for those problems to be uniformly addressed across the major WLAN
architectures. This is the ultimate aim of standardization efforts. architectures. This is the ultimate aim of standardization efforts.
The realization of this objective will ensure the development of a The realization of this objective will ensure the development of a
comprehensive set of mechanisms that address the challenges of large- comprehensive set of mechanisms that address the challenges of
scale WLAN deployments. large-scale WLAN deployments.
5.1.12. Protocol Specifications 5.1.12. Protocol Specifications
Classification: General Classification: General
Description: Description:
WLAN equipment vendors require sufficient details from protocol WLAN equipment vendors require sufficient details from protocol
specifications so that implementing them will allow for compatibility specifications so that implementing them will allow for compatibility
with other equipment that run the same protocol. In this light, it with other equipment that runs the same protocol. In this light, it
is important for the CAPWAP protocol specifications to be reasonably is important for the CAPWAP protocol specifications to be reasonably
complete for realization. complete for realization.
Protocol Requirement: Protocol Requirement:
Any WTP or WLAN controller vendor or any person MUST be able to Any WTP or WLAN controller vendor or any person MUST be able to
implement the CAPWAP protocol from the specification itself and by implement the CAPWAP protocol from the specification itself and by
that it is required that all such implementations do interoperate. that it is required that all such implementations do interoperate.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
It is beneficial for WLAN equipment vendors to refer to a single set It is beneficial for WLAN equipment vendors to refer to a single set
of specifications while implementing the CAPWAP protocol. This helps of specifications while implementing the CAPWAP protocol. This helps
to ease and quicken the development process. to ease and quicken the development process.
Relation to Problem Statement: Relation to Problem Statement:
This requirement is based on WG discussions that have determined to This requirement is based on WG discussions that have been determined
be important for CAPWAP. to be important for CAPWAP.
5.1.13. Vendor Independence 5.1.13. Vendor Independence
Classification: General Classification: General
Description: Description:
Rapid developments in WLAN technologies results in equipment vendors Rapid developments in WLAN technologies result in equipment vendors
constantly modifying their devices. In many cases, developments are constantly modifying their devices. In many cases, developments are
independently made for WLAN controllers and WTPs. The CAPWAP independently made for WLAN controllers and WTPs. The CAPWAP
protocol should not affect the the independence of device protocol should not affect the independence of device modifications.
modificaitons.
Protocol Requirement: Protocol Requirement:
A WTP vendor SHOULD be able to make modifications to hardware without A WTP vendor SHOULD be able to make modifications to hardware without
any WLAN controller vendor involvement. any WLAN controller vendor involvement.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
Independence in the type of hardware for WLAN equipment ensures that Independence in the type of hardware for WLAN equipment ensures that
new developments do not hamper protocol operation. new developments do not hamper protocol operation.
Relation to Problem Statement: Relation to Problem Statement:
This requirement is based on WG discussions that have determined to This requirement is based on WG discussions that have been determined
be important for CAPWAP. to be important for CAPWAP.
5.1.14. Vendor Flexibility 5.1.14. Vendor Flexibility
Classification: General Classification: General
Description: Description:
The CAPWAP protocol must not be specified for a particular type of The CAPWAP protocol must not be specified for a particular type of
wireless MAC design. It should be compatible with both local-MAC and wireless MAC design. It should be compatible with both local-MAC and
split-MAC WTPs. split-MAC WTPs.
skipping to change at page 22, line 19 skipping to change at page 20, line 19
of WTPs. of WTPs.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
This requirement is to ensure that WTP vendors have sufficient This requirement is to ensure that WTP vendors have sufficient
flexibility in selecting the type of wireless MAC design that they flexibility in selecting the type of wireless MAC design that they
consider best for deployments. consider best for deployments.
Relation to Problem Statement: Relation to Problem Statement:
This requirement is based on WG discussions that have determined to This requirement is based on WG discussions that have been determined
be important for CAPWAP. to be important for CAPWAP.
5.1.15. NAT Traversal 5.1.15. NAT Traversal
Classification: General Classification: General
Description: Description:
WLAN deployments may involve WTPs and the WLAN controller WLAN deployments may involve WTPs and the WLAN controller
communicating across NATs. The CAPWAP protocol must be capable of communicating across Network Address Translators (NATs). The CAPWAP
operating across topologies that contain known NAT configurations. protocol must be capable of operating across topologies that contain
It requires appropriate discovery and identification mechanisms for known NAT configurations. It requires appropriate discovery and
NAT traversal. identification mechanisms for NAT traversal.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST NOT prevent the operation of established The CAPWAP protocol MUST NOT prevent the operation of established
methods of NAT traversal. methods of NAT traversal.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The wide-spread adoption of WLANs raises the possibility for WLAN The widespread adoption of WLANs raises the possibility for WLAN
topologies containing NATs. It is important for the CAPWAP protocol topologies containing NATs. It is important for the CAPWAP protocol
to be applicable within such topologies. This requirement aims to to be applicable within such topologies. This requirement aims to
make the CAPWAP protocol relevant for NAT traversal. make the CAPWAP protocol relevant for NAT traversal.
Relation to Problem Statement: Relation to Problem Statement:
This requirement is based on WG discussions that have determined to This requirement is based on WG discussions that have been determined
be important for CAPWAP. to be important for CAPWAP.
5.2. Desirable Objectives 5.2. Desirable Objectives
These objectives have been determined to be desirable for a CAPWAP These objectives have been determined to be desirable for a CAPWAP
protocol but not mandatory. Realizing these objectives may help protocol but not mandatory. Realizing these objectives may help
improve control of WLANs but need not necessarily be required for all improve control of WLANs but need not necessarily be required for all
networks or scenarios. networks or scenarios.
5.2.1. Multiple Authentication Mechanisms 5.2.1. Multiple Authentication Mechanisms
Classification: Architecture Classification: Architecture
Description: Description:
Shared WLAN infrastructure raise the issue of multiple authentication Shared WLAN infrastructure raises the issue of multiple
mechanisms. This is because each logical group is likely to be authentication mechanisms. This is because each logical group is
associated with different service providers or WLAN domains. As a likely to be associated with different service providers or WLAN
result, the authentication needs withing them will be different. domains. As a result, the authentication needs within them will be
While CAPWAP is required to support IEEE 802.11i, it is also different. Although CAPWAP is required to support IEEE 802.11i, it
necessary for it to support other authentication mechanisms. For is also necessary for it to support other authentication mechanisms.
example, one logical group may use IEEE 802.11i while another may use For example, one logical group may use IEEE 802.11i, whereas another
web authentication. CAPWAP must be able to operate in such shared may use web authentication. CAPWAP must be able to operate in such
WLANs. shared WLANs.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST support different authentication mechanisms The CAPWAP protocol MUST support different authentication mechanisms
in addition to IEEE 802.11i. in addition to IEEE 802.11i.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The benefit of supporting various authentication mechanisms is that The benefit of supporting various authentication mechanisms is that
the protocol then becomes flexible for use in various deployments. the protocol then becomes flexible for use in various deployments.
The protocol will therefore not mandate the use of any particular The protocol will therefore not mandate the use of any particular
mechanisms which may not be appropriate for a particular deployment. mechanisms that may not be appropriate for a particular deployment.
Relation to Problem Statement: Relation to Problem Statement:
This objective relates to the problem of management complexity. This objective relates to the problem of management complexity.
Shared WLAN deployments simplifies management of large networks. Shared WLAN deployments simplify management of large networks.
5.2.2. Support for Future Wireless Technologies 5.2.2. Support for Future Wireless Technologies
Classification: Architecture Classification: Architecture
Description: Description:
The rapid pace of technology developments means that new advances The rapid pace of technology developments means that new advances
need to be catered for in current analyses. Among these is the need to be catered to in current analyses. Among these is the
support for new wireless technologies within the CAPWAP protocol, support for new wireless technologies within the CAPWAP protocol,
such as IEEE 802.16. The protocol should therefore not rely on such as IEEE 802.16. The protocol should therefore not rely on
specifics of IEEE 802.11 technology. specifics of IEEE 802.11 technology.
In all cases where the CAPWAP protocol messages contain specific In all cases where the CAPWAP protocol messages contain specific
layer 2 information elements, the definition of the protocol needs to layer 2 information elements, the definition of the protocol needs to
provide for extensibility so that these elements can be defined for provide for extensibility so that these elements can be defined for
specific layer 2 wireless protocols. This may entail assigning a specific layer 2 wireless protocols. This may entail assigning a
layer 2 wireless protocol type and version field to the message PDU. layer 2 wireless protocol type and version field to the message PDU.
Examples of other wireless protocols that might be supported include Examples of other wireless protocols that might be supported include
skipping to change at page 24, line 43 skipping to change at page 22, line 43
protocol to reflect the advances and provide a framework in which protocol to reflect the advances and provide a framework in which
they can be supported. they can be supported.
5.2.3. Support for New IEEE Requirements 5.2.3. Support for New IEEE Requirements
Classification: Architecture Classification: Architecture
Description: Description:
The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11 The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11
functionality and has made more thorough definitions for them. The functionality and has made more thorough definitions for the new
CAPWAP protocol must be able to incorporate these definitions with requirements. The CAPWAP protocol must be able to incorporate these
minimal change. Furthermore, a number of extensions for IEEE 802.11 definitions with minimal change. Furthermore, a number of extensions
are currently being standardized. The CAPWAP protocol must also be for IEEE 802.11 are currently being standardized. The CAPWAP
able to incorporate these new extensions with minimal change. protocol must also be able to incorporate these new extensions with
minimal change.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol MUST be openly designed to support new IEEE The CAPWAP protocol MUST be openly designed to support new IEEE
802.11 definitions and extensions. 802.11 definitions and extensions.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
There are a number of advances being made within the IEEE regarding There are a number of advances being made within the IEEE regarding
the functionality of IEEE 802.11 technology. Since this represents the functionality of IEEE 802.11 technology. Since this represents
one of the major wireless technologies in use today, it will be one of the major wireless technologies in use today, it will be
beneficial for CAPWAP to incorporate the relevant new extensions. beneficial for CAPWAP to incorporate the relevant new extensions.
Relation to Problem Statement: Relation to Problem Statement:
The Problem Statement presents an overview of the task of the IEEE The Problem Statement presents an overview of the task of the IEEE
802.11 working group. This group is focussed on defining the 802.11 working group. This group is focused on defining the
functional architecture of WTPs and new extensions for it. It is functional architecture of WTPs and new extensions for it. It is
necessary for the CAPWAP protocol to reflect these definitions and necessary for the CAPWAP protocol to reflect these definitions and
extensions. extensions.
5.2.4. Interconnection Objective 5.2.4. Interconnection Objective
Classification: Architecture Classification: Architecture
Description: Description:
Large scale WLAN deployments are likely to use a variety of Large-scale WLAN deployments are likely to use a variety of
interconnection technologies between different devices of the interconnection technologies between different devices of the
network. It should therefore be possible for the CAPWAP protocol to network. It should therefore be possible for the CAPWAP protocol to
operate over various interconnection technologies. operate over various interconnection technologies.
As a result of realizing this objective, the protocol will be capable As a result of realizing this objective, the protocol will be capable
of operation over both IPv4 and IPv6. It will also be designed such of operation over both IPv4 and IPv6. It will also be designed such
that it can operate within tightly administered networks, such as that it can operate within tightly administered networks, such as
enterprise networks, or on open, public access networks. For enterprise networks, or on open, public access networks. For
example, VLAN tunnels can be used across different types of networks example, VLAN tunnels can be used across different types of networks
over which CAPWAP will operate. over which CAPWAP will operate.
skipping to change at page 26, line 9 skipping to change at page 24, line 18
among various WTPs and WLAN controllers. As such, the motivation for among various WTPs and WLAN controllers. As such, the motivation for
this requirement is for the protocol to be operable independent of this requirement is for the protocol to be operable independent of
underlying interconnection technologies. underlying interconnection technologies.
Relation to Problem Statement: Relation to Problem Statement:
The Problem Statement discusses the complexity of configuring large The Problem Statement discusses the complexity of configuring large
WLANs. The selection of available interconnection technologies for WLANs. The selection of available interconnection technologies for
large-scale deployments further intensifies this complexity. This large-scale deployments further intensifies this complexity. This
requirement avoids part of the complexity by advocating independence requirement avoids part of the complexity by advocating independence
of the operational aspects of the protocol from from underlying of the operational aspects of the protocol from underlying transport.
transport.
5.2.5. Access Control 5.2.5. Access Control
Classification: Operations Classification: Operations
Description: Description:
This objective focuses on the informational needs of WLAN access This objective focuses on the informational needs of WLAN access
control and specifically the role of the CAPWAP protocol in control and specifically the role of the CAPWAP protocol in
transporting this information between WTPs and their WLAN controller. transporting this information between WTPs and their WLAN controller.
The following are some specific information aspects that need to be The following are some specific information aspects that need to be
transported by the CAPWAP protocol; transported by the CAPWAP protocol:
i. IEEE 802.11 association and authentication i. IEEE 802.11 association and authentication
The association of wireless clients is distinct for initial and The association of wireless clients is distinct for initial and
roaming cases. As a result, access control mechanisms requires roaming cases. As a result, access control mechanisms require
specific contextual information regarding each case. Additionally, specific contextual information regarding each case. Additionally,
load balancing, QoS, security and congestion information in both load balancing, QoS, security, and congestion information in both
wireless medium segments and switching segments need to be wireless medium segments and switching segments need to be
considered. considered.
ii. WTP Access Control ii. WTP Access Control
In addition to controlling access for wireless clients, it is also In addition to controlling access for wireless clients, it is also
necessary to control admission of new WTPs. Given the threat of necessary to control admission of new WTPs. Given the threat of
rogue WTPs, it is important for CAPWAP to relay appropriate rogue WTPs, it is important for CAPWAP to relay appropriate
authentication information between new WTPs and the WLAN controller. authentication information between new WTPs and the WLAN controller.
skipping to change at page 27, line 18 skipping to change at page 25, line 26
Broadly, it relates the problem of managing the complexity scale of Broadly, it relates the problem of managing the complexity scale of
such networks. With collective information of both switching and such networks. With collective information of both switching and
wireless medium segments, realizing this objective will help control wireless medium segments, realizing this objective will help control
and manage complexity. and manage complexity.
5.3. Non-Objectives 5.3. Non-Objectives
The following objectives have been prioritized as non-objectives The following objectives have been prioritized as non-objectives
during the course of working group consultations. They have been during the course of working group consultations. They have been
prioritized so in the context of CAPWAP and its considerations. They prioritized so in the context of CAPWAP and its considerations. They
may however be applicable in alternative contexts. may, however, be applicable in alternative contexts.
5.3.1. Support for Non-CAPWAP WTPs 5.3.1. Support for Non-CAPWAP WTPs
Classification: Architecture Classification: Architecture
Description: Description:
The CAPWAP protocol should provide an engine-mechanism to spring WTP The CAPWAP protocol should provide an engine-mechanism to spring WTP
auto-configuration and/or software version updates and should support auto-configuration and/or software version updates and should support
integration with existing network management system. WLAN controller integration with existing network management system. WLAN controller
skipping to change at page 27, line 50 skipping to change at page 26, line 15
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
It is expected that in many cases, the centralized WLAN architecture It is expected that in many cases, the centralized WLAN architecture
will be deployed incrementally with legacy systems. In this regard, will be deployed incrementally with legacy systems. In this regard,
it is necessary for the protocol to be used in scenarios with mixed it is necessary for the protocol to be used in scenarios with mixed
WLAN devices. WLAN devices.
Relation to Problem Statement: Relation to Problem Statement:
The Problem Statement highlights management complexity as a major The Problem Statement highlights management complexity as a major
issue with large WLANs. One part of this comlpexity can be related issue with large WLANs. One part of this complexity can be related
to the incremental deployment of centralized WLAN devices for which to the incremental deployment of centralized WLAN devices for which
this objective is applicable. this objective is applicable.
5.3.2. Technical Specifications 5.3.2. Technical Specifications
Classification: General Classification: General
Description: Description:
The CAPWAP protocol must not require AC and WTP vendors to share The CAPWAP protocol must not require AC and WTP vendors to share
skipping to change at page 28, line 29 skipping to change at page 26, line 43
be achieved. be achieved.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
It is beneficial for WLAN equipment vendors to refer to a single set It is beneficial for WLAN equipment vendors to refer to a single set
of specifications while implementing the CAPWAP protocol. This helps of specifications while implementing the CAPWAP protocol. This helps
to ease and quicken the development process. to ease and quicken the development process.
Relation to Problem Statement: Relation to Problem Statement:
This requirement is based on WG discussions that have determined to This requirement is based on WG discussions that have been determined
be important for CAPWAP. to be important for CAPWAP.
This objective has been prioritized as a non objective as it is a This objective has been prioritized as a non-objective as it is a
duplicate of the Protocol Specifications objective (Section 5.1.12). duplicate of the Protocol Specifications objective (Section 5.1.12).
5.4. Operator Requirements 5.4. Operator Requirements
The following objectives have been provided by network service The following objectives have been provided by network service
operators. They represent the requirements from those ultimately operators. They represent the requirements from those ultimately
deploying the CAPWAP protocol in their WLANs. deploying the CAPWAP protocol in their WLANs.
5.4.1. AP Fast Handoff 5.4.1. AP Fast Handoff
Classification: Operations Classification: Operations
Description: Description:
Network service operators consider handoffs crucially because of the Network service operators consider handoffs crucial because of the
mobile nature of their customers. In this regard, the CAPWAP mobile nature of their customers. In this regard, the CAPWAP
protocol should not adversely affect AP fast handoff procedures. The protocol should not adversely affect AP fast-handoff procedures. The
protocol may support optimizations for fast handoff procedures so as protocol may support optimizations for fast handoff procedures so as
to allow better support for real-time services during handoffs. to allow better support for real-time services during handoffs.
Protocol Requirement: Protocol Requirement:
CAPWAP protocol operations MUST NOT impede or obstruct the efficacy CAPWAP protocol operations MUST NOT impede or obstruct the efficacy
of AP fast handoff procedures. of AP fast-handoff procedures.
6. Summary and Conclusion 6. Summary and Conclusion
The objectives presented in this document address three main aspects The objectives presented in this document address three main aspects
of the CAPWAP protocol, namely; of the CAPWAP protocol, namely:
i. Architecture i. Architecture
ii. Operations ii. Operations
iii. Security iii. Security
These requirements are aimed to focus standardization efforts on a These requirements are aimed at focusing standardization efforts on a
simple, interoperable protocol for managing large-scale WLANs. The simple, interoperable protocol for managing large-scale WLANs. The
architecture requirements specify the structural features of the architecture requirements specify the structural features of the
protocol such as those relating to WTP types (local-MAC and split- protocol such as those relating to WTP types (local-MAC and split-
MAC) and WTP structures (logical groups). The operations MAC) and WTP structures (logical groups). The operations
requirements address the functional aspects dealing with WTP requirements address the functional aspects dealing with WTP
configuration and management. Finally, the security requirements configuration and management. Finally, the security requirements
cover authentication and integrity aspects of protocol exchanges. cover authentication and integrity aspects of protocol exchanges.
The objectives have additionally been prioritized to reflect their The objectives have additionally been prioritized to reflect their
immediate significance to the development and evaluation of an immediate significance to the development and evaluation of an
interoperable CAPWAP protocol. The priorities are Mandatory and interoperable CAPWAP protocol. The priorities are Mandatory and
Accepted, Desirable and Non-objectives. They reflect working group Accepted, Desirable, and Non-Objectives. They reflect working group
consensus on the effectiveness of the requirements in the context of consensus on the effectiveness of the requirements in the context of
protocol design. protocol design.
Additionally, this document includes requirements from network Additionally, this document includes requirements from network
service operators that have been derived based on their experience in service operators that have been derived based on their experience in
operating large- scale WLANs. operating large- scale WLANs.
The resulting requirements from this document will be used in The resulting requirements from this document will be used in
conjunction with the CAPWAP Problem Statement [RFC3990] and CAPWAP conjunction with the CAPWAP Problem Statement [RFC3990] and CAPWAP
Architecture Taxonomy [RFC4118] to develop and evalute an Architecture Taxonomy [RFC4118] to develop and evaluate an
interoperable protocol for the control and provisioning of WTPs in interoperable protocol for the control and provisioning of WTPs in
large-scale WLANs. large-scale WLANs.
7. Security Considerations 7. Security Considerations
The CAPWAP framework highlights support for both local-MAC and split- The CAPWAP framework highlights support for both local-MAC and
MAC WTPs. In deployments where both types of WTPs are used, it is split-MAC WTPs. In deployments where both types of WTPs are used, it
crucial to ensure that each be secured in consideration of their is crucial to ensure that each be secured in consideration of its
capabilities. The Architecture Taxonomy illustrates how different capabilities. The Architecture Taxonomy illustrates how different
WTPs incorporate varying levels of functionalities. Development of WTPs incorporate varying levels of functionalities. Development of
the CAPWAP protocol should ensure that the deployment of both local- the CAPWAP protocol should ensure that the deployment of both local-
MAC and split-MAC WTPs within a single WLAN do not present loopholes MAC and split-MAC WTPs within a single WLAN do not present loopholes
for security compromises. for security compromises.
In shared WLAN deployments made of a number of logical groups, In shared WLAN deployments made of a number of logical groups,
traffic from each group needs to be mutually separated. So in traffic from each group needs to be mutually separated. So in
addition to protocol related exchanges, data traffic from wireless addition to protocol-related exchanges, data traffic from wireless
terminals should also be segregated with respect to the logical terminals should also be segregated with respect to the logical
groups to which they belong. It should not be possible for data or groups to which they belong. It should not be possible for data or
control traffic from one logical group to stray to or influence control traffic from one logical group to stray to or influence
another logical group. another logical group.
The use of IEEE 802.11i over the centralized WLAN architecture allows The use of IEEE 802.11i over the centralized WLAN architecture allows
for implementations in which the PMK is shared across WTPs. This for implementations in which the PMK is shared across WTPs. This
raises the ambiguity between legitimate sharing and illegitimate raises the ambiguity between legitimate sharing and illegitimate
copies. Wireless terminals may unknowingly fall prey to or exploit copies. Wireless terminals may unknowingly fall prey to or exploit
this ambiguity. The resolution of this issue is currently being this ambiguity. The resolution of this issue is currently being
evaluted by the IEEE 802 and IETF liaisons. evaluated by the IEEE 802 and IETF liaisons.
The low-cost of launching attacks on WLANs makes the CAPWAP protocol The low cost of launching attacks on WLANs makes the CAPWAP protocol
a target. A first step in securing against any form of attacks is to a target. A first step in securing against any form of attacks is to
continuously monitor the WLAN for conditions of potential threats continuously monitor the WLAN for conditions of potential threats
from rogue WTPs or wireless terminals. For example, profiles for DoS from rogue WTPs or wireless terminals. For example, profiles for DoS
and replay attacks need to be considered for the CAPWAP protocol to and replay attacks need to be considered for the CAPWAP protocol to
effectively monitor security conditions. effectively monitor security conditions.
The open environment of many WLAN deployments makes physical security The open environment of many WLAN deployments makes physical security
breaches highly probable. Compromises resulting from theft and breaches highly probable. Compromises resulting from theft and
physical damage must be considered during protocol development. For physical damage must be considered during protocol development. For
instance, it should not be possible for a single compromised WTP to instance, it should not be possible for a single compromised WTP to
affect the WLAN as a whole. affect the WLAN as a whole.
Considering asymmetric, non-mutual authentication between WTPs and Considering asymmetric, non-mutual authentication between WTPs and
WLAN controller, there is a risk of a rogue participant exploiting the WLAN controller, there is a risk of a rogue participant
such an arrangement. It is preferrable to avoid non-mutual exploiting such an arrangement. It is preferable to avoid non-mutual
authentication. In some cases, the legitimacy of the protocol authentication. In some cases, the legitimacy of the protocol
exchange participants may be verified externally, for example by exchange participants may be verified externally, for example, by
means of physical containment within a close environment. Asymmetric means of physical containment within a close environment. Asymmetric
authentication may be appropriate here without risk of security authentication may be appropriate here without risk of security
compromises. compromises.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the Working Group Chairs, Dorothy The authors would like to thank the working group chairs, Dorothy
Gellert and Mahalingam Mani, for their support and patience with this Gellert and Mahalingam Mani, for their support and patience with this
document. We would also like to thank participants of the Working document. We would also like to thank participants of the working
Group who have helped shape the objectives. In particular, the group who have helped shape the objectives. In particular, the
authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan
Harkins, T. Sridhar, Charles Clancy and Emek Sadot for their Harkins, T. Sridhar, Charles Clancy, and Emek Sadot for their
invaluable inputs. We also extend our gratitude to the IEEE 802.11 invaluable inputs. We also extend our gratitude to the IEEE 802.11
Ad-Hoc Committee for their evaluation of the document. The authors Ad-Hoc Committee for its evaluation of the document. The authors
also acknowledge the contributions from Meimei Dang, Satoshi Iino, also acknowledge the contributions from Meimei Dang, Satoshi Iino,
Mikihito Sugiura and Dong Wang. Mikihito Sugiura, and Dong Wang.
9. References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
Provisioning for Wireless Access Points (CAPWAP) Problem Provisioning for Wireless Access Points (CAPWAP) Problem
Statement", RFC 3990, February 2005. Statement", RFC 3990, February 2005.
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005. (CAPWAP)", RFC 4118, June 2005.
10. Informative References
[802.11] IEEE Standard 802.11, "Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", June 2003.
[802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC)
Security Enhancements", July 2004.
[802.11e] IEEE Standard 802.11e, "Medium Access Control (MAC)
Quality of Service Enhancements", November 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
Authors' Addresses Authors' Addresses
Saravanan Govindan Saravanan Govindan
Panasonic Singapore Laboratories Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue #06-3530, Tai Seng Avenue
Singapore 534 415 Singapore 534 415
Singapore Singapore
Phone: +65 6550 5441 Phone: +65 6550 5441
Email: saravanan.govindan@sg.panasonic.com EMail: saravanan.govindan@sg.panasonic.com
Zhonghui Yao Zhonghui Yao
Huawei Longgang Production Base Huawei Longgang Production Base
Shenzhen 518 129 Shenzhen 518 129
P. R. China P. R. China
Phone: +86 755 2878 0808 Phone: +86 755 2878 0808
Email: yaoth@huawei.com EMail: yaoth@huawei.com
Wenhui Zhou Wenhui Zhou
China Mobile China Mobile
53A, Xibianmen Ave, Xuanwu District 53A, Xibianmen Ave, Xuanwu District
Beijing 100 053 Beijing 100 053
P. R. China P. R. China
Phone: +86 10 6600 6688 ext.3061 Phone: +86 10 6600 6688 ext.3061
Email: zhouwenhui@chinamobile.com EMail: zhouwenhui@chinamobile.com
L. Lily Yang L. Lily Yang
Intel Corp. Intel Corp.
JF3-206, 2111 NE 25th Ave. JF3-206, 2111 NE 25th Ave.
Hilsboro, OR 97124 Hilsboro, OR 97124
USA USA
Phone: +1 503 264 8813 Phone: +1 503 264 8813
Email: lily.l.yang@intel.com EMail: lily.l.yang@intel.com
Hong Cheng Hong Cheng
Panasonic Singapore Laboratories Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue #06-3530, Tai Seng Avenue
Singapore 534 415 Singapore 534 415
Singapore Singapore
Phone: +65 6550 5447 Phone: +65 6550 5447
Email: hong.cheng@sg.panasonic.com EMail: hong.cheng@sg.panasonic.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 35, line 29 skipping to change at page 32, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 128 change blocks. 
325 lines changed or deleted 331 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/