2.4.2 Control And Provisioning of Wireless Access Points (capwap)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-05-19

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
Done  Issue first Internet-Draft of CAPWAP Objectives document
Feb 05  Submit CAPWAP Objectives to IEEE/IETF experts review
Feb 05  First WGLC for CAPWAP Objectives Draft
Mar 05  Deadline to submit candidate protocol proposals to the WG
May 05  Shutdown WG if CAPWAP Objectives have not finalized, otherwise continue with next milestones.
Jun 05  Second WGLC for CAPWAP Objectives Draft
Jun 05  Submit CAPWAP Objectives draft to IESG as Informational RFC
Jul 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-ohara-capwap-lwapp-03.txt
  • draft-singh-capwap-ctp-02.txt
  • draft-ietf-capwap-objectives-03.txt
  • draft-iino-capwap-wicop-02.txt
  • draft-narasimhan-ietf-slapp-01.txt
  • draft-calhoun-capwap-lwapp-objectives-comparison-01.txt
  • draft-govindan-capwap-wicop-evaluation-00.txt
  • draft-francisco-capwap-ctp-evaluation-01.txt
  • draft-narasimhan-capwap-slapp-evaluation-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3990 I CAPWAP Problem Statement
    RFC4118 I Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)

    Current Meeting Report
    CAPWAP

    Agenda review
    Milestones and status review
    Objectives update and status:
    Richard G had a comment about logical grouping. The objective treated only "over the air" not "over the wired" network. No objection to clarifying logical groups.

    Evaluation team summary:
    • the configuration consistency objective note is protocol specific. For some protocols, this feature is not as important.

    • PMK sharing should not be an issue for the CAPWAP WG. The PMK sharing discussion has come up a number of times in 802.11.

    • Russ Housley has indicated that the PMK sharing issues needs to be addressed but does not specify whether it would be by 802.11 or CAPWAP.

    • You do not explicitly create a firmware trigger. You could the trigger a firmware download by resetting the state machine.

    • None of the protocols clearly specify how the data and control is separated.

    • The traffic separation objective addresses how user data traffic is transmitted.

    • The CAPWAP protocol needs to specify how fields such as the 802.11 sequence number, need to be set in the case of split MAC.

    • The interpretation that the protocol needs to address both Local MAC and Split MAC.

    • In some cases the the DS and IS features occur inside the WTP.

    • The SLAPP Evalutation recommendation should refer to split MAC versus local MAC.

    • Codepoints need to be registered for vendor specific codepoints - IANA consideration needs to be addressed.

    • The CTP compliance comments for authentication and encryption deals with the WTP-AC mechanism.

    • CTP uses SNMP PDU's for configuration.

    • LWAPP has an explict X.509-based authentication mechanism versus shared key authentication mechanism.

    • The independent evaluation of the LWAPP draft was valuable. More security reviews are required. If the CAPWAP group defines their own security method. More work on standardization would be required.

    • Most proposal groups intentionally did not address IANA considerations at this time.

    • The draft should be evaluation in two weeks.

    • The recommendation will pick one protocol and a series of changes.

    • It would have been nice to have more objectives in the draft to make it easier to make a selection.

    • There was a gap between two objectives that are very close, with a gap to the other two protocols.
    Protocol Overview:
    CTP:
    • The integration service was implemented entirely at WTP in version 1; it is negotiated in version 2;

    • The CTP draft should include a mechanism to do fragmentation to address IPv6 implementations.

    • CTP assumes fragmentation would be done at the application level.
    LWAPP:
    • The encryption/decryption of the data frame can be done either at the WTP or at the AC.

    • DTLS could be used to encrypt/decrypt - it could be used if there was consensus among the working group

    • Fragmentation would be preferred at the application level; the working group needs to decide what they want to do.
    SLAPP:
    • Downloading firmware into an unfriendly WTP could affect certification and standards compliance of that product.

    • Downloading firmware could potentially cause warranty issues with WTP hardware.

    • The SLAPP draft changed significantly over the last version because the SLAPP group could not convince the working group that a simple image download protocol was sufficient for a CAPWAP protocol.
    WiCoP:
    • The WiCOP skips one step in the processing, it allows the message to be processed by simply parsing the header. Other proposals involve parsing the header as well as doing a memory lookup.

    • This proposal allows the AC to bridge between logical groups within the system.
    CAPWAP Taxonomy Recommendations
    • The use of the SME versus proxying MAC Management frames has an advantage that it is more bandwidth efficient and has longer processing, but it comes at a cost of protocol complexity.

    • The group has agreed to address the issues given in the taxonomy recommendations as an activity.

    Slides

    Agenda
    CAPWAP Objectives
    CAPWAP Tunneling Protocol (CTP)
    Light Weight Access Point Protocol (LWAPP)
    SLAPP
    Wireless LAN Control Protocol (WiCoP)
    CAPWAP Evaluation Team Summary Report
    CAPWAP Taxonomy Recommendations