Subject: [Capwap] Proposal for image management

From: "David T. Perkins" <[email-masked]>
Date: Mon, 22 Jan 2007 13:23:19 -0800 (PST)

HI,

Please consider the below. All comments welcome.

--------------------------------------
WTP Image Management
--------------------

Introduction
------------

The primary goal of the CAPWAP protocol is to define
a protocol so that a wireless network can be deployed
that contains WTPs and AC from different vendors.
One part of such a system is the management of the
software that provides the WTP function in access
points. For single vendor environments with simple
access point architecture, solutions can be quite
simple. However, to support a range of WTP
implementations, a more complex solution is needed.

Most current devices that provide the WTP function
are single purposed, and the software for the device
is packaged as a single file and typically called
the "system image". It is possible however to
have a multi-purpose device provide the WTP function
along with simultaneously providing other functions.
For such devices, the software for just the WTP function
could also be packaged as single file. Thus,
the image management in CAPWAP should support
any device as long as the the software can be
packaged as a single file.

The devices that support the WTP function range in
capability of storing no image to multiple images.
The number of images that can be stored (and the
characteristics of the storage) affect the cost,
reliability, and flexibility of the devices. CAPWAP
must support devices that have the capability of
storing more than one image. This slightly increases
the complexity of CAPWAP since the protocol must
have operations to determine the number of storage
locations, determine the characteristics of
stored images, specify a location when storing
an image on the device, and to specify which
image to run after the next reset.

There are two places in the operation of a WTP
that provide for the download of an image. These
are:
  1) immediately after a DTLS session has been
     established, and the Join operation successfully
     completed, but before configuration update commands.
     At this point, the WTP has communicated in the Join
     operation its identifying characteristics including its:
       a) manufacturer
       b) model
       c) device unique ID (such as serial number or
          base MAC address)
       d) field installed components
       e) currently running WTP software
       f) list of available storage areas and the
          WTP software that exists in each
     Using this information, the AC can decide to either:
       a) proceed using the currently running software
       b) instruct the WTP to switch to run WTP software
          that is already on the WTP (which will result
          in the WTP rebooting) (Specifically, the AC would
          change the index of the WTP software to run,
          and then reboot the WTP.)
       c) download a new image (WTP software), either
          replacing an existing image or storing it in
          an unused storage area. Then, if needed, set
          the index of the WTP software to the new image,
          and reboot the WTP.
     After the WTP reboots, and re-establishes a DTLS session,
     and the Join operation completes successfully, the WTP
     should be running the version of the software desired
     by the AC.
  2) During normal operation of the WTP (that is, in the "Run"
     state), the AC may query the WTP as to determine its
     list of available storage areas for WTP software and
     what exists in each, and what is the index of the
     WTP software to run after the next reboot. The AC
     may change the value of the index, and may download
     an image to replace an existing one or store it in
     an unused storage area. The AC at a later time, such
     as during a maintenance interval, can instruct the WTP
     to reboot and run the previously downloaded image.

Currently In CAPWAP
-------------------
CAPWAP as specified in CAPWAP-03 does not support several
aspects of the above. First, it has no concept of storage
areas for multiple images. Thus, to run a different version
of WTP software requires replacement of the currently running
WTP software. Current CAPWAP does support both places during
operation to download a different image. However, when done
in the RUN state, the WTP stops all other operations, and
when the download is completed (or aborted), the WTP next
resets. That is, image download is service affecting.

Current CAPWAP Operations for Image Management
----------------------------------------------
There are three operations defined for image management,
all use "Image Data Request"(9.1) and "Image Data Response"
(9.2) messages. The operations are:
  1) AC->WTP - Initiate image download (use Initiate Download
               (4.4.26) message element, which has no content)
  2) WTP->AC - Start image download (uses Image Filename (4.4.25)
               message element, which has a filename as content)
  3) AC->WTP - Image portion (uses Image Data(4.4.24) message
               element, which has fields:
                1) opcode - selector with values:
                      a) image data included
                      b) abort transfer
                2) checksum of image data
                3) image data (zero to 1024 octets))

