Capwap Mailing List: Re: (no subject)

[Alper Yegin (alper]

>> I'm going by your description of the arch in this thread. Maybe there are
>> missing details that make a difference. Please share.
> 
> I really don't want to rehash the whole spec here in a single e-mail, but the
> key difference here is that the 802.11 MAC (or at least the data and
> management component) terminate in the AR. This is completely different from
> the PANA architecture that attempts to re-use most of the traditional APs.

I don't know how up-to-date you are with PANA, but PANA can enable AR as the
client-authenticator, and it can enable either of AP and AR as the end-point
of data traffic authenticator/decryptor.

> We 
> are trying to move most software functions back into the AR to:
> 
> 1. reduce CPU cycles on the AP, making it less expensive.
> 2. reduce the amount of software required on the AP, making it cheaper
> 3. Move all "enterprise" class features into the AR
> 4. etc, etc, etc.
> 
> As I've mentioned in another e-mail, having real-time access to the data from
> the AP at the AR let's the AR handle centralized policy enforcement, IDS
> features, etc with a complete RF topology in mind, not just a single cell.
> 
> It is very similar to the architecture used in cellular networks today (RANs).

Yes, I see the direction.

> 
>>> I suppose it would be ok for the IETF to work
>>> on something that is not being productized, but I'd wonder why...
>> 
>> It is not just OK, it is even better. Trying to solve yesterday's problem
>> that will miss the train is not the right model for IETF.
> 
> I really don't think that WG bashing is appropriate here, but the architecture
> you propose is actually behind the LWAPP architecture. PANA is much closer to
> older architectures, such as Vernier, Reef Edge, etc.

Until you give us some high-level architectural clues, I cannot understand
the difference.

> 
>>> 
>>>> - Having AP relay interesting IEEE 802.11 bits to the access router as it
>>>> bridges (forwards) the packets. This can be carried as some sort of
>>>> >auxilary
>>>> data as part of the IEEE headers. IEEE (SDO) could define this.
>>> This is what LWAPP does, right?
>> 
>> Our aim is not finding problems to a solution, it is finding the right
>> solutions to a problem.
> 
> No. Our aim is to solve problems that exist. Products with an LWAPP-like
> architecture are beginning to ship, and there are many startups (and
> incumbents) following a similar architecture. So this is not a solution
> looking for a problem. This is an attempt to ensure that we can get
> interoperability asap so folks that create APs can get to participate in this
> new exciting space.

OK.

> 
>>> I don't see this as a MAC or PHY layer thing,
>>> so I don't see why IEEE would be interested.
>> 
>> Well, note that we are trying to glue two pieces (AP and AR) that IEEE broke
>> apart, not IETF.
> 
> Explain to me how this is different from L2TP? L2TP runs PPP, which is a link
> layer (designed by the IETF, no less). L2TP allows the traditional PPP
> functions to be split among two devices.
> 
> Similar issue, but different problem space.

OK, I see the similarity. But I still don't understand why you think IEEE is
not appropriate. Above you say this is not a MAC thing. This is in a way
bridging, how is that not a MAC thing?

Alper