2.4.3 Control And Provisioning of Wireless Access Points (capwap)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-27

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 2005  Submit CAPWAP Objectives to IEEE/IETF experts review
Feb 2005  First WGLC for CAPWAP Objectives Draft
Mar 2005  Deadline to submit candidate protocol proposals to the WG
May 2005  Shutdown WG if CAPWAP Objectives have not finalized, otherwise continue with next milestones.
Jun 2005  Second WGLC for CAPWAP Objectives Draft
Jun 2005  Submit CAPWAP Objectives draft to IESG as Informational RFC
Jul 2005  Issue first Internet-Draft of CAPWAP Evaluation draft
Aug 2005  WGLC for CAPWAP Evaluation draft
Sep 2005  Submit CAPWAP Evaluation draft to IESG as Information RFC
Oct 2005  Issue first Internet Draft of CAPWAP protocol
Nov 2005  Issue first Internet-Draft of CAPWAP MIB
Dec 2005  WGLC for CAPWAP protocol
Jan 2006  Submit CAPWAP protocol to IESG as Proposed Standard RFC
Jan 2006  WGLC for CAPWAP MIB
Mar 2006  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-04.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
  • draft-ietf-capwap-eval-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

     
    - Review of agenda
- Review of milestones
- LWAPP Poll results - 39 responses, 26 for and 13 against
	Summary of no votes:
	- the majority of the no votes had to do with IPR issues (7 votes)
	- the protool should not be decoupled from recommendations (2 votes)
	- the poll will continue until Tuesday 11/15/05
	- Issues with poll:
		- the poll was used to indicate the view of the working group
		- the poll would be an indicator of the consensus
		- the protocol was tied with the recommendations to minimize the delay
		- the work moving forward will be to address issues with the protocol
		- the recommendations of the evaluation team are subject to consensus among the working group
- IEEE 802.11 Liason Report
	- IEEE 802.11v should be included in the table of Task Groups
	- IEEE 802.11u should be listed as a potential group of interest
	- If there is interest, drafts would be available to the working group through an email request to the	 	CAPWAP chairs
- CAPWAP Evaluation Draft follow-up
	- The choice of GRE as a protocol prevents it from working through NAT and addressing NAT Traversal 	requirements - it requires a NAT traversal helper
- LWAPP over DTLS
	- The protocol works with SCTP
	- When you use a protocol over a protocol, you need hooks to co-ordinate state machines when errors 		occur. The discussion will be taken off-line.
	- It seems to be a relatively straight forward job to define LWAPP over DTLS.
	- There are potential opportunities for DoS attack during the discovery phase.
	- There are two potential DoS issues: one during the initial discovery phase - however you could use 	cookie exchanges to protect from that.
- CAPWAP System Security
	- Replaying a packet to a different destination is covered as long as each SA uses a different key
	- If an application requires encryption, then that encryption should provide encryption. 
	- You always will need MAC's.
	- You could replace the proposed DTLS with something similar to 802.1x
	- The Wi-Fi Alliance is ruling out WEP at the end of 2006
	- The AC should proxy management for the WTP's. If you don't have that, you will need to establish a 	security association between the management console and each WTP. This solution is not scalable.
	- Any authenticated interaction with the WTP's should go through the AC.
- Discussion on CAPWAP evaluation recomendations
	- The more modes of operation we add, the more complex the protocol becomes.
	- This mode was discussed in the architecture taxonmy. All the modes in the taxonomy should be 	supported.
	- It might be helpful to address this issue by stating mandatory and optional modes of operation.
	- We should address the pros and cons of each issue to determine whether it should be included in the 	protocol.
	- On the DTLS issue, we wanted to have a more detailed proposal. Now we have that.
	- There are customers who want to run L2 because they can't be bothered configuring IP. However, the 	IETF should not care about this.
	- L2TPv3 is tightly coupled with PPP
	- LWAPP makes use of UDP as a shim protocol. 
	- We are defining the CAPWAP header. We should not be spending time on the transport header.
	- L2TP already has its own header. GRE needs extensions in order to work.
	- LWAPP provides configuration consistency through the handshake when it joins the AC. 
	- Configuration consistency should be able to be checked at any time.
	- There are two pieces of software in LWAPP: the system software, the boot loader, and the radio 	drivers. Make firmware updates into smaller chuncks.
- Discussion on open WG issues
	- Any form of PMK sharing requires a client/supplicant. Therefore this is an IEEE problem, not an IETF 		problem. This is an issue addressed by IEEE 802.11r.
	- Communication is needed to the WG members to indicate the current IPR conditions.
	- There is no agreement that the IPR statements are not fair.
	- This WG is bound by the IPR rules of the IETF.
	- If people are not happy with the fairness of the IPR issues. Regardless of which protocol we move 	forward with, there will be issues.
	- There's a cloud of uncertainty no matter how we proceed.
	- Even if we start clean now free of IPR, there is no guarantee that there won't be IPR issues in the 	future.
	- The holder of the patent application cannot be specific on its claims until the patent is granted.
- Discussion on WiMAX
	- Introduction to WiMAX architecture
	-

    Slides

    CAPWAP Chairs' Summary
    IEEE802.11 Liaison Report
    Summary of CAPWAP evaluation
    CAPWAP over DTLS
    CAPWAP Threat Analysis
    CAPWAP: Issues Discussion
    Applicability of CAPWAP to WiMAX
    CAPWAP Comparative analysis