Problems with Current Image Management
--------------------------------------
1) The same message is used for three different operations.
    (This can be resolved by creating two additional message
     pairs.)
2) The description of the Join operation says that the WTP
    gets the AC's version and compares it with its own to
    determine if the versions are compatible, and it not,
    then initiates image download to get the most recent
    version. However, a WTP does not have sufficient information
    to make such a decision. Only appropriate for an AC to
    have information and rules to determine what version
    of software that a WTP should be running. Note that how
    an AC obtains the information and rules is either builtin
    to the AC software, and/or provided through other management
    interfaces (such as the CLI or SNMP) to the AC.
    (This can be resolved by removing the WTP initiated
    download of software.)
3) In a WTP initiated start of image download, a filename
    is provided as the message element. The description does
    not specify whether the filename refers to a file on the
    WTP or AC. However, it is implied to be on the AC, since
    it is used to initiate a download, and the filename is
    not used in other operations. This is problematic, since
    the AC has the knowledge and rules to determine what image
    to download to each WTP. Also, as is, a filename would
    couple AC implementation with WTP implementation, which
    is doubtful in multi-vendor deployments. Also, the is nothing
    to prevent two different WTPs from choosing the same filename,
    and if used as is by the AC, then a conflict would result.
    (This can be resolved by removing the filename.)
4) No support for WTP storing more than a single image. Because
    current CAPWAP supports only a single image, the image version
    is implied in the value of the "software version field" of
    the WTP descriptor message element. However, this is flawed,
    since it assumes that vendor identifier identifies both
    the hardware and software of the WTP.
    (This can be resolved by adding a new message element
    that lists the storage areas for WTP images, and specifies
    their contents - either empty, or image description,
    provider, and version; and the identification of the
    image to be used on the next boot. It could possibly
    additionally include image attributes such as time image
    stored, number of times image used for booting the WTP,
    timestamp of last time image booted, image size, MD5 digest,
    counts such as "crashes" of image, etc. With the list of
    storage message elements, the AC sent operation that
    downloads portions of an image must be modified to specify
    which storage location to store image data.)
5) No support for WTP indicating failure during image download.
    Failure could occur due to resource exhaustion (such out of
    memory to buffer image before write), or due to write of
    image to persistent storage.
    (This can be resolved by adding result codes to the image
    portion operation.)
6) The Image Data Message element has several problems. This
    include:
      1) it has a checksum that is used to determine if the
         block of image data has been modified. However, the
         DTLS session provides information to determine if
         a message has been modified. Also, the algorithm
         for the checksum is not specified.
         (This can be resolved by removing from each message
         element, and providing for a digest, such as MD5,
         for the entire file.)
     2) end-of-file determination is implicit by the size of
        the image data element. That is, when the size of
        the image data field is less than 1024, then the end
        of the image file has been reached.
        (This can be resolved by using "opcode" field to
        explicitly indicate the end of the image transfer,
        (and used to specify that the "image data field"
        contains the digest of the image file)).
     3) no block number of image data. The message element
        does not provide the block number of the image file
        data element. Thus, outer CAPWAP message parameters
        must be used by the code that processes the data
        image to determine the block number. This becomes
        a very important issue when an image transfer occurs
        while in the run state.
        (This can be resolved by adding a 32-bit block number.)
     4) no location to store image. As previously mentioned,
        current CAPWAP does not support multiple storage
        locations for images. When this support is added,
        a mechanism needs to be added to provide this on
        image download.
        (This can be resolved by adding a location id field,
        or download session field to the image data message
        element.)
