ARC Recommendation:MIB Attribute Types & Usage Date: 2009-05-12 Authors:
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.
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.
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
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?)
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.
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.
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.
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
Examples of types • Capability – • dot11CFPollable, dot11ManufacturerID, dot11XxxImplemented, dot11RadioMeasurementCapable, dot11ChannelAgilityPresent, dot11RRMMeasurementPilotCapability, dot11FTResourceRequestSupported, dot11ExtendedChannelSwitchEnabled • Status – • dot11XxxCount, dot11RadioMeasurementEnabled • Control – • dot11RTSThreshold, dot11ShortRetryLimit, dot11LongRetryLimit, dot11FragmentationThreshold, dot11PrivacyInvoked, dot11WEPDefaultKeyID, dot11CurrentFrequency, dot11RSNAConfigPairwiseCipherEnabled
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
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
Local variable naming conventions(Still under discussion) • .11local[entityname]variablename • There is still discussion of the name format – this may change…