Subject: [Capwap] The design of configurable objects in the CAPWAP MIB drafts

From: "ff richard_fy" <[email-masked]>
Date: Fri, 12 Oct 2007 22:28:15 +0800

Besides my introduction of 01 MIB draft, here, I hope to discuss issue about
"monitoring and configurable objects".
As a common way, for most IETF standard MIB, they will usually provide
"monitoring objects" (read only objects).
Few configurable objects are there. The initial idea for CAPWAP MIB drafts
is same.
But when I thought CAPWAP is to provide a standard protocol for
configuration and management of WTP, some idea come to my mind.
The configuration functions are important to protocol, and MIB may also
provide some configuration ability.
But too many configurable objects in the MIB will also bring too many
restriction to wireless vendors' implement.
So I think MIB drafts should only provide configurable objects which is
exactly required by the way of reusing 802.11 MIB.
Besides these configurable objects, no any other configurable objects should
be provided by MIB draft.

Follow this idea, the MIB draft will provide the following configurable
objects (tables)
1)      A table to configure the mapping relationship between radio id and
"WTP virtual interface"
In the CAPWAP protocol, radio id in protocol message is a way to identify a
radio on a WTP.
As per my last mail, "WTP virtual interface" is way to virtually identify
PHY radio, and provide a way to reuse 802.11 MIB.
To make CAPWAP and 802.11 standards work together, draft will provide a way
(mib table) to configure their relationship.
2)      To configure data forward and tunnel mode of a specific WLAN
It is an important feature of FIT AP.
3)      To configure multiple BSS's relationship with a radio (virtual AP)
Current IEEE MIB did not support virtual AP. The MIB table is to provide a
way.
I wish all vendors could use these MIB table as a standard way, and provide
a way to reuse IEEE MIB standard.
Other configuration just let vendors do it by their way.

If configurable objects are not used, another way is to provide some tables
to indicate mapping relationship or configuration in the 1 ) , 2) and 3).
The difference is to only provide read only objects. The advantage is to
give more space to vendors implement.
I thought the disadvantage is: The IEEE MIB already provides lots of
configurable objects for configuration function,
and it is nature to provide some configurable objects in the CAPWAP MIB
drafts to help vendors to reuse IEEE 802.11 MIB in a consistent way.
Otherwise, I am afraid it will make compatible become difficult.

In summary, there are two alternative way for CAPWAP MIB design
1)      To provide some configurable objects, but these objects are only one
which will help WG to reuse IEEE 802.11 MIB.
2)      Only provide some monitoring object, read only objects. The
configurable objects lets vendor decide.
I thought it is a important topic for MIB design, Kindly give your comment
for this issue.

Regards

Richard (Shi yang)
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap