Subject: Re: [Capwap] Proposed Resolution to Issue 126: "Wrong Placefor"inagedata" state

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 Jan 2007 09:11:17 -0800

Peter,
 
Here is the proposed text. Let me know if this works for you.

2.3.1.  CAPWAP Protocol State Transitions
[...]
   Image Data to Reset (m):  This state transition is used to reset the
      DTLS connection prior to restarting the WTP after an image
      download.

      WTP:  When an image download completes, the WTP enters the Reset
         state, and terminates the DTLS connection, sending a
         DTLSShutdown command to the DTLS state machine.  The WTP MAY
         also transition to this state upon receiving an Image Data
         Response from the AC (see Section 9.2) indicating a failure.

4.5.24.  Image Data
[...]
   Checksum:   A 16-bit value containing a checksum of the image data
      that follows.  The checksum field is the 16 bit one's complement
      of the one's complement sum of all 16 bit words in the header.
      For purposes of computing the checksum, the value of the checksum
      field is zero.

4.5.31.  Result Code
[...]
   Result Code:   The following values are defined:
[...]
      12 Image Data Error (Invalid Checksum)

      13 Image Data Error (Invalid Data Length)

      14 Image Data Error (Other Error)

9.2.  Image Data Response

   The Image Data Response message acknowledges the Image Data Request
   message.

   An Image Data Response message is sent in response to a received
   Image Data Request message.  Its purpose is to acknowledge the
   receipt of the Image Data Request message.  The Result Code is
   included to indicate whether a previously sent Image Data Request
   message was invalid.

   The following message elements MUST be included in the Image Data
   Response message.

   o  Result Code, see Section 4.5.31

   Upon receiving an error, the WTP MAY decide to retransmit a previous
   Image Data Reqest, or abandon the firmware download to the WTP by
   transitioning to the Reset state machine.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Peter Nilsson J (LI/EAB)
[mailto:[email-masked]] 
	Sent: Wednesday, December 20, 2006 11:35 PM
	To: capwap
	Subject: Re: [Capwap] Proposed Resolution to Issue 126: "Wrong
Placefor"inagedata" state

	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

	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.

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

		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,
		
		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 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).
		
		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
<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: Wed, 10 Jan 2007 12:03:48 -0800 (PST)

HI,

Pat - the current IMAGE download model (state diagram and
operations) is broken, since allows download to occur after
initial config, and when complete causes WTP reset.

This is rehashing this issue, and I really don't understand
why you keep ignoring this.

For WTPs that have no persistent storage for a complete image,
or storage for single image (which must be the "running image"),
the model in the current draft is minimally workable. (It still
suffers the problem of having to reset the WTP to download
an image, instead of also allowing image download to be started
from the run state.) In environments where WTPs must have
minimal out of service times, and/or minimal bandwidth is
available for downloading new WTP images, WTPs would have
the capability to support image download during the RUN
state, and completion of the download does not result
in WTP reset. That is after the download is complete,
the AC can reset the WTP to run the new image at a later
time.

As for the download operations - problems with them have
also been pointed out and are not addressed. Most importantly,
the image data needs to include the offset of the data.
This will allow the download of an image to be pipelined
will generally result in effectively reducing the time
to download an image by 50%.

Regards,
/david t. perkins

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 Jan 2007 12:15:07 -0800

> initial config, and when complete causes WTP reset.

Please see issue 200.

> For WTPs that have no persistent storage for a complete 
> image, or storage for single image (which must be the 
> "running image"), the model in the current draft is minimally 
> workable. (It still suffers the problem of having to reset 
> the WTP to download an image, instead of also allowing image 
> download to be started from the run state.)

We've discussed this and have agreed that WTPs have persistent
storage.

> In environments 
> where WTPs must have minimal out of service times, and/or 
> minimal bandwidth is available for downloading new WTP 
> images, WTPs would have the capability to support image 
> download during the RUN state, and completion of the download 
> does not result in WTP reset. That is after the download is 
> complete, the AC can reset the WTP to run the new image at a 
> later time.

Please see Issue 200. The proposal below is for issue 126, not 200.

> As for the download operations - problems with them have also 
> been pointed out and are not addressed. Most importantly, the 
> image data needs to include the offset of the data.
> This will allow the download of an image to be pipelined will 
> generally result in effectively reducing the time to download 
> an image by 50%.

What you are describing here is not part of issue 126. The text
I have provided addresses issue 126. If you feel there is a new
issue that needs to be resolved, then submit it as a new issue.
That's the process we've been using so far.

Pat Calhoun

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, January 10, 2007 12:04 PM
> To: Pat Calhoun (pacalhou)
> Cc: Peter Nilsson J (LI/EAB); capwap
> Subject: Re: [Capwap] Proposed Resolution to Issue 126: 
> "Wrong Placefor"inagedata" state
> 
> HI,
> 
> 
> 
> Regards,
> /david t. perkins
> 
> > 2.3.1.  CAPWAP Protocol State Transitions [...]
> > CTO, Wireless Networking Business Unit Cisco Systems
> >
> >
> >
> >

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 11 Jan 2007 09:15:38 -0500

Hi David,

There are multiple issues open regarding FW download, and I think you  
may be mixing them together.