7) The AC initiate download operation does not specify
    any message elements that a WTP can use to determine
    if the download has high probability of succeeding.
    The WTP can determine if it supports download to a specific
    memory location (a WTP may images that are "permanent",
    or the WTP may not have enough persistent storage for
    the image).
    (This can be resolved by having AC initiated download to
    specify the size of the image file, and the location
    to store the image. The result would give the AC
    a hint if it should proceed with image download. Note
    that this operation be renamed to download check, since
    it doesn't initiate a download.)
8) There is not a mechanism for the WTP to indicate to the
    AC that the image that is being downloaded is inappropriate
    for it to use. An example would be for the image of, say,
    "model A", being downloaded to, say, "model B" and this
    would result in a system crash. Note: it is not practical
    due to multi-vendor differences of image files for an AC
    to be able to examine an image file to determine the
    the appropriate hardware and modules that can run an
    image. Thus, the check can only practically be performed
    on the WTP.
    (This issue can be resolved by adding a new error to
    be returned during image transfer that aborts image
    transfer and indicates inappropriate image for the WTP.
    Note: due to vendor design choices in where information
    is stored in the image file, the error may be generated
    after any data block of the image.)

Summary of Suggested Changes
----------------------------
1) Eliminate WTP->AC operation to initiate image transfer,
    and thus, eliminate the "image filename" message
    element (4.4.25).
2) Add new message element that is returned by Join that
    lists storage areas for images and the current contents
    and identification of image used for current and to use
    for next reboot.
3) Add new operation (and message pair) for download check.
4) Modify image data element to:
    a) eliminate checksum field
    b) add new value for opcode to specify "end-of-file",
       and when so, to include image digest type, and
       image digest in the image data field.
    c) add 32-bit block number to the beginning of the
       image data
5) Have failure results the image transfer and download check
    operations.
6) Have image check and image download operations from RUN
    state to not change current state (and have no auto-reboot)
    after image download.

Outstanding Issues
------------------
1) Can multiple simultaneous downloads occur in the RUN state?
    (Suggestion - Let this be optional, and add new error code
    to indicate non-support.)
2) How is the location of the image to run on the next download
    specified?
    (Suggestion - done with a parameter to the REBOOT operation
    and make reboot required if image download done at "join
    time".)

Example Message Flows
---------------------

1) No image download after join

            ============                         ============
                WTP                                   AC
            ============                         ============
             [--------------- discovery process -------------]

             Discover Request     ------>
                                  <------       Discover Response

                     (---- possibly additional operations ----)

             [--------------- end discovery -----------------]

                         (--- begin dtls handshake ---)

            ClientHello           ------>
                                  <------       HelloVerifyRequest
                                                    (with cookie)

            ClientHello           ------>
            (with cookie)
                                  <------       ServerHello
                                  <------       Certificate
                                  <------       ServerHelloDone

            (WTP callout for AC authorization)

            Certificate*
            ClientKeyExchange
            CertificateVerify*
            [ChangeCipherSpec]
            Finished              ------>

                                             (AC callout for WTP
                                               authorization)

                                                [ChangeCipherSpec]
                                  <------       Finished

                       (--- DTLS session is established now ---)

            Join Request           ------>
                                  <------       Join Response

                       (--- Image is desired version,
                            so proceed with initial
                            configuration and transition
                            to RUN state  ----------------)

2) Image download after join

            ============                         ============
                WTP                                   AC
            ============                         ============
             [--------------- discovery process -------------]

             Discover Request     ------>
                                  <------       Discover Response

                     (---- possibly additional operations ----)

             [--------------- end discovery -----------------]

                         (--- begin dtls handshake ---)

            ClientHello           ------>
                                  <------       HelloVerifyRequest
                                                    (with cookie)

            ClientHello           ------>
            (with cookie)
                                  <------       ServerHello
                                  <------       Certificate
                                  <------       ServerHelloDone

            (WTP callout for AC authorization)

            Certificate*
            ClientKeyExchange
            CertificateVerify*
            [ChangeCipherSpec]
            Finished              ------>

                                             (AC callout for WTP
                                               authorization)

                                                [ChangeCipherSpec]
                                  <------       Finished

                       (--- DTLS session is established now ---)

            Join Request           ------>
                                  <------       Join Response

                       (--- New image desired ---)

                                  <------       Check download Request

            Check download Response ------>

        ----
        |                         <------       Image download Request
        |
        |   Image download Response ------>
        |
        ----- repeated until image downloaded

                                  <------       Reset Request

            Reset Response         ------>

                            (---- WTP Reboots ----)

