Subject: [Capwap] discovery interval timer question

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Wed, 4 Oct 2006 08:01:08 +0530

All,
 
Idle to Discovery transition talks about Discovery Interval timer:
 
 Idle to Discovery (a): This transition occurs once device
      initialization is complete.
 
      WTP: The WTP enters the Discovery state prior to transmitting the
         first Discovery Request message (see Section 5.1).  Upon
         entering this state, the WTP sets the DiscoveryInterval timer
         (see Section 4.5).  The WTP resets the DiscoveryCount counter
         to zero (0) (see Section 4.6).  The WTP also clears all
         information from ACs it may have received during a previous
         Discovery phase.

But DiscoveryInterval timer is described as:

4.5.1.  DiscoveryInterval
 
   The minimum time, in seconds, that a WTP MUST wait after receiving a
   Discovery Response, before initiating a DTLS handshake.
 
Should Idle to Discovery actually be based on MaxDiscoveryInterval
timer? Also, there is mention of DiscoveryInterval timer even in
transition from Discovery to Discovery.
 
4.5.6.  MaxDiscoveryInterval
 
   The maximum time allowed between sending discovery requests from the
   interface, in seconds.  Must be no less than 2 seconds and no greater
   than 180 seconds.
 
   Default: 20 seconds.
 
Thanks
Smitha

_________________________________________________________________
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, 9 Oct 2006 14:47:01 -0700

hmmm.... this seems to be a bug. First of all, why would the WTP have to
wait prior to establishing the DTLS session? Why is this simply not
automatic?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Smitha Smitha (ssmitha) 
	Sent: Tuesday, October 03, 2006 7:31 PM
	To: [email-masked]
	Subject: [Capwap] discovery interval timer question

	All,
	 
	Idle to Discovery transition talks about Discovery Interval
timer:

	      WTP: The WTP enters the Discovery state prior to
transmitting the
	         first Discovery Request message (see Section 5.1).
Upon
	         entering this state, the WTP sets the DiscoveryInterval
timer
	         (see Section 4.5).  The WTP resets the DiscoveryCount
counter
	         to zero (0) (see Section 4.6).  The WTP also clears all
	         information from ACs it may have received during a
previous
	         Discovery phase.

	4.5.1.  DiscoveryInterval
	 
	   The minimum time, in seconds, that a WTP MUST wait after
receiving a
	   Discovery Response, before initiating a DTLS handshake.
	 
	Should Idle to Discovery actually be based on
MaxDiscoveryInterval timer? Also, there is mention of DiscoveryInterval
timer even in transition from Discovery to Discovery.

	   The maximum time allowed between sending discovery requests
from the
	   interface, in seconds.  Must be no less than 2 seconds and no
greater
	   than 180 seconds.
	 
	   Default: 20 seconds.
	 
	Thanks
	Smitha

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 9 Oct 2006 19:32:27 -0400 (EDT)

Hi Pat,

>wait prior to establishing the DTLS session? Why is this simply not

I recall wondering about this during the DTLS text integration. If I recall correctly, this was adapted from the original JOIN language, and I thought maybe there was a delay introduced in case the WTP received more discovery responses.  I think the language is confusing, though, and needs work either way.

