Capwap Mailing List: The design of configurable objects in the CAPWAP MIB drafts

[ff richard_fy (fy.richard]

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)