rfc2266.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,467 行 · 第 1/5 页

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



Flick                       Standards Track                     [Page 1]

RFC 2266                IEEE 802.12 Repeater MIB            January 1998


   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.




Flick                       Standards Track                     [Page 2]

RFC 2266                IEEE 802.12 Repeater MIB            January 1998


   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.




Flick                       Standards Track                     [Page 3]

RFC 2266                IEEE 802.12 Repeater MIB            January 1998


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.




Flick                       Standards Track                     [Page 4]

RFC 2266                IEEE 802.12 Repeater MIB            January 1998


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





Flick                       Standards Track                     [Page 5]

RFC 2266                IEEE 802.12 Repeater MIB            January 1998


       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