CAPWAP Arch-Draft Issues

1
CAPWAPArch-Draft Issues

• IETF 59, Seoul
• 4 March 2004

2
1 Data-forwarding

• Datapath should not be required to traverse AC.
• This draft (on architectural taxonomy) does not
  require data forwarding through AC. But it does
  intend to include description of architectural
  variant(s) which do(es)

3
2 CAPWAP focus

• CAPWAP is too narrowly focused on IEEE 802.11
• The WG has gone through enough analysis to
  justify the identified need in WLAN space.
• This alone calls for enough interface clarity in
  architecture.
• Need to minimize scope to limit complexity and
  reach consensus across SDOs and vendors
• any shortcomings to the approach may be argued
  through drafts articulated well enough to justify
  it.

4
3 CAPWAP Routing

• CAPWAP is about distributed routing.
• CAPWAP is intended to describe ability to
  monitor, control and provision AP elements across
  a RF/wireless domain. Routing between APs
  Network Infrastructure is an optional consequence.

5
4 Capabilities negotiation

• Capabilities negotiation described in
  architecture draft how does it help
  interoperability?
• The intent is to deduce functional capabilities
  APs (and AC combine to) provide.
• No clear answers yet. While outside scope of the
  charter now this is the basis of exercise to
  agree on a AP AC interworking.

6
5 Capabilities

• Will this lead to implementing all variants in
  APs and ACs?
• Capabilities are intended to identify the scope
  of AP functions.
• Taken together with IEEE work on AP functions
  should lead to a well defined functional balance

7
6 Terminology AC, AR, AB

• The usage of AB, AR and AC are inconsistent with
  the definition of terms
• Fix definition usage.
• Access Controller (AC) - can be an AB or an AR.
  Signifies the control plane rather than datapath
• AB - Access Bridge only applies to controllers
  that are capable of direct-connect or L2
  connected.
• AR - Access Router applies to controllers that
  are capable of L3/IP connect.

8
7 AP AR name

• How do APs and ACs know each others names in
  CAPWAP?
• For an entity to be managed it needs to have an
  identity
• Current CAPWAP draft does not discuss namespace
• Identity must be authenticated (such as a
  subjectname in a cert.) and reliably securely
  provisioned.
• The taxonomy will try to describe current schemes.

9
8 Interoperability

• How do we get to an interoperable WLAN backend?
• Is it by defining one reference WLAN model?
• Is there only one possible model thats right?
• What is the route to CAPWAP?
• all-embracing all APs to all ACs?
• Identify one functional distribution approach
  thats scalable?
• By defining functions that CAPWAP wants to
  decentralize and arriving at the right
  distribution of functions preserving IEEE 802.11
  WLAN semantics
• More?

10
9 RRM Distribution

• Where should RRM (Radio Resource Management)
  reside?
• AP provides measurements, AC manages
• The draft to expand on RRM approaches and their
  Pros Cons

11
10 AC registration

• AP should be authenticating to only one AC. the
  Discovery section describes it being
  authenticated to more than one available AC
• The AP will actively be associated to only one AC
  at a time managed by one instance of AC. It may
  be capable of registering with another upon an AC
  failure.

12
11 Distribution Integration

• every AP is its own, isolated ESS and no APs
  actually implement the architecture described in
  the standard
• How should distribution and integration be
  distributed to scale?
• ltopengt

13
12 TSN, TKIP, RSN

• 3.3.5.1.2 confuses TSN TKIP
• PSK can be used in TSN, RSN
• RSN is based on RSNA-only BSS TSN can be a mix
  of WEP, TKIP, RSNA capable devices.
• ltincorporate review changes from IEEE Mike Mgt

14
13 Motivation section

• seems to prefer one type of data-forwarding.
• appears to imply other wireless technologies MAC
  are splittable.
• Neither are implied.
• Data forwarding requirement through AC is not
  mandated.
• The mention of split does not make any
  assumptions about MAC-split vs. AP split it
  means functional split.
• The section will be restructured to reflect
  taxonomy goals.

15
14 ForCES, DIRAC etc.

• Comparison of ForCES, DIRAC to LWAPP is
  premature.
• This section of document, while less significant
  to the current charter, is discussing prior art.
• The intent is to reference possible relevant work
  already done.
• Comparisons to LWAPP currently may be removed.
• However, LWAPP as now adopted by some vendors may
  be another prior art (not draft submitted to
  IETF) to discuss, besides other open
  protocols/architectures.

16
1 PS draft Issue

• Incompatibilities arising due to different types
  of functional splits is an issue to be addressed