Subject: [Capwap] A simpler approach to CAPWAP

From: "Partha Narasimhan" <[email-masked]>
Date: Wed, 9 Mar 2005 08:58:31 -0800

The primary reason for the existence of the CAPWAP group is to solve
an interoperability problem between ACs and WTPs from different
vendors so that an end-user/customer has the choice of purchasing WTPs
and ACs from different vendors. The existing marketplace is full of
single-vendor solutions. To that extent, if an end-user is able to
purchase a WTP from a vendor that is different than the vendor
supplying the AC, but get them to interoperate with each other to
create a functioning WLAN, then the end-user's objective is largely
accomplished.

Based on existing single-vendor WLAN solutions, it is obvious that the
AC is where most of the control and management intelligence
resides. It is not far from the truth to state the AC determines what
functions are turned on at the WTPs and, hence, what features are
available in the WLAN. Arguably, the interoperability problem can be
restated as a customer's need to find WTPs that interoperate with
his/her choice of AC. Or at a minimum, the WTPs need to follow and
interoperate with the AC rather than the other way around. 

Interoperability can be achieved at multiple levels. In most of the
current discussion on the CAPWAP mailing list, the primary assumption
seems to be that interoperability requirement seems to be between the
individual software that both the WTP and the AC ship with and/or boot
up with. Once both the devices are up and running with their images,
the WTPs discover one or more ACs and, assuming everything is set up
right, one of the discovered ACs will configure and bring up the WTP
as part of the customer's WLAN using a protocol that will be defined
as part of the CAPWAP WG's work.

Interoperability can also be achieved using a simpler mechanism where
a WTP boots up, discovers one or more ACs to create an association
with. As part of the discovery process, the WTP identifies itself
(vendor ID, hardware version, software version, etc.). One of the
discovered ACs can then instruct the WTP to download a firmware image
that the WTP should boot itself with at the end of the download
process. Upon booting itself with this downloaded image, the WTP runs
a protocol, quite possibly proprietary to the AC vendor, contained in
the downloaded image to create an association with an AC and get
configured to be a member of the WLAN. An AC from one vendor might
download an image to a WTP that is completely different than an AC
from another vendor. This does solve the end-user's requirement of
getting interoperability between WTPs and ACs from different
vendors. The control protocol used to get the WTP to become a member
of the WLAN controlled and managed by the AC is totally upto the AC
vendor's choice.

Essentially, the solution becomes a simple protocol for the WTP to
discover one or more ACs, identify itself to the ACs, and download an
image from the AC, if possible, that it will boot itself with - a
secure download problem rather than a WLAN configuration problem from
an interoperability perspective. This solves the CAPWAP problem of
interoperability without requiring a full-fledged, new control
protocol that all the WTP and AC vendors have to implement for
interoperability. It is sufficient to implement the simpler secure
download protocol to get to interoperability. This removes the
necessity to negotiate capabilities (split MAC vs local MAC, one
person's split may not suit another but we cannot have infinite
permutations of a split, etc.) since the WTP assumes capabilities that
are contained in the image that the AC vendor chooses to build for
it. Another benefit of this approach is the extensibility of this
simpler approach to future wireless technologies or extensions to
existing technologies since these are folded into the downloaded image
and hence are transparent to the secure download protocol itself.

What are the issues with such a secure download protocol? This
requires an AC to have a bootable image for every single WTP that the
AC wants to interoperate with. Which could be a matter of
differentiation for the AC vendors. If one vendor supports 2 models of
WTPs, while another one decides to support 10, then the marketplace
could choose if they like the feature set of the former enough that
they dont mind the reduced set of interoperable WTPs or whether they
like the greater interoperability of the latter AC. Secondly, we need
a mechanism for the WTP and the AC, soon after the discovery process,
to create a trust relationship between each other so that the WTP is
sure it is not downloading code from a malicious entity masquerading
as an AC and the AC is sure it is not supplying code to an entity
masquerading as a WTP. 

The secure download approach shifts the burden of interoperability to
the AC vendors and lowers the barrier for the WTP vendors that strive
for interoperability. This shift is fine since the AC is the center of
control and management for a WLAN and it is in the AC vendor's
interests to get to wider interoperability, if they so chose to
do. This is also aligned with the current market reality where the AC
vendors' capabilities determine what features are available on the
WLAN. The WTP vendors are required to implement a simpler protocol to
get to interoperability with multiple AC vendors. The level of
interoperability is always determined by individual choices by the
vendors. For example, an AC that only supports split MAC may not
interoperate with a WTP that only suppports the local MAC. Arguably,
the interoperability achievable by the secure download approach is no
worse than what is possible with a full-blown control protocol. Not to
mention the simplicity of the protocol that the CAPWAP WG needs to
work on.