(1) We do need a way to download a firmware image at start-up when  
either the AC or the WTP determines that there is a mismatch, and  
immediately reset the WTP so that it will start using the new image.   
That is currently in the document.  Do you have specific issues with  
how this is currently documented?  If so, what are they?

(2) We also need a way to download a firmware image while the WTP is  
in a running state ("trickle download") and reboot it at a later  
time, perhaps during a scheduled service disruption.  That is not in  
the document, but can easily be added by indicating that firmware  
download and reset are valid functions to invoke (separately) in the  
running state.  This is issue #200, which is not yet addressed.

Issue #126 was opened as a placeholder for an expected proposal from  
you about changing (1) so that the firmware version was announced  
sooner in the process.  There was a little bit of (non-converging)  
discussion about what you meant, and then we waited six months for  
the proposal.  You never sent a proposal associated with this issue,  
so it is now closed.  If you do have a specific proposal about how we  
should change start-up image download, please send it to the list,  
and we'll open a new issue.  If the WG agrees with your proposed  
changes, the editors will make them.

Issue #200 was opened by me to address the fact that the current spec  
does not explicitly address (2).  I've talked to Pat, and I think we  
have a shared understanding of how to fix that.  The editors are  
going to write some text to reflect that understanding and circulate  
it to the WG.

There are also two other open issues related to image download:

Issue #231 points out an issue with error handling in the case of a  
bad checksum on the image download request.  Text has been proposed  
to the list to deal with this issue.

Issue #192 raises some issues about the structure of the image  
download requests and how errors are handled.  This is still being  
discussed, but will result in at least one change to add error handling.

If you have any other issues with image download (or anything else),  
or if you have a specific proposal for the list about how we could do  
image download (or anything else) better, please send it to the  
mailing list, and we can discuss it on the list.

If you are looking for any major changes in this area, please send  
your proposals ASAP.  As in San Diego, at the interim, we will only  
be discussing issues that have been raised and discussed on the list  
sufficiently to ensure that there is some support to make a change  
and that we have some common understanding of the issue and possible  
solutions.  This is necessary, because we do not expect to have a  
large percentage of the WG present, so it will not be the right forum  
to present new ideas to the WG -- the mailing list is.  Also, we're  
still on target to go to WGLC between the interim and the IETF  
meeting in Prague in March, so it would be good to have any major  
issues clearly on the table now.

Thanks,
Margaret

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 11 Jan 2007 08:23:44 -0800

I just realized the proposed text below was for issue 231, and not issue
126.

My apologies

Pat Calhoun

> From: Pat Calhoun (pacalhou) 
> Sent: Wednesday, January 10, 2007 9:11 AM
> To: Peter Nilsson J (LI/EAB); capwap
> "WrongPlacefor"inagedata" state
> 
> Peter,
>  
> 	Will CAPWAP define the algorithm for the checksum 
> calculation in Image Data message element?
> 	We might need to add Reslut Code in the Image Data 
> Response message.
> 	 
> 	Peter
> 
> "Wrong Place for"inagedata" state
> 	
> 	
> 	Allowing the AC to send the Image Filename message 
> element together with Initate Download works fine for me.
> 	 
> 	Peter
> 	
> 	
> 	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.
> 
> 	
> 	 Ok - the intent would be that the AC indicates to the 
> WTP that it must "update the Firmware" or "update the Boot loader"
> 	
> 
> 
> 		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
> 		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.
> 
> 	
> 	Image Data Request message to contain more than one 
> message element, and the 
> 	AC would send Image Data Request[Initiate Download, 
> Image Filename]
> 		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
> 		   Join to Configure (g):  This state 
> transition is used by the WTP and
> 		      WTP:  The WTP enters the Configure state 
> when it successfully
> 		         completes the Join operation.  If it 
> determines that its
> 		         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
> 		      AC:  This state transition occurs 
> immediately after 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
> 		         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:  The WTP enters the Image Data state 
> when it successfully
> 		         comletes DTLS session establishment, 
> and determines that its
> 		         different.  The WTP transmits the 
> Image Data Request (see
> 		         Section 9.1) message requesting that a 
> download of the AC's
> 		      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
> 		Discussion re: Issue 126 included the 
> following, based on the -01 CAPWAP
> 		draft:
> 		
> 		> 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 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).
> 		
> 		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).
> 		
> 		       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
> 		       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

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 11 Jan 2007 10:48:56 -0800 (PST)

HI,

Why is there a checksum in the image data message element, since the 
message is protected by DTLS?

Regards,
/david t. perkins

---

From: "Peter Nilsson J (LI/EAB)" <[email-masked]>
Date: Fri, 12 Jan 2007 09:31:05 +0100

Works for me

Peter 

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: den 10 januari 2007 18:11
To: Peter Nilsson J (LI/EAB); capwap
Subject: RE: [Capwap] Proposed Resolution to Issue 126: "Wrong

Peter,

4.5.24.  Image Data
[...]

4.5.31.  Result Code
[...]

9.2.  Image Data Response

Pat Calhoun

	 
	Peter

	 
	Peter

	Peter, 
	
	Inline below.
	
	Thanks,
	
	Dorothy

	
	Thanks,
	
	Dorothy

		Peter Nilsson 

				All,

		

		

		and

		

		Comments welcome,
		
		Dorothy

description
currently 
"Image
instead of

		

		
		and: