RE: Help getting CAPWAP MIB doc plan started

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Thanks for the review, and the questions.

I believe that most of your questions have already been
answered by the CAPWAP WG. That is, the WG decided to use
a specialized protocol for communication between ACs and
WTPs for configuration, control, and stats and status
gathering, plus potentially tunnelling of user data.
In the candidate protocol evaluation, at
least one the submissions was a proprietary wrapping
of SNMP PDUs. It was not selected.
I agree with the approach selected by the WG.

Note that the selected base document describes a
subset of the protocol used by Airespace (now a
part of cisco). It is quite similar in function with
the protocol used by other vendors that have sold
devices that are deployed. That is, the base protocol 
is not a paper protocol, but one that has seen deployment.

I'll answer your questions inline, with my comments
in <dtp></dtp> (because XML is where it's at)!


On Tue, 31 Jan 2006, David B Harrington wrote:
> Hi,
> 
> I'll try (but fail) to be terse ;-)
> 
> Without delving into the details of CAPWAP, a few things come to mind.
> 
> 1) I feel it would be useful to keep statistics on the CAPWAP
> messages, but cannot provide a justification.
<dtp>This is one of those things that goes back to a principle
of management. If one were to monitor the counter of
CAPWAP messages sent and received, how would you know it
was OK or not OK. And if it was not OK, how would you
know what to change to make it OK again?
There are some counters that would be better to keep,
such as how many messages for each association were 
retried, or how many associations were terminated due
to timeout. But these are details for the WG to
work out. </dtp>

> 2) with wireless devices, it can be important to understand the
> overlap of coverage, so WTPs can adjust their power output to minimize
> interference with other WTPs. Will the MIB modules reflect the STAs
> associated with each WTP (so duplicates can be detected), and the
> power levels of each WTP, and include SNMP knobs to adjust the power
> levels (and possibly other characteristics) of the WTPs to minimize
> duplicated associations between WTPs? 
<dtp>It's in my proposal to include a table that shows
which STAs are associated with each radio at each WTP. 
And one of the attributes of the association is
"received signal strength indication". And in the table
of radios for WTPs, there will be the current power level
of the radio (plus other basic status and config). However,
in first round of this MIB module, I do not expect that
it will be usable for configuration. Whether or not configuration
is included depends on the WG and the AD.
Note: in general, the AC should be dynamically adjusting
the power level of the WTPs due to changing conditions.
About the only thing you may want to do is set the max
power level that can be set at a specific WTP (this is
because you may have agreements with neighbors that you
will not use certain channels (or you must use a certain
channel) and that you will not use power above an agreed
limit). The way that the AC coordernates WTP operation
is a major difference between a CAPWAP system and 
a collection of stand-alone APs that has a chatty
management app talking to them.</dtp>

> 3) rogue access points are a notable problem in wireless networks. To
> detect them, one would need to have some understanding of the WTPs
> visible to the STAs. Will your modeling include any gathering of WTP
> visibility from the STAs, presumably passed via the associated WTP(s)
> to the AC?
<dtp>First, so far, I don't believe that rogue detection is
part the the requirements. Certainly the base protocol does
not support it. Whether or not it is added will be up to
the WG. (I personally feel that it is a requirement. However,
rogue detection is a property of the WTPs and not STAs. Some
vendors make a difference between monitoring only WTPs and
WTPs that can monitor and provide service. The monitoring only
WTPs may use a different type of hardware (or may use the same
hardware) as used for providing associations with wireless
clients.)<dtp> 

> An alternative to gathering WTP visibility to the STAs is to have the
> WTPs switch to STA mode to detect other WTPs within its range. Will
> your modeling include the possibility of gathering WTP visibility from
> a dual-mode WTP/STA?
<dtp>The WTPs hear all on the channel that they are using.
You are getting deep into design and far away from modelling.</dtp>

> 4) I am of the impression, but I'd really need to check, that WTPs can
> be used as relays to other WTPs. With the CAPWAP approach, can an AC
> ever support nested/relayed WTPs? If so, how will you model that?
<dtp>Maybe you are talking about mesh networks. That is described
in RFC 4118. That is outside the scope of CAPWAP. There are also
radio repeaters. I believe that these are transparent to
WTP and AC operation, but then I'm not a 802.11 hardware guy.</dtp>

> Given the need to gather stats from multiple levels of the wireless
> hierarchy, I can see a real problem of large tables emerging trying to
> do all the SNMP MIBs for three (or more) levels at the AC level. This
> could lead to a situation where it is decided to not bother developing
> manageability for WTPs and STAs because the only-at-the-AC design is
> flawed, or to develop a new management protocol as part of CAPWAP that
> basically duplicates the functionality that would be provided by
> having SNMP in the WTPs and STAs if a more "normal" approach to SNMP
> modeling was used.
<dtp>There is already an 802.11 MIB module published by IEEE. You can
get it from the IEEE WEB site. The module is IEEE802dot11-MIB.
It is used for management of 802.11 interfaces. These interfaces
are those on WTPs and the wireless interfaces on devices that
associate with the WTPs. The whole question about the modelling
was so that I could resuse the unmodified version of the 802.11 MIB
and not have create a new version with an extra index for the
the WTP ID.</dtp>

> Won't you have somewhat similar problems of scalability using a CLI or
> web-based mgmt if the tables can grow as large as you expect?
<dtp>The CLIs and WEB interfaces in existing products already
work. Likewise the CLIs and WEB interfaces for devices with
a large number of interfaces currently work.</dtp>

> Will the AC use Netconf (the expected IETF standard for configuration
> maagement) to configure the WTPs? If not, why not? ;-)
<dtp>This is outside the scope of the WG. However, there is
no reason why this cannot be done. Note that I know of at
least one current vendor that uses a pre-NETCONF management
interface to the AC.</dtp>

Regards,
/david t. perkins