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

From: "Paul Lambert" <[email-masked]>
Date: Wed, 9 Mar 2005 11:14:39 -0800

This 'simpler' approach would never work as propoposed to 
replace other control functioanlity.

A software upgrade mechanism might be desireable.  This
upgrade process would never replace a fuller set of control protocols.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Partha Narasimhan
> Sent: Wednesday, March 09, 2005 11:06 AM
> To: Michael Vakulenko
> Cc: [email-masked]
> Subject: RE: [Capwap] A simpler approach to CAPWAP
> 
> Just to clarify....
> 
> This moves the onus of interoperability onto the AC vendors. 
> They make images for a set of WTPs that they want to 
> interoperate with. 

The AC vendor may not have the desire or the bandwidth to make WTP
images.

Unless the WTP are on standardized hardwar, how would a AC vendor build
an image? 

>The WTP vendors just have to implement a 
> protocol where they discover ACs, identify themselves, and 
> have the ability to download an image and boot themselves 
> with it. The original image on WTP could do other things (the 
> WTP vendor's choice) with their installed images in an 
> environment where they are unable to discover an AC. 
> 
> We are not calling for specifying how a WTP is built or with 
> what components. Once it is built, every AC vendor that wants 
> that particular model of WTP to work with needs to work with 
> that WTP vendor and create their own version of a 
> downloadable image for that board. 

This is NOT the nature of open interoperable standards.  A 
Company should not have to work directly with every other vendor
to create interoperable systems.

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

---

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

Paul,

  I don't think it's designed to replace other control functionality.
The point is that it is not necessary to standardize that control
functionality. The control functionality (and how and where to split
a MAC, for instance) is all contained in the code running on the AC
and the code in the image the AC provides to the WTP. How the control
plane and data encapsulation are defined is up to the AC vendor (who
wrote the code for running on the AC and also the code in the image
provided to the WTC) and not to the IETF.

  Let a Hundred Flowers Bloom!

  Dan.

On Wed, 09 Mar 2005 11:14:39 PST you wrote

---

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

Hi Dan,

>   Let a Hundred Flowers Bloom!

Unfortunately,  I don't think I could convince DoCoMo of the value in your
botanical experiment to service providers, since the cost might come at
their OPEX. :-)

            jak

---

From: Partha Narasimhan <[email-masked]>
Date: Wed, 09 Mar 2005 12:28:37 -0800

To add to Dan's comments, if we look at the landscape of AC vendors 
today, there is a non-trivial amount of feature differentiation that is 
offered by them. To imagine that a CAPWAP proposal could create hooks to 
turn on or off a union of this feature set is unthinkable. Unless we are 
willing to spend lots and lots of time on it, we are limited to 
specifying a CAPWAP feature set that would look more like the 
intersection of the individual feature sets offered by all the AC 
vendors today - essentially, the bare minimum. If the marketplace 
requires more than that bare minimum, it is forced to go with a 
single-vendor solution. At which point all the noble objectives that 
CAPWAP started out with would have been nullified since an interoperable 
solution has not suit the end-users' needs.

With the proposed solution, the AC vendors choose the feature set that 
would be present in a multi-vendor solution. I have to imagine that 
would be more than the bare minimum that a CAPWAP protocol would 
standardize on.

Thanks
partha

---

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

Well it's a Chairman Mao quote so it might cause other problems for
them as well.

  I fail to see the cost you are imagining.

  Dan.

On Wed, 09 Mar 2005 11:38:40 PST you wrote

---

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

At 10:28 PM 3/9/2005, Partha Narasimhan wrote:
>To add to Dan's comments, if we look at the landscape of AC vendors today, 
>there is a non-trivial amount of feature differentiation that is offered 
>by them. To imagine that a CAPWAP proposal could create hooks to turn on 
>or off a union of this feature set is unthinkable. Unless we are willing 
>to spend lots and lots of time on it, we are limited to specifying a 
>CAPWAP feature set that would look more like the intersection of the 
>individual feature sets offered by all the AC vendors today - essentially, 
>the bare minimum. If the marketplace requires more than that bare minimum, 
>it is forced to go with a single-vendor solution. At which point all the 
>noble objectives that CAPWAP started out with would have been nullified 
>since an interoperable solution has not suit the end-users' needs.

These are all very valid comments. It's indeed going to be very difficult 
to design a protocol allowing vendor differentiation. IMHO, non-commodity 
ACs will have to go with single vendor approach in any case.

It's just the specific solution you are proposing is not practical, in my 
opinion.

Thanks,

-- Michael V.
    www.WaveCompass.com

>would be present in a multi-vendor solution. I have to imagine that would 
>be more than the bare minimum that a CAPWAP protocol would standardize on.
>
>Thanks
>partha
>
>Dan Harkins wrote:
>
>>  Paul,
>>
>>>This 'simpler' approach would never work as propoposed to replace other 
>>>control functioanlity.
>>>
>>>>From: [email-masked] [mailto:[email-masked]] On 
>>>>Behalf Of Partha Narasimhan
>>>>This moves the onus of interoperability onto the AC vendors. They make 
>>>>images for a set of WTPs that they want to interoperate with.
>>>>The WTP vendors just have to implement a protocol where they discover 
>>>>ACs, identify themselves, and have the ability to download an image and 
>>>>boot themselves with it. The original image on WTP could do other 
>>>>things (the WTP vendor's choice) with their installed images in an 
>>>>We are not calling for specifying how a WTP is built or with what 
>>>>components. Once it is built, every AC vendor that wants that 
>>>>particular model of WTP to work with needs to work with that WTP vendor 
>>>>and create their own version of a downloadable image for that board.
>>>This is NOT the nature of open interoperable standards.  A Company 
>>>should not have to work directly with every other vendor

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Mar 2005 14:42:56 -0800

>   Well it's a Chairman Mao quote so it might cause other problems for

Actually, I think the exact quote is "Let a thousand flowers bloom!" See:

http://www.newsarama.com/Thousand_Flowers_index.htm

You're right about the disapproval, but I think it would have been
bidirectional.

>   I fail to see the cost you are imagining.

Suppose a large wireless ISP decides to buy ACs from two or more vendors.
Now, suppose the protocol, to say nothing of the split in MAC functions, is
different between the different ACs. The WTPs might interoperate with a
specific switch, but the wireless ISP must pay for personnel to learn each
of the different protocols, including updates and training. When something
goes wrong, the right person that knows the particular protocol must be
located, and if they are on vacation, you are out of luck. Mistakes are more
likely in configuration and maintenance if the protocols and MAC functions
are different, since it becomes harder for people to remember the different
configurations and parameter settings, and easier to make a mistake by
inputting the settings for one protocol/AC to another. These are all
problems with nonstandardized gear. Nonstandardized protocols just lead to
vendor lock-in, which is no benefit to service providers.

The cellular world went through this battle 10 years ago. The GSM and cdma1
networks had proprietary RAN protocols. The wireless operators in 3GPP
insisted on having a standardized RAN protocol with standardized interfaces
to reduce equipment cost, increase network maintainability (and thereby
reduce OPEX), and simplify evolution of both the radio and RAN. The result
of this is the standardized UMTS RAN protocols (RANAP, NSAP, NBAP). 3GPP2
took longer, but they also approved a standardized RAN protocol for cdma2K.
I think the same arguments apply to CAPWAP.

If I thought there were some technical advantage to keeping the protocol
open, like, for example, open research issues, I'd certainly argue
differently. But I believe there is enough experience in RAN protocol design
of this sort from the cellular world, and I think the service providers
really do want a standard. I'd hope that IETF is still willing to listen to
service providers.

            jak

---

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

> ACs will have to go with single vendor approach in any case.

I don't know that this is the case. In the UMTS world where the RAN
protocols are standardized, the RAN vendors differentiate themselves based
on their network managment systems. Many operators buy single vendor in
order to get a particular set of network management features. Others
(typically the more technically savvy) buy multivendor and roll their own
network management software. If the protocol is standarized, the vendors
will find other areas to distinguish their products.

            jak

---

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

>will find other areas to distinguish their products.

I'm glad you are bringing up cellular. This happen to be a good example. 
Yes, there are elaborate standards defined. For example for GSM there is 
Abis interface and protocols defined between BTS and BSC (cousins of WTP 
and AC respectively). However, reality is that BTS and BSC from different 
vendors are not quite working together. BTSes are usually operated with the 
same vendor BSC. And this is in very stable GSM environment, let alone 
cdma2000 and less stable new UMTS environment.

Multi-vendor environments are common in the core network, but not at the 
RAN level.

Thanks,

-- Michael V.
    www.WaveCompass.com

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Mar 2005 15:18:03 -0800

> cdma2000 and less stable new UMTS environment.

Well, this might have been true for GSM, but its not true in UMTS. Our UMTS
RAN is multivendor.

            jak