rfc1368.txt

RFC 的详细文档！

   The object rptrGroupPortCapacity, which also has a maximum value of
   1024, indicates the maximum number of ports that a given group may
   contain. The value of rptrGroupPortCapacity must not change for a
   given group.  However, a group may be deleted from the repeater and
   replaced with a group containing a different number of ports.  The
   value of rptrGroupLastOperStatusChange will indicate that a change
   took place.

   Each port within the repeater is uniquely identified by a combination
   of group number and port number, where port number is an integer in
   the range 1..rptrGroupPortCapacity.  As with groups within a
   repeater, ports within a group may be sparsely numbered.  Likewise,
   ports may come and go within a group without causing a management
   reset.

3.2.  Supporting Functions

   The IEEE 802.3 Hub Management draft [10] defines the following seven
   functions and seven signals used to describe precisely when port
   counters are incremented.  The relationship between the functions and
   signals is shown in Figure 3.

   The CollisionEvent, ActivityDuration, CarrierEvent, FramingError,
   OctetCount, FCSError, and SourceAddress output signals defined here
   are not retrievable MIB objects, but rather are concepts used in
   defining the MIB objects.  The inputs are defined in Section 9 of the
   IEEE 802.3 standard [9].
























McMaster & McCloghrie                                           [Page 7]

RFC 1368                   802.3 Repeater MIB               October 1992


              +---------+
              |Collision|--------------------->CollisionEvent
   CollIn(X)+>|Event    |
            | |Funct    |          +--------+
            | +---------+          |Activity|
            | +-------+            |Timing  |->ActivityDuration
            +>|Carrier|      +---->|Funct   |
              |Event  |      |     +--------+
   DataIn(X)->|Funct  |+-----+---------------->CarrierEvent
              +-------+|
                       | +-------+
                       +>|Framing|------------>FramingError
                         |Funct  |  +-------+
   decodedData---------->|       |+>|Octet  |
                         +-------+| |Count  |->OctetCount
                                  | |Funct  |
                                  | +-------+
                                  | +-------+
                           Octet  | |Cyclic |
                           Stream +>|Redund.|
                                  | |Check  |->FCSError
                                  | |Funct  |
                                  | +-------+
                                  | +-------+
                                  | |Source |
                                  +>|Address|->SourceAddress
                                    |Funct  |
                                    +-------+

             Figure 3.  Port Functions Relationship


   Collision Event Function:  The collision event function asserts the
   CollisionEvent signal when the CollIn(X) variable has the value SQE.
   The CollisionEvent signal remains asserted until the assertion of any
   CarrierEvent signal due to the reception of the following event.

   Carrier Event Function:  The carrier event function asserts the
   CarrierEvent signal when the repeater exits the IDLE state, Fig 9-2
   [9], and the port has been determined to be port N.  It deasserts the
   CarrierEvent signal when, for a duration of at least Carrier Recovery
   Time (Ref: 9.5.6.5 [9]), both the DataIn(N) variable has the value II
   and the CollIn(N) variable has the value -SQE.  The value N is the
   port assigned at the time of transition from the IDLE state.

   Framing Function:  The framing function recognizes the boundaries of
   an incoming frame by monitoring the CarrierEvent signal and the
   decoded data stream.  Data bits are accepted while the CarrierEvent



McMaster & McCloghrie                                           [Page 8]

RFC 1368                   802.3 Repeater MIB               October 1992


   signal is asserted.  The framing function strips preamble and start
   of frame delimiter from the received data stream.  The remaining bits
   are aligned along octet boundaries.  If there is not an integral
   number of octets, then FramingError shall be asserted.  The
   FramingError signal is cleared upon the assertion of the CarrierEvent
   signal due to the reception of the following event.

   Activity Timing Function:  The activity timing function measures the
   duration of the assertion of the CarrierEvent signal.  This duration
   value must be adjusted by removing the value of Carrier Recovery Time
   (Ref: 9.5.6.5 [9]) to obtain the true duration of activity on the
   network.  The output of the Activity Timing function is the
   ActivityDuration value, which represents the duration of the
   CarrierEvent signal as expressed in units of bit times.

   Octet Counting Function:  The octet counting function counts the
   number of complete octets received from the output of the framing
   function.  The output of the octet counting function is the
   OctetCount value.  The OctetCount value is reset to zero upon the
   assertion of the CarrierEvent signal due to the reception of the
   following event.

   Cyclic Redundancy Check Function:  The cyclic redundancy check
   function verifies that the sequence of octets output by the framing
   function contains a valid frame check sequence field.  The frame
   check sequence field is the last four octets received from the output
   of the framing function.  The algorithm for generating an FCS from
   the octet stream is specified in 3.2.8 [9].  If the FCS generated
   according to this algorithm is not the same as the last four octets
   received from the framing function then the FCSError signal is
   asserted.  The FCSError signal is cleared upon the assertion of the
   CarrierEvent signal due to the reception of the following event.

   Source Address Function:  The source address function extracts octets
   from the stream output by the framing function.  The seventh through
   twelfth octets shall be extracted from the octet stream and output as
   the SourceAddress variable.  The SourceAddress variable is set to an
   invalid state upon the assertion of the CarrierEvent signal due to
   the reception of the following event.

