Subject: Re: [Capwap] Proposed resolution to issues 72, 73, 108, 181, and 190.

From: "Michael Montemurro" <[email-masked]>
Date: Mon, 8 Jan 2007 16:18:23 -0500

Basically, what I have done is added a configuration ACK message to
address these issues. The basic message flow would look like:

WTP --- config request  ---> AC
    <-- config response ---
    --- config ACK      --->

The WTP would transmit a configuration ACK with a result code. If the
WTP cannot apply the configuration in the configuration response
message, it would set a negative result code and include any message
elements that it could not apply to its configuration.

Cheers,

Mike

On 10/9/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
> Mike,
>
> I'm quite confused by this request. First, the WTP already sends back a
> response message when it receives the request. Why can't we simply embed the
> status code in that response message? I don't understand the need for a new
> message.
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
> ________________________________
> From: Michael Montemurro [mailto:[email-masked]]
> Sent: Saturday, September 23, 2006 11:55 AM
> To: capwap
> Subject: [Capwap] Proposed resolution to issues 72, 73, 108, 181, and 190.
>
>
> These issues all have to do with the configuration process and error handing
> of that process.
>
> I propose to resolve these comments by doing the following:
> 1) Add a add a Configuration Status Acknowledgement Frame. The WTP would
> send this frame back with a status code to indicate success or failure of
> its ability to apply the configuration.
>
> 2) The configuration update response could be modified to include any
> message elements that could not be applied by the WTP.
>
> 3) In the case of a configuration message that exceeds the MTU between the
> WTP and the AC, the CAPWAP fragmentation mechanism would be allow the
> message to be fragmented by the AC and reassembled by the WTP. I don't think
> there needs to be any updates to CAPWAP to address this issue.
>
> Cheers,
>
> Mike
_________________________________________________________________
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: Mon, 8 Jan 2007 14:11:40 -0800 (PST)

HI,

I believe this is one of the issues that we need to work out
during the interim meeting. We have had a few discussions
about how initial configuration occurs, and the problems
of the approach as described in the CAPWAP drafts.

The are several points that make initial configuration
a lot more complicated than it would at first. These
include:
1) minimizing the message size and traffic when a WTP's
    configuration has "default values"
2) defining what are "default values" (are these CAPWAP
    defaults as specified in the CAPWAP spec, or
    WTP vendor specific defaults, or something else
3) Coping with version differences and vendor specific
    configuration attributes
4) How does a WTP indicate failure, which can be
    due to:
     1) capacility limitation
     2) unsupported configuration attribute
     3) unsupported configuration attribute value
     4) semantic limitation due to the value of
        other configuration attribute value(s)
     5) failure to save the value to nonvolitile storage
     6) hardware/software failure when applying the
        configuration attribute value
5) keeping the CAPWAP operations (and state machine) from
    becoming more complex.

Because of the above, I do not support your suggestion
as is, but do support providing a mechanism to report
failure configuration changes.

Regards,
/david t. perkins

---

From: "Michael Montemurro" <[email-masked]>
Date: Mon, 8 Jan 2007 17:26:59 -0500

I am willing to work towards another proposed resolution. However, I
would expect you to have proposed text coming into the January
face-to-face meeting.

Cheers,

Mike

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 8 Jan 2007 15:21:17 -0800 (PST)

HI,

Could someone respond to whether or not a -04 draft is coming out before
the interim meeting.

Trying to
1) delta the email comments
2) delta the issue tracker comments
to drafts is not easy, since the section numbers were changed between
the -01 and -02, and it looks like between the -02 and -03 drafts.

Also, I "don't get" the configuration model as specified in the CAPWAP
spec. Also, I don't find a listings of the base or binding 
specific configuration attributes.

But I'll try to fulfil your request.

Regards,
/david t. perkins

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 8 Jan 2007 15:36:04 -0800

I'm not a particular fan of overloading the issues with a bullet list of
problems. I would like each problem to have its own issue, with clear
text on the actual issue. This allows us to track the problem one by
one, and address them individually. If the issues you listed below do
not pertain to all of the issues in the subject line, then approve the
resolution, and request a new set of problems, with more clarity on the
problems. I don't want to wait until the off-site to start discussing
complex issues.

To address your concern about default values, this has already been
taking care of.

Pat Calhoun

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Monday, January 08, 2007 2:12 PM
> To: Michael Montemurro
> Cc: Pat Calhoun (pacalhou); capwap
> Subject: Re: [Capwap] Proposed resolution to issues 72, 73, 
> 108, 181, and 190.
> 
> HI,
> 
> about how initial configuration occurs, and the problems of 
> the approach as described in the CAPWAP drafts.
> 
> The are several points that make initial configuration a lot 
> more complicated than it would at first. These
> include:
> Because of the above, I do not support your suggestion as is, 
> but do support providing a mechanism to report failure 
> configuration changes.
> 
> Regards,
> /david t. perkins
> 
> >> I'm quite confused by this request. First, the WTP already 
> sends back 
> >> a response message when it receives the request. Why can't 
> we simply 
> >> embed the status code in that response message? I don't understand 
> >> the need for a new message.
> >>
> >>
> >> Pat Calhoun
> >> CTO, Wireless Networking Business Unit Cisco Systems
> >>
> >>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 9 Jan 2007 09:08:33 -0800

