1. ARC Recommendation: MIB Attribute Types & Usage
Mar 2009
doc.: IEEE /1455r0
ARC Recommendation: MIB Attribute Types & Usage
Date:
Authors:
David Bagby, Calypso Ventures, Inc.

2. MIB usage…

3. MIB Exercise Motivation
MIB attributes are used for multiple purposes in the 2007 document, not all of which are consistent with the purpose of the MIB.
MIB syntax is used to define “local” variables
…and these are in the same section as true MIB variables
(even though they are not exposed MIB variables).
This causes confusion re functionality
ARC SC was asked to
Survey current usage of MIB variables,
Recommend a practice for categorization and use of MIB variables.

4. MIB background MIB is Management Information Base
Purpose is to manage STAs and entities within STAs to allow proper and useful interoperation in a wireless network
Such management is provided by interaction between entities to provide status and exert control
This is management interaction, not functional interaction provided by primitives.
MIB attributes (a.k.a. “objects” or “variables”) provide an implicit interface between entities through read (“GET”) and write (“SET”) operations.

5. Entities 802.11 defines many entities –
Some high level entities include:
MAC – Media Access Control entity
MLME – MAC layer management entity
SME- Station Management entity
PHY – Physical Layer entity
PLME – PHY layer management entity

6. High Level Entities

7. Existing MIB usage The Current MIB has a variety of usage models.
Some Variables have multiple usage models
Some Variables are interpreted differently by different readers
(does “enabled mean implemented. Currently turned on/off or both?)

8. ARC SC MIB Usage Recommendations…

9. Recommended types of MIB attributes
Three types:
Capability: Static, initialized by entity as part of instantiation, read by other entities.
Status: Dynamic, written by the entity to expose current conditions to reading entities.
Control: Dynamic, written by another entity to control the applicable entity’s manageable behaviors.
The definition and described usage of each attribute should be clear about its type, and which entities use the interaction for read and write.
Dynamic attributes should have discussion about how and when changes are allowed/caused, and what the effect(s) of the change are.

10. Derivation of attribute types
Read by other entity(ies)
Written by other entity(ies)
Read by applicable entity
Capability
Control
Written by applicable entity
Status
Not used

11. MIB attribute usage guidelines
Reading and Writing
One or more entities may read an attribute
At most one entity shall write an attribute (multiple writers creates interlock uncertainty)
The single entity writing to an attribute may or may not be the entity to which it applies.
Static and Dynamic Values
Dynamic attributes can be written while STA in in operation, affecting management changes
Static attributes are not written during operation
MIB attributes are not local variables
Attributes accessed solely within the entity do not provide any management function. They are implementation dependant to ensure the entity’s state-based behaviors conform to the Standard.
Such variables may be useful to describe behavior in the Standard, but are inappropriate in the MIB.

12. MIB attribute modification
No more than one entity shall write (“SET”) a MIB attribute, to avoid mutex problems and other timing assumptions violations
Every MIB attribute should be examined for how and when a write/update is allowed or caused, and the effects of the update should be explcit.
For each attribute the following should be given:
“May be written by <entity> when <conditions>. 
Changes take effect by <description>.”
A MIB attribute whose change requires other actions, should be represented with a specific Management SAP primitive, instead of a MIB attribute. This allows the specification of actions that must be taken upon a change.
For example, if an Association must be re-established, or a BSS re-initialized

13. Examples of types Capability – Status – Control –
dot11CFPollable, dot11ManufacturerID, dot11XxxImplemented, dot11RadioMeasurementCapable, dot11ChannelAgilityPresent, dot11RRMMeasurementPilotCapability, dot11FTResourceRequestSupported, dot11ExtendedChannelSwitchEnabled
Status –
dot11XxxCount, dot11RadioMeasurementEnabled
Control –
dot11RTSThreshold, dot11ShortRetryLimit, dot11LongRetryLimit, dot11FragmentationThreshold, dot11PrivacyInvoked, dot11WEPDefaultKeyID, dot11CurrentFrequency, dot11RSNAConfigPairwiseCipherEnabled

14. Naming conventions
To avoid confusion about type and purpose, name MIB attributes based on type:
Capability: dot11XxxImplemented
Status: dot11XxxCount, dot11XxxValue (statistics, etc.)
Status: dot11XxxActivated (capability that is enabled)
Control: dot11XxxThreshold, dot11XxxLimit, dot11XxxID
Avoid names that
leave writer entity ambiguous
dot11XxxEnabled
Reference the amendment
TGxxx or VHT
Use relative wording terms
HT, VHT, faster, better, even mo’ better

15. Separate & Move Local variables
Local variables are those that are not exposed outside an entity, for read or write
Some example local variables – NAV, used_time, admitted_time, aXxxXxx (e.g. aSlotTime), CW, SSRC, SLRC
Local variables should not be part of the MIB
Recommend creating a separate Annex listing local variables.
If MIB syntax is used, for local variable definitions,
It should be made clear that these are not accessible externally to the applicable entity.
The definition syntax should exclude the "::=" part of the syntax (so the varables can not be accesseed externally).
Separate Annex especially useful if usage is not localized to a small section of the text.
Some local variables could be used solely within the Standard’s text, if useful to clarify conforming behaviors, and don’t need formal definition

16. Local variable naming conventions (Still under discussion)
.11local[entityname]variablename
There is still discussion of the name format – this may change…

17. MIB Usage Recommendation Adoption Actions…

18. ARC Recommended actions
Executive Actions
Add recommendations to Editor guidelines as part of OP manual.
Action for TGs working on amendments to 2007:
TG chairs to check drafts for conformance as part of TG Chair’s “is it technically ready for LB” review prior to WG and/or SG LB.
Action for improving 2007 contents
TGMb review current std MIB contents and update appropriate portions
Portions with the effort to update are TBD by TGMb; Some sections might be marked “not up to date with 2009 MIB usage standards”
General Membership Actions:
Consider MIB usage vs recommendations when reviewing drafts.