ARC Recommendation: MIB Attribute Types & Usage

1. ARC Recommendation:MIB Attribute Types & Usage Date: 2009-05-12 Authors:

2. 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.

3. 802.11 2007 MIB usage…

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. So ARC SC cogitated and developed some Recommendations for improvements…

9. MIB Usage Recommendation Adoption Actions…

10. 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.

11. ARC SC MIB Usage Recommendations…

12. 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.

13. Derivation of attribute types

14. MIB attribute usage guidelines • Reading and Writing • One or more entities may read an attribute • 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.

15. 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

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

17. 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

18. 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

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