rfc1286.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   this group will not be implemented.  This group is applicable to
   source route only, and SRT bridges.

4.1.4.  The dot1dTp Group

   This group contains objects that describe the entity's state with
   respect to transparent bridging.  If transparent bridging is not
   supported this group will not be implemented.  This group is
   applicable to transparent only and SRT bridges.

4.1.5.  The dot1dStatic Group

   This group contains objects that describe the entity's state with
   respect to destination-address filtering.  If destination-address
   filtering is not supported this group will not be implemented.  This
   group is applicable to any type of bridge which performs
   destination-address filtering.

4.2.  Relationship to Other MIBs

   As described above, some IEEE 802.1d management objects have not been
   included in this MIB because they overlap with objects in other MIBs
   applicable to a bridge implementing this MIB.  In particular, it is
   assumed that a bridge implementing this MIB will also implement (at



Decker, Langille, Rijsinghani & McCloghrie                      [Page 7]

RFC 1286                       Bridge MIB                  December 1991


   least) the 'system' group and the 'interfaces' group defined in MIB-
   II [6].

4.2.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 as a whole irrespective of whether the entity's sole
   functionality is bridging, or whether bridging is only a subset of
   the entity's functionality.

4.2.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.) The term 'segment' is used in this memo to refer to such
   a subnetwork, whether it be an Ethernet segment, a 'ring', a WAN
   link, or even an X.25 virtual circuit.

   Implicit in this Bridge MIB is the notion of ports on a bridge.  Each
   of these ports is associated with one interface of the 'interfaces'
   group, and in most situations, each port is associated with a
   different interface. However, there are situations in which multiple
   ports are associated with the same interface.  An example of such a
   situation would be several ports each corresponding one-to-one with
   several X.25 virtual circuits but all on the same interface.

   Each port is uniquely identified by a port number.  A port number has
   no mandatory relationship to an interface number, but in the simple
   case a port number will have the same value as the corresponding
   interface's interface number.  Port numbers are in the range
   (1..dot1dBaseNumPorts).

   Some entities perform other functionality as well as bridging through
   the sending and receiving of data on their interfaces.  In such
   situations, only a subset of the data sent/received on an interface
   is within the domain of the entity's bridging functionality.  This
   subset is considered to be delineated according to a set of
   protocols, with some protocols being bridged, and other protocols not
   being bridged. For example, in an entity which exclusively performed
   bridging, all protocols would be considered as being bridged, whereas
   in an entity which performed IP routing on IP datagrams and only
   bridged other protocols, only the non-IP data would be considered as
   being bridged.



Decker, Langille, Rijsinghani & McCloghrie                      [Page 8]

RFC 1286                       Bridge MIB                  December 1991


   Thus, this Bridge MIB (and in particular, its counters) are
   applicable only to that subset of the data on an entity's interfaces
   which is sent/received for a protocol being bridged.  All such data
   is sent/received via the ports of the bridge.

4.3.  Textual Conventions

   The datatypes, MacAddress, BridgeId and Timeout, are used as textual
   conventions in this document.  These textual conventions have NO
   effect on either the syntax nor the semantics of any managed object.
   Objects defined using these conventions 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 these textual
   conventions which are adopted merely for the convenience of readers.

5.  Definitions

   RFC1286-MIB DEFINITIONS ::= BEGIN

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

   -- 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, even though 802.5 (in contrast to other
   -- 802.x protocols) requires MAC addresses to be transmitted most
   -- significant bit first.
   --
   -- 16-bit addresses, if needed, are represented by setting their
   -- upper 4 octets to all 0's, i.e., AAFF would be represented
   -- as 00000000AAFF.


   -- Similarly, all representations of Bridge-Id in this MIB Module
   -- use, as a textual convention (i.e. this convention does not affect
   -- their encoding), the data type:



Decker, Langille, Rijsinghani & McCloghrie                      [Page 9]

RFC 1286                       Bridge MIB                  December 1991


   BridgeId ::= OCTET STRING (SIZE (8))   -- the Bridge-Identifier as
                                          -- used in the Spanning Tree
   -- Protocol to uniquely identify a bridge.  Its first two octets
   -- (in network byte order) contain a priority value and its last
   -- 6 octets contain the MAC address used to refer to a bridge in a
   -- unique fashion (typically, the numerically smallest MAC address
   -- of all ports on the bridge).
   -- Several objects in this MIB module represent values of timers
   -- used by the Spanning Tree Protocol.  In this MIB, these timers
   -- have values in units of hundreths of a second (i.e. 1/100 secs).
   -- These timers, when stored in a Spanning Tree Protocol's BPDU,
   -- are in units of 1/256 seconds.  Note, however, that 802.1d/D9
   -- specifies a settable granularity of no more than 1 second for
   -- these timers.  To avoid ambiguity, a data type is defined here
   -- as a textual convention and all representation of these timers
   -- in this MIB module are defined using this data type.  An algorithm
   -- is also defined for converting between the different units, to
   -- ensure a timer's value is not distorted by multiple conversions.
   -- The data type is:

   Timeout ::= INTEGER      -- a STP timer in units of 1/100 seconds

   -- To convert a Timeout value into a value in units of
   -- 1/256 seconds, the following algorithm should be used:
   --
   --      b  = floor( (n * 256) / 100)
   --
   -- where:
   --      floor   =  quotient [ignore remainder]
   --      n is the value in 1/100 second units
   --      b is the value in 1/256 second units
   --
   -- To convert the value from 1/256 second units back to
   -- 1/100 seconds, the following algorithm should be used:
   --
   --      n = ceiling( (b * 100) / 256)
   --
   -- where:
   --      ceiling =  quotient [if remainder is 0], or
   --                 quotient + 1 [if remainder is non-zero]
   --      n is the value in 1/100 second units
   --      b is the value in 1/256 second units
   --
   -- Note: it is important that the arithmetic operations are done
   -- in the order specified (i.e., multiply first, divide second).

   dot1dBridge   OBJECT IDENTIFIER ::= { mib-2 17 }




Decker, Langille, Rijsinghani & McCloghrie                     [Page 10]

RFC 1286                       Bridge MIB                  December 1991


   -- groups in the Bridge MIB

   dot1dBase     OBJECT IDENTIFIER ::= { dot1dBridge 1 }

   dot1dStp      OBJECT IDENTIFIER ::= { dot1dBridge 2 }

   dot1dSr       OBJECT IDENTIFIER ::= { dot1dBridge 3 }

   dot1dTp       OBJECT IDENTIFIER ::= { dot1dBridge 4 }

   dot1dStatic   OBJECT IDENTIFIER ::= { dot1dBridge 5 }


   -- the dot1dBase group

   -- Implementation of the dot1dBase group is mandatory for all
   -- bridges.

   dot1dBaseBridgeAddress OBJECT-TYPE
       SYNTAX  MacAddress
       ACCESS  read-only
       STATUS  mandatory
       DESCRIPTION
               "The MAC address used by this bridge when it must
               be referred to in a unique fashion.   It is
               recommended that this be the numerically smallest
               MAC address of all ports that belong to this
               bridge.  However it is only required to be unique.
               When concatenated with dot1dStpPriority a unique
               BridgeIdentifier is formed which is used in the
               Spanning Tree Protocol."
       REFERENCE
               "P802.1d/D9, July 14, 1989: Sections 6.4.1.1.3 and 3.12.5"
       ::= { dot1dBase 1 }

   dot1dBaseNumPorts OBJECT-TYPE
       SYNTAX  INTEGER
       ACCESS  read-only
       STATUS  mandatory
       DESCRIPTION
               "The number of ports controlled by this bridging
               entity."
       REFERENCE
               "P802.1d/D9, July 14, 1989: Section 6.4.1.1.3"
       ::= { dot1dBase 2 }

   dot1dBaseType OBJECT-TYPE
       SYNTAX  INTEGER {



Decker, Langille, Rijsinghani & McCloghrie                     [Page 11]

RFC 1286                       Bridge MIB                  December 1991


                   unknown(1),
                   transparent-only(2),
                   sourceroute-only(3),
                   srt(4)
               }
       ACCESS  read-only
       STATUS  mandatory
       DESCRIPTION
               "Indicates what type of bridging this bridge can
               perform.  If a bridge is actually performing a
               certain type of bridging this will be indicated by
               entries in the port table for the given type."
       ::= { dot1dBase 3 }

   -- The Generic Bridge Port Table

   dot1dBasePortTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF Dot1dBasePortEntry
       ACCESS  not-accessible
       STATUS  mandatory
       DESCRIPTION
               "A table that contains generic information about
               every port that is associated with this bridge.
               Transparent, source-route, and srt ports are
               included."
       ::= { dot1dBase 4 }

   dot1dBasePortEntry OBJECT-TYPE
       SYNTAX  Dot1dBasePortEntry
       ACCESS  not-accessible
       STATUS  mandatory
       DESCRIPTION
               "A list of information for each port of the
               bridge."
       REFERENCE
               "P802.1d/D9, July 14, 1989: Section 6.4.2, 6.6.1"
       INDEX  { dot1dBasePort }
       ::= { dot1dBasePortTable 1 }

   Dot1dBasePortEntry ::=
       SEQUENCE {
           dot1dBasePort
               INTEGER,
           dot1dBasePortIfIndex
               INTEGER,
           dot1dBasePortCircuit
               OBJECT IDENTIFIER,
           dot1dBasePortDelayExceededDiscards



Decker, Langille, Rijsinghani & McCloghrie                     [Page 12]

RFC 1286                       Bridge MIB                  December 1991


               Counter,
           dot1dBasePortMtuExceededDiscards
               Counter
       }

   dot1dBasePort OBJECT-TYPE
       SYNTAX  INTEGER
       ACCESS  read-only
       STATUS  mandatory
       DESCRIPTION
               "The port number of the port for which this entry
               contains bridge management information."
       ::= { dot1dBasePortEntry 1 }

   dot1dBasePortIfIndex OBJECT-TYPE
       SYNTAX  INTEGER
       ACCESS  read-only
       STATUS  mandatory
       DESCRIPTION
               "The value of the instance of the ifIndex object,
               defined in [4,6], for the interface corresponding
               to this port."
       ::= { dot1dBasePortEntry 2 }

   dot1dBasePortCircuit OBJECT-TYPE
       SYNTAX  OBJECT IDENTIFIER
       ACCESS  read-only
       STATUS  mandatory
       DESCRIPTION
               "For a port which (potentially) has the same value
               of dot1dBasePortIfIndex as another port on the
               same bridge, this object contains the name of an
               object instance unique to this port.  For example,
               in the case where multiple ports correspond one-
               to-one with multiple X.25 virtual circuits, this
               value might identify an (e.g., the first) object
               instance associated with the X.25 virtual circuit
               corresponding to this port.

               For a port which has a unique value of
               dot1dBasePortIfIndex, this object can have the
               value { 0 0 }."
       ::= { dot1dBasePortEntry 3 }

   dot1dBasePortDelayExceededDiscards OBJECT-TYPE
       SYNTAX  Counter
       ACCESS  read-only
       STATUS  mandatory



Decker, Langille, Rijsinghani & McCloghrie                     [Page 13]

RFC 1286                       Bridge MIB                  December 1991