Subject: Re: [Capwap] Insufficient description of WTPs during discovery

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 12 Sep 2006 11:16:35 -0700

Created issue 219.

Overall, I agree with the concern that the WTP has no way to communicate
its complete capabilities.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Bob O'Hara (boohara) 
> Sent: Friday, September 08, 2006 2:00 PM
> To: [email-masked]
> Subject: [Capwap] Insufficient description of WTPs during discovery
> 
> Sorry for the long email, but I think this issue requires 
> some background discussion, as well as the proposal to 
> address the issue I am raising.
> 
> In the Discovery Request there is a WTP Descriptor to provide 
> the AC with information about the WTP.  This descriptor 
> provides insufficient information to the AC, if the type of 
> WTP is not know in advance.  If the WTP is not supporting 
> 802.11, this descriptor does not provide enough information 
> to the AC for it to make that determination and there is 
> insufficient space in the WTP Radio Information element to 
> make up for this lack.
> 
> If we are to produce a protocol that is able to support 
> several different types of existing wireless protocols, there 
> needs to be a clearly articulated way to describe the 
> protocols supported on the WTP, during the discovery process. 
>  It is quite possible that an AC will not support all 
> wireless protocols, as CAPWAP is applied to these other 
> protocols in the future.  The WTP needs to be able to clearly 
> specify what wireless protocol(s) it supports to the AC in 
> the Discovery Request and the AC needs to be able to indicate 
> to the WTP that it does, or does not, support the specified protocols.
> 
> This could be done in several ways.  I propose that the WTP 
> Radio Information element be extended to include a 16-bit 
> protocol ID field that contains a single value from an 
> enumeration (probably eventually managed by IANA) of the 
> protocols for which a binding document has been published by 
> the IETF.  Because it is conceivable that a WTP might support 
> more than one wireless protocol (say 802.16 and 802.11), I 
> propose that the protocol ID field be repeated in the 
> descriptor, with a count field preceding it, as often as is 
> needed to list all the protocols in the WTP.
> 
> I also propose that the protocol ID field be added to the WTP 
> Radio Information element and that this element be repeated 
> in the Discovery Request as needed to provide information 
> about all the radios for each protocol in the WTP.
> 
> Finally, I propose that the Discovery Response message 
> include a new message element, the Supported Protocols 
> element, to indicate to the WTP which of the WTP's wireless 
> protocols are supported by the AC.  This information can be 
> used by the WTP to determine the AC to which it will 
> subsequently send the Join Request.  The Supported Protocols 
> message element will include the list of protocol ID 
> supported by the AC.  
> 
> This Supported Protocols element could be constructed by the 
> AC in two different ways.  One way would be to construct the 
> list statically, at compile time, and always return this 
> entire list.  Constructed in this fashion, the list would 
> always have at least one entry.  The WTP would then scan this 
> list on receipt and determine if one or more of the protocols 
> for which it needs support are present.  
> 
> An alternate way to construct this element would be for the 
> AC to put only those protocols indicated by the WTP in the 
> Discovery Request for which the AC provides support into the 
> list.  Constructed in this fashion, the list might be empty, 
> if there are not matching protocols shared between the AC and 
> WTP.  The WTP would still scan the list on receipt to 
> determine if one or more protocols for which it needs support 
> are present in the list.
> 
> Regardless of how the AC constructs the list of supported 
> protocols, the WTP still makes the decision as to which AC it 
> will join.  In the Join Request, the WTP MUST send only those 
> protocols  in the WTP descriptor that have been indicated to 
> be supported by the AC to which the Join Request is sent.  In 
> this way, a WTP that supports multiple wireless protocols 
> might be supported by more than one AC.
> 
>  -Bob
> 
> Bob O'Hara
> Cisco Systems - WNBU
> 
> Phone:  +1 408 853 5513
> Mobile: +1 408 218 4025
>  
> _________________________________________________________________
> 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: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Sep 2006 16:45:06 -0700

State Machine (section 2.3.1), state transition o, discusses how the
connection is terminated. This can done done through a timeout, or an
explicit disconnect. The control protocol defines an explicit req/resp
scheme, which ensures that the connection is tested bi-directionally.
This is defined in section 4.3.1.

Timers are defined in section 4.5 and 4.6. As the e-mail with proposed
text I sent last week also shows, we've stepped up this section
sigificantly.

When the WTP comes up, it decides which AC to connect to, defined in
section 3.2, which is communicated to the AC through 
the Discovery Type message element (setion 4.4.18). The AC can also
configure Acs, and associated priorities, on the WTP through the "AC
Name with Index" message element (section 4.4.5). Finally, when the WTP
has a prioritized order of ACs configured, but its primary AC goes down,
it connects to an alternate. When connected, the WTP uses the Primary
Discovery Request (section 5.3) to detect the presence of the primary.
The WTP Fallback (section 4.4.34) defines the WTP's behavior when the
primary AC goes back online.

Pat Calhoun

> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, September 13, 2006 3:34 PM
> To: Pat Calhoun (pacalhou)
> Cc: Nelson, David; [email-masked]
> Subject: RE: [Capwap] Insufficient description of WTPs during 
> discovery
> 
> HI,
> 
> Well, why don't you provide a timing diagram with references 
> to section numbers in the spec to show your point.
> 
> On Wed, 13 Sep 2006, Pat Calhoun (pacalhou) wrote:
> 
> > > At time t(x) in the past, an WTP established a session with an AC 
> > > and transitioned to the run state. Due to a short term network 
> > > problem, the session between the WTP and AC is lost (terminated). 
> > > The CAPWAP-02 does not factor this history into the discovery 
> > > process.
> > 
> > Actually, the protocol supports this event quite well. The protocol 
> > makes all of the tools available, including a very 
> comprehensive state 
> > machine.
> > 
> > > This results in an increase in latency of the WTP reconnecting to 
> > > the AC, and the possibility of the WTP connecting to a 
> different AC, 
> > > plus the WTP and AC leaking information.
> > 
> > How the WTP decides to reconnect is an implementation issue. We are 
> > not here to define the failover algorithms. The protocol 
> provides the 
> > tools, vendors are the crafters.
> > 
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> Regards,
> /david t. perkins
>