3.3.  Structure of MIB

   Objects in this MIB are arranged into MIB groups.  Each MIB group is
   organized as a set of related objects.







McMaster & McCloghrie                                           [Page 9]

RFC 1368                   802.3 Repeater MIB               October 1992


3.3.1.  The Basic Group Definitions

   This mandatory group contains the objects which are applicable to all
   repeaters.  It contains status, parameter and control objects for the
   repeater as a whole, the port groups within the repeater, as well as
   for the individual ports themselves.

3.3.2.  The Monitor Group Definitions

   This optional group contains monitoring statistics for the repeater
   as a whole and for individual ports.

3.3.3.  The Address Tracking Group Definitions

   This optional group contains objects for tracking the MAC addresses
   of the DTEs attached to the ports of the repeater.

3.4.  Relationship to Other MIBs

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

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

3.4.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.  A
   repeater is a bitwise store-and-forward device.  It recognizes



McMaster & McCloghrie                                          [Page 10]

RFC 1368                   802.3 Repeater MIB               October 1992


   activity and bits, but does not process incoming data based on any
   packet-related information (such as checksum or addresses).  A
   repeater has no MAC address, no MAC implementation, and does not pass
   packets up to higher-level protocol entities for processing.

   (When a network management entity is observing the 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.5.  Textual Conventions

   The datatype MacAddress is used as a textual convention in this
   document.  This textual convention has NO effect on either the syntax
   nor the semantics of any managed object.  Objects defined using this
   convention are always encoded by means of the rules that define their
   primitive type.  Hence, no changes to the SMI or the SNMP are
   necessary to accommodate this textual convention which is adopted
   merely for the convenience of readers.

4.  Definitions

   SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       Counter, TimeTicks, Gauge
                                           FROM RFC1155-SMI
       mib-2, DisplayString                FROM RFC1213-MIB
       TRAP-TYPE                           FROM RFC-1215
       OBJECT-TYPE                         FROM RFC-1212;


   snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }


   -- All representations of MAC addresses in this MIB Module use,
   -- as a textual convention (i.e., this convention does not affect
   -- their encoding), the data type:

   MacAddress ::= OCTET STRING (SIZE (6))    -- a 6 octet address in
                                             -- the "canonical" order
   -- defined by IEEE 802.1a, i.e., as if it were transmitted least
   -- significant bit first.







McMaster & McCloghrie                                          [Page 11]

RFC 1368                   802.3 Repeater MIB               October 1992


   --                      References
   --
   -- The following references are used throughout this MIB:
   --
   -- [IEEE 802.3 Std]
   --    refers to IEEE 802.3/ISO 8802-3 Information processing
   --    systems - Local area networks - Part 3: Carrier sense
   --    multiple access with collision detection (CSMA/CD)
   --    access method and physical layer specifications
   --    (2nd edition, September 21, 1990).
   --
   -- [IEEE 802.3 Rptr Mgt]
   --    refers to IEEE P802.3K, 'Layer Management for 10 Mb/s
   --    Baseband Repeaters, Section 19,' Draft Supplement to
   --    ANSI/IEEE 802.3, (Draft 8, April 9, 1992)


   --                      MIB Groups
   --
   -- The rptrBasicPackage group is mandatory.
   -- The rptrMonitorPackage and rptrAddrTrackPackage
   -- groups are optional.


   rptrBasicPackage
       OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }

   rptrMonitorPackage
       OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }

   rptrAddrTrackPackage
       OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }


   -- object identifiers for organizing the information
   -- in the groups by repeater, port-group, and port

   rptrRptrInfo
       OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
   rptrGroupInfo
       OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
   rptrPortInfo
       OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }

   rptrMonitorRptrInfo
       OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
   rptrMonitorGroupInfo
       OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }



McMaster & McCloghrie                                          [Page 12]

RFC 1368                   802.3 Repeater MIB               October 1992


   rptrMonitorPortInfo
       OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }

   rptrAddrTrackRptrInfo     -- this subtree is currently unused