draft-ietf-capwap-objectives-02.txt   draft-ietf-capwap-objectives-03.txt 
Network Working Group S. Govindan (Editor) Network Working Group S. Govindan (Editor)
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: October 16, 2005 ZH. Yao Expires: December 19, 2005 ZH. Yao
Huawei Huawei
WH. Zhou WH. Zhou
China Mobile China Mobile
L. Yang L. Yang
Intel Intel
H. Cheng H. Cheng
Panasonic Panasonic
April 14, 2005 June 17, 2005
Objectives for Control and Provisioning of Wireless Access Points Objectives for Control and Provisioning of Wireless Access Points
(CAPWAP) (CAPWAP)
draft-ietf-capwap-objectives-02.txt draft-ietf-capwap-objectives-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 16, 2005. This Internet-Draft will expire on December 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 3, line 24 skipping to change at page 2, line 31
5.1.2 Support for Traffic Separation . . . . . . . . . . . . 9 5.1.2 Support for Traffic Separation . . . . . . . . . . . . 9
5.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 10 5.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 10
5.1.4 Configuration Consistency . . . . . . . . . . . . . . 11 5.1.4 Configuration Consistency . . . . . . . . . . . . . . 11
5.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 12 5.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 12
5.1.6 Monitoring and Exchange of System-wide Resource 5.1.6 Monitoring and Exchange of System-wide Resource
State . . . . . . . . . . . . . . . . . . . . . . . . 12 State . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.7 Resource Control Objective . . . . . . . . . . . . . . 13 5.1.7 Resource Control Objective . . . . . . . . . . . . . . 13
5.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 15 5.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 15
5.1.9 System-wide Security . . . . . . . . . . . . . . . . . 16 5.1.9 System-wide Security . . . . . . . . . . . . . . . . . 16
5.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 17 5.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 17
5.1.11 Interoperability Objective . . . . . . . . . . . . . 18 5.1.11 Interoperability Objective . . . . . . . . . . . . . 19
5.1.12 Protocol Specifications . . . . . . . . . . . . . . 20 5.1.12 Protocol Specifications . . . . . . . . . . . . . . 20
5.1.13 Vendor Independence . . . . . . . . . . . . . . . . 20 5.1.13 Vendor Independence . . . . . . . . . . . . . . . . 21
5.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 21 5.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 21
5.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 21 5.1.15 NAT Traversal . . . . . . . . . . . . . . . . . . . 22
5.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 22 5.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 22
5.2.2 Support for Future Wireless Technologies . . . . . . . 22 5.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 23
5.2.3 Support for New IEEE Requirements . . . . . . . . . . 23 5.2.2 Support for Future Wireless Technologies . . . . . . . 23
5.2.4 Interconnection Objective . . . . . . . . . . . . . . 24 5.2.3 Support for New IEEE Requirements . . . . . . . . . . 24
5.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 25 5.2.4 Interconnection Objective . . . . . . . . . . . . . . 25
5.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 26 5.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 26
5.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 26 5.3 Non-Objectives . . . . . . . . . . . . . . . . . . . . . . 27
5.3.2 Technical Specifications . . . . . . . . . . . . . . . 26 5.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 27
5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 27 5.3.2 Technical Specifications . . . . . . . . . . . . . . . 27
5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 27 5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 28
6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 28 5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . 29 6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . 33
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
This document follows the terminologies of [I-D.ietf-capwap-arch]. This document follows the terminologies of [I-D.ietf-capwap-arch].
Additionally, the following terms are defined; Additionally, the following terms are defined;
Centralized WLAN: A WLAN based on the centralized WLAN Architecture
[I-D.ietf-capwap-arch].
Switching Segment: Those aspects of a centralized WLAN that primarily Switching Segment: Those aspects of a centralized WLAN that primarily
deal with switching or routing of control and data information deal with switching or routing of control and data information
between Wireless Termination Points (WTPs) and the WLAN controller. between Wireless Termination Points (WTPs) and the WLAN controller.
Wireless Medium Segment: Those aspects of a centralized WLAN that Wireless Medium Segment: Those aspects of a centralized WLAN that
primarily deal with the wireless interface between WTPs and wireless primarily deal with the wireless interface between WTPs and wireless
terminals. The Wireless Medium Segment is specific to layer 2 terminals. The Wireless Medium Segment is specific to layer 2
wireless technology, such as IEEE 802.11. wireless technology, such as IEEE 802.11.
CAPWAP Framework: A term that covers the local-MAC and split-MAC CAPWAP Framework: A term that covers the local-MAC and split-MAC
designs of the Centralized WLAN Architecture. Standardization designs of the Centralized WLAN Architecture. Standardization
efforts are focussed on these designs. efforts are focussed on these designs.
CAPWAP Protocol: The protocol between WLAN controller and WTPs in the CAPWAP Protocol: The protocol between WLAN controller and WTPs in the
CAPWAP framework. It facilitates control, management and CAPWAP framework. It facilitates control, management and
provisioning of WTPs in an interoperable manner. 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 3. 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 to 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
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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 [I-D.ietf-capwap-arch] is a the solutions. The Architecture Taxonomy [I-D.ietf-capwap-arch] is a
result of this survey in which major WLAN architecture families are result of this survey in which major WLAN architecture families are
classified. Broadly, these are the autonomous, centralized WLAN and classified. Broadly, these are the autonomous, centralized WLAN and
distributed mesh architectures. distributed mesh architectures.
The Architecture Taxonomy identified that the current majority of The Architecture Taxonomy identified the centralized WLAN
large-scale deployments follow the centralized WLAN architecture in architecture as one in which portions of the wireless medium access
which portions of the wireless medium access control (MAC) operations control (MAC) operations are centralized in a WLAN controller. This
are centralized in a WLAN controller. This centralized WLAN centralized WLAN architecture is further classified into remote-MAC,
architecture is further classified into remote-MAC, split-MAC and split-MAC and local-MAC designs. Each differs in the degree of
local-MAC designs. Each differs in the degree of separation of separation of wireless MAC layer capabilities between WTPs and WLAN
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 controling 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.
4. Objectives Overview 4. Objectives Overview
skipping to change at page 8, line 17 skipping to change at page 8, line 17
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 Additionally, one category is provided for requirements gathered from
network service operators. These are specific need that arise from network service operators. These are specific need that arise from
operators' experiencese in deploying and managing large-scale WLANs. operators' experiencese in deploying and managing large-scale WLANs.
The priorities are; The priorities are;
i. Mandatory and Accepted Objectives i. Mandatory and Accepted Objectives
ii. Desirable Objectives ii. Desirable Objectives
iii. Rejected Objectives iii. Non-Objectives
iv. Operator Requirements 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.
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
skipping to change at page 8, line 50 skipping to change at page 8, line 50
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. For example, each BSSID of a WTP is referred to as a logical group [Section 2]. So WLANs are
physical WTP can be construed to be a logical group. So WLANs are managed in terms of logical groups instead of physical WTPs. Logical
managed in terms of logical groups instead of physical WTPs. Virtual groups are based on BSSIDs and other types of virtual APs.
APs are examples of logical groups.
Protocol Requirement: Protocol Requirement:
WLAN deployment trends require the CAPWAP protocol to be capable of The CAPWAP protocol MUST be capable of controlling and managing
controlling and managing physical WTPs in terms of logical groups. physical WTPs in terms of logical groups including BSSID-based
groups.
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 its 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 simlper 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:
skipping to change at page 9, line 43 skipping to change at page 9, line 43
with large-scale deployments by consolidating portions of wireless with large-scale deployments by consolidating portions of wireless
MAC functionality at a central WLAN controller and distributing the MAC functionality at a central WLAN controller and distributing the
remaining across WTPs. As a result, WTPs and WLAN controller remaining across WTPs. As a result, WTPs and WLAN controller
exchange control and data information between them. This objective exchange control and data information between them. This objective
states that control and data aspects of the exchanges be mutually states that control and data aspects of the exchanges be mutually
separated for further simplicity. This will allow solutions for each separated for further simplicity. This will allow solutions for each
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 being particular, given the likelihood of different logical groups, such as
managed by different administrators, separation of control and data those established by different virtual APs, being managed by
is a first step towards individually containing and securing the different administrators, separation of control and data is a first
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 be mutually separated to maintain the integrity and independence of
the logical groups. the logical groups.
Protocol Requirement: Protocol Requirement:
In order to maintain the separation of control and data traffic, the The CAPWAP Protocol MUST define transport control messages such that
CAPWAP protocol is required to define control messages such that they the transport of control messages is separate from the transport of
do not involve piggybacking or other combination with data traffic. 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, such separation provides for the separation of data and Furthermore, this requirement will help remotely located WTPs to
control paths. This will help remotely located WTPs to handle data handle data traffic in alternative ways without the need for
traffic in alternative ways without the need for forwarding them forwarding them across a wide network to the WLAN controller.
across a wide network to the WLAN controller.
Separation of WTP control and data also aids in the secure Separation of WTP control and data also aids in the secure
realization of shared WLAN deployments. realization of shared WLAN deployments.
Relation to Problem Statement: Relation to Problem Statement:
Broadly, this objective relates to the challenge of managing Broadly, this objective relates to the challenge of managing
complexity in large-scale WLANs. The requirement for traffic complexity in large-scale WLANs. The requirement for traffic
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.
skipping to change at page 10, line 47 skipping to change at page 10, line 44
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 should 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.
skipping to change at page 11, line 23 skipping to change at page 11, line 19
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 which
need to be configured and managed in a consistent manner. This is need to be configured and managed in a consistent manner. The main
possible by providing the centralized WLAN controller with regular concern in ensuring consistency is availability of appropriate
updates on the state of their operations. The centralized WLAN information corresponding to WTP configuration states. So
controller can in turn apply information from the regular updates to configuration consistency can be achieved by providing the
consistently configure the WTPs. centralized WLAN controller with regular updates on the state of WTP
operations. The centralized WLAN controller can in turn apply
information from the regular updates to ensure consistently among the
WTPs.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol must allow for regular exchanges of state The CAPWAP protocol MUST include support for regular exchanges of
information between WTPs and WLAN controller. Examples of state state information between WTPs and WLAN controller. Examples of
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 has access to regular state information can in turn A protocol that provides access to regular state information can in
use this to enhance WLAN performance. The CAPWAP protocol will be turn be used to enhance WLAN configuration and performance. The
better equipped to address configuration related problems with the CAPWAP protocol will be better equipped to address configuration
state information. So with greater state information, control and related problems with the regularly available state information. So
management operations can be improved. with greater state information, control and management operations can
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 fundamentally addresses this challenge by of a WLAN. This objective addresses the fundamental issue behind
providing relevant state information based on which configurations this - availability of timely state information.
can be appropriately maintained.
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
highlights the need for the CAPWAP protocol to trigger the delivery highlights the need for the CAPWAP protocol to trigger the delivery
of appropriate versions of firmware to WTPs. The actual delivery of of appropriate versions of firmware to WTPs. The actual delivery of
firmware need not be inclusive to the prtoocol. firmware need not be inclusive to the protocol.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol must support a trigger for delivery of firmware The CAPWAP protocol MUST support a trigger for delivery of firmware
updates. updates.
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
appropriately equivalent. This in turn results in consistent compatible. This in turn results in consistent configuration and
configuration and simplified management. So the protocol benefits by simplified management. So the protocol benefits by including
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 has been identified as a
major challenge for large-scale WTPs. This objectives helps overcome major challenge for large-scale WTPs. This objectives helps overcome
the challenge by providing for a way for the protocol to initiate the challenge by providing for a way for the CAPWAP protocol to
delivery of equivalent versions of firmware to all WTPs. initiate delivery of firmware updates that are compatible among all
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 monitored.
skipping to change at page 13, line 16 skipping to change at page 13, line 17
should combine state information from them. For example, statistics should combine state information from them. For example, statistics
information and status signals from WTPs may be merged before being information and status signals from WTPs may be merged before being
exchanged. 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 effectivness 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:
skipping to change at page 14, line 9 skipping to change at page 14, line 10
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 while 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 Task In addition to IEEE 802.11e, there are a number of other IEEE 802.11
Groups that may affect network resources. These include IEEE TGk, Task Groups that may affect network resources. These include IEEE
TGu and TGv, which are currently under progress. CAPWAP should 802.11 TGk, TGu and TGv, which are currently under progress. CAPWAP
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 maintain IEEE 802.11e QoS mappings across The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to
the switching and wireless medium segments. equivalent QoS priorities across the switching and wireless medium
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
skipping to change at page 15, line 13 skipping to change at page 15, line 13
wide QoS is therefore critical for performance. wide QoS is 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 mutually authenticated. This is - WLAN controller and WTPs - to be explicitly mutually authenticated.
to ensure that rogue WTPs do not breach legitimate WLAN systems. For This is to ensure that rogue elements do not gain access to the WLAN
example, WTPs may need to regularly renew their authentication state system. Rogue WTPs should not be allowed to breach legitimate WLANs
with the WLAN controller. and at the same time rogue WLAN controllers should not be allowed to
gain control of legitimate WTPs. For example, WTPs may need to
regularly renew their authentication state with the WLAN controller
and similarly for WLAN controllers.
If authentication is performed via an authenticated key exchange,
future knowledge of derived keys is not sufficient for
authentication.
Any session keys used between the WLAN controller and WTP MUST be
mutually derived using entropy contributed by both parties. This
ensures that no one party has control over the resulting session
keys.
Once WTPs and WLAN controller have been mutually authenticated, Once WTPs and 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. This should cover illegitimate modifications to
protocol exchanges, eavesdropping and DoS attacks, among other protocol exchanges, eavesdropping and DoS attacks, among other
potential compromises. So the protocol must be provide potential compromises. So the protocol must be provide
confidentiality, integrity and authenticity for those exchanges. 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 for
individual WTP breaches to affect the security of the WLAN as a individual WTP breaches to affect the security of the WLAN as a
whole. So WTP mis-use will be protected against. whole. So WTP mis-use 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.
While mutual authentication is necessary for CAPWAP, the protocol CAPWAP MUST NOT prevent the use of asymmetric authentication. The
should not prevent the use of asymmetric, non-mutual authentication. security considerations of such asymmetric authentication are
The security considerations of such asymmetric authentication are
described in the Security Considerations section. described in the Security Considerations section.
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 must also ensure that information
exchanges between them are secured. exchanges between them are secured.
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 assure 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
contains untrusted links. Such links could be leveraged by rogue
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
associated terminals to either redirect or compromise terminal
traffic. These security concerns can be mitigated with this
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 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
skipping to change at page 16, line 35 skipping to change at page 17, line 5
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 PMK
sharing in the CAPWAP framework. This objective highlights the need sharing in the CAPWAP framework. This objective highlights the need
to prevent exploitation of this ambiguity by rogue wireless clients. to prevent exploitation of this ambiguity by rogue wireless clients.
It is to ensure that any ambiguities arising from the CAPWAP It is to ensure that any ambiguities arising from the CAPWAP
framework are not cause for security breaches. framework are not cause for security breaches.
Protocol Requirement: Protocol Requirement:
The design of the CAPWAP protocol should not allow for any The design of the CAPWAP protocol MUST NOT allow for any compromises
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
it is relatively inexpensive for rogue individuals to mount attacks, it is relatively inexpensive for rogue individuals to mount attacks,
it is important that WLAN systems are protected against them. it is important that WLAN systems are protected against them.
Adequate mechanisms to thwart such external threats will be of Adequate mechanisms to thwart such external threats will be of
tremendous benefit to the WLAN systems controlled and managed with tremendous benefit to the WLAN systems controlled and managed with
the CAPWAP protocol. the CAPWAP protocol.
skipping to change at page 17, line 49 skipping to change at page 18, line 19
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
skipping to change at page 19, line 25 skipping to change at page 19, line 46
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 equates
to alternative interfaces with a WLAN controller. So the CAPWAP to 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 the outcome of the IEEE AP functionalities will be based on AP functionality documents produced
Functionality (APF) Ad-Hoc Committee. The APF Ad-Hoc Committee will by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee.
provide appropriate insight in to specific functional blocks which
may be used for finer capabilities negotiations within the CAPWAP
protocol.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol must include sufficient capabilities negotiations The CAPWAP protocol MUST include sufficient capabilities negotiations
to distinguish between major types of WTPs. to distinguish between major types of WTPs.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The benefits of realizing this architecture objective are both The benefits of realizing this architecture objective are both
technical and practical. First, there are substantial overlaps in technical and practical. First, there are substantial overlaps in
the control operations of local-MAC and split-MAC architecture the control operations of local-MAC and split-MAC architecture
designs. The Architecture Taxonomy tabulates major common features designs. The Architecture Taxonomy tabulates major common features
of the two designs. As a result, it is technically practical to of the two designs. As a result, it is technically practical to
devise a single protocol that manages both types of devices. devise a single protocol that manages both types of devices.
skipping to change at page 20, line 29 skipping to change at page 20, line 46
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 run 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 AC vendor or any person can implement the CAPWAP protocol Any WTP or WLAN controller vendor or any person MUST be able to
from the specification itself and by that it is required that all implement the CAPWAP protocol from the specification itself and by
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 determined to
be important for CAPWAP. 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 results in equipment vendors
constantly modifying their devices. In many cases, developments are constantly modifying their devices. In many cases, developments are
independently made for ACs and WTPs. The CAPWAP protocol should not independently made for WLAN controllers and WTPs. The CAPWAP
affect the the independence of device modificaitons. protocol should not affect the the independence of device
modificaitons.
Protocol Requirement: Protocol Requirement:
A WTP vendor can make modifications to hardware without any AC vendor A WTP vendor SHOULD be able to make modifications to hardware without
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 determined to
be important for CAPWAP. 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 MAC. It The CAPWAP protocol must not be specified for a particular type of
should be compatible with both local-MAC and split-MAC WTPs. wireless MAC design. It should be compatible with both local-MAC and
split-MAC WTPs.
Protocol Requirement: Protocol Requirement:
WTP vendors must not be bound to a specific MAC. The CAPWAP protocol MUST NOT limit WTP vendors in their choice of
local-MAC or split-MAC WTPs. It MUST be compatible with both types
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 MAC that they consider best for flexibility in selecting the type of wireless MAC design that they
deployments. consider best for deployments.
Relation to Problem Statement:
This requirement is based on WG discussions that have determined to
be important for CAPWAP.
5.1.15 NAT Traversal
Classification: General
Description:
WLAN deployments may involve WTPs and the WLAN controller
communicating across NATs. The CAPWAP protocol must be capable of
operating across topologies that contain known NAT configurations.
It requires appropriate discovery and identification mechanisms
NAT traversal.
Protocol Requirement:
The CAPWAP protocol MUST NOT prevent the operation of established
methods of NAT traversal.
Motivation and Protocol Benefits:
The wide-spread adoption of WLANs raises the possibility for WLAN
topologies containing NATs. It is important for the CAPWAP protocol
to be applicable within such topologies. This requirement aims to
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 determined to
be important for CAPWAP. 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
skipping to change at page 22, line 23 skipping to change at page 23, line 23
associated with different service providers or WLAN domains. As a associated with different service providers or WLAN domains. As a
result, the authentication needs withing them will be different. result, the authentication needs withing them will be different.
While CAPWAP is required to support IEEE 802.11i, it is also While CAPWAP is required to support IEEE 802.11i, it is also
necessary for it to support other authentication mechanisms. For necessary for it to support other authentication mechanisms. For
example, one logical group may use IEEE 802.11i while another may use example, one logical group may use IEEE 802.11i while another may use
web authentication. CAPWAP must be able to operate in such shared web authentication. CAPWAP must be able to operate in such shared
WLANs. 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 which may not be appropriate for a particular deployment.
Relation to Problem Statement: Relation to Problem Statement:
skipping to change at page 23, line 11 skipping to change at page 24, line 11
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
but are not limited to 802.16e, 802.15.x, etc. but are not limited to 802.16e, 802.15.x, etc.
Protocol Requirement: Protocol Requirement:
CAPWAP protocol messages must be designed to be extensible for CAPWAP protocol messages MUST be designed to be extensible for
specific layer 2 wireless technologies. It should not be limited to specific layer 2 wireless technologies. It should not be limited to
the transport of elements relating to IEEE 802.11. the transport of elements relating to IEEE 802.11.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
There are many benefits to an extensible protocol. It allows for There are many benefits to an extensible protocol. It allows for
application in different networks and provides greater scope. application in different networks and provides greater scope.
Furthermore, service providers require WLAN solutions that will be Furthermore, service providers require WLAN solutions that will be
able to meet current and future market requirements. able to meet current and future market requirements.
skipping to change at page 23, line 35 skipping to change at page 24, line 35
other standards bodies like the IEEE. It is important for the CAPWAP other standards bodies like the IEEE. It is important for the CAPWAP
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 is currently reviewing IEEE 802.11 functionality. It is The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11
expected that the review by the IEEE AP Functionality Ad-Hoc functionality and has made more thorough definitions for them. The
Committee may result in new definitions of functional blocks, CAPWAP protocol must be able to incorporate these definitions with
interfaces or information flows. The CAPWAP protocol must be able to minimal change. Furthermore, a number of extensions for IEEE 802.11
incorporate these revisions with minimal change. are currently being standardized. The CAPWAP 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
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 focussed on defining the
functional architecture of WTPs. It is necessary for the CAPWAP functional architecture of WTPs and new extensions for it. It is
protocol to reflect these definitions. necessary for the CAPWAP protocol to reflect these definitions and
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
skipping to change at page 24, line 32 skipping to change at page 25, line 34
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.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol must not be constrained to specific underlying The CAPWAP protocol MUST NOT be constrained to specific underlying
transport mechanisms. transport mechanisms.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
The main aim of the CAPWAP protocol is to achieve interoperability The main aim of the CAPWAP protocol is to achieve interoperability
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:
skipping to change at page 25, line 36 skipping to change at page 26, line 36
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.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol must be capable of exchanging information The CAPWAP protocol MUST be capable of exchanging information
required for access control of WTPs and wireless terminals. required for access control of WTPs and wireless terminals.
Motivation and Protocol Benefits: Motivation and Protocol Benefits:
Due to the scale of deployments in which CAPWAP will be employed, Due to the scale of deployments in which CAPWAP will be employed,
comprehensive access control is crucial. The effectiveness of access comprehensive access control is crucial. The effectiveness of access
control in turn is affected by the information on which such control control in turn is affected by the information on which such control
is based. As a result, this objective has critical relevance to a is based. As a result, this objective has critical relevance to a
CAPWAP protocol. CAPWAP protocol.
Relation to Problem Statement: Relation to Problem Statement:
This objective addresses the issue of access control in large WLANs. This objective addresses the issue of access control in large WLANs.
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 Rejected Objectives 5.3 Non-Objectives
The following objectives have been rejected during the course of The following objectives have been prioritized as non-objectives
working group consultations. These objectives have been rejected in during the course of working group consultations. They have been
the context of CAPWAP and its considerations. They may however be prioritized so in the context of CAPWAP and its considerations. They
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
as a management agent is optional. as a management agent is optional.
If entities other than WLAN controllers manage some aspects of WTPs, If entities other than WLAN controllers manage some aspects of WTPs,
such as software downloads, the CAPWAP protocol may be used for WTPs such as software downloads, the CAPWAP protocol may be used for WTPs
to notify WLAN controllers of any changes made by the other entities. to notify WLAN controllers of any changes made by the other entities.
Protocol Requirement: Protocol Requirement:
The CAPWAP protocol should be capable of recognizing legacy WTPs and The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and
existing network management systems. existing network management systems.
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:
skipping to change at page 27, line 11 skipping to change at page 28, line 11
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
technical specifications to establish compatibility. The protocol technical specifications to establish compatibility. The protocol
specifications alone must be sufficient for compatibility. specifications alone must be sufficient for compatibility.
Protocol Requirement: Protocol Requirement:
WTP vendors should not have to share technical specifications for WTP vendors SHOULD NOT have to share technical specifications for
hardware and software to AC vendors in order for interoperability to hardware and software to AC vendors in order for interoperability to
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 determined to
be important for CAPWAP. be important for CAPWAP.
This objective has been prioritized as rejected as it is a duplicate This objective has been prioritized as a non objective as it is a
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
skipping to change at page 27, line 49 skipping to change at page 28, line 49
Description: Description:
Network service operators consider handoffs crucially because of the Network service operators consider handoffs crucially 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
skipping to change at page 28, line 26 skipping to change at page 29, line 26
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 Rejected. 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 [I-D.ietf-capwap- conjunction with the CAPWAP Problem Statement [I-D.ietf-capwap-
problem-statement] and CAPWAP Architecture Taxonomy [I-D.ietf-capwap- problem-statement] and CAPWAP Architecture Taxonomy [I-D.ietf-capwap-
skipping to change at page 30, line 11 skipping to change at page 31, line 11
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 Harkins authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan
and T. Sridhar for their invaluable inputs. The authors also Harkins, T. Sridhar, Charles Clancy and Emek Sadot for their
acknowledge the contributions from Meimei Dang, Satoshi Iino, invaluable inputs. We also extend our gratitude to the IEEE 802.11
Ad-Hoc Committee for their evaluation of the document. The authors
also acknowledge the contributions from Meimei Dang, Satoshi Iino,
Mikihito Sugiura and Dong Wang. Mikihito Sugiura and Dong Wang.
9. References 9. References
[I-D.ietf-capwap-arch] [I-D.ietf-capwap-arch]
Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access for Control and Provisioning of Wireless Access
Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in
progress), November 2004. progress), November 2004.
skipping to change at page 30, line 42 skipping to change at page 31, line 44
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: sgovindan@psl.com.sg 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
skipping to change at page 31, line 38 skipping to change at page 32, line 38
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: hcheng@psl.com.sg Email: hong.cheng@sg.panasonic.com
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/