2.4.15 Control And Provisioning of Wireless Access Points (capwap) Bof

Current Meeting Report


Meeting notes
58th IETF
Friday, November 14, 0900-1130
[Notes scribbled by Chris Hertel  crh@ubiqx.mn.org]

Agenda Bashing

- The agenda was presented with no dissent.

Update since Vienna Meeting - James Kempf

- There were some critical comments on the CAPWAP workgroup charter.
  Issues raised included:
  + How would the CAPWAP WG coordinate with the IEEE?
  + The WG should focus on architecture.
  + The scope of the WG would need to be clarified.

Problem Statement - Pat Calhoun
  - Four basic problems in current 802.11 wireless systems were 
    + Large networks contain too many devices (Access Points), all of 
which must be individually managed.
    + Variations in products and rich feature sets result in a 
configuration mess.
    + Wireless networks should be viewed as a single network, not as many.
    + There is no mechanism for authenticating Access Points to the wired 
  - There are six start-ups with products that fit the general CAPWAP 
  - The goal of standardizing protocols is plug-and-play 
interoperability between such products.
  - Questions:
    + Is this (the IETF standards process) the only way to achieve the 
stated goals?
    + Is there to be only one standard?
    + How is this an IETF problem?

CAPWAP Architecture - Mahalingam Mani
  - Ease of Use
    + Central Management
  - Increased Security
    + Central policy decisions and enforcement
  - Architectures
    + Classic AP
    + Split AP
    + Split MAC
    + single AP Switch (Bridge)
  - Authentication
    + The Access Point (AP) and Access Controller (AC) should 
authenticate to one another.
    + Key exchange/management issues to be discussed.
    + Some discussion of the terms Access Controller (AC) vs. Access 
Router (AR).
  - Layer 2 / Layer 3 questions
  - Scalability
    + One AC or a group of ACs?
      > AC to AC communications
        * Peer to peer?
        * Hierarchy?
        * Hybrid?
  - Discussion of Architecture vs. descriptions of functional 
    + Define the *Functional* architecture.
  - Discussion about the Scope of CAPWAP and the time it might take to 
produce a workable protocol and specification.
    + What is the scope of the WG?
    + Will vendors cooperate via the IETF?

DIRAC - Songwu Lu
  - Presentation describing a software-based wireless router system

CAPWAP Issues - Dorothy Gellert
  - Question:  Does this work belong in the IETF and/or the IEEE?
    + It does not change IEEE standards.
    + There is an IEEE liaison (Dorothy Stanley)
    + Technical Advisor (Bob O'Hara)

  - Dorothy Stanley provided an overview of IEEE documentation 
    + 802.11 is one document, the letters following the numbers 
indicate ammendments which will be incorporated.
    + Ammendments get rolled into a single document.

  - Is "Secure Download" in scope.
    + Consensus: No.
  - Why re-invent discovery
    + WG will recommend an existing discovery mechanism
  - Is IP used just to justify creating an IETF WG?
  - Why discuss protocol work in the charter?
    + The charter should discuss architecture work.
  - Should there be more agreement on "proper" ways to split the 
    + The focus should be on identifying and isolating 
  - The WG will work with raw 802.11 protocols.
    + No vender extensions.
  - CAPWAP is all about interoperability.
  - The term Access Controller will be used instead of Access Router.
  - Is management not a MIB issue?

IEEE 802.11 and CAPWAP/IETF interaction
  - Bob O'Hara will be technical advisor
  - 802.11 will review CAPWAP
  - The IEEE has study groups working on:
    + Mesh architectuers
    + Wireless performance and prediction
    + Public Access issues
    + Fast roaming


CAPWAP Architecture
CAPWAP Problem Statement
IETF Liaison Report
DIRAC: A Software-Based Wireless Router System