We intend to submit a proposal along these lines to the CAPWAP WG. It
will involve a simple process as follows:
- a WTP discovers one or more ACs,
- the WTP identifies itself to the ACs that it discovered,
- the WTP and one of the ACs create a mutual trust relationship, and
- the WTP downloading an image from an AC.
The details will be present in the draft that will follow soon.

This approach is quite different from what has been discussed in the
WG so far. It probably also has implications on the objectives
draft. I would like to initiate some discussion on whether all the
mandatory objectives as stated in the current objectives draft are
still valid. I understand that the objectives were stated with a
full-fledged, open and/or externally verifiable protocol in mind. If a
certain set of objectives precludes such a simpler solution then we
may need to re-visit and discuss that set of objectives. In other
words, if a set of objectives as they currently stand are unnecessary
for solving the problem that we started out to address, then we should
discuss these now.

Thanks
partha
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Mar 2005 10:01:57 -0800

Partha,

I believe having downloadable firmware is a highly desirable requirement for
CAPWAP, to ensure AC-
WTP interoperability. However, I do not believe it is a replacement for
having an interoperable protocol. From a managability standpoint, I'd like
to have a protocol that was standardized among AC vendors, not a bunch of
proprietary protocols that would all require different specialized
management expertiese (which adds up to OPEX expense). Personally, I don't
think restricting CAPWAP goals just to downloadable firmware would fufill
the charter, but I'll let it up to the chairs to make the call.

            jak

----- Original Message ----- 
From: "Partha Narasimhan" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 09, 2005 8:58 AM
Subject: [Capwap] A simpler approach to CAPWAP

Thanks
partha

---

From: Michael Vakulenko <[email-masked]>
Date: Wed, 09 Mar 2005 20:45:25 +0200

Partha,

I don't see how your suggestion makes things simpler. If CAPWAP would 
follow your approach, this WG had to define standard APIs that needs to be 
supported by all interoperable WTPs. These APIs will have to be quite 
low-level and detailed to provide interface to 802.11 chipset, Ethernet 
driver and operating system of the WTPs.

Moreover, different WTP models may use different processor cores and 
therefore firmware object code cannot be the same for all WTPs. (We are not 
talking about Java here, are we?.. :-) )

The real complexity of what you have proposed is in fact higher than 
traditional approach to protocol design, if you consider practicalities of 
achieving interoperability, stability and predictable performance for 
downloadable firmware.

-- Michael V.
    http://www.WaveCompass.com

>for solving the problem that we started out to address, then we should

-- Michael Vakulenko
         Phone:  +972-54-776-2269

---

From: Dan Harkins <[email-masked]>
Date: Wed, 09 Mar 2005 11:12:17 -0800

On the contrary. If the CAPWAP protocol defines a full control plane
and data frame encapsulation it will have to define standard APIs
that need to be supported by all interoperable WTPs. If Partha's
approach is taken then all that is defined is a discovery and download
protocol. The WTC runs the downloaded image and that contains the
(not-defined by CAPWAP) control and data frame protocols.

  No we're not talking about Java.

  The practicalities of achieving interoperability are solely on 
implementation of the discovery and download protocol. It is simple and
therefore acheiving interoperability would not be hard. The practicalities
of achieving stability and predictable performance are borne by the
AC vendors who will guarantee that the image they provide to a WTP
is stable and has predictable performance.

  Dan.

On Wed, 09 Mar 2005 20:45:25 +0200 you wrote

---

From: Inderpreet Singh <[email-masked]>
Date: Wed, 9 Mar 2005 14:27:29 -0500

James, I agree that firmware download is a nice to have.  I am trying
to rationalize the work that might potentially go on in defining yet
another method of firmware download in the context of CAPWAP.  How is
the firmware download problem different and unique in the case of WTPs
vs. routers, switches, printers, or any other networking device?

Partha - I think what you are proposing is substantially changing the
scope of the CAPWAP charter.  What you are proposing would mean that
our group should be called PWAP WG as the control aspect would then be
totally sidelined and that would be totally proprietary.  I am not
sure if there is value in "only" a firmware update protocol for WTPs
and ACs.

---
Inderpreet Singh

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Mar 2005 11:31:52 -0800

Inderpreet,

