[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG Action: Control and Provisioning of Wireless Access Points (capwap)
A new IETF working group has been formed in the Operations and Management Area.
For additional information, please contact the Area Directors or the WG Chairs.
Control and Provisioning of Wireless Access Points (capwap)
Current Status: Active Working Group
Mahalingam Mani <firstname.lastname@example.org>
Dorothy Gellert <email@example.com>
Operations and Management Area Director(s):
Bert Wijnen <firstname.lastname@example.org>
David Kessens <email@example.com>
Operations and Management Area Advisor:
Bert Wijnen <firstname.lastname@example.org>
IEEE Liaison to IETF:
Dorothy Stanley (email@example.com)
Bob O'Hara (firstname.lastname@example.org)
General Discussion: email@example.com.
To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap
As the size and complexity of IEEE 802.11 wireless networks has
increased, problems in the deployment, management, and usability
of these networks have become evident. Access points (APs)
typically require complex management at the IP level. As the
number of APs increases, the number of devices requiring complex
management increases, in some cases, doubling the number of IP
devices requiring management in a provider's network. In addition,
because APs have no visibility beyond their own cell, a variety of
problems ensue in large scale 802.11 networks. Load balancing
between APs, dead cell detection, and correlating patterns of
usage between APs to detect attacks are difficult to impossible.
Finally, because each AP acts as its own Network Access Server
(NAS), a network provider is faced with the prospect of moving
from a situation where the NAS is a few machines with dialup
access in a machine room to a situation where hundreds or perhaps
thousands of devices scattered across a wide geographic area have
NAS functionality. Maintaining security on such a wide collection
of devices is a difficult challenge.
In recent attempts to solve these problems, various vendors have
introduced products that redistribute the functionality of 802.11
APs in various ways. However, because the 802.11 access network
functional architecture is incompletely specified, the network
interfaces between network entities in different vendors'
products are defined in incompatible ways. As a result, the
protocols between the network entities in different products are
As a first step, the CAPWAP Working Group will develop a problem
statement and network architecture taxonomy describing the
current set of approaches to providing more support for scalable
802.11 access networks. The problem statement will describe, at
a high level, what the deployment, management, and usability
concerns are with 802.11 networks based on the traditional
autonomous AP architecture, and will link those concerns to
specific technical aspects of the autonomous AP architecture.
The network architecture taxonomy will:
- Describe the current set of approaches (including the
traditional autonomous AP architecture) to partitioning
802.11 access network functionality between network
- List what the interfaces between the network entities
are in each approach,
- At a functional level, describe what the protocols on
the interfaces between the network entites in each
- Describe the advantages and disadvantages of each
approach for scalable 802.11 access network deployment
Additionally, the architecture document will contain a threat
analysis that describes the security threats involved in each
network architectural approach.
Specific Working Group deliverables are:
- A problem statement document,
- A network architecture taxonomy document including
Specific non-goals of this work are:
- Any work requiring revising the 802.11 access network
The network architecture taxonomy document, when stable, will be
discussed with IEEE 802 in order to validate and synchronize this
work with the work in IEEE 802. This may result in merging the
work with IEEE 802 documentation in which case it may not need
to be published as an RFC. Such decision will be made in
co-operation with IEEE.
The CAPWAP WG will maintain a close working liaison with relevant
working groups in IEEE 802.11 and IEEE 802.1. Working Group
documents will be sent to an expert review board for review prior
to submission to the IESG. In order to facilitate quick
completion of this work, the Working Group charter will expire
6 months after it is approved by the IESG, at which time the
Working Group can either petition the IESG for a continuation
or recharter for further work on the interoperability problem.
Goals and Milestones:
Feb 2004: Last call for problem statement draft.
Mar 2004: Discuss last call comments for problem statement
at IETF 59.
Mar 2004: Last Call for architecture description document.
Apr 2004: Submit problem statement to IESG for publication
May 2004: Architecture document to expert review.
Jun 2004: Stable Architecture document for review/sync-up
with IEEE 802
Jul 2004: Discuss results of IEEE 802 review/sync-up
Aug 2004: Close WG or Re-charter