Capwap Mailing List: RE: (no subject)

[Pat R. Calhoun (pcalhoun]

>>> Why not achieve these goals by:
>>> - Running PANA between the station and access router.
>> PANA assumes a completely different architecture - not one that any of the
>> startups seemed to have adopted.
>
>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. 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).

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

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

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

PatC