3) Image download in RUN state

                       (--- WTP in RUN state ---)

                       (--- Different image desired. due to
                            administrative operation
                            at AC                  ---)

                                  <------       Check download Request

            Check download Response ------>

        ----
        |                         <------       Image download Request
        |
        |   Image download Response ------>
        |
        ----- repeated until image downloaded, while still in RUN state

                       (---- WTP still in RUN state ---)

                       (---- time passes by -----)

                       (---- AC decides (due to administrative
                             specification or action) that
                             WTP should be running different
                             image ----)

                                  <------       Reset Request

            Reset Response         ------>

                            (---- WTP Reboots using
                                  specified image ----)

--------------------------------------
Regards,
/david t. perkins
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Peter Nilsson J (LI/EAB)" <[email-masked]>
Date: Tue, 23 Jan 2007 10:14:08 +0100

I think this a good proposal.

In particular I do like
The possibility to support multiple images.
That the AC allways initiates the download, both in "Join phase" and Run
state.
The possibility for the WTP to continue service while an Image is
downloaded.
That the AC are in control of which and when an image is activated
(booted). 

Peter

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: den 22 januari 2007 22:23
To: [email-masked]
Cc: [email-masked]
Subject: [Capwap] Proposal for image management

HI,

Introduction
------------

The primary goal of the CAPWAP protocol is to define a protocol so that
a wireless network can be deployed that contains WTPs and AC from
different vendors.
One part of such a system is the management of the software that
provides the WTP function in access points. For single vendor
environments with simple access point architecture, solutions can be
quite simple. However, to support a range of WTP implementations, a more
complex solution is needed.

Most current devices that provide the WTP function are single purposed,
and the software for the device is packaged as a single file and
typically called the "system image". It is possible however to have a
multi-purpose device provide the WTP function along with simultaneously
providing other functions.
For such devices, the software for just the WTP function could also be
packaged as single file. Thus, the image management in CAPWAP should
support any device as long as the the software can be packaged as a
single file.

The devices that support the WTP function range in capability of storing
no image to multiple images.
The number of images that can be stored (and the characteristics of the
storage) affect the cost, reliability, and flexibility of the devices.
CAPWAP must support devices that have the capability of storing more
than one image. This slightly increases the complexity of CAPWAP since
the protocol must have operations to determine the number of storage
locations, determine the characteristics of stored images, specify a
location when storing an image on the device, and to specify which image
to run after the next reset.

There are two places in the operation of a WTP that provide for the
download of an image. These
are:

Currently In CAPWAP
-------------------
CAPWAP as specified in CAPWAP-03 does not support several aspects of the
above. First, it has no concept of storage areas for multiple images.
Thus, to run a different version of WTP software requires replacement of
the currently running WTP software. Current CAPWAP does support both
places during operation to download a different image. However, when
done in the RUN state, the WTP stops all other operations, and when the
download is completed (or aborted), the WTP next resets. That is, image
download is service affecting.

There are three operations defined for image management, all use "Image
Data Request"(9.1) and "Image Data Response"

Outstanding Issues
------------------

Example Message Flows
---------------------

             Discover Request     ------>

            ClientHello           ------>

            ClientHello           ------>
            (with cookie)
                                  <------       ServerHello
                                  <------       Certificate
                                  <------       ServerHelloDone

            Certificate*
            ClientKeyExchange
            CertificateVerify*
            [ChangeCipherSpec]
            Finished              ------>

                                             (AC callout for WTP
                                               authorization)

                                                [ChangeCipherSpec]
                                  <------       Finished

            Join Request           ------>
                                  <------       Join Response

             Discover Request     ------>

            ClientHello           ------>

            ClientHello           ------>
            (with cookie)
                                  <------       ServerHello
                                  <------       Certificate
                                  <------       ServerHelloDone

            Certificate*
            ClientKeyExchange
            CertificateVerify*
            [ChangeCipherSpec]
            Finished              ------>

                                             (AC callout for WTP
                                               authorization)

                                                [ChangeCipherSpec]
                                  <------       Finished

            Join Request           ------>
                                  <------       Join Response

        ----

                                  <------       Reset Request

            Reset Response         ------>

                            (---- WTP Reboots ----)

        ----

                                  <------       Reset Request

            Reset Response         ------>

                            (---- WTP Reboots using
                                  specified image ----)

---

From: Scott G Kelly <[email-masked]>
Date: Tue, 23 Jan 2007 05:27:23 -0800

I also think this is a good proposal in many ways. I do have a few 
concerns, though. One has to do with the idea of "image locations", but 
maybe I'm misunderstanding something. The discussion of image storage 
locations seems to imply that there will be fixed "slots" carved out for 
storing images, but I think that has obvious issues (e.g. how big are 
they, and what happens if an image grows beyond this size?)

If I'm just missing something, you can correct me. Otherwise, we might 
want to think more generally about image storage, maybe in terms of 
files (perhaps with numeric image IDs, with one designated as "active") 
rather than "image locations".

Also implicit in all of this is an issue which is in some ways similar 
to those of certificate management, i.e. what is the format of an 
"image"? Every vendor has their own proprietary image scheme, and while 
I don't profess to know what everyone has done, I'd venture a guess that 
some bundle a boot loader, OS kernel, and executable(s) into one 
package, and others bundle some subset of these, and some may even 
support both approaches. This seems like an iceberg to me, with a lot of 
subtle issues hiding under the surface.

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 23 Jan 2007 09:59:32 -0800

> Problems with Current Image Management
OK

>     (This can be resolved by removing the WTP initiated
OK

>     (This can be resolved by removing the filename.)
OK

>     which storage location to store image data.)
So here I have to disagree. The WTP is in the best position to manage
its own memory, and determine the best place to store the latest image.
If the WTP is capable of storing 4 images, then let it do so through
its own accord, and don't burden the AC with this decision. The AC
should not be in a position to manage image "slots". The WTP then needs
to know which is the latest image to boot from, and have its own
strategy on using a backup should the primary be corrupted.

>     (This can be resolved by adding result codes to the image
I believe this has been recently added, and text was proposed to
the list.

>          element, and providing for a digest, such as MD5,
I believe this has been recently added, and text was proposed to
the list.

>         contains the digest of the image file)).
OK

>         (This can be resolved by adding a 32-bit block number.)
OK

>         or download session field to the image data message
CAPWAP doesn't need to support it. This is an implementation issue.

>     it doesn't initiate a download.)
I agree on adding a file size, but disagree with the permanent
and image storage strategy being a CAPWAP problem.

>     after any data block of the image.)
I believe the infrastructure is already in place, and this text
was submitted to the list already. We may want/need a new result
code for this purpose.

> Summary of Suggested Changes
OK

>     and identification of image used for current and to use
I disagree with this change request (see above)

> 3) Add new operation (and message pair) for download check.
Not sure what "download check" means.

>     a) eliminate checksum field
I don't this as adding harm

>        image digest in the image data field.
OK

>     c) add 32-bit block number to the beginning of the
OK

> 5) Have failure results the image transfer and download check
results are provided in the latest text

>     state to not change current state (and have no auto-reboot)
This is a problem which is being tracked separately. Let's leave this
out of this specific issue.

> Outstanding Issues
Not necessary, IMHO

>     and make reboot required if image download done at "join
This is a WTP implementation problem.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 23 Jan 2007 10:31:23 -0800 (PST)

HI,

It looks like there is much agreement with the proposal.

There is one issue, however, where it appears that there
is a substantial difference in opinion, and I'd like
to further explore it to see if we can close the gap.

