2.4.3 Control And Provisioning of Wireless Access Points (capwap)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

Mahalingam Mani <mmani@avaya.com>
Dorothy Gellert <dorothy.gellert@nokia.com>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Bob O'Hara <bohara@airespace.com>
Mailing Lists:
General Discussion: capwap@frascone.com
To Subscribe: http://mail.frascone.com/mailman/listinfo/capwap
Archive: http://mail.frascone.com/pipermail/capwap/
Description of Working Group:
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 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 04  Last call for problem statement draft.
Mar 04  Discuss last call comments for problem statement at IETF 59.
Mar 04  Last Call for architecture description document.
Apr 04  Submit problem statement to IESG for publication approval.
May 04  Architecture document to expert review.
Jun 04  Stable Architecture document for review/sync-up with IEEE 802
Jul 04  Discuss results of IEEE 802 review/sync-up
Aug 04  Close WG or Re-charter
  • - draft-ietf-capwap-problem-statement-00.txt
  • - draft-ietf-capwap-arch-00.txt
  • No Request For Comments

    Current Meeting Report

    Control and Provisioning of Wireless Access Points WG (capwap)
    Wednesday, March 3 at 1530-1730
    CHAIRS: Mahalingam Mani(mmani@avaya.com)
    IEEE Liaison: Dorothy Stanley (dstanley@agere.com)
    Technical Advisor: Bob O'Hara (bohara@airespace.com)
    5 min.
    Problem Statement Draft Presentation & Discussions:   15
    Architecture Design
    15 minutes
    Architecture Draft
    15  minutes
    Summary of January IEEE 802.11
    10 minutes
    Upcoming IEEE 802.11
    10 minutes
    Current Issues
    20 minutes
    Functionality Classification for CAPWAP
    draft:        15 minutes 
    Open Discussions & Next
    15 minutes
    Reading List:
    Capwap Problem Statement: 
    Capwap Architecture: 
    Functionality Classifications for CAPWAP:
    Mailing List:
    subscribe in Subject line
    Reported by Matt Holdrege   <matt@strixsystems.com> 
    Changes since IETF 58 (see slides)
    Any comments on last call for the problem statement 
    Ajit? – questions on problem statement. What about mobility triggers? 
    Deriving the privacy function that the access point provides? 
    Dorothy – we are not chartered to address mobility, but security will be 
    Russ Housley: Need more than just one sentence on the security in the 
    problem statement. What security concerns will be addressed by solving this 
    Pat Calhoun – This document talks about the problems that people are 
    having today. 
    Russ:  I’ll think about it.
    ? Why are we considering 802.11? 
    Dorothy: We are taking a small scope at this time in order to 
    accomplish something with IEEE. After this effort is complete, we can 
    think about re-chartering to take on other work besides 802.11.
    Mani: We are just working on 802.11 deployments to  get an 
    understanding of what the IETF and IEEE responsibilities are before we take 
    on other technologies.
    Dorothy: Russ will provide more info on security issues for the 
    Milestones: (see slide)
    Rohan Mahy: This seems very optimistic. 
    It was agreed that it is optimistic but we need to sync up with the IEEE and 
    they are being aggressive with AP definitions. 
    Burt Wijnen: Plenty of people have signed up with the design team and the 
    IEEE has committed to review this document. 
    There were no more comments on the milestones.
    Architecture taxonomy design team: (See slides)
    The team has 12 members and there were about 7 present in the meeting.
    Expert review (see slide)
    Lily Yang: Architecture draft. (see slides)
    Questions on the speculations made? Yes there were many 
    speculations but they will be addressed by the design team. 
    Charlie: Given that each data point is encumbered by vendor 
    implementation, it’s going to be hard to come to consensus on each data 
    Mani: Why the AP functionalities are split and why people are making the 
    choices on splits? 
    Pat C: We should make it useful and easy for the vendors to apply their 
    solutions to the taxonomy. 
    ? Could you be more specific on how this taxonomy relates to layer 3? 
    Pat: What we show is that the access points can be split at layer 2 or 
    layer 3. 
    Arvid: The proposed architecture needs to be scrutinized by the design 
    Lily: This is only an input document to the design team. 
    ? There is a danger by letting the vendors simply submit their 
    architectures to the document. 
    Dorothy: We are only taking a market survey to make sure we 
    understand the market. We are not changing the basis of the document. 
    Bob O’Hara: The design team is more of a detective team that will create a 
    catalogue of the architectures. We will not design new 
    Burt: The design team shall present their work to the WG via the mailing 
    ? Suggest to publish a template?
    The March 17th date is too aggressive to submit comments. The design team 
    will be receptive beyond that date.
    Dorothy Stanley IEEE status:  (see slides)
    Burt: A good input to our document will be a list of functions that 
    don’t exist in the IEEE document. Hopefully the IEEE will accept 
    these definitions in their documents. And we hope that the IEEE will ask for 
    clarifications as needed. Also, the expert review is independent of the 
    call for interested parties. 
    We need to show what is missing from the IEEE. We hear that we need a more 
    complete definition of an AP and we need a dialogue on this. 
    After this group concludes with taxonomy we will decide together with the 
    IETF on future steps. Maybe we need a flexible AP/AC protocol. Maybe 
    something else. 
    From the .11 perspective there may not be a definitive 
    architecture, rather there will be many. We will work jointly 
    IEEE/IETF to develop these architectures.
    Mani: Current architecture issues: (See Slides)
    ? Will we define policy enforcement points?
    Pat C: That is an 802.11 function and we won’t address such 
    Parvid:  Are we splitting the control function and bearer function? 
    Pat C: we are defining architectures that work either way.
    Parvid: Is this a restriction for phase one or is the in the charter? We 
    should be cautious to not preclude future work on other 
    technologies such as CDMA or GSM, etc.
    James Kempf: We may take some future work in the IRTF and try to include 
    certain other IETF WG’s.
    ? James said that if we look at anything other than 802.11 it should be 
    research and I totally disagree. The other link-layer technologies are the 
    same model and we should include them here rather than relegate them to 
    James: Some technologies fit and others don’t.
    ? 1X and .16 give us the same architecture. 
    James: The difficulties are in the details.
    Pat: Where do you draw the line? There are a lot of radio protocols out 
    there and we can’t take them all on.
    Dorothy: Our charter is focused on 802.11 only.
    Burt: We have fully discussed this on the mailing list and we have to 
    focus on 802.11 for now. You are free to write a similar taxonomy 
    document for other radio technologies and compare them to what this group 
    Indpreet Singh: Why can’t the AP have bindings with multiple AC’s? 
    Pat: We should include this capability for fast-failover
    Dorothy: These comments were from previous work and they are simply input 
    points for our work. The architecture draft is limited to what is in the 
    charter. The problem statement does not exclude other 
    architectures such as autonomous AP’s. 
    Hong Cheng: Capwap functional classifications: (see slides)
    Bob: What options need to be negotiated on each end. If we have too many 
    options on both sides won’t that impede interoperability. 
    Cheng: Some functions cannot be split, but there are a limited set of 
    functions that can be split and we need to declare them. 
    Bob: If I want to develop an AP don’t I need to implement all the 
    optional functions? 
    Lily: The AC should implement everything and the AP can make the choice of 
    what to implement.
    Saravanan Govindan: You don’t need to implement everything. We just want a 
    list of classifications such as what we have in the draft.
    Parvid: Is there a requirement for backward compatibility.
    Dorothy: There is no requirement at this time.


    Status of CAPWAP Architecture Draft
    IEEE 802.11-IETF March Summary
    CAPWAP Arch-Draft Issues
    CAPWAP Functional Classifications