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

Re: CAPWAP BOF follow up: nmrg - CAPWAP

Plus other non-802 radio protocols, like UWB.
Like Bluetooth, my understanding was that UWB was not really focussed on wireless access points, so I'm not clear why CAPWAP would help. Am I missing something?

The whole "lightweight" issue is a red hearing, which is why the BOF name is
CAPWAP and not LWAPP. The architectural role CAPWAP plays is like the radio
access network protocols in cellular systems, that do radio resource
management between cells, control individual base stations, and provide
security provisioning between the wired backhaul network and the access
network router.
Security provisioning seems like a separate issue from control or radio resource management. I understand the control portion. Radio resource management is an important issue, and something that IEEE 802.11k is working on. Is 802.11k also working on MIBs for the control of radio resources?

The lack of such a protocol leads to some serious problems in
802.11 systems, for example, there is no way for access points to load
balance except to refuse to associate with stations.
Load balancing and roaming are important issues, and we do observe lots of "odd" behavior and instabilities in practice, which is largely due to poor algorithms implemented in today's 802.11 NIC drivers. Is load balancing something that CAPWAP is looking to address?

One thing to note, though, is that the companies who want this protocol feel
it isn't a research issue, and if NMRG thinks it is, there's a problem.
There might be areas where research is needed (e.g. load balancing algorithms) but management of IEEE 802 wireless networks seems a bit practical for that.

There are some potential areas where existing work could be used, like IPsec
for security between APs and ARs
My understanding is that we're talking about security over a single link layer hop going between the AP and the switch. Is this something that can be handled by link layer security or are there scenarios where this traffic might need to travel over the Internet?

possibly DHCP and SLP for discovery
If this is only about a single link layer hop, aren't we talking about a ZEROCONF network? If not, are we requiring that the switch run a DHCP server or act as an SLP DA?

define how the existing protocol would support the
wireless network control function, as there was in iSCSI
I don't think there's much of a parallel with iSCSI here. In that case there was an existing protocol which handled both control and data that needed to run over IP. In this case, we have existing standards for the data (e.g. IEEE 802.11 encapsulation) that need to be mapped over IP, but there is already a significant body of work relating to the control aspects that already uses IP
(the 802.11 MIBs).

support for the AR to load balance mobiles between access points and
eliminate the possibility of mobiles "ping-ponging" between access points,
that isn't supported by any existing protocol.
Ping-ponging is largely the artifact of poor load balancing algorithms (e.g. no hysterisis) and can be fixed without having to change the roaming model (from host-driven to AP or AR-driven).

W.r.t. IEEE, I don't want to get into a charter war with them about this.
The IETF is free to do whatever it thinks is genuinely useful and makes sense. However, it is important that we consider carefully what kinds of expertise would be necessary for such a WG to succeed, and determine whether that expertise is in evidence before proceeding. In this particular case, there seems to be a need for a very clear (and focussed!) problem statement, as well as a demonstration of understanding of management requirements. A charter that focussed on those things might channel the energy that currently exists in a productive direction while also providing more evidence that the group has the "genetics" to survive if it is turned loose on protocol design.

Maybe there's a lesson in this: trying to
tackle the network part of supporting wireless network configuration and
seamless handover piecemeal isn't likely to provide a good, well integrated
solution to the problem.
IEEE 802.11f was no more successful than SEAMOBY for some of the same reasons -- lack of vendor interest in encouraging the deployment of heterogeneous AP networks. Ultimately, I believe that this ties back to the focus of current customers, which is largely on trying to get wireless networks deployed and operating at some basic level. I see few WLANs today with a second source AP provider, which means that the focus of interoperability testing is mostly on interop between stations and APs, not between APs.

Since IEEE doesn't have a good track record above
the MAC layer, if IETF decided to do this, we could try to run this with
heavy IEEE involvement, possibly as a joint activity.
A joint effort seems too unwieldy, but if the problem could be clearly partitioned between the two bodies that might be more workable.

Maybe we should organize some kind of interm meeting at which both IETF and IEEE
I'm not sure such a meeting would be likely to be productive, but it's certainly possible to ask for (and receive) IEEE 802 input on the subject.

If IETF decides not
to take it on, then my advice to IEEE is: don't tie it to 802.11, do it for
all your radio protocols.
Unfortunately, IEEE 802 doesn't have a very good way of handling this organizationally. IEEE 802.1 is the architecture group, but they meet on a different schedule than the 802.11/16/20 wireless folks and don't really understand wireless architecture very well. As a result, groups like Handoff ECSG are requesting a charter within the wireless constellation (IEEE 802.21) instead of becoming an IEEE 802.1 sub-group.

If it turns out to be the right thing to do this in IEEE,
then she'll support it, as will I.
I suggest that we need to think more about the problem and what kinds of resources we'd need to be successful. The issue that I've heard is not that CAPWAP is being proposed in the wrong place, but that the design has a poorly thought out security and deployment model.

If CAPWAP does nothing else than spur IEEE into starting a working group to
do a MAC layer independent radio access network control protocol, I'll be
happy.
Judging by the quality of recent IEEE 802.11 work, happiness does not seem to be all that likely an outcome.

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail