May 2009 doc.: IEEE 802.11-09/533r1
ARC Recommendation:
MIB Attribute Types & Usage
Date: 2009-05-12
Authors:
Name Company Address Phone email
David Bagby Calypso 2028 Arbor Ave. +1-650-637- Dave@CalypsoVentures.c
om
Arc SC Chair Ventures, Inc. Belmont, CA 94002 7741
Submission Slide 1 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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.
Submission Slide 2 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
802.11 2007 MIB usage…
Submission Slide 3 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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.
Submission Slide 4 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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
Submission Slide 5 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
High Level Entities
802.1X
Authenticator
/Supplicant
MAC_SAP
Data Link RSNA Key
MAC Sublayer Management
Management
MAC Sublayer Entity MLME_SAP
PHY_SAP MLME-PLME_SAP
Station
Management
PLCP Sublayer Entity
Physical
PMD_SAP PHY Sublayer
Management PLME_SAP
Entity
PMD Sublayer
Submission Slide 6 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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?)
Submission Slide 7 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
So ARC SC cogitated and developed some
Recommendations for improvements…
Submission Slide 8 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
MIB Usage Recommendation Adoption
Actions…
Submission Slide 9 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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.
Submission Slide 10 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
ARC SC MIB Usage Recommendations…
Submission Slide 11 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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.
Submission Slide 12 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
Derivation of attribute types
Read by other Written by other
entity(ies) entity(ies)
Read by applicable Capability Control
entity
Written by applicable Status Not used
entity
Submission Slide 13 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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.
Submission Slide 14 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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 when .
• Changes take effect by .”
• 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
Submission Slide 15 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
Examples of types
• Capability –
– dot11CFPollable, dot11ManufacturerID, dot11XxxImplemented,
dot11RadioMeasurementCapable, dot11ChannelAgilityPresent,
dot11RRMMeasurementPilotCapability, dot11FTResourceRequestSupported,
dot11ExtendedChannelSwitchEnabled
• Status –
– dot11XxxCount, dot11RadioMeasurementEnabled
• Control –
– dot11RTSThreshold, dot11ShortRetryLimit, dot11LongRetryLimit,
dot11FragmentationThreshold, dot11PrivacyInvoked, dot11WEPDefaultKeyID,
dot11CurrentFrequency, dot11RSNAConfigPairwiseCipherEnabled
Submission Slide 16 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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
Submission Slide 17 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
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
Submission Slide 18 David Bagby, ARC Chair
Submitted on behalf of ARC SC.
May 2009 doc.: IEEE 802.11-09/533r1
Local variable naming conventions
(Still under discussion)
• .11local[entityname]variablename
– There is still discussion of the name format – this may change…
Submission Slide 19 David Bagby, ARC Chair
Submitted on behalf of ARC SC.