Michael,

The protocol already provides this function, via the Change State Event.

Please note the following text, pulled from -03:

2.3.1.  CAPWAP Protocol State Transitions
[...]

   Configure to Run (m):  This state transition occurs when the WTP and
      AC enter their normal state of operation.

      WTP:  The WTP enters this state when it receives a successful
         Configuration Status Response message from the AC.  The WTP
         initializes the HeartBeat timer (see Section 4.5), and
         transmits the Change State Event Request message (see
         Section 8.6).

      AC:  This state transition occurs when the AC receives the Change
         State Event Request message (see Section 8.6) from the WTP.
         The AC responds with a Change State Event Response (see
         Section 8.7) message.  The AC must start the
         NeighborDeadInterval timer (see Section 4.5).

I believe the challenge here is that the text describing the State
Change Event
only discusses changes in the radio operational state. We would need to
change
the text to allow this message to also be used to confirm the recent
configuration
changes by including the Result Code message element.

Pat Calhoun

> Sent: Monday, January 08, 2007 1:18 PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap
> Basically, what I have done is added a configuration ACK 
> message to address these issues. The basic message flow would 
> look like:
> 
> The WTP would transmit a configuration ACK with a result 
> code. If the WTP cannot apply the configuration in the 
> configuration response message, it would set a negative 
> result code and include any message elements that it could 
> not apply to its configuration.
> 
> Cheers,
> 
> Mike
> 
> > embed the status code in that response message? I don't 
> understand the 
> > need for a new message.
> >
> >
> > Pat Calhoun

---

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

The plan is to have a draft published around 1/22.

Pat Calhoun

> Sent: Monday, January 08, 2007 3:21 PM
> To: Michael Montemurro
> Could someone respond to whether or not a -04 draft is coming 
> out before the interim meeting.
> 
> Trying to
> to drafts is not easy, since the section numbers were changed 
> between the -01 and -02, and it looks like between the -02 
> and -03 drafts.
> 
> Also, I "don't get" the configuration model as specified in 
> the CAPWAP spec. Also, I don't find a listings of the base or 
> binding specific configuration attributes.
> 
> >>  I believe this is one of the issues that we need to work 
> out  during 
> >> the interim meeting. We have had a few discussions  about 
> how initial 
> >> configuration occurs, and the problems  of the approach as 
> described 
> >> in the CAPWAP drafts.
> >>
> >>  The are several points that make initial configuration  a 
> lot more 
> >> complicated than it would at first. These
> >>  include:
> as is, but 
> >> do support providing a mechanism to report  failure configuration 
> >> changes.
> >>
> >>  Regards,
> >>  /david t. perkins
> >>
> >> >  Basically, what I have done is added a configuration 
> ACK message 
> >> > to  address these issues. The basic message flow would look like:
> >> > 
> >> >  The WTP would transmit a configuration ACK with a 
> result code. If 
> >> > the  WTP cannot apply the configuration in the configuration 
> >> > response  message, it would set a negative result code 
> and include 
> >> > any message  elements that it could not apply to its 
> configuration.
> >> > 
> >> >  Cheers,
> >> > 
> >> >  Mike
> >> > 
> >> > >  I'm quite confused by this request. First, the WTP 
> already sends 
> >> > > back  a  response message when it receives the 
> request. Why can't 
> >> > > we simply  embed the  status code in that response message? I 
> >> > > don't understand the need for  a new  message.
> >> > > 
> >> > > 
> >> > >  Pat Calhoun
> >> > >  These issues all have to do with the configuration 
> process and 
> >> > > error  handing  of that process.
> >> > > 
> >> > >  1) Add a add a Configuration Status Acknowledgement 
> Frame. The 
> >> > > WTP  would  send this frame back with a status code to 
> indicate 
> >> > > success or failure  of  its ability to apply the configuration.
> >> > > 
> >> > >  2) The configuration update response could be modified to 
> >> > > include any  message elements that could not be 
> applied by the WTP.
> >> > > 
> >> > >  3) In the case of a configuration message that 
> exceeds the MTU 
> >> > > between  the  WTP and the AC, the CAPWAP fragmentation 
> mechanism 
> >> > > would be allow the  message to be fragmented by the AC and 
> >> > > reassembled by the WTP. I don't  think  there needs to be any 
> >> > > updates to CAPWAP to address this issue.
> >> > > 
> >> > >  Cheers,
> >> > > 
> >> > >  Mike

---

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 9 Jan 2007 14:49:38 -0500

So given this approach, we could simply add a result code to indicate
bad configuration and the WTP could transmit it in the Change State
Event. Is that what your thinking?

Mike

