A new IETF working group has been proposed in the Operations and
Management Area. The IESG has not made any determination as yet.
The following description was submitted, and is provided for
informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by January 7th, 2004.
Control and Provisioning of Wireless Access Points (capwap)
-----------------------------------------------------------
Current Status: Proposed Working Group
Mailing Lists:
General Discussion: capwap@frascone.com
To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap
Archive: http://mail.frascone.com/pipermail/capwap/
Description:
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
not interoperable.
Charter:
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
entities,
- 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
approach do,
- Describe the advantages and disadvantages of each
approach for scalable 802.11 access network deployment
and management.
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
threat analysis.
Specific non-goals of this work are:
- Any work requiring revising the 802.11 access network
functional architecture
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
9 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
approval.
May 2004: Architecture document to expert review.
Aug 2004: Discuss last call and expert review comments
at IETF 60.
Aug 2004: Submit architecture document to IESG for
publication approval.
Sep 2004: Close WG or Re-charter
