2.4.3 Control And Provisioning of Wireless Access Points (capwap)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-17


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

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

* 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
Done  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
Mar 06  Submit CAPWAP MIB to IESG as Proposed Standard RFC


  • draft-ietf-capwap-arch-06.txt
  • draft-ietf-capwap-objectives-00.txt

    Request For Comments:

    RFC3990 I CAPWAP Problem Statement

    Current Meeting Report

    IETF 62
    CAPWAP session
    3/7/05 - 3:30pm

    Comments on the agenda


    Comments on updated milestones by the chairs


    Comments on Next steps


    IEEE 802.11-IETF Liason report
    Dorothy Stanley

    - AP functional description
    adhoc committee was formed in Sept 2004
    distinction between function and device
    work ongoing since 9/04, to be completed in 03/05 - text to be included in TGMa draft
    list of documents

    - Additional activities of interest
    TGv WNM, chair is Pat Calhoun
    address station management and AP MIB enhancements

    TGt - wireless performance prediction TG
    TGr - fast BSS transition
    chair is Clint Chaplin

    - IEEE standards overview
    info on where to find 802.11 documents
    request letter ballot documents for IETF review

    - Comments on the objectives draft
    request for IEEE 802.11 comments
    when draft is available, will be sent to 802.11 members
    conf call to elicit comments in April
    get approval from the WG for the comments in May

    - Bernard
    what is the path by which that work goes forward
    - Dorothy S
    areas of potential work - identification of additional work needed at 802.11
    APF conf call on Wednesday to discuss official recommendation to form official liason
    - Haixiang
    question on formal procedure between the work at the two groups
    - Dorothy S
    real answers from CAPWAP WG
    - Haixiang
    what parts of the APF work are required
    - Dorothy S
    APF work is done, lots of different views on what an AP is
    - Haixiang
    concern is there may not be a single view of what an AP is
    are there many splits possible?
    - Dorothy S
    there is no right split
    - Dorothy G
    comments from review into objectives draft
    recognize IEEE 802.11 as the foremost authority for AP functions
    IEEE 802.11 determines how to split the MAC

    CAPWAP objectives - Saravanan


    - Mani
    simple capabilities exchange, granularity of the exchange
    - SG
    use capabilities as described in the arch taxonomy
    may not have to define the granularity
    enough to provide mechanisms
    - Mani
    any number of permutations & combinations that affect interoperability
    - SG
    protocol does not need to define permutations
    - JK
    protocol needs to define
    makes troubleshooting a problem
    dont mind large chunks of commonalities that dont have to be negotiated
    smaller chunks make the protocol complicated
    - SG
    its an AC issue
    - JK
    minimize choices to keep it simpler and more manageable
    - DG
    minimal set of requirements
    limit the different choices
    can be extended later
    hard deadlines, dont want to spend all the time on how many permutations
    keep the number of choices small that cover most use cases
    how to split the MAC, refer to APF on how to split
    keep the general requirements with minimal choices of diff approaches
    - SG
    arch taxonomy definitions?
    - JK
    group them into split MAC or local MAC, but dont split into tiny pieces that have to be negotiated
    keep it simple

    - Inder
    its not necessary to explicitly state how to the split MAC
    APF will not define how to split MAC
    is it possible that we can agree on a single split?
    - JK
    would be the easiest possible
    - Inder
    should we make it a requirement?
    - DG
    looking for a volunteer to write a draft on how to split the MAC
    - DS
    APF will list functions, but not implementations or how to split
    - JK
    protocol draft is the place to split
    draft should state set of functions in each group - split & local
    no need for a separate draft
    - DG
    draft that lists minimal set of functions and how to split or not
    could also be in the protocol draft
    - Mani
    goal of the objectives draft is establish sufficient basis to faclilitate protocol evaluation
    feedback from WG to draw the line between rigor and flexibility
    should the objectives draft outline the functions of the split MAC and where each function sits?
    QoS mapping from 11e - why is this relevant to CAPWAP?
    - SG
    two segments - switching and wireless
    need to manage the network as a whole - consider both segments
    - Mani
    11e already specifies the required mapping
    how is different from 11e?
    why do we need a requirement
    - SG
    requirement merely states that we need a mapping
    if it already exists then thats fine
    - Inder
    Firmware distribution
    should CAPWAP protocol require a mechanism to send sw images to WTP?
    - SG
    - Inder
    agree the firmware should be separate
    recommend just firmware update trigger, mechanism to send fw into WTP is out of scope
    - DG
    not a mandatory requirement
    looking for comments on how to split the MAC
    other than capabilities, is there a consensus on the objectives
    update the draft and WGLC at the end of the month

    - JK
    idea was to get a common set of functions, a set thats exclusive to split and another for local
    couldnt mix and match
    - Haixiang
    should not make anyone mandatory
    - DG
    objectives should not dictate protocol design
    - SG
    need to prioritize the features/objectives
    - DG
    no feedback yet
    - JK
    were there any objections
    - SG
    some of the new ones didnt have a clear priority

    - LWAPP update
    - Mani
    Does the protocol negotiate encryption capabilities?
    - PC
    requirement should state that encryption in one of WTP or AC is mandatory
    capabilities in the join phase will include the list of encryption capabilities
    AC determines where the enctyption happens
    - Clint
    is the 802.11 data frame already decrypted?
    - PC
    if encryption is at the WTP then yes, if its at the AC then no
    - Mani
    do data and ctrl frames use the same security properties?
    - PC
    this is used only for ctrl frames
    if security is required for data, use the same algo on the wire as on the air
    802.11i is between stations and AC
    - Mani
    Will PSK be part of the AC or WTP
    - PC
    configured on both, unfortunately

    CTP update

    - PC
    IP reassembly path - WTPs across firewalls and firewalls drop it
    - Inder
    - PC
    how are you securing the SNMP messages
    - IS
    SNMP over CTP and CTP is secured
    - PC
    fragmentation and reassembly for these
    - IS
    between AC and WTP
    - PC
    where does 11e terminate?
    - IS
    WTP, triggers for control go from WTP to AC
    - PC
    why do we need a separate control message to the AC instead of sending .11 frames?
    - IS
    for extensibility to other wireless standards
    - PC
    imposing work on ourselves for future technologies instead of passing it through
    - IS
    you may still need if signalling is required to the WTP
    - PC
    sending all MAC mgmt messages through to the AC simplifies CAPWAP work
    - IS
    all radio-related work happens at the WTP, results go up to the AC
    - PC
    if the AC solicits the information, then it sends a message to the WTP which then sends a different (MAC-compliant) message on the air interface
    the reverse happens in the upstream direction
    - JK
    what happens after WTP tells the AC what MAC (split or local) it supports
    - IS
    the AC ACKs what it needs the WTP to do
    some vendors may not support both, others might do
    - JK
    WTP vendors may support both MACs (similar to printers supporting multiple discovery protocols)
    ACs may not support both MACs
    - IS
    assumed that WTP will support one method, while the ACs may support both
    - JK
    protocol has to support both, AC vendors need not
    - PC
    AC has to support both, not the WTP
    - JK
    Dont think the WTP will only support one
    protocol should require the AC to tell the WTP what MAC to use
    - PC
    requirements exist today for mixed WTPs
    ACs need to support both
    - BA
    confusion on the user scenarios and how networks get deployed
    too many variations for a light-weight environment
    - Clint
    unclear how many heterogeneous (across vendors) deployments exist
    - DG
    taxonomy draft includes multiple vendors' view of the marketplace
    assume market requires heterogeneous deployments
    - Haixiang
    need capability negotiation requirement
    - IS
    challenge for WG is how the negotiation will be supported
    need to agree on the number of variations
    - PC
    the different split MACs are useful in different environments
    - IS
    there is only one type of local MAC, but split MAC may have multiple variations
    - PC
    proposal should state how the MAC is split
    - Haixiang
    even local MAC should state clearly what goes where

    SG = Saravanan
    DG = Dorothy G
    DS = Dorothy S
    IS = Inderpreet
    PC = Pat Calhoun
    JK = James Kempf
    BA = Bernard Aboba


    IEEE 802.11 - IETF Liaison Report
    CAPWAP Objectives
    Light Weight Access Point Protocol (LWAPP)
    CAPWAP Tunneling Protocol (CTP)