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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 4 Jan 2007 15:53:36 -0800

Created issue 231 to track this.
 
We need to define how the checksum is created (propose the same
algorithm as iphdr checksum). Further, the Image Download Response does
not include the Result Code to cause a retransmission of a previous
Image Data Request when the checksum is invalid.

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 

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

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