Subject: RE: : Re: [Capwap] A simpler approach to CAPWAP

From: "Partha Narasimhan" <[email-masked]>
Date: Wed, 9 Mar 2005 10:55:41 -0800

What we are proposing is not a 'desirable' firmware download option inside a bigger control protocol. It is meant to restrict the control protocol to a simple discover and download process. 

The motivation for this is fairly simple. The primary question to answer is whether the end-users require interoperability at
- a software level, i.e. the original software running on each of the WTP and the AC need to interoperate, or
- a hardware level, i.e. buy cheaper (hopefully) WTPs from a different vendor than the one supplying the AC, but get the AC to control and manage the WTPs by downloading a new image into the WTPs, or
- do they even care as long as the WLAN is up and running as advertised by the AC vendor
The AC in most networks controls what features show up on the deployed WLAN. If a WTP from a different vendor shows up with a set of features that the AC cannot exploit, then these features are simply not going to be turned on.

If the discover and download process solves the end-user's problems (the same ones that we convince each other that we are solving), I dont understand why there is no 'value' is such a solution. Especially, when the problems are being solved with a simpler solution. This gives each AC vendor all the more options to differentiate their products from the competition. 

Personally, I do not want to go down the path of specifying a full-fledged control protocol simply because we have spent some time on it or that this simpler approach is not seen as appealing to our creative abilities. The important question to ask are whether this is sufficient to solve the interoperability problems from an end-users' perspective.

Thanks
partha

-----Original Message-----
From:	Inderpreet Singh [mailto:[email-masked]]
Sent:	Wed 3/9/2005 10:20 AM
To:	'James Kempf'; Partha Narasimhan; [email-masked]
Cc:	
Subject:	RE: : Re: [Capwap] A simpler approach to CAPWAP
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

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

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

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

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

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

---

From: "Victor Lin" <[email-masked]>
Date: Wed, 9 Mar 2005 11:37:56 -0800

I think firmware management is an important feature for AC to support,
thus having standardized protocol between WTP and AC to handle this task
will reduce the operation overhead of WLAN.

Victor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Kempf
Sent: Wednesday, March 09, 2005 11:32 AM
To: Inderpreet Singh; 'Partha Narasimhan'; [email-masked]
Subject: Re: : Re: [Capwap] A simpler approach to CAPWAP

Inderpreet,

>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