Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2266

Definitions of Managed Objects for IEEE 802.12 Repeater Devices

Pages: 56
Proposed Standard
Part 1 of 3 – Pages 1 to 11
None   None   Next

Top   ToC   RFC2266 - Page 1
Network Working Group                                           J. Flick
Request for Comments: 2266                       Hewlett Packard Company
Category: Standards Track                                   January 1998



    Definitions of Managed Objects for IEEE 802.12 Repeater Devices


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing network repeaters
   based on IEEE 802.12.


Table of Contents

   1.  The SNMP Network Management Framework ......................    2
   1.1.  Object Definitions .......................................    2
   2.  Overview ...................................................    2
   2.1.  Repeater Management Model ................................    3
   2.2.  MAC Addresses ............................................    4
   2.3.  Master Mode and Slave Mode ...............................    4
   2.4.  IEEE 802.12 Training Frames ..............................    4
   2.5.  Structure of the MIB .....................................    6
   2.5.1.  Basic Definitions ......................................    7
   2.5.2.  Monitor Definitions ....................................    7
   2.5.3.  Address Tracking Definitions ...........................    7
   2.6.  Relationship to other MIBs ...............................    7
   2.6.1.  Relationship to MIB-II .................................    7
   2.6.1.1.  Relationship to the 'system' group ...................    7
   2.6.1.2.  Relationship to the 'interfaces' group ...............    8
   2.6.2.  Relationship to the 802.3 Repeater MIB .................    8
Top   ToC   RFC2266 - Page 2
   2.7.  Mapping of IEEE 802.12 Managed Objects ...................    9
   3.  Definitions ................................................   12
   4.  Acknowledgements ...........................................   53
   5.  References .................................................   53
   6.  Security Considerations ....................................   54
   7.  Author's Address ...........................................   55
   8.  Full Copyright Statement ...................................   56

1.  The SNMP Network Management Framework

   The SNMP Network Management Framework consists of several components.
   For the purpose of this specification, the applicable components of
   the Framework are the SMI and related documents [2, 3, 4], which
   define the mechanisms used for describing and naming objects for the
   purpose of management.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

1.1.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base (MIB).  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1) [1]
   defined in the SMI [2].  In particular, each object type is named by
   an OBJECT IDENTIFIER, an administratively assigned name.  The object
   type together with an object instance serves to uniquely identify a
   specific instantiation of the object.  For human convenience, we
   often use a textual string, termed the descriptor, to refer to the
   object type.

2.  Overview

   Instances of these object types represent attributes of an IEEE
   802.12 repeater, as defined by Section 12, "RMAC Protocol" in IEEE
   Standard 802.12-1995 [6].

   The definitions presented here are based on Section 13, "Layer
   management functions and services", and Annex C, "GDMO Specifications
   for Demand Priority Managed Objects" of IEEE Standard 802.12-1995
   [6].

   Implementors of these MIB objects should note that the IEEE document
   explicitly describes (in the form of Pascal pseudocode) when, where,
   and how various repeater attributes are measured.  The IEEE document
   also describes the effects of repeater actions that may be invoked by
   manipulating instances of the MIB objects defined here.
Top   ToC   RFC2266 - Page 3
   The counters in this document are defined to be the same as those
   counters in IEEE Standard 802.12-1995, with the intention that the
   same instrumentation can be used to implement both the IEEE and IETF
   management standards.

