Subject: [Capwap] Proposed Resolution for Issue 58 - Need to rename Config Request and Config Update Request

From: "Dorothy Stanley" <[email-masked]>
Date: Mon, 10 Apr 2006 10:51:56 -0700

All,

Issue 58 currently has the following discussion in the issues list:

>
> Page 104, Section 11.8.1. The description for Config-Request
> describes a message sent from the AC to the WTP. In Section
> 7.2, the config request is sent from the AP to the WTP. I
> would prefer the mechanism described in 11.8.1.
> 40.	

There are two types of configuration messages, one that comes from
the WTP to the AC, and is used for the WTP to update the AC with its
config at boot time. The second allows the AC to push down a new
config to the WTP, and this can occur at run time. The former is
called the Configure Request, while the latter is called the Configuration
update Request. That said, I think we should come up with a different
set of names to differentiate them better.

In the Configure State, we currently have:
Configure Request - WTP sends AC its boot-time config
Configure Response - AC overrides the current WTP boot-time config

In the Run state, we currently have
Configure Update Request - AC sends WTP new config parameters
Configure Update Response - WTP acknowledges the Configure Update Request,
includes result code
IEEE 802.11 WLAN Config Request

Recommended resolution: Accept, make the following changes:

In the Configure State, rename to
Configuration Status - WTP sends AC its boot-time config
Configuration Status Response - AC overrides the current WTP boot-time
config

In the Run state,  - keep
Configure Update Request - AC sends WTP new config parameters
Configure Update Response - WTP acknowledges the Configure Update Request,
includes result code, and in
IEEE 802.11 WLAN Config Request, update the text in 11.8.1  to reference
usage after Configure Update Request

Comments please.

Thanks,

Dorothy
_________________________________________________________________
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: Tue, 11 Apr 2006 22:36:32 -0700 (PDT)

HI,

I believe that the current config model is broken due to the
following:
  1) Config changes can fail (even when they are "not suppose to").
     This may be due to
       a) resource deletion
       b) semantic constraints
       c) hardware failures
       d) software failures
       e) lack of authorization
     In the "configure request/response" (sections 7.2/7.3) , the
     "response" message specifies configuration settings. As
     described, there is no mechanism for the WTP to communicate
     to the AC that some (or part) of the config sent by the AC
     to WTP failed. Thus, I suggest that the response contain
     no configuration.
  2) I'm not sure that all of the configuration info can fit
     into one CAPWAP control message. However, a WTP needs to
     be able to indicate to a AC the "classes" of config info
     that it supports. SNMP uses the GETNEXT operation to
     iterate through both all classes and instances of
     management info (which includes config info). I suggest
     for CAPWAP that a WTP specify in the "configure
     request" the classes of configuration info and then
     allow an AC to use one or more "Update config request"
     messages to change the WTP config.
  3) When an AC changes the WTP config with an "Update config
     request", the request can fail. The response message needs
     to indicate which config message element(s) had an error
     and what was the error. Currently, this is not the case.
     (The error code in the result, as currently defined 
     makes no sense to me!) Also, I didn't see if a config
     request was "all or nothing". That is, do the OK
     config values get applied and the error one not,
     or none get applied on any failure.
  4) There are a lot of stange (too me) and not well defined
     config elements. I believe that all need to be reviewed,
     but this is really a separate issue.
  5) A get config operation is needed that specifies at
     least a class of configuration info, and possibly
     additionally the instance of config info. (Again,
     this is because not all config info will be able to
     fit in a single CAPWAP message.)
  6) I've ignored what should be done when an WTP has
     config info that is not supported by an AC, or
     when an AC tries to modify config info (class or
     specific values) that is not supported by the WTP.
     (CAPWAP is suppose to support WTPs and ACs from
     different vendors, and, thus, there can be no
     "tight version synchonization" as found in current
     products.

> usage after Configure Update Request
Regards,
/david t. perkins

---

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 25 Apr 2006 13:22:42 -0700

David,

Iissue, # 108 "Configuration Failure Processing" has been opened to track
the
issues that you have raised.

There have been no objections to the proposed configuration message name
changes, so
I'll plan to incorporate those into -01.

Thanks,

Dorothy