802.12 Rptr MIB Intro

[John Flick <[e-mail]>]

I have enclosed my updated intro text for the 802.12 Repeater MIB.
Please review and get comments to either me or the list by this
friday (July 26).

Thanks,
John
==========================================================

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


1.  Introduction

   This memo defines an experimental 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.


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


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




















John Flick              Expires January 29, 1997                [Page 2]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


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

   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.


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





















John Flick              Expires January 29, 1997                [Page 3]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


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





























John Flick              Expires January 29, 1997                [Page 4]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


   The requested configuration field allows the device at the lower end
   of a link to inform the device at the upper end of the link about
   itself and to request configuration options.  The training response
   frame from the device at the upper end of the link contains the
   requestor'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.
       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



















John Flick              Expires January 29, 1997                [Page 5]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


   The allowed configuration field allows the training responder to
   respond with the allowed configuration.  The training initiator sets
   the contents of this field to all zero bits.  The training responder
   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|
       +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

       vvv: The version of the 802.12 training protocol with which
            the training responder is compliant.  The current version
            is 100.
       D:   0  = No duplicate address has been detected.
            1  = Duplicate address has been detected
       C:   0  = The requested configuration is compatible with the
                 network.
            1  = The requested configuration is not compatible with
                 the network.  In this case, the FF, PP, and R bits
                 indicate the 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 received without
   error to complete training ensures that marginal links will not



John Flick              Expires January 29, 1997                [Page 6]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


   complete training.


3.3.  Structure of the MIB

   Objects in this MIB are arranged into packages, each of which
   contains a set of related objects within a broad functional category.
   Objects within a package are generally defined under the same OID
   subtree.  These packages are intended for organizational convenience
   ONLY, and have no relation to the conformance groups defined later in
   the document.


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

3.3.2.  Monitor Definitions

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


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


3.4.  Relationship to other MIBs


3.4.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].





John Flick              Expires January 29, 1997                [Page 7]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


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


3.4.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 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.)


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



John Flick              Expires January 29, 1997                [Page 8]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


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


3.5.  Mapping of IEEE 802.12 Managed Objects

   IEEE 802.12 Managed Object         Corresponding SNMP Object

   oRepeater
     .aCurrentFramingType             vgRptrInfoCurrentFramingType
     .aDesiredFramingType             vgRptrInfoDesiredFramingType
     .aFramingCapability              vgRptrInfoFramingCapability
     .aGroupMap                       <none>
     .aMACAddress                     vgRptrInfoMACAddress
     .aRepeaterGroupCapacity          <none>
     .aRepeaterHealthData             <none>
     .aRepeaterHealthState            vgRptrInfoOperStatus
     .aRepeaterHealthText             <none>
     .aRepeaterID                     vgRptrInfoIndex
     .aRepeaterSearchAddress          SNMP-REPEATER-MIB -
                                          rptrAddrSearchAddress
     .aRepeaterSearchGroup            SNMP-REPEATER-MIB -
                                          rptrAddrSearchGroup
     .aRepeaterSearchPort             SNMP-REPEATER-MIB -
                                          rptrAddrSearchPort
     .aRepeaterSearchState            SNMP-REPEATER-MIB -
                                          rptrAddrSearchState
     .aRMACVersion                    vgRptrInfoTrainingVersion
     .acExecuteNonDisruptiveSelfTest  <none>
     .acRepeaterSearchAddress         SNMP-REPEATER-MIB -
                                          rptrAddrSearchAddress
     .acResetRepeater                 vgRptrInfoReset
     .nGroupMapChange                 <none>
     .nRepeaterHealth                 vgRptrHealth
     .nRepeaterReset                  vgRptrResetEvent

   oGroup
     .aGroupCablesBundled             vgRptrGroupCablesBundled
     .aGroupID                        vgRptrGroupIndex



John Flick              Expires January 29, 1997                [Page 9]

Internet Draft          IEEE 802.12 Repeater MIB            July 29 1996


     .aGroupPortCapacity              vgRptrGroupPortCapacity
     .aPortMap                        <none>
     .nPortMapChange                  <none>

   oPort
     .aAllowableTrainingType          vgRptrPortAllowedTrainType
     .aBroadcastFramesReceived        vgRptrPortBroadcastFrames
     .aCentralMgmtDetectedDupAddr     vgRptrMgrDetectedDupAddress
     .aDataErrorFramesReceived        vgRptrPortDataErrorFrames
     .aHighPriorityFramesReceived     vgRptrPortHighPriorityFrames
     .aHighPriorityOctetsReceived     vgRptrPortHCHighPriorityOctets, or
                                      vgRptrPortHighPriorityOctets and
                                      vgRptrPortU32HighPriorityOctets
     .aIPMFramesReceived              vgRptrPortIPMFrames
     .aLastTrainedAddress             vgRptrAddrLastTrainedAddress
     .aLastTrainingConfig             vgRptrPortLastTrainConfig
     .aLocalRptrDetectedDupAddr       vgRptrRptrDetectedDupAddress
     .aMediaType                      <not yet mapped>
                                      Tranceiver MIB issue
     .aMulticastFramesReceived        vgRptrPortMulticastFrames
     .aNormalPriorityFramesReceived   vgRptrPortNormPriorityFrames
     .aNormalPriorityOctetsReceived   vgRptrPortHCNormPriorityOctets, or
                                      vgRptrPortNormPriorityOctets and
                                      vgRptrPortU32NormPriorityOctets
     .aNullAddressedFramesReceived    vgRptrPortNullAddressedFrames
     .aOctetsInUnreadableFramesRcvd   vgRptrPortHCUnreadableOctets, or
                                      vgRptrPortUnreadableOctets and
                                      vgRptrPortU32UnreadableOctets
     .aOversizeFramesReceived         vgRptrPortOversizeFrames
     .aPortAdministrativeState        vgRptrPortAdminStatus
     .aPortID                         vgRptrPortIndex
     .aPortStatus                     vgRptrPortOperStatus
     .aPortType                       vgRptrPortType
     .aPriorityEnable                 vgRptrPortPriorityEnable
     .aPriorityPromotions             vgRptrPortPriorityPromotions
     .aReadableFramesReceived         vgRptrPortReadableFrames
     .aReadableOctetsReceived         vgRptrPortHCReadableOctets, or
                                      vgRptrPortReadableOctets and
                                      vgRptrPortU32ReadableOctets
     .aSupportedCascadeMode           vgRptrPortSupportedCascadeMode
     .aSupportedPromiscMode           vgRptrPortSupportedPromiscMode
     .aTrainedAddressChanges          vgRptrAddrTrainedAddressChanges
     .aTrainingResult                 vgRptrPortTrainingResult
     .aTransitionsIntoTraining        vgRptrPortTransitionToTrainings
     .acPortAdministrativeControl     vgRptrPortAdminStatus






John Flick              Expires January 29, 1997               [Page 10]