Re: CAPWAP BOF follow up: nmrg - CAPWAP

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

There is an additional architectural issue here. What CAPWAP is trying to do
is put some network control of APs into the 802 family of radio protocols
(not just 802.11, but 802.16 and possibly 802.20 if it happens). Plus other
non-802 radio protocols, like UWB. If it were just an 802.11 issue, then I
would see no point in IETF involvement.

The whole "lighweight" 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. Some of these functions can be designed in a way that is
independent of the radio protocol. It is impossible for the host to perform
some of these functions by itself, though it can provide information to the
APs that allow them to perform the function. Parviz Yegani and I did a paper
on a pretty basic design for such an architecture based on IETF protocols
that came out of the MWIF work a few years back (but somewhat slanted
towards CDMA since that was the starting point) if you are interested in
seeing more. 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.

W.r.t. to the "re-inventing the wheel" charge, I've been hearing that from
people with axes to grind on the list, but perhaps NMRG doesn't have an ax.
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 are some potential areas where existing work could be used, like IPsec
for security between APs and ARs, possibly DHCP and SLP for discovery; and
there is ongoing but just started work on device configuration in netconf
that might be useful (I'm undecided about SNMP, but since the issue is
device configuration, I think netconf is more appropriate), but may take a
long time to complete. In each of these cases, there would need to be
additional work to define how the existing protocol would support the
wireless network control function, as there was in iSCSI (in fact, iSCSI
seems very similar, except for the lack of another standards body
threatening a competing standard). There is also some work, like protocol
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.

W.r.t. IEEE, I don't want to get into a charter war with them about this.
Suffice to say, their track record on 802.11f is less than stellar. But ours
with Seamoby isn't so hot either. 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. 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. Maybe we should
organize some kind of interm meeting at which both IETF and IEEE are
present, to clear up the confusion and charter conflict? 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. The 3Gs have working groups that work explicitly
on radio access network protocols, and these working groups are separate
from the MAC and PHY layer working groups, though, of course, closely
related. The 3G radio access network protocols support multiple MACs and
PHYs.

W.r.t. Dorothy, I think she is just trying to do the right thing. As am I.
She and Pat were supposed to report to IEEE last week, don't know what
happened there. If it turns out to be the right thing to do this in IEEE,
then she'll support it, as will I.

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.

            jak

----- Original Message ----- 
From: "Bernard Aboba" <bernard_aboba@hotmail.com>
To: <randy@psg.com>; <bwijnen@lucent.com>
Cc: <iesg@ietf.org>; <iab@ietf.org>
Sent: Friday, July 25, 2003 6:05 PM
Subject: Re: CAPWAP BOF follow up: nmrg - CAPWAP


> >as usual, i am hearing both sides of the song.  many folk are
> >indeed saying "reinventing the wheel."  many others are saying
> >"but this is different."  and 802.11 is pushing it.  so i asked
> >bert to post this to iesg and iab so we can have a consensus
> >before we move in either direction.
>
> I do not believe that CAPWAP is "reinventing the wheel."  There is today
no
> protocol appropriate for control of a "lightweight AP" device, so at least
> that much is new.
>
> That said, there is disagreement about whether the protocol proposals
> discussed in CAPWAP are appropriate to the problem.
>
> I attended the IEEE 802 plenary this week, and got feedback from quite a
few
> 802.11 vendors relating to CAPWAP.  I've asked them to forward their
> feedback directly.  Several expressed the concern that the protocol and
> approach proposed is inappropriate for a "lightweight" device.  I heard
this
> from vendors on both sides of the "lightweight AP" issue, including both
> startups and well established players, so I don't think it's just axe
> grinding.  Several vendors mentioned that they will be advocating that
IEEE
> 802 start its own competing standards effort in order to produce a more
> appropriate design.
>
> Given the level of debate within IEEE 802, we probably should not assume
> that Dorothy Stanley, the IEEE 802.11 Liason to IETF, is speaking for IEEE
> 802.11 relating to CAPWAP.
>
> _________________________________________________________________
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> http://join.msn.com/?page=features/virus
>
>
>