Re: CAPWAP BOF follow up: nmrg - CAPWAP

["James Kempf" <kempf@docomolabs-usa.com>]

Bernard/Randy,

Agree we need a clearly focussed statement of proposed work that is a page
or so long. We should learn from the AAA/Diameter work that complicated
designs requiring years for completion are not likely to hold people's
interest over the long period required to standardize. W.r.t.:

> > 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.
>
Randy> is this effort different?
>

Well, I think it is different in that there are vendors stepping up saying
they want interoperability. Whether their interest will continue through the
process of getting a standard is a different matter, and a good reason for
simplifying the work so that it can complete more quickly before they drift
away.

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

I can't say that someone would be ready to lay out money for the proposed
interoperable protocol, but there is a lot of frustration among enterprise
IT managers about the expense and difficulty of deploying and managing
802.11 networks based on the existing standalone AP model. Service providers
aren't quite there yet with deployment, but I suspect Comseco and some of
the others that are starting deployment will run into these problems soon.
Current estimates are that it costs about $3-5K per AP for deployment in the
US. The so-called "lightweight access point" startups have proprietary
solutions that vary, and some have customers. That said, it is not clear
whether the split mac model being proposed in LWAPP is the right or only
solution to the problem, and it may not be the ideal solution for
interoperability. The design space obviously has some volume, and
partitioning it such that there is some reasonable hope of getting
interoperability and success based on experience with IETF process seems
important. What the vendors seem to be saying (after having surveyed
enterprise customers and presumably come up with proprietary solutions that
match the vendors' interpretation of the customer demand) is that they feel
they need some work on interoperable protocols to mach customer demands.

> >> 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.
> > The specification would not be for algorithms but for the
> > interoperable protocol to distribute the information. 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.
>
Randy > so i won't be able to load balance in a multi-vendor environment?

The thought is that the protocol is all that is required for
interoperability. In practice, that might not be so.

>
> > CAPWAP doesn't change the roaming (actually, in IETF we call this
> > handover) model. The host still makes the ultimate decision. It's
> > like ICMP Redirect.  If a router doesn't want to handle a
> > particular host's traffic, it sends a Redirect and tells the host
> > to go elsewhere. The host can still hit on the router with its
> > traffic, but if the router won't route it, then the traffic won't
> > go anywhere.
>
Randy > is this a feature?
>

No, but if the host makes the ultimate decision then one must realize that
it could happen. Any reasonably designed host will take the hint in a
Redirect and go to the offered alternative. Any host not doing this is
either broken or attempting to mount a DoS attack on the router.

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

I still think something is needed for the AP or AR to tell the host to move.
After all, we have both ICMP Router Advertisement (which, in IPv4 has
metrics) and ICMP Redirect at the IP level.

> > OK. I'm open to suggestions about how to proceed. There is a lot
> > of industry interest in this, which doesn't mean IETF needs to do
> > it.
>
Randy > i would like to hear that there is a lot of USER interest in this
> too, not just vendors.  i suspect there is, but as bernard says,
> today users are trapped in a single vendor environment if we want
> it to work.  i keep hammering on it as i don't want the user
> component left out of the focus.
>

With my Docomo hat on, I can certainly say that it would be immensely useful
for Docomo as a service provider to have an interoperable protocol that
would allow this kind of mix and match between APs and ARs. Docomo Labs USA
already has experience with one vendor's so-called "lightweight access point
product" that is built on a proprietary protocol, and, while there are some
bugs in it (it's new, after all), installation was overwhelmingly simpler
than the typical piece-built network which we replaced. With my IETF hat on,
though, I realize the need to dampen my enthusiasm somewhat and make sure we
can get an effort going that has some reasonable possibility of succeeding.

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

Makes sense. So one direction CAPWAP could go is to just focus on the
management problem, and split off the data transport problem for someone
else (which might be another IETF WG, or might be in IEEE) to decide.

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

I'm not sure I follow. Handoff metrics certainly are an area for IEEE, but
management data is exactly the issue that is frustrating many enterprise IT
managers. Or did you mean that IEEE needs to specify the MIB? Certainly, if
the MIB contains radio specific parameters, that must be the case. What
would be left for IETF in that case?

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

OK, this sounds like a fairly narrowly focussed bullet item that CAPWAP
could focus on that might have a chance of getting done in reasonable amount
of time.

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

Sure, but is this really IETF's (or IEEE's) problem? A standardized
algorithm would certainly solved the problem (provided of course it wasn't
broken itself, remember WEP?) but consider the amount of IPR infighting to
get that to happen. The other alternative is to let natural selection cull
those vendors with broken algorithms. That's why having the UL-like function
that Bill Arbaugh is trying to provide is quite useful.




            jak