Capwap Mailing List: Insufficient description of WTPs during discovery

[Bob O'Hara (boohara) (boohara]

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