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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 4 Jan 2007 07:14:17 -0800

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