2.4.3 Control And Provisioning of Wireless Access Points (capwap)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-11-03

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:

The original CAPWAP WG charter included drafting a problem statement
and a taxonomy of architectures. The new charter of the CAPWAP WG
proposes building upon the original charter and developing a CAPWAP
protocol to provide interoperability among WLAN backend architectures.
The intent of the CAPWAP protocol is to facilitate control, management
and provisioning of WLAN Termination Points (WTPs) specifying the
services, functions and resources relating to 802.11 WLAN Termination
Points in order to allow for interoperable implementations of WTPs
and ACs.

The revised CAPWAP WG will reference two classes of the Centralized
WLAN Architecture family, namely the Local MAC and the Split MAC,
as described in the CAPWAP Architecture Taxonomy draft. The protocol
will define the CAPWAP control plane including the primitives to
control data access. An effective Centralized CAPWAP Architecture
impacts how WLAN data traffic is managed over the backend network.
This implies the abilitiy to control how data is forwarded by
negotiating existng data encapsulation mechanisms and specifying
data payload formats in order to ensure interoperability between
CAPWAP vendors. No other specifications of the CAPWAP data plane
are within the scope of this charter.

The CAPWAP WG will strive for extensibility in the protocol design
to favor future applicability to other access technologies, especially
IEEE 802.16. While accommodation of any access technology other than
IEEE 802.11 is not required for successful completion, there are clear
deployment advantages if a wide range of access technologies are
accommodated.

In summary, the primary goals of the group will be:

1. Defining a set of Objectives based on the architecture taxonomy
work that lists the requirements for an interoperable CAPWAP
protocol. In addition, the WG will incorporate requirements
derived from the inputs provided by Enterprise and (hotspot)
Providers based on the WLAN deployment challenges addressed
by CAPWAP architecture. This document will:

a. include objectives to address problems described in the
CAPWAP Problem statement document
b. Describe each objective, its benefit to the protocol and
how it satisfies the problem statement.
c. Prioritize and classify the objectives into 3 categories:
i. Mandatory and Accepted
ii. Desirable
iii. Rejected
d. Undergo review in IEEE 802 as needed

This should result in the first WG Last Call for Objectives draft.

To avoid requirements bloat and stalemate, the WG has a
hard deadline on the Objectives phase. The WG MUST reach WG
consensus on the objectives draft by Feb 2005. This is for
several reasons:
* We must send this for review to IEEE at that time.
* We must have a reasonably stable set of objectives
so that candidate submissions are aware of the objectives
to be met.

The 2nd WG Last Call (in April) for the objectives draft is to
ensure that the WG has consensus on any changes that may result
from IEEE and expert review. So it is not the intention that
the WG keeps adding new Objectives after Feb 2005.

If the WG cannot reach consensus on the Objectives draft by the
May 2005 milestone to the IESG, the WG will close.

2. Evaluating a set of candidate proposals that include existing
IETF protocols and any proposals leading to the selection of
a protocol on which to base the CAPWAP standard.

3. Developing a CAPWAP protocol standard that meets the Mandatory
and Accepted objectives from the Evaluation draft and contains
the minimal set of feature needed to control and provision
WLAN Access Points. Specifically The CAPWAP protocol document
will address the following considerations:
a. Architecture
b. Operations
c. Security
d. Network Management
e. Scalability
f. Performance

4. A MIB Document to support the CAPWAP protocol.

In addition, the CAPWAP WG will maintain its Liaison with the
IEEE to ensure consistency of its work with the IEEE 802.11
Standard.

Deliverables:
* Objectives/Criteria Document for CAPWAP protocol
* Protocol evaluation and base protocol selection document
* CAPWAP Protocol standard
* MIB support standard

Goals and Milestones:

Done  Last call for problem statement draft.
Done  Discuss last call comments for problem statement at IETF 59.
Done  Last Call for architecture description document.
Done  Submit problem statement to IESG for publication approval.
Done  Architecture document to expert review.
Done  Stable Architecture document for review/sync-up with IEEE 802
Done  Discuss results of IEEE 802 review/sync-up
Nov 04  Issue first Internet-Draft of CAPWAP Objectives document
Feb 05  First WGLC for CAPWAP Objectives Draft
Feb 05  Submit CAPWAP Objectives to IEEE/IETF experts review
Mar 05  Deadline to submit candidate protocol proposals to the WG
Apr 05  Second WGLC for CAPWAP Objectives Draft
May 05  Submit CAPWAP Objectives draft to IESG as Informational RFC
May 05  Shutdown WG if CAPWAP Objectives have not finalized, otherwise continue with next milestones.
Jun 05  Issue first Internet-Draft of CAPWAP Evaluation draft
Aug 05  WGLC for CAPWAP Evaluation draft
Sep 05  Submit CAPWAP Evaluation draft to IESG as Information RFC
Oct 05  Issue first Internet Draft of CAPWAP protocol
Nov 05  Issue first Internet-Draft of CAPWAP MIB
Dec 05  WGLC for CAPWAP protocol
Jan 06  Submit CAPWAP protocol to IESG as Proposed Standard RFC
Jan 06  WGLC for CAPWAP MIB
Mar 06  Submit CAPWAP MIB to IESG as Proposed Standard RFC

