draft-ietf-capwap-objectives-01.txt   draft-ietf-capwap-objectives-02.txt 
Network Working Group S. Govindan (Editor) Network Working Group S. Govindan (Editor)
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: August 5, 2005 ZH. Yao Expires: October 16, 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
March 2005 April 14, 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-01.txt draft-ietf-capwap-objectives-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. 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 other groups may also distribute working documents as Internet-
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 August 5, 2005. This Internet-Draft will expire on October 16, 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
1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Objectives Overview . . . . . . . . . . . . . . . . . . . . 6 4. Objectives Overview . . . . . . . . . . . . . . . . . . . . 7
5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Mandatory and Accepted Objectives . . . . . . . . . . . . 7 5.1 Mandatory and Accepted Objectives . . . . . . . . . . . . 8
5.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 7 5.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 8
5.1.2 Support for Traffic Separation . . . . . . . . . . . . 8 5.1.2 Support for Traffic Separation . . . . . . . . . . . . 9
5.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 9 5.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 10
5.1.4 Configuration Consistency . . . . . . . . . . . . . . 10 5.1.4 Configuration Consistency . . . . . . . . . . . . . . 11
5.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 State . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.7 Resource Control Objective . . . . . . . . . . . . . . 12 5.1.7 Resource Control Objective . . . . . . . . . . . . . . 13
5.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 14 5.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 15
5.1.9 System-wide Security . . . . . . . . . . . . . . . . . 15 5.1.9 System-wide Security . . . . . . . . . . . . . . . . . 16
5.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 16 5.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 17
5.1.11 Interoperability Objective . . . . . . . . . . . . . 17 5.1.11 Interoperability Objective . . . . . . . . . . . . . 18
5.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 19 5.1.12 Protocol Specifications . . . . . . . . . . . . . . 20
5.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 19 5.1.13 Vendor Independence . . . . . . . . . . . . . . . . 20
5.2.2 Support for Future Wireless Technologies . . . . . . . 20 5.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 21
5.2.3 Support for New IEEE Requirements . . . . . . . . . . 21 5.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 21
5.2.4 Interconnection Objective . . . . . . . . . . . . . . 22 5.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 22
5.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 22 5.2.2 Support for Future Wireless Technologies . . . . . . . 22
5.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24 5.2.3 Support for New IEEE Requirements . . . . . . . . . . 23
5.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 24 5.2.4 Interconnection Objective . . . . . . . . . . . . . . 24
5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 24 5.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 25
5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 25 5.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 26
6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 26 5.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . 27 5.3.2 Technical Specifications . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 32
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].
skipping to change at page 5, line 36 skipping to change at page 6, line 36
The Architecture Taxonomy identified that the current majority of The Architecture Taxonomy identified that the current majority of
large-scale deployments follow the centralized WLAN architecture in large-scale deployments follow the centralized WLAN architecture in
which portions of the wireless medium access control (MAC) operations which portions of the wireless medium access control (MAC) operations
are centralized in a WLAN controller. This centralized WLAN are centralized in a WLAN controller. This centralized WLAN
architecture is further classified into remote-MAC, split-MAC and architecture is further classified into remote-MAC, split-MAC and
local-MAC designs. Each differs in the degree of separation of local-MAC designs. Each differs in the degree of separation of
wireless MAC layer capabilities between WTPs and WLAN controller. wireless MAC layer capabilities between WTPs and WLAN 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 that address the challenges of controling and provisioning large-
large-scale WLAN deployments. The realization of these objectives in scale WLAN deployments. The realization of these objectives in a
a CAPWAP protocol will ensure that WLAN equipment of major design CAPWAP protocol will ensure that WLAN equipment of major design types
types may be integrally deployed and managed. may be integrally deployed and managed.
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 architecture, operation and security requirements of managing large-
large-scale WLAN deployments. 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, 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 both
the protocol between WLAN controller and WTPs and also the WLAN the protocol between WLAN controller and WTPs and also the WLAN
system as a whole. system as a whole.
Additionally, a general classification is used for objectives
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 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;
skipping to change at page 7, line 32 skipping to change at page 8, line 32
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
[Ed. Note: Was 5.2.3i]
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
efficiency of their expenditures. efficiency of their expenditures.
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
skipping to change at page 8, line 25 skipping to change at page 9, line 23
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:
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 deployments. Consequently, deployment and management cost-
cost-efficiencies are realized. efficiencies are realized.
5.1.2 Support for Traffic Separation 5.1.2 Support for Traffic Separation
[Ed. Note: Was 5.2.7 and 5.2.3ii]
Classification: Operations Classification: Operations
Description: Description:
The centralized WLAN architecture simplifies complexity associated The centralized WLAN architecture simplifies complexity associated
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
skipping to change at page 9, line 38 skipping to change at page 10, line 34
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.
5.1.3 Wireless Terminal Transparency 5.1.3 Wireless Terminal Transparency
[Ed. Note: Was 5.2.4iii]
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.
skipping to change at page 10, line 24 skipping to change at page 11, line 18
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
[Ed. Note: Was 5.2.5i]
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. This is
possible by providing the centralized WLAN controller with regular possible by providing the centralized WLAN controller with regular
updates on the state of their operations. The centralized WLAN updates on the state of their operations. The centralized WLAN
controller can in turn apply information from the regular updates to controller can in turn apply information from the regular updates to
consistently configure the WTPs. consistently configure the WTPs.
skipping to change at page 11, line 13 skipping to change at page 12, line 7
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 fundamentally addresses this challenge by
providing relevant state information based on which configurations providing relevant state information based on which configurations
can be appropriately maintained. can be appropriately maintained.
5.1.5 Firmware Trigger 5.1.5 Firmware Trigger
[Ed. Note: Was 5.2.5i]
[Ed. Note: Was titled "Firmware Distribution]
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 prtoocol.
skipping to change at page 11, line 50 skipping to change at page 12, line 40
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 protocol to initiate
delivery of equivalent versions of firmware to all WTPs. delivery of equivalent versions of firmware to all WTPs.
5.1.6 Monitoring and Exchange of System-wide Resource State 5.1.6 Monitoring and Exchange of System-wide Resource State
[Ed. Note: Was 5.2.5ii]
[Ed. Note: Was titled "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.
In the wireless medium segment, the dynamic nature of the medium In the wireless medium segment, the dynamic nature of the medium
itself has to be monitored. Overall, there are also various itself has to be monitored. Overall, there are also various
statistics need to be considered for efficient WLAN operation. statistics need to be considered for efficient WLAN operation.
skipping to change at page 12, line 49 skipping to change at page 13, line 36
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
[Ed. Note: Was 5.2.6]
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.
skipping to change at page 14, line 13 skipping to change at page 14, line 47
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 The interaction and coordination between the two aspects of system-
system-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
[Ed. Note: Was 5.2.10]
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 mutually authenticated. This is
to ensure that rogue WTPs do not breach legitimate WLAN systems. For to ensure that rogue WTPs do not breach legitimate WLAN systems. For
example, WTPs may need to regularly renew their authentication state example, WTPs may need to regularly renew their authentication state
skipping to change at page 15, line 27 skipping to change at page 16, line 15
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
[Ed. Note: Was 5.2.11]
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.
skipping to change at page 16, line 24 skipping to change at page 17, line 10
This objective is based on the security needs highlighted in the This objective is based on the security needs highlighted in the
Problem Statement. Specifically, the Problem Statement discusses the Problem Statement. Specifically, the Problem Statement discusses the
effects of the shared wireless medium. This represents the external effects of the shared wireless medium. This represents the external
aspects of the CAPWAP framework from which certain threats can arise. aspects of the CAPWAP framework from which certain threats can arise.
The system-wide security objective addresses such threats in relation The system-wide security objective addresses such threats in relation
to the Problem Statement. to the Problem Statement.
5.1.10 IEEE 802.11i Considerations 5.1.10 IEEE 802.11i Considerations
[Ed. Note: Was 5.2.15]
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
skipping to change at page 17, line 49 skipping to change at page 18, line 35
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 occuring 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. accommated within the CAPWAP protocol.
5.1.11 Interoperability Objective 5.1.11 Interoperability Objective
[Ed. Note: Was 5.2.1]
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
them. them.
This objective for the CAPWAP protocol is to ensure that WTPs of both This objective for the CAPWAP protocol is to ensure that WTPs of both
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
skipping to change at page 19, line 29 skipping to change at page 20, line 12
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 comprehensive set of mechanisms that address the challenges of large-
large-scale WLAN deployments. scale WLAN deployments.
5.1.12 Protocol Specifications
Classification: General
Description:
WLAN equipment vendors require sufficient details from protocol
specifications so that implementing them will allow for compatibility
with other equipment that run the same protocol. In this light, it
is important for the CAPWAP protocol specifications to be reasonably
complete for realization.
Protocol Requirement:
Any WTP or AC vendor or any person can implement the CAPWAP protocol
from the specification itself and by that it is required that all
such implementations do interoperate.
Motivation and Protocol Benefits:
It is beneficial for WLAN equipment vendors to refer to a single set
of specifications while implementing the CAPWAP protocol. This helps
to ease and quicken the development process.
Relation to Problem Statement:
This requirement is based on WG discussions that have determined to
be important for CAPWAP.
5.1.13 Vendor Independence
Classification: General
Description:
Rapid developments in WLAN technologies results in equipment vendors
constantly modifying their devices. In many cases, developments are
independently made for ACs and WTPs. The CAPWAP protocol should not
affect the the independence of device modificaitons.
Protocol Requirement:
A WTP vendor can make modifications to hardware without any AC vendor
involvement.
Motivation and Protocol Benefits:
Independence in the type of hardware for WLAN equipment ensures that
new developments do not hamper protocol operation.
Relation to Problem Statement:
This requirement is based on WG discussions that have determined to
be important for CAPWAP.
5.1.14 Vendor Flexibility
Classification: General
Description:
The CAPWAP protocol must not be specified for a particular MAC. It
should be compatible with both local-MAC and split-MAC WTPs.
Protocol Requirement:
WTP vendors must not be bound to a specific MAC.
Motivation and Protocol Benefits:
This requirement is to ensure that WTP vendors have sufficient
flexibility in selecting the type of MAC that they consider best for
deployments.
Relation to Problem Statement:
This requirement is based on WG discussions that have determined 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
[Ed. Note: Was 5.2.3iii]
Classification: Architecture Classification: Architecture
Description: Description:
Shared WLAN infrastructure raise the issue of multiple authentication Shared WLAN infrastructure raise the issue of multiple authentication
mechanisms. This is because each logical group is likely to be mechanisms. This is because each logical group is likely to be
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
skipping to change at page 20, line 27 skipping to change at page 22, line 40
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:
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 simplifies management of large networks.
5.2.2 Support for Future Wireless Technologies 5.2.2 Support for Future Wireless Technologies
[Ed. Note: Was 5.2.4i]
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 for 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.
skipping to change at page 21, line 21 skipping to change at page 23, line 31
Relation to Problem Statement: Relation to Problem Statement:
The Problem Statement describes some of the advances taking place in The Problem Statement describes some of the advances taking place in
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
[Ed. Note: Was 5.2.4ii]
Classification: Architecture Classification: Architecture
Description: Description:
The IEEE is currently reviewing IEEE 802.11 functionality. It is The IEEE is currently reviewing IEEE 802.11 functionality. It is
expected that the review by the IEEE AP Functionality Ad-Hoc expected that the review by the IEEE AP Functionality Ad-Hoc
Committee may result in new definitions of functional blocks, Committee may result in new definitions of functional blocks,
interfaces or information flows. The CAPWAP protocol must be able to interfaces or information flows. The CAPWAP protocol must be able to
incorporate these revisions with minimal change. incorporate these revisions with minimal change.
skipping to change at page 22, line 7 skipping to change at page 24, line 14
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. It is necessary for the CAPWAP
protocol to reflect these definitions. protocol to reflect these definitions.
5.2.4 Interconnection Objective 5.2.4 Interconnection Objective
[Ed. Note: Was 5.2.2]
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
skipping to change at page 22, line 48 skipping to change at page 25, line 7
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 from underlying
transport. transport.
5.2.5 Access Control 5.2.5 Access Control
[Ed. Note: Was 5.2.8]
[Ed. Note: Was titled "STA Admission Control Objective"]
Classification: Operations Classification: Operations
[Ed. Note: Priority of this objectives needs to be confirmed by WG.]
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;
skipping to change at page 24, line 14 skipping to change at page 26, line 15
5.3 Rejected Objectives 5.3 Rejected Objectives
The following objectives have been rejected during the course of The following objectives have been rejected during the course of
working group consultations. These objectives have been rejected in working group consultations. These objectives have been rejected in
the context of CAPWAP and its considerations. They may however be the context of CAPWAP and its considerations. They may however be
applicable in alternative contexts. applicable in alternative contexts.
5.3.1 Support for Non-CAPWAP WTPs 5.3.1 Support for Non-CAPWAP WTPs
[Ed. Note: Was 5.2.12]
[Ed. Note: Was titled "Centralized WTP Management"]
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,
skipping to change at page 24, line 50 skipping to change at page 26, line 47
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 comlpexity 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
Classification: General
Description:
The CAPWAP protocol must not require AC and WTP vendors to share
technical specifications to establish compatibility. The protocol
specifications alone must be sufficient for compatibility.
Protocol Requirement:
WTP vendors should not have to share technical specifications for
hardware and software to AC vendors in order for interoperability to
be achieved.
Motivation and Protocol Benefits:
It is beneficial for WLAN equipment vendors to refer to a single set
of specifications while implementing the CAPWAP protocol. This helps
to ease and quicken the development process.
Relation to Problem Statement:
This requirement is based on WG discussions that have determined to
be important for CAPWAP.
This objective has been prioritized as rejected as it is a 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
[Ed. Note: Operator requirements from China Mobile]
Classification: Operations Classification: Operations
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.
skipping to change at page 26, line 17 skipping to change at page 28, line 17
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 to focus 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 protocol such as those relating to WTP types (local-MAC and split-
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 Rejected. 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 conjunction with the CAPWAP Problem Statement [I-D.ietf-capwap-
[I-D.ietf-capwap-problem-statement] and CAPWAP Architecture Taxonomy problem-statement] and CAPWAP Architecture Taxonomy [I-D.ietf-capwap-
[I-D.ietf-capwap-arch] to develop and evalute an interoperable arch] to develop and evalute an interoperable protocol for the
protocol for the control and provisioning of WTPs in large-scale control and provisioning of WTPs in large-scale WLANs.
WLANs.
7. Security Considerations 7. Security Considerations
The CAPWAP framework highlights support for both local-MAC and The CAPWAP framework highlights support for both local-MAC and split-
split-MAC WTPs. In deployments where both types of WTPs are used, it MAC WTPs. In deployments where both types of WTPs are used, it is
is crucial to ensure that each be secured in consideration of their crucial to ensure that each be secured in consideration of their
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 the CAPWAP protocol should ensure that the deployment of both local-
local-MAC and split-MAC WTPs within a single WLAN do not present MAC and split-MAC WTPs within a single WLAN do not present loopholes
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
skipping to change at page 28, line 11 skipping to change at page 30, 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 and T. authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan Harkins
Sridhar for their invaluable inputs. The authors also acknowledge and T. Sridhar for their invaluable inputs. The authors also
the contributions from Meimei Dang, Satoshi Iino, Mikihito Sugiura acknowledge the contributions from Meimei Dang, Satoshi Iino,
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)", Internet-Draft draft-ietf-capwap-arch-06, Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in
November 2004. progress), November 2004.
[I-D.ietf-capwap-problem-statement] [I-D.ietf-capwap-problem-statement]
Calhoun, P., "CAPWAP Problem Statement", Calhoun, P., "CAPWAP Problem Statement",
Internet-Draft draft-ietf-capwap-problem-statement-02, draft-ietf-capwap-problem-statement-02 (work in progress),
September 2004. September 2004.
[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.
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
 End of changes. 

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