Subject: [Capwap] Proposed Resolution Issue 219 - Insufficient description of WTPs during discovery

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 19 Dec 2006 14:32:10 -0800

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