Subject: [Capwap] Selecting image for downloading to WTP

From: Basker Ms <[email-masked]>
Date: Sat, 27 May 2006 11:17:31 +0530

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? 

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

---

From: sujay <[email-masked]>
Date: Sat, 27 May 2006 14:52:26 +0530

Hi,
The new proposal tracked as per Issue 118 should 
address your concern.
("[Capwap] Proposed Resolution for Issue 118: Change AC Descriptor SW/HW
version formats")
 
As it carries the Vendor Identifier both in WTP Descriptor
and the AC Descriptor.Perhaps then your implementation may
choose to choose the correct image, vendor specific.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229
<http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.52508
5&t=h&hl=en> &spn=4.724852,7.525085&t=h&hl=en

This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient's) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it! 

-----Original Message-----
From: Basker Ms [mailto:[email-masked]] 
Sent: Saturday, May 27, 2006 11:18 AM
To: 'capwap'
Subject: [Capwap] Selecting image for downloading to WTP

All,

 

 
Regards,
Basker Swaminathan

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 27 May 2006 12:30:08 -0700 (PDT)

HI,

Yes, the booting process as currently specified is 
seriously broken!

Regards,
/david t. perkins

---

From: qinxia <[email-masked]>
Date: Wed, 31 May 2006 09:18:26 +0800

My comment is inserted in the email, as the following:

> 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
> 

==> 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
> > 
> > 
> > 
> > 
> > 
> > 
>

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 30 May 2006 23:21:08 -0700 (PDT)

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.