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

Re: CAPWAP BOF follow up: nmrg - CAPWAP

> 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.

is this effort different?
That's the question. If there is someone ready to write a large check for a 3000 AP deployment who will tell his/her vendor "support this protocol or kiss this check goodbye" then it will work. For this to happen IMHO, you've got to have a protocol which has wide industry support and excellent interoperability, so that the customer has a wide selection of vendors supporting the protocol and doesn't lose a lot of functionality moving from one vendor to another.

imiho, this caused the biggest core damage to aaa/diameter.  e.g.,
the proxy model could not be removed and it vastly complicated
everything.
And required so much effort that the protocol took too long to finish. It is ironic, but now Diameter is back to the original re-direct model (bypassing proxies).

I do think that there is an analogy in the CAPWAP design. There is a fairly clean division between encapsulation and management. There could be multiple encapsulations that an AP could use to get its traffic to the switch. Some might run over IP; there might be an L2 encapsulation defined by IEEE; some encapsulations might include security, some might not have security (e.g. if 802.11i protected frames were being encapsulated). But there is probably only one set of management objects.

The algorithms are for proprietary innovation, and don't really need
a standard for interoperability. Or, at least, that is my
understanding of what the supporters want.

so i won't be able to load balance in a multi-vendor environment?
Today there are no standards for load balancing, and the code exists in the NIC driver. This has lead to a variety of algorithms, quite a few of which are fundamentally broken. In recent measurements, we found that 50% of the load on our AAA server came from 7-10 hosts that were flipping continuously between APs and reauthenticating in the process. So rather than "proprietary innovation" I'd prefer algorithms that work.

If a router doesn't want to handle a
particular host's traffic, it sends a Redirect and tells the host
to go elsewhere.
That's likely to cause additional/unnecessary handoffs and connectivity losses, particularly since to secure the "Redirect" the station would need to negotiate a security association first. Better to let the AP advertise metrics that will clearly indicate to stations whether it can handle additional traffic. That way the station can focus its efforts and choose a reasonable AP to connect to from the start.

Note that the issue of "metric export" is being handled in IEEE 802.11k (Radio Resource Management) as well as potentially IEEE 802 Handoff ECSG.

let's think of it as requirements and road map, where are we going,
why, and how are we going to get there.  and maybe where are we NOT
going, why, and how do we plan to not get there.  and keep it
simple.  if the requirements and road map can not be simple and
done in a few weeks, then how will the results of the wg be simple
enough to be achievable?
Right now CAPWAP is all over the map, and the quality of work in several of the areas that it is looking at is unpromising. Focus is not sufficient to go from a "heap of bad ideas" to a single, well focussed good idea.

partitioning of what?  i.e., lets see the requirements and road
map, and maybe we'll have some idea of how to divide the workload
appropriately.
I'd suggest that work relating to "handoff metrics" or "management data model" needs to go to the IEEE. Handoff ECSG might be the appropriate group for some of this, or it might be IEEE 802.11k, radio resource management.

the issue of how to do wireless network managment (and by that I
mean certain real time functions like dynamic power control as
well as the typical kinds of monitoring functions that are done
with SNMP) is one that we need to figure out, together with IEEE
if that makes sense.
Dynamic Power control is indeed quite useful, as is debug functionality. I don't believe that IEEE 802 currently has any work going on in Dynamic Power control.

I have an IEEE 802.11 remote sniffer that has a protocol to discover the sniffer, uses a control protocol to control the parameters of the sniffer from a remote PC, and can funnel data from the sniffer to the PC (runs over UDP). Very useful, but lacking in congestion control and not very secure. This seems like a function that makes more sense over TCP/IP than L2, so one might argue that it belongs in the IETF.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail