Subject: [Capwap] Proposed Resolution to Issue 126: "Wrong Place for "inage data" state

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 19 Dec 2006 15:39:10 -0800

All,

Issue 126, and related discussion is listed below.

Proposed resolution: Close with no change to the draft.
The WTP Descriptor, which includes the Hardware, Software and Boot
version numbers is included in the Join Request, and the AC Descriptor,
which includes similar information for the AP is included in the Join
Response.
Thus each knows the version info of the other. The mechanism for
determining "compatibility" is not specified.

The text currently states:

   Join to Configure (g):  This state transition is used by the WTP and
      the AC to exchange configuration information.

      WTP:  The WTP enters the Configure state when it successfully
         completes the Join operation.  If it determines that its
         version number and the version number advertised by the AC are
         compatible, the WTP transmits the Configuration Status message

         (see Section 8.2) to the AC with a snapshot of its current
         configuration.  The WTP also starts the ResponseTimeout timer
         (see Section 4.5).  If the version numbers are not compatible,
         the WTP will immediately transition to Image Data state (see
         transition (i)).  If the AC determines that a new firmware
         image should be installed on the WTP, the AC initiates a
         firmware download by sending an Image Data Request Message with
         an Initiate Download message element to the WTP

      AC:  This state transition occurs immediately after the AC
         transmits the Join Response message to the WTP.  If the AC
         receives the Configuration Status message from the WTP, the AC
         must transmit a Configuration Status Response message(see
         Section 8.3) to the WTP, and may include specific message
         elements to override the WTP's configuration.  If the AC
         instead receives the Image Data Request from the WTP, it
         immediately transitions to the Image Data state (see transition
         (i)).

and

Configure to Image Data (i):  This state transition is used by the
      WTP and the AC to download executable firmware.

      WTP:  The WTP enters the Image Data state when it successfully
         comletes DTLS session establishment, and determines that its
         version number and the version number advertised by the AC are
         different.  The WTP transmits the Image Data Request (see
         Section 9.1) message requesting that a download of the AC's
         latest firmware be initiated.

      AC:  This state transition occurs when the AC receives the Image
         Data Request message from the WTP.  The AC must transmit an
         Image Data Response message (see Section 9.2) to the WTP, which
         includes a portion of the firmware.

Comments welcome,

Dorothy
----------------------------------------------------------------------------------------------------------------------------------
Discussion re: Issue 126 included the following, based on the -01 CAPWAP
draft:

> The state machine shows that the "image data" state is
> entered after the "configure" state. However, the description
> of the state machine doesn't really match this. As currently
> specified, I believe that it would be clearer for the "Image
> Data" state to be entered from the "Join" state instead of
> the "Configure"
> state.

This change was made as part of the state machine revisions resulting from
DTLS integration. The single exit from the Join state to the Configure
statewas chosen
for simplicity, and because which image(s) the WTP has available (and which
image should be the active one) really is a matter of system configuration.
I know someone on this list argued that this is not configuration, but
looking at it this way provides a certain consistency and clean logic that
is hard to deny.

What I think is more important though, and as you've noted in previous
posts, is that we have not clearly defined the criteria for transitioning to
image download. I think (based on your earlier post) that you have very
definite ideas on how this should be managed, and I think what you've
suggested makes sense.

It seems like your suggestions would work fine with the state machine as
specified - in this case, the WTP sends the Configure Request with it's
current config, and that includes a list of available images, and the
current "active" image; if the AC wants the WTP to reboot with a different
image, this is accomplished by changing the current "active" image in a
Config Rsp message.

If the AC wants the WTP to download a new image, it can follow the same
procedure, i.e. set the appropriate version for the current active image;
when the WTP determines that it does not have this image stored locally, it
transitions to the Image Data state, fetches the new image, and reboots.

I know there are a few missing details here, but does this address your
concerns in general?

and:

I think we need to fully specify the mechanism by which the version
communication takes place, and also who makes the decision (currently,
the language is a bit ambiguous, saying either the AC or WTP can intiate
the image download, but saying nothing about how they decide and do
contention resolution).

I think David is proposing making the version information/setting part
of the Join exchange, and transitioning directly to Image Data (without
ever entering Configure) if appropriate (or rebooting, if the desired
image is different than what is running, and is already stored on the WTP).

I don't feel strongly about this. I think David is preparing a proposal,
and that will have all the detail we need (David, please correct if I am
wrong about this).

And the following on Draft -02 text:

 I was reading the about the state transistions chapter 2.3.1 in
draft -02.
       In transintion (g) "Join to Configure" and (i) "Configure to
Image Data" it is said that the WTP determines that its version number
is same or different than the version number advertised by the AC.

       First of all I assume that the version number meant here is the
software or firmware version.
       What is not clear to me is how the WTP get to know the version
number advertised by the AC. The only software version I have seen that
the AC sends to the WTP is the AC's Software version in AC Descriptor
message element sent in the Discovery Response. But the AC's own
software version would not be much help to determine if the WTP needs to
update its firmware or not.

       Can some one explain how this is meant to work?
_________________________________________________________________
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: Wed, 20 Dec 2006 11:50:20 +0100

It is said that "The mechanism for determing "compatilbilty" is not
specified". 
Will it be specified by the CAPWAP spec?
 
An other thing regarding firmware updates. A WTP can report the version
of the Firmware and the Boot loader respectivly in the WTP Descriptor.
But the AC can not tell the WTP which one that needs to be updated.
I am confused how the Filename attribute in the Image Filename message
element is supposed to be configured by the WTP. As it is now the AC has
no way of configuring this.
I suggest that we add the filename in the Initiate Download message
element which is sent by the AC. This filename is then sent by the WTP
in the Image Filename message element.
With this change the AC have a chance to manage the software to be
updated on the WTP.
 
Peter Nilsson

________________________________

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: den 20 december 2006 00:39
To: capwap
Subject: [Capwap] Proposed Resolution to Issue 126: "Wrong Place for
"inagedata" state

All,

and

Comments welcome,

Dorothy
------------------------------------------------------------------------
----------------------------------------------------------
Discussion re: Issue 126 included the following, based on the -01 CAPWAP

> Data" state to be entered from the "Join" state instead of

This change was made as part of the state machine revisions resulting
from DTLS integration. The single exit from the Join state to the
Configure state was chosen for simplicity, and because which image(s)
the WTP has available (and which image should be the active one) really
is a matter of system configuration. I know someone on this list argued
that this is not configuration, but looking at it this way provides a
certain consistency and clean logic that is hard to deny.

What I think is more important though, and as you've noted in previous
posts, is that we have not clearly defined the criteria for
transitioning to image download. I think (based on your earlier post)
that you have very definite ideas on how this should be managed, and I
think what you've suggested makes sense.

It seems like your suggestions would work fine with the state machine as
specified - in this case, the WTP sends the Configure Request with it's
current config, and that includes a list of available images, and the
current "active" image; if the AC wants the WTP to reboot with a
different image, this is accomplished by changing the current "active"
image in a Config Rsp message.

If the AC wants the WTP to download a new image, it can follow the same
procedure, i.e. set the appropriate version for the current active
image; when the WTP determines that it does not have this image stored
locally, it transitions to the Image Data state, fetches the new image,
and reboots.

and:

I think David is proposing making the version information/setting part
of the Join exchange, and transitioning directly to Image Data (without
ever entering Configure) if appropriate (or rebooting, if the desired
image is different than what is running, and is already stored on the
WTP).

---

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 20 Dec 2006 12:56:02 -0800

Peter,

Inline below.

Thanks,

Dorothy

> Will it be specified by the CAPWAP spec?

No. The algorithm for determining that a new image is needed would not be
defined by the CAPWAP spec.

An other thing regarding firmware updates. A WTP can report the version of
> the Firmware and the Boot loader respectivly in the WTP Descriptor.

 Ok - the intent would be that the AC indicates to the WTP that it must
"update the Firmware" or "update the Boot loader"

> element is supposed to be configured by the WTP. As it is now the AC has no
> way of configuring this.
>

Currently, (Section 9.1) the Image Data Request message is used by the AC to
initiate a firmware download.
The AC sends Image Data Request [Initiate Download].  <--------- and needs
to indicate the Image Filename
WTP sends Image Data Response Message[]
WTP Sends Image Data Request [Image Filename]  <-----------------Image
filename included here
AC sends Image Data Request[Image Data}

I suggest that we add the filename in the Initiate Download message element
> which is sent by the AC. This filename is then sent by the WTP in the Image
> Filename message element.
> With this change the AC have a chance to manage the software to be updated
> on the WTP.
>

We already have an Image Filename message element (4.4.25). Alternatively,
we could allow the
Image Data Request message to contain more than one message element, and the

AC would send Image Data Request[Initiate Download, Image Filename]
WTP sends Image Data Response Message[]
WTP Sends Image Data Request [Image Filename]  <-----------------Image
filename included here

Thanks,

Dorothy

Peter Nilsson
>  ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* den 20 december 2006 00:39
> *To:* capwap
> *Subject:* [Capwap] Proposed Resolution to Issue 126: "Wrong Place for
> "inagedata" state
>
> All,
>
> state was chosen for simplicity, and because which image(s) the WTP has
> available (and which image should be the active one) really is a matter of
> system configuration. I know someone on this list argued that this is not
> configuration, but looking at it this way provides a certain consistency and
> clean logic that is hard to deny.
>
> posts, is that we have not clearly defined the criteria for transitioning
> to image download. I think (based on your earlier post) that you have very
> when the WTP determines that it does not have this image stored locally,
> it transitions to the Image Data state, fetches the new image, and
> reboots.
>

---

From: "Peter Nilsson J (LI/EAB)" <[email-masked]>
Date: Thu, 21 Dec 2006 08:20:55 +0100

Allowing the AC to send the Image Filename message element together with
Initate Download works fine for me.
 
Peter

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: den 20 december 2006 21:56
To: Peter Nilsson J (LI/EAB)
Cc: capwap
Subject: Re: [Capwap] Proposed Resolution to Issue 126: "Wrong Place for
"inagedata" state

Peter, 

Inline below.

Thanks,

Dorothy

On 12/20/06, Peter Nilsson J (LI/EAB) <[email-masked]>
wrote: 

	It is said that "The mechanism for determing "compatilbilty" is
not specified". 
	Will it be specified by the CAPWAP spec?

No. The algorithm for determining that a new image is needed would not
be defined by the CAPWAP spec.

	An other thing regarding firmware updates. A WTP can report the
version of the Firmware and the Boot loader respectivly in the WTP
Descriptor.
	But the AC can not tell the WTP which one that needs to be
updated.

	I am confused how the Filename attribute in the Image Filename
message element is supposed to be configured by the WTP. As it is now
the AC has no way of configuring this.

Currently, (Section 9.1) the Image Data Request message is used by the
AC to initiate a firmware download. 
The AC sends Image Data Request [Initiate Download].  <--------- and
needs to indicate the Image Filename
WTP sends Image Data Response Message[]
WTP Sends Image Data Request [Image Filename]  <-----------------Image
filename included here
AC sends Image Data Request[Image Data}

	I suggest that we add the filename in the Initiate Download
message element which is sent by the AC. This filename is then sent by
the WTP in the Image Filename message element.
	With this change the AC have a chance to manage the software to
be updated on the WTP.

We already have an Image Filename message element (4.4.25).
Alternatively, we could allow the
Image Data Request message to contain more than one message element, and
the 
AC would send Image Data Request[Initiate Download, Image Filename]
WTP sends Image Data Response Message[]
WTP Sends Image Data Request [Image Filename]  <-----------------Image
filename included here

Thanks,

Dorothy

	Peter Nilsson 

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: den 20 december 2006 00:39
	To: capwap
	Subject: [Capwap] Proposed Resolution to Issue 126: "Wrong Place
for "inagedata" state

	All,

	Proposed resolution: Close with no change to the draft.
	The WTP Descriptor, which includes the Hardware, Software and
Boot
	version numbers is included in the Join Request, and the AC
Descriptor, 
	which includes similar information for the AP is included in the
Join Response.
	Thus each knows the version info of the other. The mechanism for
	determining "compatibility" is not specified.

	   Join to Configure (g):  This state transition is used by the
WTP and
	      the AC to exchange configuration information.
	
	      WTP:  The WTP enters the Configure state when it
successfully
	         completes the Join operation.  If it determines that
its
	         version number and the version number advertised by the
AC are
	         compatible, the WTP transmits the Configuration Status
message
	
	         (see Section 8.2) to the AC with a snapshot of its
current
	         configuration.  The WTP also starts the ResponseTimeout
timer
	         (see Section 4.5).  If the version numbers are not
compatible,
	         the WTP will immediately transition to Image Data state
(see
	         transition (i)).  If the AC determines that a new
firmware
	         image should be installed on the WTP, the AC initiates
a
	         firmware download by sending an Image Data Request
Message with
	         an Initiate Download message element to the WTP
	
	      AC:  This state transition occurs immediately after the AC
	         transmits the Join Response message to the WTP.  If the
AC
	         receives the Configuration Status message from the WTP,
the AC
	         must transmit a Configuration Status Response
message(see
	         Section 8.3) to the WTP, and may include specific