On Tue, 23 Jan 2007, Pat Calhoun \(pacalhou\) wrote:
<text cut>
>>     which storage location to store image data.)
<pat>
> strategy on using a backup should the primary be corrupted.
</pat>

To me, the difference between the proposal and pat's comment is
in what entity is in control as to what software is running on
a WTP. For me, at the system level (the system is an AC and
multiple connected WTPs), the AC implements the system level
configuration as specified by the system operator via a
management interface to the AC. I believe that WTPs have
NO management interface other than CAPWAP.

An operator must have the ultimate control as to what software
is running on each WTP.

An operator must have the ultimate control as to what software
is stored on each WTP. (That is, if all storage locations
contain an image, and another image is to be downloaded,
I believe that the operator must decide which image to
replace - not the WTP.)

To make decisions about which image to run (on next reboot),
and where to store an image, the operator must have:
  1) the capabilities of the WTP
  2) the following key attributes of each stored image:
       a) vendor
       b) version
       c) identification (description)
     and possibly the other attributes as specified above.

Regards,
/david t. perkins

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 23 Jan 2007 14:21:50 -0800

I understand your argument, but disagree. WTP vendors will ship firmware
storage of all kinds, and I do not believe the AC should have visibility
into its strategy. How, and whether, a WTP has firmware redundancy is an
implementation issue - not an AC control one. 

Otherwise, I believe we have agreement on the strategy.

Pat Calhoun

> Sent: Tuesday, January 23, 2007 10:31 AM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Capwap] Proposal for image management
> 
> HI,
> 
> There is one issue, however, where it appears that there is a 
> substantial difference in opinion, and I'd like to further 
> explore it to see if we can close the gap.
> 
> 
> > should not be in a position to manage image "slots". The WTP then 
> > needs to know which is the latest image to boot from, and 
> have its own 
> To me, the difference between the proposal and pat's comment 
> is in what entity is in control as to what software is 
> running on a WTP. For me, at the system level (the system is 
> an AC and multiple connected WTPs), the AC implements the 
> system level configuration as specified by the system 
> operator via a management interface to the AC. I believe that 
> WTPs have NO management interface other than CAPWAP.
> 
> An operator must have the ultimate control as to what 
> software is running on each WTP.
> 
> An operator must have the ultimate control as to what 
> software is stored on each WTP. (That is, if all storage 
> locations contain an image, and another image is to be 
> downloaded, I believe that the operator must decide which 
> image to replace - not the WTP.)
>

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 23 Jan 2007 14:45:14 -0800 (PST)

HI,

I'm assuming that we agree that the operator must have
ultimate control. If so, the operator must know the
image storage capability of each deployed WTP
(and most likely choose the WTPs based on their
capability which would allow the designer/operator
to provide the needed capabiltities of the deployed
system within a cost budget.) Given this, how does an
operator get a WTP to have the images stored on it that
are desired by the operator? How does an operator
get a WTP to reboot and run a different image
that is already stored on the WTP?

Regards,
/david t. perkins

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 23 Jan 2007 16:33:05 -0800

I've had the time to think about this some more, and have changed my
mind on a couple of issues. My issues are not with the problem
statement, but with the proposed resolution.

Please see below.

> >     and thus, eliminate the "image filename" message

There are two issues here. I am ok with the image filename, but
disagree with eliminating the WTP->AC. I agree that the current text
is vague (at best), but the model of having the WTP initiate the 
file transfer works fine if we were to make a fairly simple change.
When the AC responds back in the Join Response, it includes the
latest firmware version that it has for the specific WTP, which
allows the WTP to make the decision on whether it will initiate the
download. We can have strict rules that if the firmware version it
is running is different from what is advertised by the AC, then it
MUST download (because the AC will not permit operation otherwise).

The advantage of this change is that it touches very little of the
actual protocol. It does not impact the state machine at all.

PatC

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 23 Jan 2007 16:36:29 -0800

