1 / 19

ARC Recommendation: MIB Attribute Types & Usage

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

nayef
Télécharger la présentation

ARC Recommendation: MIB Attribute Types & Usage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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…

More Related