Subject: [Capwap] Re: In-band/out-of-band about the firmware download

From: zhaoyujin 00919 <[email-masked]>
Date: Tue, 13 Sep 2005 09:23:41 +0500

CAPWAP defines an architecture of WLAN. At present there are may realization protocols--LWAPP,SLAPP,CTP, and so on.

All those protocols use control tunnel and data tunnel. In one mail the next information is mentionned:"in-band mechanism(Download firmware with control tunnel)" and "out-of-band mechanism(Download firmware with other protocol like ftp,tftp)". And the mail give another mention--"perhaps a slightly more compicated state machine."

But in fact the out-of-band mechanism is not very compicated. If the capwap uses the out-of-band mechanism, the function will be clarified.

Can we add a payload in the version negotiation packet. This payload can decide the firmware download mechanism. For example the mechanism can use OUI+type. If the OUI is equal to 0x000000, capwap should think the download mechanism is common. Otherwise the mechanise is private for vendor.

Best regards
Michael

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 13 Sep 2005 09:04:01 -0700

> Can we add a payload in the version negotiation packet. This payload can 
> decide the firmware download mechanism. For example the mechanism can use 
> OUI+type. If the OUI is equal to 0x000000, capwap should think the 
> download mechanism is common. Otherwise the mechanise is private for 
> vendor.
>

I can't see any real functional difference between one kind of firmware 
download mechanism and another. So the result of letting it be configurable 
would be to add additional complexity without any additional benefit in 
terms of functionality. The only benefit is to avoid having the WG make a 
decision. I think we should just choose one and thereby simplify the 
protocol.

            jak