Firmware storage is an implementation issue on the AC. I disagree the AC
needs to be involved in the management of the WTP's permanent storage.
To do so can lead to all kinds of interesting issues. Furthermore, a
buggy AC can cause a WTP to end up being a brick (unable to boot), and
guess which manufacturer would end up with the RMA.

So I respectfully disagree on this point.

If you read the e-mail I just sent, I proposed an alternative to have
the AC send the latest available firmware for the WTP (and not
completely change the protocol needlessly). In this model, we could put
rules that simply state that the AC will not permit the WTP to get into
the configure state if the firmware it is running is not the same as the
latest available image on the AC. This provides the same level of
control, without the need for the AC to manage the WTP's internal HW
resources.

Pat Calhoun

> Sent: Tuesday, January 23, 2007 2:45 PM
> ultimate control. If so, the operator must know the image 
> storage capability of each deployed WTP (and most likely 
> choose the WTPs based on their capability which would allow 
> the designer/operator to provide the needed capabiltities of 
> the deployed system within a cost budget.) Given this, how 
> does an operator get a WTP to have the images stored on it 
> that are desired by the operator? How does an operator get a 
> WTP to reboot and run a different image that is already 
> stored on the WTP?
> 
> Regards,
> /david t. perkins
> 
> > I understand your argument, but disagree. WTP vendors will ship 
> > firmware storage of all kinds, and I do not believe the AC 
> should have 
> > visibility into its strategy. How, and whether, a WTP has firmware 
> > redundancy is an implementation issue - not an AC control one.
> >
> > CTO, Wireless Networking Business Unit Cisco Systems
> >
> >
> >

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 23 Jan 2007 17:07:00 -0800 (PST)

HI,

I appreciate you rethinking this issue. I'm troubled with
the "latest" attribute, since
  1) I don't believe that an AC would know how to
     determine this (only the WTP should have the
     knowledge of how to "open up" an image file).
  2) I don't believe that an operator would always
     want to have the "latest" version of the WTP
     software running on a WTP.

For the second, there are several examples. Here are
some:
  1) a vendor creates two release trains. One is a
     stable and well supported version. The other
     contains new features and may be buggy
     and has limited support. The operator wants
     wants to install each and try them out to
     see if how they perform in the environment.
  2) a third party vendor creates images for the WTP.
     The operator wants to try out the code from
     the 3rd party vendor.
  3) a WTP vendor creates normal and a debug version
     of software for the WTP. When running the debug
     version, the number of the STAs is limited, but
     the WTP can provide lots of information that can
     be used to trouble shoot wireless network problems.
     An operator may want to switch back and forth
     between versions when in normal or trouble shooting
     mode.
So please describe how the above scenarios can be supported?

Regards,
/david t. perkins

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 24 Jan 2007 08:10:54 -0800

> I appreciate you rethinking this issue. I'm troubled with the 
> "latest" attribute, since

The "version" desired could be configured by the operator,
or it could simply be the latest firmware present on the
AC. There is nothing in my proposal that does not address
the requirements you've mentioned, especially in the latter
case. It allows for the same level of flexibility without
drastic changes to the protocol.

>      see if how they perform in the environment.
That would be an AC implementation thing. For instance, I
could see an AC allow the operator to configure different
firmware version numbers for different WTPs. 

>      The operator wants to try out the code from
See above.

> So please describe how the above scenarios can be supported?

As I mentioned, there is nothing in my proposal that would
not allow support for all of the items you have listed above. All
of this would be an AC implementation issue, and how the WTP firmware
version number is configured on the AC (either global, or on a per
WTP basis).

Pat Calhoun

> > is vague (at best), but the model of having the WTP 
> initiate the file 
> > transfer works fine if we were to make a fairly simple change.
> > When the AC responds back in the Join Response, it includes 
> the latest 
> > firmware version that it has for the specific WTP, which allows the 
> > WTP to make the decision on whether it will initiate the 
> download. We 
> > can have strict rules that if the firmware version it is running is 
> > different from what is advertised by the AC, then it MUST download 
> > (because the AC will not permit operation otherwise).
> >