rfc2674.txt

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

   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.



Bell, et al.                Standards Track                    [Page 13]

RFC 2674                 Bridge MIB Extensions               August 1999


3.4.  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
   least) the 'system' group defined in MIB-II [MIB2], the 'interfaces'
   group defined in [INTERFACEMIB] and the original bridge MIB
   [BRIDGEMIB].

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

3.4.2.  Relation to Interfaces MIB

   The Interfaces Group MIB [INTERFACEMIB], requires that any MIB which
   is an adjunct of the Interfaces Group MIB, clarify specific areas
   within the Interfaces Group MIB.  These areas were intentionally left
   vague in the Interfaces Group MIB to avoid over-constraining the MIB,
   thereby precluding management of certain media-types.

   The Interfaces Group MIB enumerates several areas which a media-
   specific MIB must clarify.  Each of these areas is addressed in a
   following subsection.  The implementor is referred to the Interfaces
   Group MIB in order to understand the general intent of these areas.

   In the Interfaces Group MIB, 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 Extended Bridge MIB is the notion of ports on a
   bridge.  Each of these ports is associated with one interface of the
   'interfaces' group (one row in ifTable) 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




Bell, et al.                Standards Track                    [Page 14]

RFC 2674                 Bridge MIB Extensions               August 1999


   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.  Thus, this Extended Bridge MIB (and in particular,
   its counters) is 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.

3.4.2.1.  Layering Model

   This memo assumes the interpretation of the Interfaces Group to be in
   accordance with the Interfaces Group MIB [INTERFACEMIB] which states
   that the interfaces table (ifTable) contains information on the
   managed resource's interfaces and that each sub-layer below the
   internetwork layer of a network interface is considered an interface.

   This document recommends that, within an entity, VLANs which are
   instantiated as an entry in dot1qVlanCurrentTable by either
   management configuration through dot1qVlanStaticTable or by dynamic
   means (e.g.  through GVRP), are NOT also represented by an entry in
   ifTable.

   Where an entity contains higher-layer protocol entities e.g. IP-layer
   interfaces that transmit and receive traffic to/from a VLAN, these
   should be represented in the ifTable as interfaces of type
   propVirtual(53).  Protocol-specific types such as l3ipxvlan(137)
   should not be used here since there is no implication that the bridge
   will perform any protocol filtering before delivering up to these
   virtual interfaces.





Bell, et al.                Standards Track                    [Page 15]

RFC 2674                 Bridge MIB Extensions               August 1999


3.4.2.2.  ifStackTable

   In addition, the Interfaces Group MIB [INTERFACEMIB] defines a table
   'ifStackTable' for describing the relationship between logical
   interfaces within an entity.  It is anticipated that implementors
   will use this table to describe the binding of e.g. IP interfaces to
   physical ports, although the presence of VLANs makes the
   representation less than perfect for showing connectivity: the
   ifStackTable cannot represent the full capability of the IEEE 802.1Q
   VLAN bridging standard since that makes a distinction between VLAN
   bindings on 'ingress' to and 'egress' from a port: these
   relationships may or may not be symmetrical whereas Interface MIB
   Evolution assumes a symmetrical binding for transmit and receive.
   This makes it necessary to define other manageable objects for
   configuring which ports are members of which VLANs.

3.4.2.3.  ifRcvAddressTable

   This table contains all MAC addresses, unicast, multicast, and
   broadcast, for which an interface will receive packets and forward
   them up to a higher layer entity for local consumption.  Note that
   this does not include addresses for data-link layer control protocols
   such as Spanning-Tree, GMRP or GVRP.  The format of the address,
   contained in ifRcvAddressAddress, is the same as for ifPhysAddress.

   This table does not include unicast or multicast addresses which are
   accepted for possible forwarding out some other port.  This table is
   explicitly not intended to provide a bridge address filtering
   mechanism.

3.4.3.  Relation to Original Bridge MIB

   This section defines how objects in the original bridge MIB module
   [BRIDGEMIB] should be represented for devices which implement the
   extensions: some of the old objects are less useful in such devices
   but must still be implemented for reasons of backwards compatibility.
   Note that formal conformance statements for that MIB module do not
   exist since it is defined in SMIv1.

3.4.3.1.  The dot1dBase Group

   This mandatory group contains the objects which are applicable to all
   types of bridges.  Interpretation of this group is unchanged.








Bell, et al.                Standards Track                    [Page 16]

RFC 2674                 Bridge MIB Extensions               August 1999


3.4.3.2.  The dot1dStp Group

   This group contains the objects that denote the bridge's state with
   respect to the Spanning Tree Protocol.  Interpretation of this group
   is unchanged.

