Subject: Re: [Capwap] Proposed Resolution Issue 219 - Insufficientdescriptionof WTPs during discovery

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

I spoke to Dorothy today, and now agree with her proposed resolution.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Pat Calhoun (pacalhou) 
> Sent: Thursday, January 04, 2007 7:14 AM
> To: Dorothy Stanley; capwap
> Subject: Re: [Capwap] Proposed Resolution Issue 219 - 
> Insufficientdescriptionof WTPs during discovery
> 
> I'm a little uncomfortable with having the AC include the WTP 
> Radio Information message element because it contains radio 
> specific info (e.g., 802.11a, 802.11n), which the AC clearly 
> does not support. I wonder if instead we could create a 
> separate message element, which could be common if desired, 
> called the AC Supported Binding message element. 
>  
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
> 
> ________________________________
> 
> 	From: Dorothy Stanley [mailto:[email-masked]] 
> 	Sent: Tuesday, December 19, 2006 2:32 PM
> 	To: capwap
> 	Subject: [Capwap] Proposed Resolution Issue 219 - 
> Insufficient descriptionof WTPs during discovery
> 	
> 	
> 	All,
> 	
> 	Issue 219 is copied below; to summarize:
> 	
> 	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.
> 	
> 
> 	Based on changes made in
> draft-ietf-capwap-protocol-binding-ieee80211-00, to require
> 	inclusion of the IEEE 802.11 WTP Radio Information 
> Element in the Discovery Request, Primary
> 	Discovery Request and Join Request, and in the 
> draft-ietf-capwap-protocol-specification-03, to require that
> 	each binding specification provide a WTP Radio 
> Information element to be included in the
> 	Discovery Request message, there appears to be 
> sufficient information
> 	provided from the WTP to the AC for the AC to determine 
> the radio types supported by the WTP.
> 	
> 	Going in the other direction, today there is no 
> mechanism for the AC to communicate the wireless protocols 
> that it supports to the
> 	WTP.
> 	
> 	Suggested resolution: Require the AC to include the 
> binding specific WTP Radio Information elements
> 	that it supports in the Discovery Response, Primary 
> Discovery Response and Join Response messages.
> 	The binding specific WTP Radio Information elements 
> included must be selected from the set of 
> 	WTP Radio Information elements that the AC
> 	received from the WTP in the Discovery Request, Primary 
> Discovery Request or Join Request message. 
> 	
> 	Comments welcome,
> 	
> 	Dorothy
> 	
> 	
> 	
> --------------------------------------------------------------
> ----------
> ---------------
> 	Issue 219
> 	
> 	
> 	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.
> 
> _________________________________________________________________
> 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