2.1.  Repeater Management Model

   The model used in the design of this MIB allows for a managed system
   to contain one or more managed 802.12 repeaters, and one or more
   managed 802.12 repeater ports.

   A repeater port may be thought of as a source of traffic into a
   repeater in the system.  The vgRptrBasicPortTable contains entries
   for each physical repeater port in the managed system.  An
   implementor may choose to separate these ports into "groups".  For
   example, a group may be used to represent a field-replaceable unit,
   so that the port numbering may match the numbering in the hardware
   implementation.  Note that this group mapping is recommended but
   optional.  An implementor may choose to put all of the system's ports
   into a single group, or to divide the ports into groups that do not
   match physical divisions.  Each group within the system is uniquely
   identified by a group number.  Each port within a system is uniquely
   identified by a combination of group number and port number.  The
   method of numbering groups and ports is implementation-specific.
   Both groups and ports may be sparsely numbered.

   In addition to the externally visible ports, some implementations may
   have internal ports that are not obvious to the end-user but are
   nevertheless sources of traffic into the repeater system.  Examples
   include internal management ports, through which an agent
   communicates, and ports connecting to a backplane internal to the
   implementation.  It is the decision of the implementor to select the
   appropriate group(s) in which to place internal ports.

   Managed repeaters in the system are represented by entries in the
   vgRptrInfoTable.  There may be multiple repeaters in the managed
   system.  They are uniquely identified by a repeater number.  The
   method of numbering repeaters is implementation-specific.  Each port
   will either be associated with one of the repeaters, or isolated (a
   so-called "trivial" repeater).  The set of ports associated with a
   single repeater will be in the same contention domain, and will be
   participating in the same instance of the Demand Priority Access
   Method protocol.  The mapping of ports to repeaters may be static or
   dynamic.  A column in the vgRptrBasicPortTable,
   vgRptrPortRptrInfoIndex, indicates the repeater that the port is
   currently associated with.  The method for assigning a port to a
   repeater is implementation-specific.
Top   ToC   RFC2266 - Page 4
2.2.  MAC Addresses

   All representations of MAC addresses in this MIB module are in
   "canonical" order defined by 802.1a, i.e., as if it were transmitted
   least significant bit first.  This is true even if the repeater is
   operating in token ring framing mode, which requires MAC addresses to
   be transmitted most significant bit first.

2.3.  Master Mode and Slave Mode

   In an IEEE 802.12 network, "master" devices act as network
   controllers to decide when to grant requesting end-nodes permission
   to transmit.  These master devices may be repeaters, or other active
   controller devices such as switches.

   Devices which do not act as network controllers, such as end-nodes or
   passive switches, are considered to be operating in "slave" mode.

   An 802.12 repeater always acts in "master" mode on its local ports,
   which may connect to end nodes, switch or other device ports acting
   in "slave" mode, or lower-level repeaters in a cascade.  It acts in
   "slave" mode on cascade ports, which may connect to an upper-level
   repeater in a cascade, or to switch or other device ports operating
   in "master" mode.

2.4.  IEEE 802.12 Training Frames

   Training frames are special MAC frames that are used only during link
   initialization.  Training frames are initially constructed by the
   device at the "lower" end of a link, which is the slave mode device
   for the link.  The training frame format is as follows:

       +----+----+------------+--------------+----------+-----+
       | DA | SA | Req Config | Allow Config |   Data   | FCS |
       +----+----+------------+--------------+----------+-----+

               DA = destination address (six octets)
               SA = source address (six octets)
               Req Config = requested configuration (2 octets)
               Allow Config = allowed configuration (2 octets)
               Data = data (594 to 675 octets)
               FCS = frame check sequence (4 octets)

   Training frames are always sent with a null destination address.  To
   pass training, an end node must use its source address in the source
   address field of the training frame.  A repeater may use a non-null
   source address if it has one, or it may use a null source address.
Top   ToC   RFC2266 - Page 5
   The requested configuration field allows the slave mode device to
   inform the master mode device about itself and to request
   configuration options.  The training response frame from the master
   mode device contains the slave mode device's requested configuration
   from the training request frame.  The currently defined format of the
   requested configuration field as defined in the IEEE Standard
   802.12-1995 standard is shown below.  Please refer to the most
   current version of the IEEE document for a more up to date
   description of this field.  In particular, the reserved bits may be
   used in later versions of the standard.

       First Octet:       Second Octet:

        7 6 5 4 3 2 1 0    7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
       |v|v|v|r|r|r|r|r|  |r|r|r|F|F|P|P|R|
       +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

       vvv: The version of the 802.12 training protocol with which
            the training initiator is compliant.  The current version
            is 100.  Note that because of the different bit ordering
            used in IEEE and IETF documents, this value corresponds
            to version 1.
       r:   Reserved bits (set to zero)
       FF:  00 = frameType88023
            01 = frameType88025
            10 = reserved
            11 = frameTypeEither
       PP:  00 = singleAddressMode
            01 = promiscuousMode
            10 = reserved
            11 = reserved
       R:   0  = the training initiator is an end node
            1  = the training initiator is a repeater

   The allowed configuration field allows the master mode device to
   respond with the allowed configuration.  The slave mode device sets
   the contents of this field to all zero bits.  The master mode device
   sets the allowed configuration field as follows:

       First Octet:       Second Octet:

        7 6 5 4 3 2 1 0    7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
       |v|v|v|D|C|N|r|r|  |r|r|r|F|F|P|P|R|
       +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