3.4.3.3.  The dot1dTp Group

   This group contains objects that describe the entity's state with
   respect to transparent bridging.

   In a device operating with a single Filtering Database,
   interpretation of this group is unchanged.

   In a device supporting multiple Filtering Databases, this group is
   interpreted as follows:

   dot1dTpLearnedEntryDiscards
        The number of times that *any* of the FDBs became full.

   dot1dTpAgingTime
        This applies to all Filtering Databases.

   dot1dTpFdbTable
        Report MAC addresses learned on each port, regardless of which
        Filtering Database they have been learnt in.  If an address has
        been learnt in multiple databases on a single port, report it
        only once.  If an address has been learnt in multiple
        databases on more than one port, report the entry on any one of
        the valid ports.

   dot1dTpPortTable
        This table is port-based and is not affected by multiple
        Filtering Databases or multiple VLANs.  The counters should
        include frames received or transmitted for all VLANs.  Note that
        equivalent 64-bit port statistics counters, as well as other
        objects to represent the upper 32 bits of these counters, are
        defined in this document for high capacity network interfaces.
        These have confromance statements to indicate for which speeds of
        interface they are required.

3.4.3.4.  The dot1dStatic Group

   This optional group contains objects that describe the configuration
   of destination-address filtering.

   In a device operating with a single Filtering Database,
   interpretation of this group is unchanged.



Bell, et al.                Standards Track                    [Page 17]

RFC 2674                 Bridge MIB Extensions               August 1999


   In a device supporting multiple Filtering Databases, this group is
   interpreted as follows:

   dot1dStaticTable
        Entries read from this table include all static entries from all
        of the Filtering Databases.  Entries for the same MAC address
        and receive port in more than one Filtering Database must appear
        only once since these are the indices of this table.  This table
        should be implemented as read-only in devices that support
        multiple Forwarding Databases - instead, write access should be
        provided through dot1qStaticUnicastTable and
        dot1qStaticMulticastTable, as defined in this document.

3.4.3.5.  Additions to the Original Bridge MIB

   In addition to the objects in the original bridge MIB [BRIDGEMIB],
   this document contains:

    (1)   support for multiple traffic classes and dynamic multicast
          filtering as per IEEE 802.1D-1998 [802.1D].

    (2)   support for bridged Virtual LANs as per IEEE 802.1Q-1998
          [802.1Q].

    (3)   support for 64-bit versions of original bridge MIB [BRIDGEMIB]
          port counters.

4.  Definitions for Extended Bridge MIB

P-BRIDGE-MIB DEFINITIONS ::= BEGIN

-- -------------------------------------------------------------
-- MIB for IEEE 802.1p devices
-- -------------------------------------------------------------

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64
        FROM SNMPv2-SMI
    TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF
    dot1dTp, dot1dTpPort, dot1dBridge,
    dot1dBasePortEntry, dot1dBasePort
        FROM BRIDGE-MIB;






Bell, et al.                Standards Track                    [Page 18]

RFC 2674                 Bridge MIB Extensions               August 1999


pBridgeMIB MODULE-IDENTITY
    LAST-UPDATED "9908250000Z"
    ORGANIZATION "IETF Bridge MIB Working Group"
    CONTACT-INFO
        "       Les Bell
        Postal: 3Com Europe Ltd.
                3Com Centre, Boundary Way
                Hemel Hempstead, Herts. HP2 7YU
                UK
         Phone: [phone]
         Email: [e-mail]

                Andrew Smith
        Postal: Extreme Networks
                3585 Monroe St.
                Santa Clara CA 95051
                USA
         Phone: [phone]
         Email: [e-mail]

                Paul Langille
        Postal: Newbridge Networks
                5 Corporate Drive
                Andover, MA 01810
                USA
         Phone: [phone]
         Email: [e-mail]

                Anil Rijhsinghani
        Postal: Cabletron Systems
                50 Minuteman Road
                Andover, MA 01810
                USA
         Phone: [phone]
         Email: [e-mail]

                Keith McCloghrie
        Postal: cisco Systems, Inc.
                170 West Tasman Drive
                San Jose, CA 95134-1706
                USA
         Phone: [phone]
         Email: [e-mail]"

    DESCRIPTION
        "The Bridge MIB Extension module for managing Priority
        and Multicast Filtering, defined by IEEE 802.1D-1998."




Bell, et al.                Standards Track                    [Page 19]

RFC 2674                 Bridge MIB Extensions               August 1999


-- revision history

    REVISION     "9908250000Z"
    DESCRIPTION
         "Initial version, published as RFC 2674."

    ::= { dot1dBridge 6 }

pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 }

-- -------------------------------------------------------------
-- Textual Conventions
-- -------------------------------------------------------------