>James, I agree that firmware download is a nice to have.  I am trying to
>rationalize the work that might potentially go on in defining yet another
>method of firmware download in the context of CAPWAP.  How is the firmware
>download problem different and unique in the case of WTPs vs. routers,
>switches, printers, or any other networking device?

It's different because routers, switches and printers aren't acting as
controllers for other devices. The interfaces between these devices and
others are peer interfaces. If there's a firmware mismatch between the WTPs
and AC, the net might not work. With printers, etc., the device itself might
fail to function, of course, but that won't influence whether other devices
do.

            jak

---

From: Michael Vakulenko <[email-masked]>
Date: Wed, 09 Mar 2005 23:43:32 +0200

At 09:12 PM 3/9/2005, Dan Harkins wrote:
>that need to be supported by all interoperable WTPs.

If we are referring to Application Programming Interface (API) here, I 
disagree with your comment.

None of the well-known and widely used protocols (IP, TCP, FTP, HTTP, you 
name it) required definition of an API that have to go with the protocol. 
The whole point of defining a protocol is to decouple implementation from 
external interface.

>If Partha's approach is taken then all that is defined is a discovery and 
>download protocol. The WTC runs the downloaded image and that contains the

I'm afraid you are over-simplifying it. This downloaded image is just a 
piece of object code for a specific processor instruction set, right? This 
piece of object code was created by compiling it with a specific compiler, 
linking it with appropriate libraries and storing it in some kind of a file 
format (e.g. ELF). Now this file has to be downloaded to the WTP memory and 
dynamically linked to the rest of the software running on the WTP. Once 
this is done, this piece of code can be finally activated and make calls to 
WTP API software, which in turn will exercise the actual hardware.

All this is before mentioning such insignificant things as programming 
model (tasks, threads, semaphores, queues, memory management, etc.) and 
development tools needed for such an endeavor.

Sorry for the tutorial, but it's going to be much simpler define CAPWAP 
protocol than deal with all these issues.

>therefore acheiving interoperability would not be hard.

Agreed. But what does this buy to us?

>The practicalities of achieving stability and predictable performance are 
>borne by the AC vendors who will guarantee that the image they provide to 
>a WTP is stable and has predictable performance.

I'm confused now. This statement defeats the (declared) motivation of this 
discussion: "...the interoperability problem can be
restated as a customer's need to find WTPs that interoperate with
his/her choice of AC. Or at a minimum, the WTPs need to follow and
interoperate with the AC rather than the other way around. "

Thanks,

-- Michael V.
    www.WaveCompass.com

---

From: Partha Narasimhan <[email-masked]>
Date: Wed, 09 Mar 2005 14:00:40 -0800

The idea is to download code into the WTP and have it reboot itself with 
the downloaded code. At this point, the original vendor installed code 
on the WTP is no longer active and the WTP has been reborn with the new 
code. This does require the AC vendor to have worked with the specific 
WTPs that they want to support or interoperate and create an image for 
these individual boards. We are not suggesting that we abstract the 
hardware capabilities on the WTP and interoperate at that level 
dynamically. The AC vendors are responsible for the code that they 
download into the WTP and for the subsequent proper operation of that 
piece of hardware.

This is why the interoperability onus now rests on the AC vendors. If 
they dont have an image ready for a specific WTP, then they dont 
interoperate with that WTP.

Thanks
partha

Michael Vakulenko wrote:

> None of the well-known and widely used protocols (IP, TCP, FTP, HTTP, 
> you name it) required definition of an API that have to go with the 
> protocol. The whole point of defining a protocol is to decouple 
> implementation from external interface.
>
>> If Partha's approach is taken then all that is defined is a discovery 
>> and download protocol. The WTC runs the downloaded image and that 
>> contains the
> I'm afraid you are over-simplifying it. This downloaded image is just 
> a piece of object code for a specific processor instruction set, 
> right? This piece of object code was created by compiling it with a 
> specific compiler, linking it with appropriate libraries and storing 
> it in some kind of a file format (e.g. ELF). Now this file has to be 
> downloaded to the WTP memory and dynamically linked to the rest of the 
> software running on the WTP. Once this is done, this piece of code can 
> be finally activated and make calls to WTP API software, which in turn 
> will exercise the actual hardware.
>
> model (tasks, threads, semaphores, queues, memory management, etc.) 
> and development tools needed for such an endeavor.
>
> Sorry for the tutorial, but it's going to be much simpler define 
> CAPWAP protocol than deal with all these issues.
>
>> The practicalities of achieving stability and predictable performance 
>> are borne by the AC vendors who will guarantee that the image they 
>> provide to a WTP is stable and has predictable performance.
>
>
> I'm confused now. This statement defeats the (declared) motivation of 
> this discussion: "/...the interoperability problem can be
> /Thanks,
> <http://www.wavecompass.com/>
>
>>   Dan.
>>
>> >     http://www.WaveCompass.com <http://www.wavecompass.com/>
>> >
>> >