Internet-Drafts:

  • draft-ietf-capwap-problem-statement-02.txt
  • draft-ietf-capwap-arch-05.txt

    No Request For Comments

    Current Meeting Report
    IETF 61 CAPWAP 11/8/2004 Meeting notes

    Chairs

    Dorothy Gellert
    Mahalingam Mani

    Meeting start
    [Dorothy Gallery] Announce agenda:
    Going through charter
    IEEE AP functions ad-hoc group update - Dorothy Stanly
    CAPWAP taxonomy update - Lily Yang

    [DG] Present new charter.
    Local MAC and split MAC are supported by CAPWAP.
    CAPWAP protocols should include control plane, data forwarding, extensibility to other 802 access technology, especially 802.16.
    Goal for new charter:
    Define objectives
    Evaluate candidate protocols.
    Currently in objective draft phase.
    Present objective draft format and dates.
    Need to follow the format, currently draft does not comply with the format.
    WGLC - Feb. 2005 submit IEEE for review.
    List of milestones

    [Pat] What happens if the protocol is submitted and then the objective is changed because of IEEE review?
    [DG] Protocol will be updated based.

    [Hong] What if different 802 protocols have conflicting requirements?
    [DG] If requirement are conflicting among 802 protocols, we will focus on 802.11.
    [Hong] Which flavor of 802.16 will CAPWAP focus on?
    [DG] We should discuss this on mailing list.

    [Lili] CAPWAP draft update
    Complete security review.
    Address comments on security review.
    Concluded WG last call and address comments on v06.
    Changes from v4 to v5 are from security review, including 4.8.1, 4.8.3, 5.2, and section 7.
    Changes from v5 to v6: reorganization (introduction before definition). Clarify WTP in definition. Add more information on "client data security".
    Discuss PMK sharing issue- it is out of scope of the taxonomy draft.

    [Bernard] PMK is bound to authenticator, but not MAC address.
    [Roth] Propos new text for PMK sharing. If you want PMK sharing, need to know the scope of sharing. Roth sent out new text and Lily will put new text in draft and try to close it in a week.

    [Dorothy Stanly] 802.11 liaison report
    Create Ad-hoc group to describe AP functional definition.
    Create TGma to update AP functional definition into standard document.
    Details are in IEEE document 1191 and 1225
    Propose to start Wireless network management study group.
    TGT - performance prediction.
    TGr - Fast BSS transition.
    Summary of IEEE groups.
    Present IEEE working group summary.

    [Mani] CAPWAP working group charter
    Aggressive schedule
    Initial focus on objectives -
    Objective is to help to create guideline for protocol selection process.
    Avoid orthogonal information
    Avoid stating the obvious - be specific.
    [Saravanan] presentation of draft-govindan-capwap-objectives-00.txt
    Comments
    [Interdeep] Multiple authentication methods are for user authentication. It should not be part of CAPWAP.
    [Saeavanan] CAPWAP needs to support multiple authentications so authentication information can be transported from WTP to AC.
    [Pat] Need more details on problem statement.
    [Lily] presentation of draft-zhou-capwap-objectives-00.txt
    Architecture requirement - local MAC and split MAC need to be supported.
    One AC needs to support both WTP architectures at the same time.
    Needs to define Local MAC and split MAC clearly.
    AC and WTP needs to be interconnected via multiple technologies - Ethernet, ATM, internal bus, etc.
    CAPWAP should be transparent to clients.
    VoWLAN is the most important service for service provider - 802.11e, fast handoff.
    Restrict direct inter WTP layer 2 communication- all intelligence should be sent through WTP.
    WLAN virtualization - allow multiple logical WLANs on single physical WLAN.
    Not clear if the handoff is focus on same subnet or multiple subnets.
    Management - WTP should be managed directly or indirectly via AC.
    Security - 802.11i, secure information exchange between AC and WTP.
    QoS - QoS policy should be supported between AC and WTP.


    Comments:
    [Interdeep] Restrict direct inter WTP layer 2 communication should be optional, not required.
    [Bob] Should WTP be managed directly even if AC is present?
    [Lily] Not clear about it. It might be needed due to the deployment rollout.
    [Bert]How CWPWAP affect fast-handoff? Need to focus on the right thing.
    [Lily] Not clearly defined in draft now. Need to go through details.
    [Dorothy] Need to reformat both drafts to comply with standard objective format.
    [Pat] There are more AC implementation details than protocols requirements in current draft.
    [Lily] We should clean up draft to focus on protocol requirements.
    [Bernard] Need to separate feature list from protocol requirement document.
    [Bernard] Objective should have performance requirement.

    [Dorothy G] open discussion
    Poll: Have conference call next week to have 2 draft editors to work together- approved.

    Slides

    Agenda - Chairs
    Status Update of CAPWAP Architecture Taxonomy
    IEEE 802.11 - IETF Liaison Report
    Agenda
    IETF CAPWAP Protocol Objectives
    CAPWAP Objectives