[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: laugh test - capwap

The split AP architecture does
not involve any changes in IEEE 802.11 standards, since the IEEE
802.11 specification says nothing about the architecture of the
IEEE 802.11 access point.

This isn't really true. There are quite a few assumptions about Access Point behavior made in IEEE 802.11, although they are mostly not explict. It is true that an AP may not conform to the classic Bridge Architecture of IEEE 802.1D, but much of the behavior needs to be equivalent for things like VLAN tagging/untagging to work properly.

One thing that is very clear about the IEEE 802.11 architecture is that the AP is *not* required to be an "Access Router", and that an AP needs to be able to perform functions like VLAN tagging and untagging like an 802.1D bridge would, not a router. So I am concerned that this little sentence hides some major mis-understandings about the function of an IEEE 802.11 which will come back to bite us later.

This new architecture has been adopted
by many manufacturers, each with some variation.  Creating an
interoperable protocol between the AP and the AR will benefit the
network operator community by allowing operators to build networks
with equipment from a variety of conforming vendors.

This is not true in general. 802.11 APs have so many proprietary aspects that I doubt that a single protocol could enable interoperability across the board. For example, many APs have proprietary Inter-Access Point Protocols (IAPPs); others do proprietary communication between the STA and AP; still others have proprietary fast handoff schemes.


Specific Working Group work items are:
  - Clear problem statement and description of the split AP
    architecture,

It's hard for me to see how work on 802.11 AP architecture belongs in the IETF, unless there is some kind of review process with IEEE to make sure it makes sense. It's been hard enough to get architectural agreement with IEEE 802.11.

  - CAPWAP security requirements, defining the needs for security
    between the AP and the AR both for host data transport and for
    AP-AR signalling and control,


  - A protocol for implementing the split AP architecture,
    including the following functionality:


    . Discovery of ARs by APs (this work should point to existing
      IETF standards, if possible)


    . Auto-organization of APs and ARs into a managed wireless
      access network, including failover if an AR should fail,


    . A tunneling protocol for IEEE 802.11 non-realtime
      host-related signalling and data between the AP and the AR,

Doesn't the IETF have enough tunneling protocol already?


    . Support for configuration of the AP by the AR, including
      secure download and booting of code to the AP (some aspects
      of this task may involve existing IETF standards),


It's hard for me to see why this WG should be allowed to do any work on
the boot problem.

    . Security for both tunneled host data and AR-AP signaling, as
      necessary to address the requirements (this work may involve
      utilizing existing IETF standards).

The intent of the CAPWAP Working Group is to complete the protocol
specification as quickly as prudently possible and to serve as a
forum for discussion of issues found when testing interoperability,
in typical IETF fashion.

While not specifically a work item, the Working Group will attempt
to make all designs as independent of the IEEE 802.11 radio
protocol as possible, so that the protocol might, in the future be
used with other radio protocols.  However, in any situation where a
tradeoff between simplicity/speed of design completion and
extensibility is required, the Working Group will opt for the
former.  The Working Group will also co-ordinate closely with the
IEEE 802.11 WG.

Specific non-goals of this work are:

  - Support for general, inter-subnet micromobility,
  - Interoperable APIs for downloaded AP code images,
  - Any IP-layer work that would require changes to the IEEE 802.11
    MAC layer,
  - Dependence on yet to be approved IEEE 802.11 work or drafts,
  - Support for an inter-AP communication protocol, like IEEE
    802.11f,
  - Direct joint development of protocols with the IEEE 802.11 WG.

Is review of CAPWAG work by IEEE 802.11 precluded? I would certainly hope not.

_________________________________________________________________