Subject: Re: [Capwap] Wrong place for "Image data" state

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 2 Jun 2006 10:56:33 -0700 (GMT-07:00)

Hi David,

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

Scott

Scott

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

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

---

From: "Michael Montemurro" <[email-masked]>
Date: Sat, 3 Jun 2006 13:46:53 -0400

Scott,

At the end of your reply, you mentioned that there were missing details
here. Could you either enumerate the missing details or provide additional
text to address them. I'll incorporate the changes into version -02

Cheers,

Mike

On 6/2/06, Scott G. Kelly <[email-masked]> wrote:
> 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.
>

---

From: Scott G Kelly <[email-masked]>
Date: Sat, 03 Jun 2006 11:00:14 -0700

Hi Mike,

Michael Montemurro wrote:
> here. Could you either enumerate the missing details or provide 
> additional text to address them. I'll incorporate the changes into 
> version -02
>  
> Cheers,
>  
> Mike

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

Scott

> 
>  
> On 6/2/06, *Scott G. Kelly* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi David,
> 
>     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.
> 
>     <http://lists.frascone.com/pipermail/capwap>
> 
>

---

From: "Michael Montemurro" <[email-masked]>
Date: Sat, 3 Jun 2006 14:07:49 -0400

In any case, I've created issue 126 to track this.

Mike

---

From: "Michael Montemurro" <[email-masked]>
Date: Fri, 16 Jun 2006 22:36:29 -0400

David,

Were you going to propose text to address this issue?

Thanks,

Mike

On 6/3/06, Michael Montemurro <[email-masked]> wrote:
> > > <mailto:[email-masked] >> wrote:
> > >
> > >     Hi David,
> > >
> > >     I know there are a few missing details here, but does this address
> >
> > >     your concerns in general?
> > >
> > >     Scott
> > >
> > >
> > >     Scott
> > >