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

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 9 Mar 2005 22:38:07 -0800

Hi Partha/ Dorothy,

> I also don't believe in the vendor id solution.  It doesn't work from
> the operator's perspective, since the operator has to individually 
> negotiate features from all vendors they support to create a
homogenous 
> network.

I do not agree with this comment, wouldn't the same be required in
CAPWAP protocol too. I think this is done even in standard protocols
(IS-IS is an example) where a vendor-id is specified in the proprietary
TLV's used by vendor to do different proprietery interesting stuff. The
protocol details of negotiation are much simpler.

In my view the discussion is veering towards whether standard control
mechanism can allow vendors to differentiate and the time it takes to
standardize the mechanisms. Partha, is that right?

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, March 10, 2005 4:25 AM
To: [email-masked]
Subject: RE: [Capwap] A simpler approach to CAPWAP

-----Original Message-----
From: Gellert Dorothy (Nokia-ES/MtView) 
Sent: Wednesday, March 09, 2005 12:41 PM
To: 'ext Partha Narasimhan'
Subject: RE: [Capwap] A simpler approach to CAPWAP

Partha-

I believe we have gone through an extensive market evaluation in our
last Charter with the taxonomy draft, and have created a charter that
was agreed upon that includes control.   I don't see a reason to change
this.

I also don't believe in the vendor id solution.  It doesn't work from
the operator's perspective, since the operator has to individually
negotiate features from all vendors they support to create a homogenous
network.  This is hardly interoperable.  The benefits to the customer of
the network view was very well stated in taxonomy draft that was
reviewed and accepted by the IEEE and the IESG.  This is one of our
basic requirements for the formation of this WG.

We should also be complete in addressing all the AP functions in a BSS
to deliver a complete solution.  

I also don't see a need to change the Objectives draft as it stands now,
as it meet the problem statement and represents the findings in the
taxonomy draft.

While the architecture you describe is certainly an approach to this
problem, it doesn't meet the needs of this chartered WG.

Dorothy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext Partha Narasimhan
Sent: Wednesday, March 09, 2005 8:59 AM
To: [email-masked]
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

---

From: Partha Narasimhan <[email-masked]>
Date: Thu, 10 Mar 2005 20:22:14 -0800

>standardize the mechanisms. Partha, is that right?
Yes. I have doubts over the possibility that a multi-vendor solution 
based on a complex control protocol (assuming that the extremely 
cost-conscious WTP vendors will implement their end of the bargain) 
could offer at least as good a feature set as many of the current 
single-vendor solutions do. And we all know that these single-vendor 
feature sets are moving targets.

Thanks
partha