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

From: <[email-masked]>
Date: Wed, 9 Mar 2005 14:55:20 -0800

-----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
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Partha Narasimhan <[email-masked]>
Date: Thu, 10 Mar 2005 19:51:48 -0800

Dorothy

Thanks for your comments. Though I am not sure I am in complete
agreement with all of them.

The intent of my email and the draft that we will be submitting
shortly to the WG is not to say that we do not need a control
protocol. The disagreement that we have with the current state of the
discussion in the WG on the objectives draft and the two proposals out
there is that they seem geared towards something that is inherently
more complex than what is required to solve the interoperability
problem.

We have already had lots of discussion in both the mailing list and in
the CAPWAP session at the IETF on limiting the number of possibilities
in the capabilities negotiation. If we take a split MAC architecture,
for example, it would boil down to the IETF (or the IEEE) dictating
how the MAC should be split because of the need to keep things
simple. The solution we are proposing would simplify things
significantly without restricting innovation on either side. There are
a bunch of features that one or more of the AC vendors support in
their single-vendor solutions that are not being negotiated in the
control protocol in the interests of bounding the problem. Let us take
the example of a WTP's ability to support multiple BSSIDs on the same
radio. If we have no mechanism to negotiate this capability using the
control protocol, then the only safe assumption is that the WTP does
not possess this capability. We are either forced to increase the
scope of the capabilities negotiation or restrict the feature set that
is possible in a multi-vendor WLAN.

What we are proposing will enable complete multi-vendor solutions that
the marketplace desires and chooses - only it shifts that onus onto
the AC vendors that want to interoperate with one or more WTPs and
requiring the WTP vendors to implement a simple control protocol. Even
from an service provider's point of view, this would appear to be a
better solution since the responsibility of bringing up the network
and maintaining it rests on the shoulders of the AC vendor, quite
possibly, preventing finger pointing between the AC and WTP vendors in
the case of problems.

With a complex control protocol, we are forced with two choices:
- to have a set of negotiable capabilities at either end that cover
the union of the feature sets across all the AC vendors, which, based
on the comments at the meeting, no one is in favor of, or
- standardize on a set that looks more like the intersection of the
feature sets, which seriously lowers the value of a multi-vendor
deployment.
In my mind, neither one of these choices seem acceptable.

The motivation for simplifying the protocol came as a result of an
exercise to scope out the complexity of a control protocol that
guarantees true interoperability while not stifling innovation on
either the WTP or the AC side of the equation. Not to mention the need
to keep this control protocol in sync with whatever is coming down the
pipeline from current and future standardization work at various
bodies.

I am surprised by your conclusion that the objectives draft is fine
the way it is. One of the goals of reviewing the objectives draft is
to ensure that it is not drawn up in a way that prevents a certain
class of solutions that do solve the problem that we are setting out
to solve from being considered because the objectives are more
targeted for a different class of solutions. After all, this is the
period in which the objectives draft is meant to go through such a
review process.

Thanks
partha