Subject: [Capwap] Problems with setting initial config

From: "David T. Perkins" <[email-masked]>
Date: Fri, 3 Feb 2006 17:23:52 -0800 (PST)

HI,

In the state machine (figure 2 in LWAPP-02), the
WTP in state "Join-Confirm" has set up a control
channel and sends a "Configure Request" to
transfer to state "Configure" (as described
by label "2"). The "Configure Request" (described
in section 7.2) contains message elements that
describe the state and configuration of the WTP,
plus a little bit of status and statistics.
On receiving the "Configure Request" message,
an AC responds with a "Configure Response"
message (described in section 7.3).
The "Configure Response" message may contain
overrides of the configuration message
elements that may be present in the
the "Configuration Request" message.

My concern is that a "Configuration Response"
message tells the WTP to "change config" and
the WTP may not be able to change the config
to the specified values, and there is NO WAY
for the WTP to tell the AC that the "config
change" failed, and why it failed. The AC
would implictly know that the "config change"
failed because the WTP is suppose to
transition to the "Run" state and send
a "Change State Event Request" message.
When the AC does not get this within
the expected time interval, I'm guessing
it could figure out what went wrong.
The message and state descriptions don't
appear to support a failure of the
"Configuration Response" message.

(Note: on success the WTP sends a
"State Change Event Request" and
transitions "Run" state. The AC
will continue configuring the WTP
(if needed) with "Configuration
Update Request" messages. On success
the message flow looks like:

 | in Configure state
WTP  -----Configuration Request------> AC
WTP  <------Configure Response-------- AC
WTP  ---Change State Event Request---> AC
 | to Run state
 v
WTP  <--Change State Event Response--- AC
WTP  <--Configuration Update Request-- AC --| as many as needed
WTP  --Configuration Update Reponse--> AC --| 
...)

I believe that the message contents
and the causes of the state transitions
should be changed to the following:

In the "configure" state, the WTP
should send a "Configuration Request"
message (as currently) described.
The AC should respond with a new
version of the "Configuration Response"
message, which contains no configuration
message elements. On receiving the
"Configuration Response" message,
the WTP stays in the "Configure"
state until it receives a "Configuration
Update Request" that contains a
message element to put it in the
run state. Thus, the message flow
would look like:
 | in Configure state
WTP  -----Configuration Request------> AC
WTP  <------Configure Response-------- AC
WTP  <--Configuration Update Request-- AC --| as many as needed
WTP  --Configuration Update Reponse--> AC --| with last telling
                                              WTP to go to Run
                                              state  
WTP  ---Change State Event Request---> AC
 | to Run state
 v
WTP  <--Change State Event Response--- AC

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: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 6 Feb 2006 15:00:36 -0800

I've created tracker entry 73 for this issue.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Friday, February 03, 2006 5:24 PM
> To: [email-masked]
> Subject: [Capwap] Problems with setting initial config
> 
> HI,
> 
> In the state machine (figure 2 in LWAPP-02), the WTP in state 
> "Join-Confirm" has set up a control channel and sends a 
> "Configure Request" to transfer to state "Configure" (as 
> described by label "2"). The "Configure Request" (described 
> in section 7.2) contains message elements that describe the 
> state and configuration of the WTP, plus a little bit of 
> status and statistics.
> On receiving the "Configure Request" message, an AC responds 
> with a "Configure Response"
> The "Configure Response" message may contain overrides of the 
> configuration message elements that may be present in the the 
> "Configuration Request" message.
> 
> message tells the WTP to "change config" and the WTP may not 
> be able to change the config to the specified values, and 
> there is NO WAY for the WTP to tell the AC that the "config 
> change" failed, and why it failed. The AC would implictly 
> know that the "config change"
> the expected time interval, I'm guessing it could figure out 
> what went wrong.
> The message and state descriptions don't appear to support a 
> failure of the "Configuration Response" message.
> 
> WTP  -----Configuration Request------> AC WTP  
> <------Configure Response-------- AC WTP  ---Change State 
> Event Request---> AC  | to Run state  v WTP  <--Change State 
> Event Response--- AC WTP  <--Configuration Update Request-- 
> AC --| as many as needed WTP  --Configuration Update Reponse--> AC --|
> ...)
> 
> message, which contains no configuration message elements. On 
> receiving the "Configuration Response" message, the WTP stays 
> in the "Configure"
> state until it receives a "Configuration Update Request" that 
> contains a message element to put it in the run state. Thus, 
> the message flow would look like:
>  | in Configure state
> WTP  -----Configuration Request------> AC WTP  
> <------Configure Response-------- AC WTP  <--Configuration 
> Update Request-- AC --| as many as needed WTP  
> --Configuration Update Reponse--> AC --| with last telling
>                                               WTP to go to Run
>                                               state WTP  
> ---Change State Event Request---> AC  | to Run state  v WTP  
> <--Change State Event Response--- AC
> 
> Regards,
> /david t. perkins
>