Top   ToC   RFC2266 - Page 6
       vvv: The version of the 802.12 training protocol with which
            the training responder is compliant.  The current version
            is 100.  Note that because of the different bit ordering
            used in IEEE and IETF documents, this value corresponds
            to version 1.
       D:   0  = No duplicate address has been detected.
            1  = Duplicate address has been detected.
       C:   0  = The requested configuration is compatible with the
                 network and the attached port.
            1  = The requested configuration is not compatible with
                 the network and/or the attached port.  In this case,
                 the FF, PP, and R bits indicate a configuration that
                 would be allowed.
       N:   0  = Access will be allowed, providing the configuration
                 is compatible (C = 0).
            1  = Access is not granted because of security
                 restrictions.
       r:   Reserved bits (set to zero).
       FF:  00 = frameType88023 will be used.
            01 = frameType88025 will be used.
            10 = reserved
            11 = reserved
       PP:  00 = singleAddressMode
            01 = promiscuousMode
            10 = reserved
            11 = reserved
       R:   0  = Requested access as an end node is allowed.
            1  = Requested access as a repeater is allowed.

   Again, note that the most recent version of the IEEE 802.12 standard
   should be consulted for the most up to date definition of the
   requested configuration and allowed configuration fields.

   The data field contains between 594 and 675 octets and is filled in
   by the training initiator.  The first 55 octets may be used for
   vendor specific protocol information.  The remaining octets are all
   zeros.  The length of the training frame combined with the
   requirement that 24 consecutive training frames be exchanged without
   error to complete training ensures that marginal links will not
   complete training.

2.5.  Structure of the MIB

   Objects in this MIB are arranged into OID subtrees, each of which
   contains a set of related objects within a broad functional category.
   These subtrees are intended for organizational convenience ONLY, and
   have no relation to the conformance groups defined later in the
   document.
Top   ToC   RFC2266 - Page 7
2.5.1.  Basic Definitions

   The basic definitions include objects for managing the basic status
   and control parameters for each repeater within the managed system,
   for the port groups within the managed system, and for the individual
   ports themselves.

2.5.2.  Monitor Definitions

   The monitor definitions include monitoring statistics for each
   repeater within the system and for individual ports.

2.5.3.  Address Tracking Definitions

   This collection includes objects for tracking the MAC addresses of
   the DTEs attached to the ports within the system.

   Note that this MIB also includes by reference a collection of objects
   from the 802.3 Repeater MIB which may be used for mapping the
   topology of a network.  These definitions are based on a technology
   which has been patented by Hewlett-Packard Company (HP).  HP has
   granted rights to this technology to implementors of this MIB.  See
   [8] and [9] for details.

2.6.  Relationship to other MIBs

2.6.1.  Relationship to MIB-II

   It is assumed that a repeater implementing this MIB will also
   implement (at least) the 'system' group defined in MIB-II [5].

2.6.1.1.  Relationship to the 'system' group

   In MIB-II, the 'system' group is defined as being mandatory for all
   systems such that each managed entity contains one instance of each
   object in the 'system' group.  Thus, those objects apply to the
   entity even if the entity's sole functionality is management of
   repeaters.

   Note that all of the managed repeaters (i.e. entries in the
   vgRptrInfoTable) will normally exist within a single naming scope.
   Therefore, there will normally only be a single instance of each of
   the objects in the system group for the entire managed repeater
   system regardless of how many managed repeaters there are in the
   system.