---

From: Michael Vakulenko <[email-masked]>
Date: Thu, 10 Mar 2005 00:22:10 +0200

At 12:00 AM 3/10/2005, Partha Narasimhan wrote:
>the downloaded code. At this point, the original vendor installed code on 
>the WTP is no longer active and the WTP has been reborn with the new code. 
>This does require the AC vendor to have worked with the specific WTPs that 
>they want to support or interoperate and create an image for these 
>individual boards. We are not suggesting that we abstract the hardware 
>capabilities on the WTP and interoperate at that level dynamically. The AC 
>vendors are responsible for the code that they download into the WTP and 
>for the subsequent proper operation of that piece of hardware.

How it's different from just having several WTP models on AC vendors's 
price list, as it happens today? What makes you believe that an AC vendor 
will assume responsibility for a piece of hardware bought on the street?

-- Michael V.
    www.WaveCompass.com

>This is why the interoperability onus now rests on the AC vendors. If they 
>dont have an image ready for a specific WTP, then they dont interoperate 
>with that WTP.
>
>Thanks
>partha
>
>Michael Vakulenko wrote:
>
>>>and download protocol. The WTC runs the downloaded image and that contains the
>>piece of object code for a specific processor instruction set, right? 
>>This piece of object code was created by compiling it with a specific 
>>compiler, linking it with appropriate libraries and storing it in some 
>>kind of a file format (e.g. ELF). Now this file has to be downloaded to 
>>the WTP memory and dynamically linked to the rest of the software running 
>>on the WTP. Once this is done, this piece of code can be finally 
>>activated and make calls to WTP API software, which in turn will exercise 
>>the actual hardware.
>>

---

From: Dan Harkins <[email-masked]>
Date: Wed, 09 Mar 2005 15:49:35 -0800

On Wed, 09 Mar 2005 23:43:32 +0200 you wrote
> protocol than deal with all these issues.

You should be sorry; don't do that again.

Yes it's "object code". And it's compiled "with a specific compiler" and
"appropriate libraries" and blah blah ELF blah. But you're viewing this as
some runtime loadable module that is dynamically linked to something that
runs the WTP. This image RUNS THE WTP. It is a brain transplant. It is
not a runtime loadable module, it's more like the de-penguinator
(http://www.daemonology.net/depenguinator).

If you tell me what radio chipset you have in your AP, what ethernet chip
you're using, what your memory and flash layout looks like, and what
your bootloader is expecting in terms of where the executable image 
resides I will create an image that runs your AP that makes it look
just like one of our's--- that is, it speaks our proprietary control and
data plane encapsulation protocol and is managed by our switch. 

> Agreed. But what does this buy to us?

It buys us commodity-priced APs that can be managed by a plethora of ACs,
each of which can continue to differentiate itself from other ACs by
producing new and different features.

It buys us extensibility for the next wireless media that hasn't yet been
standardized. With the other model you have to rev the spec for every
addition.

> interoperate with the AC rather than the other way around. "

I don't see anything in that quote that is in opposition to anything
I've said. Part of your confusion, I think, is that you have several hard
and pre-conceived notions and you're trying to fit everything I say into
them.

  Dan.

---

From: "Inderpreet Singh" <[email-masked]>
Date: Wed, 9 Mar 2005 13:20:12 -0500

Partha - I think what you are proposing is substantially changing the scope
of the CAPWAP charter.  What you are proposing would mean that our group
should be called PWAP WG as the control aspect would then be totally
sidelined and that would be totally proprietary.  I am not sure if there is
value in "only" a firmware update protocol for WTPs and ACs.

---
Inderpreet Singh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James Kempf
Sent: Wednesday, March 09, 2005 1:02 PM
To: Partha Narasimhan; [email-masked]
Subject: **** SPAM **** 3.1: Re: [Capwap] A simpler approach to CAPWAP

Partha,

            jak

----- Original Message ----- 
From: "Partha Narasimhan" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 09, 2005 8:58 AM
Subject: [Capwap] A simpler approach to CAPWAP

Thanks
partha