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

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Wed, 9 Mar 2005 17:09:45 -0500

Partha's proposal introduces a great advantage related to future
enhancement either within the 802.11 realm or associated to other
technologies (e.g. 802.16). Bear in mind that defining a signaling
protocol with particular embedded identifiers/object will required
extensive extensions to maintain interoperability for any new
feature/technology. Although I assume we cherish the CAPWAP group do we
really want it to be an ongoing process?

Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dan Harkins
Sent: Wednesday, March 09, 2005 2:12 PM
To: Michael Vakulenko
Cc: Partha Narasimhan; [email-masked]
Subject: Re: [Capwap] A simpler approach to CAPWAP 

  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
> 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
> 
> 
> At 06:58 PM 3/9/2005, Partha Narasimhan wrote:
> 
> >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
> 
> -- Michael Vakulenko
>          Phone:  +972-54-776-2269
> 
> _______________________________________________
> 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: "James Kempf" <[email-masked]>
Date: Wed, 9 Mar 2005 14:20:45 -0800

Whether or not we standardize a WTP control protocol or a code downloading
protocol has nothing to do with whether CAPWAP is an ongoing process. When
the CAPWAP charter is complete, the group can disband (this is what we did
with SEND). Or not (other WGs like DNSEXT do this). It depends on what the
WG members want to do and whether the IESG agrees.

            jak

----- Original Message ----- 
From: "Sadot, Emek (Emek)" <[email-masked]>
To: "Dan Harkins" <[email-masked]>; "Michael Vakulenko"
<[email-masked]>
Cc: "Partha Narasimhan" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 09, 2005 2:09 PM
Subject: RE: [Capwap] A simpler approach to CAPWAP

Emek

-----Original Message-----

  Dan.

itself.