rfc1516.txt

中、英文RFC文档大全打包下载完全版 .

   ports will not show up in the table.

   It is the decision of the implementor to select the appropriate
   group(s) in which to place internal ports.  GroupCapacity for a given
   group always reflects the number of MANAGED ports in that group.

   If some ports are unmanaged such that not all packet sources are
   represented by managed ports, then the sum of the input counters for
   the repeater will not equal the actual output of the repeater.

2.2.  Supporting Functions

   The IEEE 802.3 Hub Management draft [8] 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 [7].























McMaster & McCloghrie                                           [Page 7]

RFC 1516                   802.3 Repeater MIB             September 1993


              +---------+
              |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
   [7], 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 [7]), 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



McMaster & McCloghrie                                           [Page 8]

RFC 1516                   802.3 Repeater MIB             September 1993


   decoded data stream.  Data bits are accepted while the CarrierEvent
   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 [7]) 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 [7].  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.

2.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 1516                   802.3 Repeater MIB             September 1993


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

2.3.2.  The Monitor Group Definitions

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

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

2.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 [3].

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

2.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
   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
   activity and bits, but does not process incoming data based on any
   packet-related information (such as checksum or addresses).  A



McMaster & McCloghrie                                          [Page 10]

RFC 1516                   802.3 Repeater MIB             September 1993


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

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

3.  Definitions

   SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       Counter, TimeTicks, Gauge
                                           FROM RFC1155-SMI
       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.


   --                      References
   --
   -- The following references are used throughout this MIB:
   --



McMaster & McCloghrie                                          [Page 11]

RFC 1516                   802.3 Repeater MIB             September 1993


   -- [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 }
   rptrMonitorPortInfo
       OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }

   rptrAddrTrackRptrInfo     -- this subtree is currently unused



McMaster & McCloghrie                                          [Page 12]

RFC 1516                   802.3 Repeater MIB             September 1993


       OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
   rptrAddrTrackGroupInfo    -- this subtree is currently unused
       OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
   rptrAddrTrackPortInfo
       OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }


   --
   --                    The BASIC GROUP
   --
   -- Implementation of the Basic Group is mandatory for all
   -- managed repeaters.

   --
   -- Basic Repeater Information
   --
   -- Configuration, status, and control objects for the overall
   -- repeater