On 1/9/07, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> > include any

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 9 Jan 2007 11:54:36 -0800

and added text to the Change State Event that it is also used to
confirm the WTP's configuration. The text only mentions the radio
state at this point.

Pat Calhoun

> Sent: Tuesday, January 09, 2007 11:50 AM
> So given this approach, we could simply add a result code to 
> indicate bad configuration and the WTP could transmit it in 
> the Change State Event. Is that what your thinking?
> 
> Mike
> 
> > 2.3.1.  CAPWAP Protocol State Transitions [...]
> >
> > Change Event only discusses changes in the radio 
> operational state. We 
> > would need to change the text to allow this message to also 
> be used to 
> > confirm the recent configuration changes by including the 
> Result Code 
> > message element.
> >
> > Pat Calhoun

---

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 9 Jan 2007 15:01:28 -0500

I could live with that change. Comments?

Mike

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 9 Jan 2007 13:09:26 -0800 (PST)

HI

So, on failure, a "synchronous" result is returned, and
on success an "asychronous" result is returned.
Seems like bad design to me!

In general the config model is not well specified. A config
update can specify one or more configuration attributes.
Is a configure update "all or nothing", or "partial".
What happens if it takes a "long time" to apply a config
change? Which changes are presistent and which are only
to "running config"?

Regards,
/david t. perkins

---

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 9 Jan 2007 16:24:16 -0500

Not really. It depends on how you interpret the State Change message.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 Jan 2007 06:44:31 -0800

> So, on failure, a "synchronous" result is returned, and on 
> success an "asychronous" result is returned.

Sorry, you've lost me. The state machine, and message exchanges,
are identical regardless of whether success or failure has occurred.
Could you please expand?

> change? Which changes are presistent and which are only to 
> "running config"?
ok, so I believe what you are asking for in the first question is
a timer that if it expires prior to receiving a Change State Event
causes the AC to abandon the WTP. correct? 

I believe that the second question is not relevant to the issues
being addressed. However, if you feel there is an issue, it would 
be great if you could provide more context on what exactly you
believe the problem is.

I would propose the addition of the timer and closing the issues. 
We can open a separate issue if you deem it necessary.

Thanks,

Pat Calhoun

> Sent: Tuesday, January 09, 2007 1:09 PM
> Cc: Michael Montemurro; capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 Jan 2007 08:31:29 -0800

Michael,

Here is proposed text to resolve this issue:

4.5.  CAPWAP Protocol Message Elements
[...]
   Returned Message Element                             46

4.5.31.  Result Code
[...]
   Result Code:   The following values are defined:
[...]
      10 Failure (Unable to Apply Requested Configuration - Service
         Provided Anyhow)

      11 Failure (Unable to Apply Requested Configuration - Service Not
         Provided)

4.5.32.  Returned Message Element

   The Returned Message Element is sent by the WTP within the Change
   State Event Request in order to communicate to the AC which message
   elements in the Configuration Status Response it was unable to apply
   locally.  The Returned Message Element contains a result code that is
   used to indicate the reason why the configuration could not be
   applied, and encapsulates the offending message element.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reason     |       Message Element...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reason:   The reason why the configuration in the offending message
      element could not be applied by the WTP

      1 -  Unknown Message Element

      2 -  Unsupported Message Element

      3 -  Unknown Message Element Value

      4 -  Unsupported Message Element Value

   Message Element:   The Message Element field encapsulates the message
      element sent by the AC in the Configuration Status Response
      message that caused the error.

8.7.  Change State Event Request

   The Change State Event Request message is used by the WTP for two
   main purposes:

   o  When sent by the WTP following the reception Configuration Status
      Response from the AC, the WTP uses the Change State Event to
      provide an update on the WTP radio's operational state as well as
      to confirm that the configuration provided by the AC was
      successfully applied.

   o  When sent during the Run state, the WTP uses the Change State
      Event to notify the AC of an unexpected change in the WTP's radio
      operational state.

   When an AC receives a Change State Event Request message it will
   respond with a Change State Event Response message and make any
   necessary modifications to internal WTP data structures. The AC MAY
   decide not to provide service to the WTP if it receives an error,
   based on local policy, which is done by transitioning to the
   CAPWAP Reset state.

   The Change State Event Request is sent by a WTP to acknowledge or
   report an error condition to the AC for a requested configuration
   through the Configuration Status Response.  The Change State Event
   Request includes the Result Code message element, which indicates
   whether the configuration was successfully applied.  If the WTP is
   unable to apply a specfic configuration request, it indicates the
   failure by including one or more Returned Message Element message
   elements (see Section 4.5.32).

   The following message elements MUST be present in the Change State
   Event Request message.

   o  Radio Operational State, see Section 4.5.30

   o  Result Code, see Section 4.5.31

   One or more of the following message elements MAY be present in the
   Change State Event Request message.

   o  Returned Message Element, see Section 4.5.32

Pat Calhoun

> Sent: Tuesday, January 09, 2007 12:01 PM