CAPWAP Working Group S. Govindan (Editor)
Internet-Draft Panasonic
Expires: May 2005 ZH. Yao
Huawei
WH. Zhou
China Mobile
L. Yang
Intel
H. Cheng
Panasonic
November 2004
Objectives for Control and Provisioning of Wireless Access Points
(CAPWAP)
draft-ietf-capwap-objectives-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Govindan (Editor), et al. Expires May 2005 [Page 1]
Internet-Draft CAPWAP Objectives November 2004
This document presents a set of objectives for an interoperable
protocol for the Control and Provisioning of Wireless Access Points
(CAPWAP). It presents objectives in three categories: architecture,
operations and security. The primary purpose of the document is to
present focused requirements which when realized, will ensure
interoperability among wireless local area network (WLAN) devices of
alternative designs. These objectives will form the basis for the
development and evaluation of a CAPWAP protocol.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Categories of Objectives . . . . . . . . . . . . . . . . . . . 7
5. Architecture Objectives . . . . . . . . . . . . . . . . . . . 8
5.1 Interoperability Objective . . . . . . . . . . . . . . . . 8
5.1.1 Objective Details . . . . . . . . . . . . . . . . . . 8
5.1.2 Motivation and Protocol Benefits . . . . . . . . . . . 9
5.1.3 Relation to Problem Statement . . . . . . . . . . . . 9
5.1.4 Customer Requirements . . . . . . . . . . . . . . . . 9
5.1.5 Classification (Mandatory, Desirable, Rejected) . . . 9
5.2 Interconnection Objective . . . . . . . . . . . . . . . . 9
5.2.1 Objective Details . . . . . . . . . . . . . . . . . . 10
5.2.2 Motivation and Protocol Benefits . . . . . . . . . . . 10
5.2.3 Relation to Problem Statement . . . . . . . . . . . . 10
5.2.4 Customer Requirements . . . . . . . . . . . . . . . . 10
5.2.5 Classification (Mandatory, Desirable, Rejected) . . . 10
5.3 Support for Logical Networks . . . . . . . . . . . . . . . 10
5.3.1 Objective Details . . . . . . . . . . . . . . . . . . 11
5.3.2 Motivation and Protocol Benefits . . . . . . . . . . . 11
5.3.3 Relation to Problem Statement . . . . . . . . . . . . 12
5.3.4 Customer Requirement . . . . . . . . . . . . . . . . . 12
5.3.5 Classification (Mandatory, Desirable, Rejected) . . . 12
5.4 Extensibility Objective . . . . . . . . . . . . . . . . . 12
5.4.1 Objective Details . . . . . . . . . . . . . . . . . . 12
5.4.2 Motivation and Protocol Benefits . . . . . . . . . . . 13
5.4.3 Relation to Problem Statement . . . . . . . . . . . . 13
5.4.4 Customer Requirements . . . . . . . . . . . . . . . . 13
5.4.5 Classification (Mandatory, Desirable, Rejected) . . . 13
6. Operations Objective . . . . . . . . . . . . . . . . . . . . . 14
6.1 WLAN Monitoring Objective . . . . . . . . . . . . . . . . 14
6.1.1 Objective Details . . . . . . . . . . . . . . . . . . 14
6.1.2 Motivation and Protocol Benefits . . . . . . . . . . . 15
6.1.3 Relation to Problem Statement . . . . . . . . . . . . 15
6.1.4 Customer Requirement . . . . . . . . . . . . . . . . . 15
6.1.5 Classification (Mandatory, Desirable, Rejected) . . . 15
6.2 Resource Control Objective . . . . . . . . . . . . . . . . 15
Govindan (Editor), et al. Expires May 2005 [Page 2]
Internet-Draft CAPWAP Objectives November 2004
6.2.1 Objective Details . . . . . . . . . . . . . . . . . . 15
6.2.2 Motivation and Protocol Benefits . . . . . . . . . . . 16
6.2.3 Relation to Problem Statement . . . . . . . . . . . . 16
6.2.4 Customer Requirements . . . . . . . . . . . . . . . . 16
6.2.5 Classification (Mandatory, Desirable, Rejected) . . . 16
6.3 Support for Traffic Separation . . . . . . . . . . . . . . 17
6.3.1 Objective Details . . . . . . . . . . . . . . . . . . 17
6.3.2 Motivation and Protocol Benefits . . . . . . . . . . . 17
6.3.3 Relation to Problem Statement . . . . . . . . . . . . 17
6.3.4 Customer Requirements . . . . . . . . . . . . . . . . 17
6.3.5 Classification (Mandatory, Desirable, Rejected) . . . 17
6.4 STA Admission Control Objective . . . . . . . . . . . . . 17
6.4.1 Objective Details . . . . . . . . . . . . . . . . . . 18
6.4.2 Motivation and Protocol Benefits . . . . . . . . . . . 18
6.4.3 Relation to Problem Statement . . . . . . . . . . . . 18
6.4.4 Customer Requirements . . . . . . . . . . . . . . . . 18
6.4.5 Classification (Mandatory, Desirable, Rejected) . . . 18
6.5 Centralized WTP Management . . . . . . . . . . . . . . . . 18
7. Security Objectives . . . . . . . . . . . . . . . . . . . . . 19
7.1 CAPWAP Protocol Security . . . . . . . . . . . . . . . . . 19
7.1.1 Objective Details . . . . . . . . . . . . . . . . . . 19
7.2 System-wide Security . . . . . . . . . . . . . . . . . . . 19
8. Objectives for Further Discussion . . . . . . . . . . . . . . 20
8.1 Centralized WTP Management . . . . . . . . . . . . . . . . 20
8.2 Security borderline Control . . . . . . . . . . . . . . . 20
8.3 Trust model Definition . . . . . . . . . . . . . . . . . . 20
8.4 IEEE 802.11i Considerations . . . . . . . . . . . . . . . 20
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . 22
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 26
Govindan (Editor), et al. Expires May 2005 [Page 3]
Internet-Draft CAPWAP Objectives November 2004
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Govindan (Editor), et al. Expires May 2005 [Page 4]
Internet-Draft CAPWAP Objectives November 2004
2. Terminology
This document follows the terminologies of [I-D.ietf-capwap-arch].
Additionally, the following terms are defined;
Switching segment: Those aspects of a centralized WLAN that primarily
deal with switching or routing control and data information between
Wireless Termination Points (WTPs) and the WLAN controller.
Wireless medium segment: Those aspects of a centralized WLAN that
primarily deal with the end-user interface which is wireless.
Initially, CAPWAP focuses on IEEE 802.11 technologies but this
segment may also refer to other technologies such as IEEE 802.16.
CAPWAP framework: A term that includes the local MAC and split MAC
designs of the Centralized WLAN Architecture. Standardization
efforts are focussed on these designs.
CAPWAP protocol: The protocol between WLAN controller and WTPs in the
CAPWAP framework. It facilitates control, management and
provisioning of WTPs in an interoperable manner.
Govindan (Editor), et al. Expires May 2005 [Page 5]
Internet-Draft CAPWAP Objectives November 2004
3. Introduction
The growth in large scale wireless local area network (WLAN)
deployments has brought to focus a number of technical challenges.
This includes the complexity of managing large numbers of wireless
termination points (WTPs), which is further exacerbated by
differences in their design. Another challenge is the maintenance of
consistent configurations among the numerous WTPs. The dynamic
nature of the wireless medium is also a concern together with WLAN
security. These challenges have been highlighted in
[I-D.ietf-capwap-problem-statement].
Many vendors have addressed these challenges for large scale WLAN
deployments by developing new architectures and solutions. A survey
of the various architectures and solutions was conducted to better
understand the context of the challenges so as to develop
interoperability among them. The Architecture Taxonomy
[I-D.ietf-capwap-arch] is a result of this survey in which major
architecture families are classified. Broadly, these are the
autonomous, centralized WLAN and distributed mesh architectures. The
survey showed that the current majority of large scale deployments
follow the centralized WLAN architecture in which portions of the
wireless medium access control (MAC) operations are centralized in a
WLAN controller. This architecture family is further classified into
remote MAC, split MAC and local MAC. Each differs in the degree of
separation of MAC layer capabilities among WTPs and WLAN controller.
This document puts forth critical objectives for achieving
interoperability in a CAPWAP framework. It presents objectives that
address the challenges of large scale WLAN deployments. The
realization of these objectives will ensure that WLAN equipment of
major design types may be integrally deployed and managed.
Govindan (Editor), et al. Expires May 2005 [Page 6]
Internet-Draft CAPWAP Objectives November 2004
4. Categories of Objectives
The objectives for the CAPWAP protocol are organized into three major
categories; architecture, operations and security.
Architecture objectives deal with system level aspects of the CAPWAP
protocol. They address issues of protocol extensibility, diverse
network deployments and architecture designs and differences in
transport technologies.
Operational objectives address the control and management features of
the CAPWAP protocol. They deal with operations relating to
system-wide resource management, WTP management, QoS and STA access
control.
Security objectives address potential threats to WLANs and their
containment. Specifically, they deal with securing the CAPWAP
protocol and the WLAN system as a whole. The objectives also address
security requirements from end-users and service providers.
Govindan (Editor), et al. Expires May 2005 [Page 7]
Internet-Draft CAPWAP Objectives November 2004
5. Architecture Objectives
The architectural considerations of centralized WLAN networks are
fundamental to the development and evaluation of a CAPWAP protocol.
The objectives in this category deal with system level aspects
relating to protocol extensibility, diversity of network deployments
and differences among vendor equipment.
5.1 Interoperability Objective
Two major designs of the centralized WLAN architecture are local MAC
and split MAC. With the focusing of standardization efforts on these
two designs, it is crucial to ensure mutual interoperation among
them.
5.1.1 Objective Details
This objective for the CAPWAP protocol is to ensure that WTPs of both
local MAC and split MAC architecture designs are capable of
interoperation within a single WLAN. Consequently, a single WLAN
controller will be capable of controlling both types of WTPs using a
single CAPWAP protocol. Integral support for these designs comprises
a number of protocol aspects.
i. Functionality negotiations between WLAN controller and WTPs
Local MAC and split MAC designs differ in the degree of IEEE 802.11
MAC functionalities that each type of WTP realizes. The CAPWAP
protocol should allow WLAN controllers to determine the
functionalities of different WTPs as a first step in controlling
them.
ii. Establishment of alternative interfaces
The functionality differences among different WTPs essentially
equates to alternative interfaces with a WLAN controller. So the
CAPWAP protocol should be capable of adapting its operations to the
different interfaces. The definition of these interfaces is
dependent on the functionality differences among local MAC and split
MAC WTPs. It is therefore out of scope of the objectives
specifications.
[Functionality Classifications] presents additional details on these
two aspects. It shows how flexibility in the CAPWAP protocol may be
achieved so as to realize this architecture objective.
This objective also addresses the need for flexibly configuring WTPs
based on their design types and other setup aspects.
Govindan (Editor), et al. Expires May 2005 [Page 8]
Internet-Draft CAPWAP Objectives November 2004
5.1.2 Motivation and Protocol Benefits
The benefits of realizing this architecture objective are both
technical and practical. First, there are substantial overlaps in
the control operations of local MAC and split MAC architecture
designs. As a result, it is technically practical to devise a single
protocol that manages both types of devices.
Next, the ability to operate a CAPWAP protocol for both types of
architectural designs enhances its practical prospects as it will
have wider appeal.
Furthermore, the additional complexity resulting from such
alternative interfaces is marginal. Consequently, the benefits of
this objective will far outweigh any cost of realizing it.
5.1.3 Relation to Problem Statement
The objective for supporting both local MAC and split MAC WTPs is
fundamental to addressing [I-D.ietf-capwap-problem-statement]. It
forms the basis for those problems to be uniformly addressed across
the major WLAN architectures. This is the ultimate aim of
standardization efforts. The realization of this objective will
ensure the development of a comprehensive set of solutions to the
challenges of large scale WLAN deployments.
5.1.4 Customer Requirements
A number of service providers and equipment vendors see benefits with
the combined usage of both local MAC and split MAC designs. WTPs of
different designs are placed in different locations so as to
selectively take advantage of their respective characteristics. The
integral support of different architectures therefore addresses
critical needs for the market.
Furthermore, since there are products of each design type already in
the market and widely deployed, it is necessary for CAPWAP protocol
to support both of them.
5.1.5 Classification (Mandatory, Desirable, Rejected)
[TBD] [This section to contain reasons for the particular
classification of the objective.]
5.2 Interconnection Objective
Large scale WLAN deployments are likely to use a variety of
interconnection technologies between different devices of the
Govindan (Editor), et al. Expires May 2005 [Page 9]
Internet-Draft CAPWAP Objectives November 2004
network. It should therefore be possible for the CAPWAP protocol to
operate over the different interconnection technologies. So the
protocol needs to be independent of underlying transport
technologies.
5.2.1 Objective Details
WLAN controllers and WTPs must be able to connect by a variety of
interconnection technologies. The fundamental intent is for CAPWAP
protocol exchanges to be transparent to underlying transport
technologies. As a result of realizing this objective, the protocol
will be capable of operation over different interconnect technologies
including Ethernet, bus backplanes, ATM (cell) fabrics and also
wireless technologies such as IEEE 802.11. Ethernet architecture is
most widely used and should be recommended.
The CAPWAP protocol should have the ability to support this diversity
of interconnection technologies for data and control exchanges. For
example, VLAN tunnels are an example of an interconnection technology
over which CAPWAP may operate.
Related to this objective, is the QoS aspect of interconnection
technologies. Given that QoS will be enabled differently in each of
these technologies, the CAPWAP protocol must ensure that network
performance is consistent across different transport means.
Additionally, QoS consistency has to cover the switching segment and
the wireless medium segment.
5.2.2 Motivation and Protocol Benefits
[TBD]
5.2.3 Relation to Problem Statement
[TBD]
5.2.4 Customer Requirements
[TBD]
5.2.5 Classification (Mandatory, Desirable, Rejected)
[TBD] [This section to contain reasons for the particular
classification of the objective.]
5.3 Support for Logical Networks
Large WLAN deployments are complex and expensive. Furthermore,
Govindan (Editor), et al. Expires May 2005 [Page 10]
Internet-Draft CAPWAP Objectives November 2004
enterprises are under pressure to improve the efficiency of their
expenditures. These issues are increasingly being addressed by means
of shared deployments. As a result, a number of logical networks
cover a single physical WLAN infrastructure. This way the cost of
deployment and management can be shared among network service
providers. A scenario together with additional details for such
shared WLANs is presented in [Functionality Classifications].
5.3.1 Objective Details
The objective for supporting logical networks involves a number of
aspects. These are discussed below;
i. WLAN management in terms of logical groups
Traditionally, each WTP has represented one complete subset of a
larger WLAN system. However, with shared deployments, each WTP
represents a number of subsets of possibly a number of larger WLAN
systems. So with such deployments, WLANs need to be managed in terms
of logical groups instead of physical devices.
ii. Mutual separation of control and communications
Since different logical networks are likely to be associated to
different enterprises, it is crucial that control and data
communications among them be mutually separated. In addition to
being a security concern, this aspect of the objective also
highlights a complexity concern. Specifically, mixing of traffic for
different logical networks can complicate control. So the CAPWAP
protocol must be capable of separating traffic among logical
networks. VLANs and other types of tunnels may be used for this
purpose.
iii. Multiple authentication mechanisms
The presence of multiple logical networks within an infrastructure
also means there are different subscriber groups in a WLAN system.
Since the subscriber groups are likely to belong to different service
providers or WLAN domains, their authentication needs will also be
different. As a result, the CAPWAP protocol must be capable of
transferring different authentication information. For example, one
subscriber group may be authenticated with IEEE 802.11i with the WLAN
controller being the authenticator, while another group could use web
authentication at an alternative server.
5.3.2 Motivation and Protocol Benefits
Given the realities of cost and complexity of WLANs, a CAPWAP
Govindan (Editor), et al. Expires May 2005 [Page 11]
Internet-Draft CAPWAP Objectives November 2004
protocol that incorporates the objective of supporting logical
networks ensures simpler and cost effective WLAN management and
deployment. A protocol that realizes this is therefore consistent
with the goal of reducing complexity in large scale WLANs.
5.3.3 Relation to Problem Statement
This objective for supporting logical networks addresses problem of
management complexity in terms of cost. Such cost complexity is
reduced by sharing infrastructure among a number of service
providers. Consequently, deployment and managements
cost-efficiencies are realized.
5.3.4 Customer Requirement
Businesses require the benefits of management ease by the most cost
effective means. This can be achieved with the objective of
supporting logical networks within a single set of physical WLAN
equipment. There are a number of ways of realizing this objective
some being virtual APs, VLAN tunnels and other tunnels.
This objective also allows for separation between providers of
infrastructure from services. Logical networks allows for the
separation of physical deployment and maintenance from actual
management of WLANs. This helps lower costs and responsibilities for
service providers.
5.3.5 Classification (Mandatory, Desirable, Rejected)
[TBD] [This section to contain reasons for the particular
classification of the objective.]
5.4 Extensibility Objective
Wireless technology is developing at rapid pace in a number of
industry and scientific groups. With such pace, it is important to
design CAPWAP in a way as to allow future extensibility. In
particular, the IEEE is in the process of specifying standards for
broadband wireless access, namely IEEE 802.16. There also other
activities within the IEEE that needs to be considered in the CAPWAP
context.
5.4.1 Objective Details
This objective has a number of aspects that are described below;
i. Enable support for future wireless technologies
Govindan (Editor), et al. Expires May 2005 [Page 12]
Internet-Draft CAPWAP Objectives November 2004
This aspect of the objective essentially purposes that the CAPWAP
protocol does not rely on specifics of IEEE 802.11 technology for its
operations. This will simplify extensibility to support IEEE 802.16.
ii. Enable support for new IEEE extensions
The IEEE is currently reviewing IEEE 802.11 functionality. It is
expected that the review will result in new functional blocks,
interfaces or information flows. The CAPWAP protocol must be able to
handle these revisions with minimal changes.
iii. User(Client) Access Requirement
There should not be any impact on the end-user of CAPWAP WLAN in
terms of both hardware and software aspects. End-users should not be
required to be aware of the existence of CAPWAP protocol.
5.4.2 Motivation and Protocol Benefits
[TBD]
5.4.3 Relation to Problem Statement
[TBD]
5.4.4 Customer Requirements
Service providers are not enthusiastic about deploying technologies
with limited potential for extension. They require WLAN
infrastructure to be able to meet current and future market
requirements. So the objective for extensibility is critical to
service providers and other customers of WLAN equipment.
5.4.5 Classification (Mandatory, Desirable, Rejected)
[TBD] [This section to contain reasons for the particular
classification of the objective.]
Govindan (Editor), et al. Expires May 2005 [Page 13]
Internet-Draft CAPWAP Objectives November 2004
6. Operations Objective
CAPWAP aims to provide an interoperable solution to the control and
provisioning of large scale WLAN deployments. In this context, the
operational objectives address functional aspects of the protocol.
These functions cover system monitoring, resource management and QoS.
6.1 WLAN Monitoring Objective
The scale of WLANs in the CAPWAP context results in numerous
information sources. For example, the configuration of each WTP can
be considered as an information source. Additionally, the switching
segment and wireless medium segment can also be considered as
information sources. So for effective performance, the CAPWAP
protocol needs to regularly monitor the various information sources.
6.1.1 Objective Details
Large WLANs need a variety of information sources to be monitored.
So this objective includes a number of aspects.
i. Configuration consistency
CAPWAP based WLANs include a large number of WTPs, each of which need
to be configured and managed. The protocol should therefore allow
WTPs to regularly send information on the state of their
configuration to their WLAN controller. Furthermore, it should also
be capable of consistently distributing firmware to all the WTPs.
ii. System-wide resource state
The centralized WLAN architecture is made up of a switching segment
and wireless medium segment. In the switching segment, network
congestion and WTP status, including firmware information, have to be
monitored. In the wireless medium segment, the dynamic nature of the
medium itself has to be monitored. Overall, there are also various
statistics that are required for operation.
The CAPWAP protocol should therefore be capable of monitoring various
information sources. Moreover, given relationships among information
sources, CAPWAP should combine information from such sources. For
example, statistics information may be merged with status signals.
So this aspect of the objective proposes collective information
arising from different information sources. Within this aspect of
the monitoring objective, the protocol may also allow WTPs to send
regular send feedback using CAPWAP.
Govindan (Editor), et al. Expires May 2005 [Page 14]
Internet-Draft CAPWAP Objectives November 2004
6.1.2 Motivation and Protocol Benefits
The effectiveness of a protocol is based on the relevance of
information on which it operates. The objective for WLAN monitoring
can provide this information to the CAPWAP protocol. So there will
tangible benefits with this objective.
6.1.3 Relation to Problem Statement
This objective addresses the problems of management complexity. This
challenge is better solved with the appropriate information resulting
from this WLAN monitoring. With collective information from various
information sources, realizing this objective will help control and
manage complexity.
The objective also helps address the challenge of maintaining
consistent configurations among WTPs.
6.1.4 Customer Requirement
WLAN equipment customers require effective management solutions for
their networks. This objective will ensure such a solution by
providing collective information from a variety of information
sources.
6.1.5 Classification (Mandatory, Desirable, Rejected)
[TBD] [This section to contain reasons for the particular
classification of the objective.]
6.2 Resource Control Objective
Integral to the success of any wireless network system is the
performance and quality it can offer its subscribers. Since CAPWAP
based WLANs combine a switching segment and a wireless medium
segment, performance and quality need to be coordinated across both
of these segments. So QoS performance must be enforced system-wide.
6.2.1 Objective Details
This objective is for QoS over the entire WLAN system which includes
the switching segment and the wireless medium segment. Given the
fundamental differences between the two, it is likely that there are
alternate QoS mechanisms between WTPs and wireless service
subscribers and between WTPs and WLAN controllers. For instance, the
former will be based on IEEE 802.11e while the latter will be an
alternative. So resources need to be adjusted in a coordinated
fashion over both segments. The CAPWAP protocol should ensure that
Govindan (Editor), et al. Expires May 2005 [Page 15]
Internet-Draft CAPWAP Objectives November 2004
these adjustments are appropriately exchanged between WLAN
controllers and WTPs.
6.2.2 Motivation and Protocol Benefits
A protocol that addresses QoS aspects of WLAN systems will deliver
high performance thereby being beneficial for subscribers and
resource utilization. Since CAPWAP deals with WTPs directly and with
the wireless medium indirectly, both of these must be considered for
performance.
For the wireless medium segment, QoS aspects in the protocol enable
high quality communications within the domain of a WLAN controller.
Since each domain generally covers an enterprise or a group of
service providers, such protocol performance has wide-ranging
effects.
Within the switching segment of CAPWAP, a QoS-enabled protocol
minimizes the adverse effects of dynamic traffic characteristics so
as to ensure system-wide performance.
6.2.3 Relation to Problem Statement
QoS control is critical to large WLANs and relates to a number of
aspects. In particular, this objective can help address the problem
of managing dynamic conditions of the wireless medium.
Furthermore, traffic characteristics in large scale WLANs are
constantly varying. So network utilization becomes inefficient and
user experience is unpredictable.
The interaction and coordination between the two aspects of
system-wide QoS is therefore critical for performance.
6.2.4 Customer Requirements
VoIP is a major application over WLANs. The basic requirement for
such applications is QoS. Furthermore, end-users demand quality
means of communications, so service providers in turn emphasize on
the QoS capabilities of WLAN systems. Adopting this objective will
ensure all demands are met.
6.2.5 Classification (Mandatory, Desirable, Rejected)
[TBD] [This section to contain reasons for the particular
classification of the objective.]
Govindan (Editor), et al. Expires May 2005 [Page 16]
Internet-Draft CAPWAP Objectives November 2004
6.3 Support for Traffic Separation
The centralized WLAN architecture simplifies complexity associated
with large scale deployments. This is achieved by consolidating some
functionality at a central WLAN controller and distributing the
remaining across WTPs. As a result, WTPs and WLAN controller
exchange control and data among them. This objective suggests
separating control and data aspects of the exchanges for further
simplicity.
6.3.1 Objective Details
It is the aim of CAPWAP to simplify the control and management of
large scale WLANs. One way of achieving this is to separate control
and data aspects within the protocol. This will allow solutions for
control and data exchanges to be independently optimized.
6.3.2 Motivation and Protocol Benefits
The aim of separating data and control aspects of the protocol is to
simplify the protocol. It also allows for flexibility since each
part can be separately addressed in the most appropriate manner.
Furthermore, such separation can also allow separation of data and
control paths. This will enable remotely located WTPs to handle data
in alternative ways instead of forwarding them across a wide network
to the WLAN controller.
6.3.3 Relation to Problem Statement
Broadly, this objective relates to the challenge of managing
complexity in large scale WLANs.
6.3.4 Customer Requirements
This objective offers simplicity and flexibility in operation. These
are important issues for service providers and other enterprises
deploying large scale WLANs.
6.3.5 Classification (Mandatory, Desirable, Rejected)
[TBD] [This section to contain reasons for the particular
classification of the objective.]
6.4 STA Admission Control Objective
STA Admission control deals with client authentication, handoff
between WTPs, load balance, QoS etc. Access control in the CAPWAP
Govindan (Editor), et al. Expires May 2005 [Page 17]
Internet-Draft CAPWAP Objectives November 2004
context must be based on a variety of information. This is because
CAPWAP combines both switching and wireless medium segments.
6.4.1 Objective Details
This objective focuses on access control based on collective
information from the switching and wireless medium segments. As
such, access to the WLAN is based on both the radio resources, i.e.
wireless medium segment and network resources, i.e. switching
segment.
6.4.2 Motivation and Protocol Benefits
Due to the scale of deployments in which CAPWAP will be employed,
comprehensive access control is crucial. The effectiveness of access
control in turn is affected by the information on which such control
is based. As a result, this objective has critical relevance to a
CAPWAP protocol.
6.4.3 Relation to Problem Statement
This objective addresses the issue of access control in large WLANs.
Broadly, it relates the problem of managing the complexity scale of
such networks. With collective information of both switching and
wireless medium segments, realizing this objective will help control
and manage complexity.
6.4.4 Customer Requirements
[TBD]
6.4.5 Classification (Mandatory, Desirable, Rejected)
[TBD]
6.5 Centralized WTP Management
Large scale WLAN deployments necessitate in centralized control. The
CAPWAP protocol interfaces the central control to the numerous WTPs.
One aspect of centralized control includes firmware distribution.
This objective relates to configuration aspects of the WLAN.
Govindan (Editor), et al. Expires May 2005 [Page 18]
Internet-Draft CAPWAP Objectives November 2004
7. Security Objectives
Security is a major issue for any communications network and is
especially important for large scale WLANs. In this context,
security must encompass both the protocol between WLAN controller and
WTPs and also the WLAN system as a whole. So the following
objectives deal with securing exchanges between WLAN elements and
devising contingencies in case of physical security breaches.
7.1 CAPWAP Protocol Security
This objective addresses the security of the protocol.
7.1.1 Objective Details
[Note: This objective generally deals with the security between WTP
and WLAN controller. It deals with threats that arise from within
the network infrastructure.]
The CAPWAP protocol between WLAN controller and WTPs must be secured
such that information exchange between them is not threatened. As
such, it must provide confidentiality, integrity and authenticity for
those exchanges.
Furthermore, CAPWAP protocol security must ensure that rogue WTPs do
not breach legitimate WLAN systems. The CAPWAP protocol should
therefore include authentication mechanisms for WTPs. For example,
WTPs may be required to regularly renew their authentication states.
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
whole. So WTP mis-use will be protected against.
7.2 System-wide Security
[Note: This objective is to prevent against security threats from
outside the CAPWAP framework. Specifically, it addresses threats
posed by rogue wireless users. For example, recent discussions of
PMK sharing in the CAPWAP context illustrates a situation while may
be taken advantage of by a rogue wireless user. This objective
differs from that of the previous section in that it deals with
external threats that may affect the WLAN system.
The emphasis here is that there should be no ambiguities arising from
the CAPWAP framework that causes threats from external entities.]
Govindan (Editor), et al. Expires May 2005 [Page 19]
Internet-Draft CAPWAP Objectives November 2004
8. Objectives for Further Discussion
[Note: The following are some of objectives for further discussion in
the WG.]
8.1 Centralized WTP Management
The CAPWAP protocol should provide an engine-mechanism to spring WTP
auto-configuration and/or software version updates and should support
integration with existing network management system. WLAN controller
as a management agent is optional.
If entities other than WLAN controllers manage some aspects of 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.
One example of transport mechanism for the CAPWAP protocol is TCP/IP.
This will bring more flexibility to the way in which WLAN systems are
deployed.
8.2 Security borderline Control
[Note: This objective addresses the issue of a large WLAN
infrastructure featuring the co-existence of different security
policies for different user groups. It deals with traffic flow
isolation on borderline of any two user groups or two users.]
8.3 Trust model Definition
[Note: When 802.1x authenticator role in 802.11i is relocated from
WTP to WLAN controller, the following needs to be clarified for
CAPWAP protocol development; whether there are any potential changes
in the trust relationship between WTP and infrastructure. If there
are changes, the new trust model needs to be defined.]
8.4 IEEE 802.11i Considerations
In the centralized WLAN architecture, authentication based on IEEE
802.11i presents options based on the location of the authenticator.
Particularly, if the authenticator is located within the WLAN
controller, means for key distribution need to be considered, whereas
if the authenticator is within a WTP, communications between the AAA
server and the WTP need to be considered. The CAPWAP protocol should
therefore be able to address these options.
Govindan (Editor), et al. Expires May 2005 [Page 20]
Internet-Draft CAPWAP Objectives November 2004
9. Summary and Conclusion
The objectives presented in this document address architectural,
operational and security aspects for CAPWAP. They present a
framework which will be used to develop and evaluate candidate
protocols for managing large scale WLAN deployments.
Govindan (Editor), et al. Expires May 2005 [Page 21]
Internet-Draft CAPWAP Objectives November 2004
10. Security Considerations
[Note: This section will detail the security implications of the
various objectives. One way to look at it would be to analyze the
security considerations of the Architecture Taxonomy and borrow/infer
from it.]
The objective dealing with alternative interfaces covers the
interoperability of WTPs from both local MAC and split MAC designs.
As such, a WLAN controller must be capable of securing both of these
design types. This may include handling different degrees of
security or authentication processing for the two types of WTPs.
In shared deployments with a number of logical networks, it is
crucial to ensure mutual separation of traffic among them. Access
control should therefore be distinct for each of the logical
networks. Furthermore, subscribers to different service providers
need to be managed based on their respective requirements,
subscriptions, etc. Cross exchanges need to be secured against.
It should be ensured that any stray exchanges be prevented with the
automation of discovery and initialization processes.
The objective for WLAN monitoring relates to security also. Wireless
systems need to be constantly monitored for potential threats in the
form of rogue WTPs or terminals. For example, profiles for DoS and
replay attacks need to be monitored.
In addition to securing protocol exchanges between devices in large
scale WLANs, the CAPWAP protocol should also incorporate
contingencies for physical security breaches. For instance, it
should be ensured that the network as a whole is not compromised if a
single AP is stolen or otherwise compromised. The protocol should
therefore contain measures to detect and contain physical security
threats.
Govindan (Editor), et al. Expires May 2005 [Page 22]
Internet-Draft CAPWAP Objectives November 2004
11. Contributors
This document is the result of a merger of two individual
Internet-Draft submissions. The authors of both drafts have
contributed to shape this document. The authors are;
Meimei Dang
RITT, CATR
No.11 YueTanNanJie, Xicheng District
Beijing 100045
P. R. China
Phone: +86 10 68094457
Email: dangmeimei@mail.ritt.com.cn
Satoshi Iino
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224 8539
Japan
Phone: +81 45 938 3789
EMail: iino.satoshi@jp.panasonic.com
Mikihito Sugiura
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224 8539
Japan
Phone: +81 45 938 3789
EMail: sugiura.mikihito@jp.panasonic.com
Dong Wang
ZTE
No.68 Zijinghua Rd, Yuhuatai District
Tsuzuki-ku
Nanjing, Jiangsu Prov. 210 012
P. R. China
Phone: +86 25 5287 1713
EMail: wang.dong@mail.zte.com.cn
Govindan (Editor), et al. Expires May 2005 [Page 23]
Internet-Draft CAPWAP Objectives November 2004
12. Acknowledgements
The authors would like to thank the Working Group Chairs, Dorothy
Gellert and Mahalingam Mani, for their support and patience with this
document. We would also like to thank participants of the Working
Group who have helped shape the objectives. In particular, the
authors thank Pat Calhoun and Inderpreet Singh for their invaluable
inputs.
13 References
[Functionality Classifications]
Cheng, H. et al, "Functionality Classifications for
Control and Provisioning of Wireless Access Points",
draft-cheng-capwap-classifications-01, (work in
progress), July 2004.
[I-D.ietf-capwap-arch]
Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access
Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in
progress), November 2004.
[I-D.ietf-capwap-problem-statement]
Calhoun, P., "CAPWAP Problem Statement",
draft-ietf-capwap-problem-statement-02 (work in progress),
September 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Saravanan Govindan
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5441
EMail: sgovindan@psl.com.sg
Govindan (Editor), et al. Expires May 2005 [Page 24]
Internet-Draft CAPWAP Objectives November 2004
Zhonghui Yao
Huawei Longgang Production Base
Shenzhen 518 129
P. R. China
Phone: +86 755 2878 0808
EMail: yaoth@huawei.com
Wenhui Zhou
China Mobile
53A, Xibianmen Ave, Xuanwu District
Beijing 100 053
P. R. China
Phone: +86 10 6600 6688 ext.3061
EMail: zhouwenhui@chinamobile.com
L. Lily Yang
Intel Corp.
JF3-206, 2111 NE 25th Ave.
Hilsboro, OR 97124
USA
Phone: +1 503 264 8813
EMail: lily.l.yang@intel.com
Hong Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5447
EMail: hcheng@psl.com.sg
Govindan (Editor), et al. Expires May 2005 [Page 25]
Internet-Draft CAPWAP Objectives November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Govindan (Editor), et al. Expires May 2005 [Page 26]
