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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 13 Sep 2005 19:51:07 -0700

Vendors should always be free to make changes to protocols, as long as
the protocol allows for vendor extensions. That said, the WG needs to
define a mandatory to implement mode - and if that is the case, I wonder
why a vendor would feel compelled to support multiple methods. If the
concern is that the mechanism defined by the WG is insufficient, then
they should try to address that problem in the WG.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of zhaoyujin 00919
> Sent: Monday, September 12, 2005 9:24 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Capwap] Re: In-band/out-of-band about the firmware download
> 
> 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
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun [[email-masked]]" <[email-masked]>
Date: Wed, 14 Sep 2005 20:19:49 -0700

But once more this introduces optional download mechanisms, which means interoperability issues.

Pat Calhoun

> From: zhaoyujin 00919 [mailto:[email-masked]] 
> Sent: Wednesday, September 14, 2005 2:46 AM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]
> Subject: 回复:RE: [Capwap] Re: In-band/out-of-band about the 
> firmware download
> 
> I think capwap wants to define a control management of AP. 
> And I think the WG has give some firmware download mechinasm 
> which is enough for the capwap.
> 
> But the firmware download is only a small part of the control 
> management. And at present there are many file transimission 
> protocol, capwap may think about using those protocol.
> 
> If the vendor has not support any file transimission 
> protocol, it can use the in-band firmware download. Otherwise 
> the vendor may choose to negotiate which type download mechinasm.
> 
> 
> 
> > define a mandatory to implement mode - and if that is the case, I 
> > wonderwhy a vendor would feel compelled to support multiple 
> methods. 
> > If the concern is that the mechanism defined by the WG is 
> > insufficient, then they should try to address that problem 
> in the WG.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> > 
> > 
> > > [[email-masked]] On Behalf Of zhaoyujin 00919
> > > Subject: [Capwap] Re: In-band/out-of-band about the firmware
> > download> 
> > > 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."
> > > 
> > > 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
> > > 
> > >