Top   ToC   RFC2266 - Page 8
2.6.1.2.  Relationship to the 'interfaces' group

   In MIB-II, the 'interfaces' group is defined as being mandatory for
   all systems and contains information on an entity's interfaces, where
   each interface is thought of as being attached to a 'subnetwork'.
   (Note that this term is not to be confused with 'subnet' which refers
   to an addressing partitioning scheme used in the Internet suite of
   protocols.)

   This Repeater MIB uses the notion of ports on a repeater.  The
   concept of a MIB-II interface has NO specific relationship to a
   repeater's port.  Therefore, the 'interfaces' group applies only to
   the one (or more) network interfaces on which the entity managing the
   repeater sends and receives management protocol operations, and does
   not apply to the repeater's ports.

   This is consistent with the physical-layer nature of a repeater.  An
   802.12 repeater has an RMAC implementation, which acts as the
   repeater end of the Demand Priority Access Method, but does not
   contain a DTE MAC implementation, and does not pass packets up to
   higher-level protocol entities for processing.

   (When a network management entity is observing a repeater, it may
   appear as though the repeater is passing packets to a higher-level
   protocol entity.  However, this is only a means of implementing
   management, and this passing of management information is not part of
   the repeater functionality.)

2.6.2.  Relationship to the 802.3 Repeater MIB

   An IEEE 802.12 repeater can be configured to operate in either
   ethernet or token ring framing mode.  This only affects the frame
   format and address bit order of the frames on the wire.  An 802.12
   network does not use the media access protocol for either ethernet or
   token ring.  Instead, IEEE 802.12 defines its own media access
   protocol, the Demand Priority Access Method (DPAM).

   There is an existing standards-track MIB module for instrumenting
   IEEE 802.3 repeaters [7].  That MIB module is designed to instrument
   the operation of the repeater in a network implementing the 802.3
   media access protocol.  Therefore, much of that MIB does not apply to
   802.12 repeaters.

   However, the 802.3 Repeater MIB also contains a collection of objects
   that may be used to map the topology of a network.  These objects are
   contained in a separable OBJECT-GROUP, are not 802.3-specific, and
   are considered useful for 802.12 repeaters.  In addition, the layer
Top   ToC   RFC2266 - Page 9
   management clause of the IEEE 802.12 specification includes similar
   functionality.  Therefore, vendors of agents for 802.12 repeaters are
   encouraged to implement the snmpRptrGrpRptrAddrSearch OBJECT-GROUP
   defined in the 802.3 Repeater MIB.

2.7.  Mapping of IEEE 802.12 Managed Objects

   IEEE 802.12 Managed Object        Corresponding SNMP Object

   oRepeater
     .aCurrentFramingType            vgRptrInfoCurrentFramingType
     .aDesiredFramingType            vgRptrInfoDesiredFramingType
     .aFramingCapability             vgRptrInfoFramingCapability
     .aMACAddress                    vgRptrInfoMACAddress
     .aRepeaterHealthState           vgRptrInfoOperStatus
     .aRepeaterID                    vgRptrInfoIndex
     .aRepeaterSearchAddress         SNMP-REPEATER-MIB -
                                         rptrAddrSearchAddress
     .aRepeaterSearchGroup           SNMP-REPEATER-MIB -
                                         rptrAddrSearchGroup
     .aRepeaterSearchPort            SNMP-REPEATER-MIB -
                                         rptrAddrSearchPort
     .aRepeaterSearchState           SNMP-REPEATER-MIB -
                                         rptrAddrSearchState
     .aRMACVersion                   vgRptrInfoTrainingVersion
     .acRepeaterSearchAddress        SNMP-REPEATER-MIB -
                                         rptrAddrSearchAddress
     .acResetRepeater                vgRptrInfoReset
     .nRepeaterHealth                vgRptrHealth
     .nRepeaterReset                 vgRptrResetEvent

   oGroup
     .aGroupCablesBundled            vgRptrGroupCablesBundled
     .aGroupID                       vgRptrGroupIndex
     .aGroupPortCapacity             vgRptrGroupPortCapacity

   oPort
     .aAllowableTrainingType         vgRptrPortAllowedTrainType
     .aBroadcastFramesReceived       vgRptrPortBroadcastFrames
     .aCentralMgmtDetectedDupAddr    vgRptrMgrDetectedDupAddress
     .aDataErrorFramesReceived       vgRptrPortDataErrorFrames
     .aHighPriorityFramesReceived    vgRptrPortHighPriorityFrames
     .aHighPriorityOctetsReceived    vgRptrPortHCHighPriorityOctets, or
                                     vgRptrPortHighPriorityOctets and
                                     vgRptrPortHighPriOctetRollovers
     .aIPMFramesReceived             vgRptrPortIPMFrames
     .aLastTrainedAddress            vgRptrAddrLastTrainedAddress
     .aLastTrainingConfig            vgRptrPortLastTrainConfig