message
	         elements to override the WTP's configuration.  If the
AC
	         instead receives the Image Data Request from the WTP,
it
	         immediately transitions to the Image Data state (see
transition
	         (i)).
	
	and
	
	Configure to Image Data (i):  This state transition is used by
the
	      WTP and the AC to download executable firmware.
	
	      WTP:  The WTP enters the Image Data state when it
successfully
	         comletes DTLS session establishment, and determines
that its
	         version number and the version number advertised by the
AC are
	         different.  The WTP transmits the Image Data Request
(see
	         Section 9.1) message requesting that a download of the
AC's
	         latest firmware be initiated.
	
	      AC:  This state transition occurs when the AC receives the
Image
	         Data Request message from the WTP.  The AC must
transmit an
	         Image Data Response message (see Section 9.2) to the
WTP, which
	         includes a portion of the firmware.

	Comments welcome,
	
	Dorothy
	
------------------------------------------------------------------------
----------------------------------------------------------
	Discussion re: Issue 126 included the following, based on the
-01 CAPWAP
	
	> Data" state to be entered from the "Join" state instead of
	
	This change was made as part of the state machine revisions
resulting from DTLS integration. The single exit from the Join state to
the Configure state was chosen for simplicity, and because which
image(s) the WTP has available (and which image should be the active
one) really is a matter of system configuration. I know someone on this
list argued that this is not configuration, but looking at it this way
provides a certain consistency and clean logic that is hard to deny.
	
	What I think is more important though, and as you've noted in
previous posts, is that we have not clearly defined the criteria for
transitioning to image download. I think (based on your earlier post)
that you have very definite ideas on how this should be managed, and I
think what you've suggested makes sense.
	
	It seems like your suggestions would work fine with the state
machine as specified - in this case, the WTP sends the Configure Request
with it's current config, and that includes a list of available images,
and the current "active" image; if the AC wants the WTP to reboot with a
different image, this is accomplished by changing the current "active"
image in a Config Rsp message.
	
	If the AC wants the WTP to download a new image, it can follow
the same procedure, i.e. set the appropriate version for the current
active image; when the WTP determines that it does not have this image
stored locally, it transitions to the Image Data state, fetches the new
image, and reboots.
	
	I know there are a few missing details here, but does this
address your concerns in general?
	
	and:
	
	I think we need to fully specify the mechanism by which the
version
	communication takes place, and also who makes the decision
(currently,
	the language is a bit ambiguous, saying either the AC or WTP can
intiate
	the image download, but saying nothing about how they decide and
do
	contention resolution).
	
	I think David is proposing making the version
information/setting part
	of the Join exchange, and transitioning directly to Image Data
(without
	ever entering Configure) if appropriate (or rebooting, if the
desired
	image is different than what is running, and is already stored
on the WTP).
	
	I don't feel strongly about this. I think David is preparing a
proposal,
	and that will have all the detail we need (David, please correct
if I am
	wrong about this).

	 I was reading the about the state transistions chapter 2.3.1 in
	draft -02.
	       In transintion (g) "Join to Configure" and (i) "Configure
to
	Image Data" it is said that the WTP determines that its version
number 
	is same or different than the version number advertised by the
AC.
	
	       First of all I assume that the version number meant here
is the
	software or firmware version.
	       What is not clear to me is how the WTP get to know the
version 
	number advertised by the AC. The only software version I have
seen that
	the AC sends to the WTP is the AC's Software version in AC
Descriptor
	message element sent in the Discovery Response. But the AC's own

	software version would not be much help to determine if the WTP
needs to
	update its firmware or not.

	

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

---

From: "Peter Nilsson J (LI/EAB)" <[email-masked]>
Date: Thu, 21 Dec 2006 08:35:15 +0100

One other thing regarding firmware update procedure. 
Will CAPWAP define the algorithm for the checksum calculation in Image
Data message element?
And what shall the WTP do if the checksum is bad? 
We might need to add Reslut Code in the Image Data Response message.
 
Peter

From: Peter Nilsson J (LI/EAB) [mailto:[email-masked]] 
Sent: den 21 december 2006 08:21
Cc: capwap
Subject: Re: [Capwap] Proposed Resolution to Issue 126: "Wrong Place
for"inagedata" state

Peter

Peter, 

Inline below.

Thanks,

Dorothy

Thanks,

Dorothy

	Peter Nilsson 

	
	All,

	

	

	and

	

	Comments welcome,
	
	Dorothy

	

	

	and: