Re: CAPWAP BOF follow up: nmrg - CAPWAP

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

Hi Bernard,


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

Bluetooth has access points, at least, we have such in our lab. I think it
is a bit early to say how UWB will be used. It is, after all, a PHY
technique.

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

My understanding (from Dorothy) is that k is working on management frames
between the mobile station and access point about radio measurements, not
resource management between access points. That would include such items as
dynamic channel allocation and dynamic power control. As for security, it is
perhaps separate, but as I'm sure you are aware, if IPsec is used, every
application of IPsec runs into its attendant list of special case items that
need to be done. Certificate profiles, how to negotiate the ISAKMP SA, etc.
Very few people in IETF can figure out how to do these things. much less in
IEEE. If IPsec isn't used, we are back in the case where work is needed for
basic security mechanisms like key distribution, something that is difficult
even in IETF.

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

Yes.

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

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.

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

What link layer security? There is no authentication on 802 frames, and no
encryption either as far as I know. Bob Moskowitz tells me there is a WG
starting in 802 to do authentication for 802 frames, however.

But to answer your question, there are some scenarios where the traffic runs
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?
>

No, it's not a zeroconf network. And it might not run to a switch, it might
run to an access router. I've called the termination point the CAPWAP
manager, to emphasize its functional rather than implementational nature, in
the slides I did for the BOF.

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

The main parallel is that CAPWAP is proposing to split the 802.11 MAC
between the AP and the CAPWAP manager, so that the real time control
functions are in the AP and the data handling functions are in the manager.
The AP sends 802.11 frames encapsulated in IP packets (or in another
version, 802.3 frames) to the manager, which then decapsulates. This is why
I thought it is similar to iSCSI. As for 802.11 MIBs, my understanding is
currently there is no MIB for the AP, just the mobile station, though, of
course, one could be developed.

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

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.

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

OK, this is good feedback. My inclination would be to tell the group that
wants to do this to work on the problem statement and requirements before
the WG is formed, to provide them with an incentive to agree (after bad
experiences with trying to do problem statements and requirements in a WG).
Randy, Bert, what do you think? Should I send a note to the list suggesting
a couple drafts in this area?

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

If and when the current crop of products start coming out, that radically
reduce the amount of time needed to set up and manage networks, customers
will want interoperability I think. At least, with my Docomo hat on, I can
say that one customer does.

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

Any suggestion about how to best achieve that partitioning?

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

OK.

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

Yes, well that has been the problem all along. IEEE is getting into the
radio networking standards business without the right structure to handle
it. The 3Gs fixed this problem long ago. Alister Ulwin of Acatel (and on the
ETSI board) told me he believed IEEE and IETF should merge to form something
like ETSI did with 3GPP. Note that this is a radical suggestion and somewhat
tongue in cheek suggestion, but if IEEE wants to get into the radio network
standards busines (especially with 802.20) they need to recognize that there
is more to it than just specifying the PHY and MAC. Otherwise, they are
going to end up with the same problems that 802.11 has.

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

You mean LWAPP, not CAPWAP. The whole point of naming the BOF CAPWAP was not
to tie it to the currently proposed protocol, but to give it some space to
develop into what IETF wants. I agree about LWAPP, but 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.

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

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.

            jak