Subject: Re: [Capwap] Selecting image for downloading to WTP

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sat, 3 Jun 2006 12:46:40 -0700

Dave, issue 131 has been created based on this thread (and your input). 

However, you state you are working on a new document - are you expecting
a separate CAPWAP booting specification?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Tuesday, May 30, 2006 11:21 PM
> To: qinxia
> Cc: 'capwap'; 'Basker Ms'
> Subject: Re: [Capwap] Selecting image for downloading to WTP
> 
> HI,
> 
> I don't quite follow your contribution.
> In simple terms, here is how I see the booting model, which 
> is not the same as the CAPWAP-01 spec
> 
> 1) A WTP creates a list of potential ACs to connect to
> 2) The WTP asks the ACs if it can connect
> 3) An AC may respond saying:
>    a) no
>    b) Ok if no other AC wants you and here is my
>        preference to compare with other ACs
>    c) no, but you should ask the following ACs
>    d) yes, I'm the AC configured to manage you
> 4) The WTP creates a DTLS session with the best AC
>    (There is a whole lot of details about this
>     to work out with respect to verifying CERTs,
>     CA CERTs, and preshared keys)
> 5) After the DTLS session is up, the WTP and
>    AC can thus communicate privately, and determine
>    if messages have been modified, delayed, and
>    are from each other
> 6) The WTP tells the AC it's device type and
>    hardware configuration. It also tells the
>    AC what version of software it is running,
>    and if it has other software images (and
>    their versions), and whether or not it
>    can transfer and run a new image via CAPWAP.
> 7) The AC uses the info in #6 and a table that
>    the AC maintains to decide whether to:
>     a) continue with the current image
>     b) ask the WTP to load another image
>         (which might result in a reboot
>          of the WTP)
>     c) ask the WTP to transfer a new image
>         from the AC and run it (which might
>         result in a reboot of the WTP
>         or CAPWAP portion of the WTP)
>     d) tell the WTP it cannot support it,
>         and to try the next best AC
>         (that is have the WTP goto step #4)
> 8) If the WTP has to reboot for #7, then
>    it starts over at step #1 with a single 
>    member in the list of ACs
> 9) Otherwise, the AC determines the current
>    configuration saved on the WTP, and 
>    modifies it (if needed) to have the
>    configuration desired by the AC at
>    the WTP
> 10) The configuration phase is finished, and
>     the AC tells the WTP to begin operation.
> 
> NOTE: the significant differences from the boot model and the 
> boot model (as far as I can determine) in the CAPWAP-01 document are:
>  1) The AC's response to WTP's inquiry to be
>     able to connect.
>  2) What information is provided to the AC
>     by the WTP before a DTLS session is established.
>  3) What information is provided to WTPs by ACs
>  4) What information is used by an WTP to decide
>     which AC to connect to
>  5) How it is determined what image a WTP is
>     to run
>  6) How initial configuration of the WTP is
>     done before the WTP starts operation
> 
> I hope that the above set of steps and list of differences 
> provides you with enough details so that you understand what 
> I believe is the needed boot model for CAPWAP. 
> 
> Just one more detail...
> The "table that the AC must maintain" maps WTP hardware to 
> desired image for the WTP.
> The table is not part of the CAPWAP standard, and can be 
> implemented in any way that the AC vendor chooses. However, 
> if I were to implement it, the table would support both 
> classes of devices, such as "vendor X, model Y", and specific 
> devices, such as "device with ID=zz:zz:zz:zz:zz:zz", and have 
> a prioritized list of image IDs, and action to take if the 
> image was not on the WTP. Also, there must be a rule that 
> specifies what to do if the WTP is not in the table. The 
> table is really a list of rules for a simple image management system!
> A table as described above would allow
> 1) an AC to support a WTP from any number
>    of WTP vendors.
> 2) there would be no relationship on the
>    image identification and versioning
>    scheme between the WTP and AC, (or
>    between WTPs)
> 3) ideally, the table could be updated in
>    the field as just another part of
>    AC configuration.
> 4) ideally, new images could be made
>    available for the AC to transfer to
>    WTPs as updated configuration for
>    the AC without requiring new AC
>    system software
> 5) An AC could support different WTPs
>    (which are the same hardware) running
>    different versions of sofware (to support
>    a trial version, or a phased upgrade)
> 
> Note that "the table" could be a single
> rule that supports what ever software version that that WTP 
> is running. Or it could be a single rule that supported only 
> a single software version for each known WTP hardware type. 
> 
> Hope this helps. If not, send email.
> Please send me any scenarios that I didn't cover that should be.
> I'm working on a real document with
> CAPWAP message types and elements.
> 
> On Wed, 31 May 2006, qinxia wrote:
> >  My comment is inserted in the email, as the following:
> > 
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:[email-masked]]
> > > Sent: Sunday, May 28, 2006 3:30 AM
> > > To: Basker Ms
> > > Cc: 'capwap'
> > > Subject: Re: [Capwap] Selecting image for downloading to WTP
> > > 
> > > HI,
> > > 
> > > Yes, the booting process as currently specified is 
> seriously broken!
> > > 
> > > Regards,
> > > /david t. perkins
> > > 
> > > On Sat, 27 May 2006, Basker Ms wrote:
> > > > All,
> > > > 
> > > > According to capwap spec-01, during the discovery phase:
> > > > 
> > > > * WTP will send *its* h/w and s/w version (Section 4.4.34). 
> > > > * AC will respond with *its* h/w and s/w version (4.4.1)
> > > > 
> > > > WTP enters Image Data state when it determines that its
> > > version number
> > > > and the version number advertised by the AC are different.
> > > > 
> > > > Suppose, if the AC is connected with many WTPs from
> > > different vendors,
> > > > how the AC picks the correct image for downloading?
> > 
> > ==> In SNMP, OID  indicate the vendor, WTP may send its  
> OID, then , 
> > AC will respond with the corresponding version.
> > 
> > 
> > > > 
> > > > Or is it that AC will always send the same image to all the
> > > WTP(s) in
> > > > case of version mismatch?
> > > > 
> > > > Regards,
> > > > Basker Swaminathan
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 3 Jun 2006 15:35:16 -0700 (PDT)

HI,

I'm not at all proposing a separate CAPWAP Boot Model document.
I just want to make sure the following is clear:
 1) what are the supported WTP hardware capabilities,
     such as WTPs with no storage for image, WTPs that
     support a single image, WTPs that support multiple
     images. Plus WTPs that have limited storage for
     config, and those that have "essentially unlimited"
     storage for config. And devices that are single
     function purpose built WTPs, and devices that
     support the "WTP function" but also perform
     other functions.
2) a conplete list of configuration attributes, and
     specified CAPWAP default values
3) support for interoperation of WTPs and AC from
     different vendors
etc

The reason that I'm doing this in "a separate document"
is that I find that the CAPWAP document has generic
portions that have nothing to do with radios and
portions that are very radio specific, and I don't
find the portion that is generic that describes
how WTPs connect to ACs, manage the images, and
set initial configuration to be well specified.
That's the first step in my implementation of
my CAPWAP prototypes of a WTP and AC.

I hope it will be clear when done.  

I wish there were others that were prototyping.
If so, please let me know.

Regards,
/david t. perkins