2.4.4 Control And Provisioning of Wireless Access Points (capwap)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, California USA. It may now be out-of-date.

Last Modified: 2004-06-16

Chair(s):
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
Internet-Drafts:
  • - draft-ietf-capwap-problem-statement-01.txt
  • - draft-ietf-capwap-arch-03.txt
    • No Request For Comments

    Current Meeting Report
    CAPWAP IETF-60 Meeting notes taken by Dr. Sarikaya.


    The following agenda is proposed for the meeting on Wednesday (8/4/04,
    1-3pmPT) session:


    1. Agenda Bashing - 5 min.
    2. Status of the current drafts - 5 min
    Problem statement
    Architecture document v04. new security comments from IETF expert review.
    3. WG milestone Review - 5 min.
    6 month charter. All done. Final milestone: conclude or recharter
    Chair expressed thanks to architecture taxanomy DT.
    4. Revision Changes to Architecture Taxonomy draft
    (http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-03.txt)
    - 20 min. (Lily Yang)
    Lily presented revised taxanomy draft. 12 people DT. 14 submissions to the survey from vendors. Work closely with IEEE.
    Lily talked about whats new in each version from v0 to v4. In June 2 more survey submissions from mesh vendors. Next week v5 will be issued.
    16 surveys 15 from vendors one from UCLA.
    Lily next taled about architectures, autonomous, centralized, distributed. Mostly centralized, 3 distributed (mesh) type.
    Autonomous : AP supports all including L3.
    Centralized: WTP +AC together AP functions. Challenge: no standard way of splitting MAC. Local, 5, split 6, remote MAC 1
    In split MAC, real time MAC is local, non RT MAC is at AC. There is no standard way of splitting each vendor different.
    Next Lily talked about each architecture details. Func. Distribution in local MAC. Choice in data integration some in AC some in WTP.
    Split MAC mgmt termination most at AC one at AC/WTP.
    Mesh : data plane decentralized, multi-hop, APs use wireless link to communication. Control plane peer-to-peer mesh interface. Or could be a central AC.
    Lily summarized current generation is centralized distributed is emerging.
    Local and split MAC cross vendor interoperability feasible within each category. Harder question is interoperability across local and split MAC.
    Is it necessary/ feasible? Optimized protocol in each category is possible.
    Pat: not necessary to define two protocols.
    Kempf: a single protocol.
    Inderpreet: deployment scenarios of local & split MAC are different.
    Gopal: can we backup to previous versions of taxanomy? What exactly is split MAC? Do we want to live with S-MAC? This is IEEE questions.
    Chair: restrict discussion to v4/v5 no backup.
    Bob: IEEE will not address split MAC.
    Gopal: then why IETF should address?
    Lily: yes IETF addresses because of protocol orientation.
    Delegate: IEEE new WG wll consider Split MAC.
    Parviz: we have a clear channel with IEEE.
    Pat: IEEE defines components, how to split components is upto vendors.
    Kempf: we should look at 11f to define our architecture.
    IEEE delegate: IEEE goal is to define thing flexible way.
    Lily propsed next steps, now v4 in WG last call. In Sept. define scope for interoperability.
    Lily thanked DT members.
    5. IEEE IETF Liaison and Status of IEEE activities -
    (Dorothy Stanley/Bob O'Hara) - 20 min.
    Draft 3 of taxanomy incorporated IEEE comments. IEEE new SG to determine
    AP functional definition. Approved July 04. SG chair is Dorothy Stanley. Next step is to complete PAR (to define scope), continue content development, form a task group. Meet in Sept.
    Parviz: timeline for having work done
    Dorothy: as soon as possible. A document defining new AP functions at least 2-3 years.
    Parviz: we need requirements to develop a new protocol.
    Kempf. Parallel work with IETF.
    Dorothy: yes, parallel.
    Inderpreet: main reason for IEEE work is how to split MAC
    Chair: better address the split not the problem for splitting.
    Dorothy: IEEE needs to address what is DS.
    Inderpreet: IEEE time frame is long, then how IETF can do protocol work now?
    Dorothy: make assumptions and do your work and at every step liason with IEEE.
    Pat: AP functions will not define MAC, MAC is defined.
    Dorothy: SG will make descriptions not make new definitions.
    Gopal: what IEEE thinks of splitting MAC?
    Dorothy: it is up to members.
    Bernard: IEEE AP functions enable many things and you can make it a AP. So IEEE work can go on in parallel to protocol work.
    Bert: IEEE has a document on violation of IEEE standards? Dorothy would indicate any violation.
    Dorothy: yes.
    Bert: we want a better definition of IEEE specs then we make sure not to violate. IETF would ask IEEE reviews. Vendors then can continue to make products and IETF can continue to develop the protocol.
    6. Next steps for WG - Dorothy Gellert & Mani
    Chair presented recharter proposal. Scope develop a CAPWAP protocol. Interoperability among WLAN controller backend architectures.
    First an objectives draft will be developed. More then requirements draft. Provide vemdor and customer perspective. List AP functional features. Reviewed by IEEE and IETF. Classify 3 categories: mandatory, desirable and rejected. It should avoid a bloat of requirements.
    Next evaluate set of candidate protocols based on objectives draft. Consider new protocols and existing IETF protocols. Then selection.
    Next CAPWAP protocol and MIB will be developed. RFC 2418 defines what is required of an IETF protocol.
    Chair presented goals and milestones. Jan 06 final submission of MIB. Aug. 05 first I-D of protocol. Oct 04 objectives document.
    Kempf: Trying to get requirements first and then protocol does not work in IETF. It prolongs process of protocol completion. Instead consider protocol proposals and ask them to agree on a converged protocol.
    Pat: How do we take customer input.
    Chair: we have a number of people to contact. We want to make sure that customer opinions are taken.
    Pat: submit draft and two months later ietf expert review is unrealistic.
    Chair: we want to be optimistic.
    Gopal: customer input good idea, but how do we choose customers? Can we clarify what customer is?
    Chair: categorize enterprise, corporate, etc.
    Gopal: what is the minimum commonality, take that and work on that.
    Parviz: gap between objectives and protocol. Do we have a good architecture for protocol development?
    Chair: taxanomy indicated main convergence, so we can build on that.
    Parviz: defining final architecture will be part of new charter?
    Chair: yes.
    Inderpreet: which architecture?
    Chair: converged architecture.
    Inderpreet: is it more than the requirements?
    Bert: we used objectives not requirements. Requirements vs. implementation, we wont consider implementation in objectives document, we will consider implementation during protocol development. This will speed up the process.
    Gopal. Milestones. We need to agree on an architecture before protocol development?
    Chair. We agreed on centralized architecture. Local and Split MAC have been agreed upon.
    Gopal: there seems to be a missing task on agreeing on an architecture.
    Chair: taxanomy draft is clear, if you have questions you should write on the mailing list.
    Gopal: I agree on taxanomy document. It defines what is available on the market.
    Pat: Local and split MAC are two approaches and people can agree on an interoperable protocol.
    Bernard: Features list and objectives. IETF should not define bloated protocols. Capwap is taking the approach of building a minimum acceptable protocol rather than bloated. Lets try this.
    Kempf: this could result in an interoperable protocol. Good for vendors and customers.
    Bernard: customers we should not ask what features they want. Instead what is painful in using should be asked.
    Chair: we should what are the problems.
    Inderpreet: we should pick customers carefully. Information gathering process should be clarified up front.
    Bert: We finished taxanomy on time with the vendor:s care. Consensus on developing a single protocol.
    I hope fair play in WG.
    Pat: Customers should be those who use large number of APs.
    7. Open discussions on possible re-charter
    Chair: goals a little too aggressive.
    Consensus on rechartering.
    Bert : check on consensus on the proposed charter.
    Yes there is consensus.
    8. CAPWAP classifications - Cheng Hong / Saravanan 15 min.
    (time-permitting)
    Govindan: AC can talk to APs to determine capabilities and then adapt its operation. We should classify functional blocks like ass. Request, traffic aggregation and then adapt.
    Framework. The draft presents an example for adaptability.
    Requirements: adaptive interfaces, shared infrastructure multiple authentication mechanism.
    Propose adapting the requirements by the WG.


    Chair. Meeting adjurned at 2:47pm.

    Slides

    Agenda
    Status Update of CAPWAP Architecture Taxonomy
    IEEE 802.11 - IETF Liaison Report
    Re-cap & Next Steps
    Re-charter Proposal
    CAPWAP Classifications & Requirements