Top   ToC   RFC2266 - Page 10
     .aLocalRptrDetectedDupAddr      vgRptrRptrDetectedDupAddress
     .aMulticastFramesReceived       vgRptrPortMulticastFrames
     .aNormalPriorityFramesReceived  vgRptrPortNormPriorityFrames
     .aNormalPriorityOctetsReceived  vgRptrPortHCNormPriorityOctets, or
                                     vgRptrPortNormPriorityOctets and
                                     vgRptrPortNormPriOctetRollovers
     .aNullAddressedFramesReceived   vgRptrPortNullAddressedFrames
     .aOctetsInUnreadableFramesRcvd  vgRptrPortHCUnreadableOctets, or
                                     vgRptrPortUnreadableOctets and
                                     vgRptrPortUnreadOctetRollovers
     .aOversizeFramesReceived        vgRptrPortOversizeFrames
     .aPortAdministrativeState       vgRptrPortAdminStatus
     .aPortID                        vgRptrPortIndex
     .aPortStatus                    vgRptrPortOperStatus
     .aPortType                      vgRptrPortType
     .aPriorityEnable                vgRptrPortPriorityEnable
     .aPriorityPromotions            vgRptrPortPriorityPromotions
     .aReadableFramesReceived        vgRptrPortReadableFrames
     .aReadableOctetsReceived        vgRptrPortHCReadableOctets, or
                                     vgRptrPortReadableOctets and
                                     vgRptrPortReadOctetRollovers
     .aSupportedCascadeMode          vgRptrPortSupportedCascadeMode
     .aSupportedPromiscMode          vgRptrPortSupportedPromiscMode
     .aTrainedAddressChanges         vgRptrAddrTrainedAddressChanges
     .aTrainingResult                vgRptrPortTrainingResult
     .aTransitionsIntoTraining       vgRptrPortTransitionToTrainings
     .acPortAdministrativeControl    vgRptrPortAdminStatus

   The following IEEE 802.12 managed objects have not been included in
   the 802.12 Repeater MIB for the indicated reasons.

   IEEE 802.12 Managed Object        Disposition

   oRepeater
     .aGroupMap                      Can be determined by GetNext sweep
                                     of vgRptrBasicGroupTable

     .aRepeaterGroupCapacity         Meaning is unclear in many
                                     repeater implementations.  For
                                     example, some cards may have
                                     daughter cards which make group
                                     capacity change depending on the
                                     cards installed.  Meaning is also
                                     unclear in a stackable
                                     implementation.  Also, since
                                     groups are not required to be
                                     numbered from 1..capacity, but may
                                     be computed algorithmically or
Top   ToC   RFC2266 - Page 11
                                     related to Entity MIB indices,
                                     this object was not considered
                                     useful.

     .aRepeaterHealthData            Since the data is implementation
                                     specific and non-interoperable,
                                     it was not considered useful.

     .aRepeaterHealthText            Implementation experience with
                                     similar object in 802.3 Rptr MIB
                                     indicated it was not useful.

     .acExecuteNonDisruptiveSelfTest Implementation experience with
                                     similar object in 802.3 Rptr MIB
                                     indicated it was not useful.

     .nGroupMapChange                Since aGroupMap was not included,
                                     a notification of a change in that
                                     object was not needed.

   oGroup
     .aPortMap                       Can be determined by GetNext sweep
                                     of vgRptrBasicPortTable
     .nPortMapChange                 Since aPortMap was not included,
                                     a notification of a change in that
                                     object was not needed.

   oPort
     .aMediaType                     This object is a function of the
                                     Physical Media Dependent (PMD)
                                     layer, which is defined
                                     differently for each type of
                                     network. For an 802.3 network,
                                     .aMediaType corresponds to the PMD
                                     definitions in the 802.3 MAU MIB.
                                     For management of an 802.12
                                     network, mapping of this object is
                                     deferred to future work on an
                                     802.12 PMD MIB which will include
                                     both repeater and interface PMD
                                     information and redundant link
                                     support.


(next page on part 2)

Next Section