Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages

From: "Saravanan Govindan" <[email-masked]>
Date: Fri, 21 Apr 2006 15:53:16 +0800

Hi Scott,

I think David's note does address the issue on hand. 

To formalize; 

The exchange of control messages between a WTP and AC implicitly
indicates that the WTP is operational. For the purpose of protocol
simplicity, I suggest that we focus on statistics messages alone for
this purpose, reason being that statistics are periodically exchanged. 

My concern is that by using "any" control message to indicate keepalive
(Echo), the AC processing will be complicated. This is because the AC
will need to process each control message for both its own value (e.g.
Configure Request) and also keepalive value. 

So I suggest keeping it simple - arrival of statistics message from WTP
means WTP is alive. 

Saravanan

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Wednesday, April 19, 2006 1:51 AM
To: capwap
Subject: RE: [Capwap] Proposed Resolution to Issue 45
-Issueoncombiningmessages

Just trying to close the loop: I think David's point (i.e. that echoes
should only be sent in the absence of other control traffic) is dead on,
and that this effectively closes the question as to whether echoes and
stats should be combined in the same messages.

Does anyone disagree?

Scott

_________________________________________________________________
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

---

From: Scott G Kelly <[email-masked]>
Date: Fri, 21 Apr 2006 05:52:12 -0700

Hi Saravanan,

> Configure Request) and also keepalive value. 

Of course, complexity is a function of many factors, but there is a 
straightforward way to implement an echo trigger with a flag and timer: 
when you receive a control message, unconditionally raise the flag. 
Periodically (according to your keepalive interval timer) check the 
flag; If it's up, put it down, else send a keepalive. There are more 
complicated ways to implement, but this works just fine.

On the AC this can easily be implemented by having the fastpath raise 
the flag, and having the cp lower it and/or do whatever it is your AC 
does if a WTP doesn't report in a given echo interval (which may be 
nothing). Pretty basic stuff.

On the WTP, implementation is similar, except that if the flag is down, 
you send the keepalive. Again, very simple and basic.

> So I suggest keeping it simple - arrival of statistics message from WTP

Certainly, a statistics message qualifies as a control message, so I 
have no issues with this statement when taken alone. I'm concerned with 
the earlier suggestion that the echo req/reply message be discarded and 
replaced by the statistics message.

In some cases, the keepalive interval must be *very* brief in order to 
facilitate rapid link loss detection and recovery. I know of one vendor 
who routinely uses a one second interval, and it's conceivable that in 
some scenarios one might choose to use even less.

And keep in mind that WTP and AC requirements are typically asymmetric 
in this regard: the WTP needs to react quickly (maybe try to find 
another AC), whereas the AC simply needs to somehow report the event. 
While in some cases reporting might be considered urgent, this is not 
the typical (or average) case.

The granularity requirements for reporting are typically much coarser 
than those of recovery. That is, the AC may, at it's option, only check 
every 10,20,30,... seconds for WTP liveness, and it may very well do 
that via the stats message, rather than the echo, since this allows echo 
processing to remain wholly in the AC fastpath.

But say we eliminate the echo: what happens when, say, 500 WTPs send 
stats potentially every second or less?

I think we still need the echo req/rsp.

Scott