Seems like the behavior varies depending on the discovery method. For a broadcast method, it seems reasonable that a WTP should wait some reasonable period to probabalistically ensure that it has received whatever discovery responses it is going to receive before it acts. Otherwise, you could have kid-in-a-candy-store behavior (I'll take that one! No -- that one! Wait... I want THAT one!)  For a directed discover, obviously the WTP can act upon receiving a response.

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 9 Oct 2006 20:04:59 -0700

> Seems like the behavior varies depending on the discovery 
> method. For a broadcast method, it seems reasonable that a 
> WTP should wait some reasonable period to probabalistically 
> ensure that it has received whatever discovery responses it 
> is going to receive before it acts. Otherwise, you could have 
> kid-in-a-candy-store behavior (I'll take that one! No -- that 
> one! Wait... I want THAT one!)  For a directed discover, 
> obviously the WTP can act upon receiving a response.

sure, but that seems like a logical "implementation specific" condition.

Pat Calhoun

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Tue, 10 Oct 2006 16:10:17 +0530

So, MaxDiscoveryInterval is not specific to an AC, in that it is a
global timer which decides how frequently we send out Discovery
Requests. But "DiscoveryCount" talks about the maximum # of discoveries
transmitted by the WTP to an AC.

Also, the spec says:
" A WTP MUST send no more than the maximum of
   MaxDiscoveries Discovery Request messages, waiting for a random delay
   less than MaxDiscoveryInterval between each successive message."

Is it OK to assume that:
1. DiscoveryInterval timer is the delay between successive discovery
requests sent to the same AC?
2. DiscoveryCount will be obtained based on DiscoveryInterval timer
(when the same expires).
3. MaxDiscoveryInterval - why is this needed?
4. Transition from Discovery to Sulking state occurs when DiscoveryCount
reaches the max limit - for a particular AC?

However, this does not cover the case of being able to "select" from a
set of discovery responses obtained at the WTP.

Thanks
Smitha

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Tuesday, October 10, 2006 8:35 AM
To: Scott G. Kelly; Smitha Smitha (ssmitha); [email-masked]
Subject: RE: [Capwap] discovery interval timer question

> Seems like the behavior varies depending on the discovery method. For 
> a broadcast method, it seems reasonable that a WTP should wait some 
> reasonable period to probabalistically ensure that it has received 
> whatever discovery responses it is going to receive before it acts. 
> Otherwise, you could have kid-in-a-candy-store behavior (I'll take 
> that one! No -- that one! Wait... I want THAT one!)  For a directed 
> discover, obviously the WTP can act upon receiving a response.

Pat Calhoun

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 12 Oct 2006 16:57:17 -0400 (EDT)

Sorry, I meant to reply to Pat, but I was distracted. I've added some comments inline below...

> From: Smitha Smitha (ssmitha) [mailto:[email-masked]] 
> Sent: Tuesday, October 10, 2006 3:40 AM
> To: Pat Calhoun (pacalhou); Scott G. Kelly; [email-masked]
> Subject: Re: [Capwap] discovery interval timer question
> 

Yes, but if you ammend your definition number 1, I think we're covered:

The definition of DiscoverInterval timer varies depending on the discovery type. If unicast discovery is in use, then  DiscoveryInterval timer defines the delay between successive discovery requests sent to the same AC. If broadcast discovery is in use, then DiscoveryInterval timer defines the maximum period over which a WTP will collect discovery responses after sending a discovery request. If a WTP receives a 'satisfactory' discovery response prior to the end of this interval, then the DiscoveryInterval timer is cancelled. Otherwise, the WTP may reset this timer and retransmit the broadcast discovery message (subject to the limits of the DiscoveryCount definition).

Scott

> method. For

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Mon, 16 Oct 2006 10:43:25 +0530

Scott,

Thanks for the clarification on discovery interval timer. Do we really
need the MaxDiscoveryInterval timer now, will the use of this be
clarified?

Thanks
Smitha

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Friday, October 13, 2006 2:27 AM
To: capwap
Subject: Re: [Capwap] discovery interval timer question

Sorry, I meant to reply to Pat, but I was distracted. I've added some
comments inline below...

> Requests. But "DiscoveryCount" talks about the maximum # of 
> discoveries transmitted by the WTP to an AC.
> 
> Also, the spec says:
> 4. Transition from Discovery to Sulking state occurs when 
> DiscoveryCount reaches the max limit - for a particular AC?
> 

The definition of DiscoverInterval timer varies depending on the
discovery type. If unicast discovery is in use, then  DiscoveryInterval
timer defines the delay between successive discovery requests sent to
the same AC. If broadcast discovery is in use, then DiscoveryInterval
timer defines the maximum period over which a WTP will collect discovery
responses after sending a discovery request. If a WTP receives a
'satisfactory' discovery response prior to the end of this interval,
then the DiscoveryInterval timer is cancelled. Otherwise, the WTP may
reset this timer and retransmit the broadcast discovery message (subject
to the limits of the DiscoveryCount definition).

Scott

> CTO, Wireless Networking Business Unit Cisco Systems

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 16 Oct 2006 11:00:42 -0700

I agree with your interpretation (and Scott's clarification).

Pat Calhoun

> Sent: Thursday, October 12, 2006 1:57 PM
> To: capwap
> The definition of DiscoverInterval timer varies depending on 
> the discovery type. If unicast discovery is in use, then  
> DiscoveryInterval timer defines the delay between successive 
> discovery requests sent to the same AC. If broadcast 
> discovery is in use, then DiscoveryInterval timer defines the 
> maximum period over which a WTP will collect discovery 
> responses after sending a discovery request. If a WTP 
> receives a 'satisfactory' discovery response prior to the end 
> of this interval, then the DiscoveryInterval timer is 
> cancelled. Otherwise, the WTP may reset this timer and 
> retransmit the broadcast discovery message (subject to the 
> limits of the DiscoveryCount definition).
> 
> Scott
> 
> 
> 
> > 
> > Thanks
> > Smitha
> >