Internet DRAFT - draft-govindan-capwap-objectives
draft-govindan-capwap-objectives
Network Working Group S. Govindan
Internet-Draft H. Cheng
Expires: April 2005 S. Iino
M. Sugiura
Panasonic
October 2004
Objectives for Control and Provisioning of Wireless Access Points
(CAPWAP)
draft-govindan-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 in April 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document presents objectives for the Control and Provisioning of
Wireless Access Points (CAPWAP) framework. Primarily it presents a
fundamental objective for interoperability among wireless local area
Govindan, et al. Expires April 2005 [Page 1]
Internet-Draft CAPWAP Objectives October 2004
network (WLAN) devices of different designs. The document also
describes additional objectives for shared WLAN infrastructure and
QoS.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Adaptive Interfaces Objective . . . . . . . . . . . . . . . . 5
3.1 Objective Details . . . . . . . . . . . . . . . . . . . . 5
3.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 5
3.3 Relation to Problem Statement . . . . . . . . . . . . . . 5
3.4 Customer Requirements . . . . . . . . . . . . . . . . . . 6
4. Logical Networks Support . . . . . . . . . . . . . . . . . . . 7
4.1 Objective Details . . . . . . . . . . . . . . . . . . . . 7
4.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 7
4.3 Relation to Problem Statement . . . . . . . . . . . . . . 7
4.4 Customer Requirements . . . . . . . . . . . . . . . . . . 7
5. Coexistence of Multiple Authentication Mechanisms . . . . . . 9
5.1 Objective Details . . . . . . . . . . . . . . . . . . . . 9
5.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 9
5.3 Relation to Problem Statement . . . . . . . . . . . . . . 9
5.4 Customer Requirements . . . . . . . . . . . . . . . . . . 9
6. Automated Processes Objective . . . . . . . . . . . . . . . . 10
6.1 Objective Details . . . . . . . . . . . . . . . . . . . . 10
6.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 10
6.3 Relation to Problem Statement . . . . . . . . . . . . . . 10
6.4 Customer Requirements . . . . . . . . . . . . . . . . . . 10
7. WLAN Status Monitoring Objective . . . . . . . . . . . . . . . 11
7.1 Objective Details . . . . . . . . . . . . . . . . . . . . 11
7.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 11
7.3 Relation to Problem Statement . . . . . . . . . . . . . . 11
7.4 Customer Requirements . . . . . . . . . . . . . . . . . . 11
8. QoS Objective . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1 Objective Details . . . . . . . . . . . . . . . . . . . . 12
8.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 12
8.3 Relation to Problem Statement . . . . . . . . . . . . . . 12
8.4 Customer Requirements . . . . . . . . . . . . . . . . . . 13
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18
Govindan, et al. Expires April 2005 [Page 2]
Internet-Draft CAPWAP Objectives October 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, et al. Expires April 2005 [Page 3]
Internet-Draft CAPWAP Objectives October 2004
2. Introduction
The first phase of standardization for the Control and Provisioning
of Wireless Access Points (CAPWAP) has resulted in the recognition of
major problems associated with large scale wireless local area
network (WLAN) deployments [I-D.ietf-capwap-problem-statement].
Briefly, these relate to management complexity, configuration
consistency, management of wireless medium and WLAN security.
The WLAN landscape, in the context of design variants, was also
surveyed as part of this initial phase. The Architecture Taxonomy
[I-D.ietf-capwap-arch] classifies WLANs in to three major
architecture families; remote MAC, split MAC and local MAC. Each
differs in the degree of separation of MAC layer capabilities among
access points (APs) and WLAN controller.
This document puts forth critical objectives for realizing
interoperability in a CAPWAP framework. It presents a basic
objective for APs of different architectural designs to interoperate
within a single WLAN controller domain. The realization of this
objective will enable true interoperability in that major WLAN
designs may be integrally deployed and managed.
Additional objectives put forth in this document relate to Qos and
shared infrastructure deployments. Such deployments are increasingly
popular in the commercial market as they offer cost benefits and
flexibility. Details of the deployment scenario are provided in
[I-D.cheng-capwap-classifications].
Govindan, et al. Expires April 2005 [Page 4]
Internet-Draft CAPWAP Objectives October 2004
3. Adaptive Interfaces Objective
With the focusing of standardization efforts on local MAC and split
MAC designs, it is crucial to ensure mutual interoperation among
them. This is emphasized in the first objective.
3.1 Objective Details
The first objective for CAPWAP is to ensure that APs designed for
both local MAC and split MAC architectures are capable of
interoperation within a single WLAN. On the basis of this objective,
the CAPWAP protocol will utilize adaptive interfaces corresponding to
the design variants. [I-D.cheng-capwap-classifications] presents
additional details on how flexibility in the CAPWAP protocol may be
achieved so as to realize this objective.
This objective also addresses the need for flexibly configuring APs
based on their design types and other setup aspects.
3.2 Protocol Benefits
The benefits of realizing the adaptive interfaces objective are both
technical and practical. First, there are substantial overlaps in
the control operations between the local MAC and split MAC
architectures. 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 adaptive
interfaces is marginal. Consequently, the benefits of this objective
will far outweigh any cost of realizing it.
3.3 Relation to Problem Statement
The objective for adaptive interfaces between APs and WLAN
controllers is fundamental to addressing the Problem Statement
[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 first objective will ensure that the
solutions for [I-D.ietf-capwap-problem-statement] are consistent for
both WLAN designs.
Govindan, et al. Expires April 2005 [Page 5]
Internet-Draft CAPWAP Objectives October 2004
3.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. APs of
different designs are placed in different locations so as to
selectively take advantage of their respective characteristics. The
adaptive interface objective 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.
[TBD]
Govindan, et al. Expires April 2005 [Page 6]
Internet-Draft CAPWAP Objectives October 2004
4. Logical Networks Support
Large WLANs are complex systems that need to be closely managed for
optimal performance. Furthermore, they are expensive to deploy and
enterprises are under pressure to improve the efficiency of their
expenditures. These issues are being addressed by means of deploying
a number of logical networks over a single physical WLAN
infrastructure. This way the cost of deployment and management can
be shared. A scenario together with additional details for such
shared WLANs is presented in [I-D.cheng-capwap-classifications].
4.1 Objective Details
The objective for supporting logical networks involves mutual
separation of control and communications among them. Large WLANs are
therefore controlled in terms of distinct logical networks. So, a
number of service providers may jointly utilize network
infrastructure thereby sharing expenditures.
4.2 Protocol Benefits
Given the realities of cost and complexity of WLANs, a CAPWAP
protocol that incorporates this objective 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.
4.3 Relation to Problem Statement
This objective for supporting logical networks directly addresses
problem of management complexity. It is solved by breaking
complexity in to manageable levels. So different logical networks
are separated and then individually managed.
4.4 Customer Requirements
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.
Govindan, et al. Expires April 2005 [Page 7]
Internet-Draft CAPWAP Objectives October 2004
[TBD]
Govindan, et al. Expires April 2005 [Page 8]
Internet-Draft CAPWAP Objectives October 2004
5. Coexistence of Multiple Authentication Mechanisms
As WLANs grow in size and utility, there are increasing means of
authenticating subscribers. The choice of which to use depends on
the deployment scenario, service provider preference and other design
aspects. This objective addresses such diversity.
5.1 Objective Details
The objective is to include support for multiple authentication
mechanisms. This is to ensure that a CAPWAP protocol has a framework
where different types of authentication may coexist. In practice,
the different mechanisms may coexist within a single logical WLAN or
among a number of them. In either case, protocol support is
critical.
5.2 Protocol Benefits
A protocol that includes support for a number of authentication
mechanisms will be applicable in a wide range of deployments and
scenarios.
5.3 Relation to Problem Statement
This objective relates to large WLAN deployments where there are a
variety of requirements from service providers, subscribers and
regulators. Authentication mechanisms will therefore differ for
various requirements. In order to accommodate all these differences,
the CAPWAP protocol must support multiple authentication mechanisms.
5.4 Customer Requirements
Customers are demanding choice and flexibility in the way in which
they use WLANs. For example, service providers want different ways
of authenticating different subscriber groups; some groups need IEEE
802.1X while others web-based authentication. Furthermore, there are
trends for temporary authentications where the duration of
authentication is adapted. This objective is in response to such
requirements.
[TBD]
Govindan, et al. Expires April 2005 [Page 9]
Internet-Draft CAPWAP Objectives October 2004
6. Automated Processes Objective
WLANs are increasing in complexity due to the sheer size of
deployments. As a result, the cost of operating and managing
wireless networks is becoming substantial. This section presents an
objective for automating key processes of WLAN control by which
operational costs may be reduced.
6.1 Objective Details
The objective is to simplify and automate discovery and
initialization processes. New AP designs being inexpensive and easy
to install, allow for frequent alterations to the physical WLAN
according to deployment needs. This calls for automating the
processes for setting up new WLAN devices.
6.2 Protocol Benefits
Automation is a key benefit to a CAPWAP protocol as it makes for
cost-effective deployment. This has a direct effect on the adoption
of the protocol.
6.3 Relation to Problem Statement
This objective for automation is derived from the problem of managing
complexity. The problem relates to large scale deployments in which
discovery and initialization are intensive, error-prone and
consequently, costly, operations. Realization of this objective will
be a direct solution to this problem.
6.4 Customer Requirements
Wireless network service providers have consistently required
cost-effective solutions. As these providers are predominantly
commercial, this objective is crucial for realization.
[TBD]
Govindan, et al. Expires April 2005 [Page 10]
Internet-Draft CAPWAP Objectives October 2004
7. WLAN Status Monitoring Objective
The scale of WLANs that CAPWAP addresses results in a number of
challenges. Among them, is the possibility of multiple points of
failure at different time instances.
7.1 Objective Details
This objective is for monitoring the status of WLANs, including
various devices, so as to appropriately configure and manage them.
WLAN status is used broadly here to include statistics, keepalive
signals and other input information. Status information may
therefore be combined in the realization of this objective.
7.2 Protocol Benefits
The effectiveness of a protocol is based on the relevance of
information on which it operates. So, the fulfillment of this
objective will ensure that such information is made available to a
CAPWAP protocol.
7.3 Relation to Problem Statement
This objective addresses the problems of management complexity and
WLAN configuration for which solutions require appropriate
information. For the former problem, the scale, type and active
status of the WLAN is required, while in the latter, consistent
configurations are maintained based on timely information.
7.4 Customer Requirements
WLAN equipment customers require effective management solutions for
their networks. This objective will ensure such a solution by
providing the appropriate information on traffic conditions and
network status.
[TBD]
Govindan, et al. Expires April 2005 [Page 11]
Internet-Draft CAPWAP Objectives October 2004
8. QoS Objective
Integral to the success of any wireless network system is the
performance and quality it can offer its subscribers. So for large
scale WLANs, system-wide QoS is particularly important.
8.1 Objective Details
The objective is for QoS over the entire WLAN system which includes
the switching segment and the wireless medium. Given the fundamental
differences between the two, it is likely that there are alternate
QoS mechanisms between APs and wireless service subscribers and
between APs and WLAN controllers. So resources need to be adjusted
over both portions of the system so as to ensure throughput and other
performance.
8.2 Protocol Benefits
A protocol that addresses QoS aspects of WLAN systems will deliver
high performance thereby beneficial for wireless subscribers and
resource utilization. Since CAPWAP deals with APs directly and with
the wireless medium indirectly, both of these must be considered for
performance.
For the wireless medium portion, QoS aspects in the protocol enable
high quality communications within the domain of a WLAN controller.
Since each domain generally covers an enterprise, such protocol
performance affects enterprise-wide communications.
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.
8.3 Relation to Problem Statement
QoS control is critical to large WLANs and relates to a number of
aspects. In particular, this objective addresses the problem of
accommodating 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.
Govindan, et al. Expires April 2005 [Page 12]
Internet-Draft CAPWAP Objectives October 2004
8.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.
[TBD]
Govindan, et al. Expires April 2005 [Page 13]
Internet-Draft CAPWAP Objectives October 2004
9. Conclusion
This draft presents critical objectives for the CAPWAP framework.
Most importantly, it lays down the need for enabling CAPWAP over
adaptive interfaces so that APs of both local MAC and split MAC
designs are integrally manageable and controlled. The document also
provides additional objectives for shared infrastructure and QoS.
Govindan, et al. Expires April 2005 [Page 14]
Internet-Draft CAPWAP Objectives October 2004
10. Security Considerations
The adaptive interface objective covers the interoperability of APs
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 APs.
In shared deployments with a number of a when a number 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 exchange be prevented with the
automation of discovery and initialization processes.
The objective for WLAN status monitoring relates to security also.
Wireless systems need to be constantly monitored for potential
threats in the form of rogue APs or terminals. For example, profiles
for DoS and replay attacks need to be monitored.
Govindan, et al. Expires April 2005 [Page 15]
Internet-Draft CAPWAP Objectives October 2004
11. Acknowledgements
The authors gratefully thank T. Sridhar for reviewing an earlier
version of this draft.
12 References
[I-D.cheng-capwap-classifications]
Cheng, H., Iino, S. and Govindan S., "Funcationality
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-05 (work in
progress), August 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
S. Govindan
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534415
Singapore
Phone: +65 6550 5441
EMail: sgovindan@psl.com.sg
Govindan, et al. Expires April 2005 [Page 16]
Internet-Draft CAPWAP Objectives October 2004
H. Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534415
Singapore
Phone: +65 6550 5477
EMail: hcheng@psl.com.sg
S. Iino
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224-8539
Japan
Phone: +81 45 938 3789
EMail: iino.satoshi@jp.panasonic.com
M. Sugiura
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224-8539
Japan
Phone: +81 45 938 3789
EMail: sugiura.mikihito@jp.panasonic.com
Govindan, et al. Expires April 2005 [Page 17]
Internet-Draft CAPWAP Objectives October 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, et al. Expires April 2005 [Page 18]
