Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2674

Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions

Pages: 86
Obsoleted by:  4363
Part 1 of 4 – Pages 1 to 18
None   None   Next

ToP   noToC   RFC2674 - Page 1
Network Working Group                                             E. Bell
Request for Comments: 2674                                     3Com Corp.
Category: Standards Track                                        A. Smith
                                                         Extreme Networks
                                                              P. Langille
                                                       Newbridge Networks
                                                          A. Rijhsinghani
                                                        Cabletron Systems
                                                            K. McCloghrie
                                                            cisco Systems
                                                              August 1999


        Definitions of Managed Objects for Bridges with Traffic
        Classes, Multicast Filtering and Virtual LAN Extensions

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 (1999).  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 two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) RFC 1525 [SBRIDGEMIB].
ToP   noToC   RFC2674 - Page 2

Table of Contents

1 The SNMP Management Framework ................................... 3 2 Overview ........................................................ 4 2.1 Scope ......................................................... 4 3 Structure of MIBs ............................................... 5 3.1 Structure of Extended Bridge MIB module ....................... 5 3.1.1 Relationship to IEEE 802.1D-1998 Manageable Objects ......... 6 3.1.2 Relationship to IEEE 802.1Q Manageable Objects .............. 8 3.1.3 The dot1dExtBase Group ...................................... 8 3.1.4 The dot1dPriority Group ..................................... 9 3.1.5 The dot1dGarp Group ......................................... 9 3.1.6 The dot1dGmrp Group ......................................... 9 3.1.7 The dot1dTpHCPortTable ...................................... 9 3.1.8 The dot1dTpPortOverflowTable ................................ 9 3.2 Structure of Virtual Bridge MIB module ........................ 9 3.2.1 Relationship to IEEE 802.1Q Manageable Objects .............. 9 3.2.2 The dot1qBase Group .........................................13 3.2.3 The dot1qTp Group ...........................................13 3.2.4 The dot1qStatic Group .......................................13 3.2.5 The dot1qVlan Group .........................................13 3.3 Textual Conventions ...........................................13 3.4 Relationship to Other MIBs ....................................14 3.4.1 Relationship to the 'system' group ..........................14 3.4.2 Relation to Interfaces MIB ..................................14 3.4.2.1 Layering Model ............................................15 3.4.2.2 ifStackTable ..............................................16 3.4.2.3 ifRcvAddressTable .........................................16 3.4.3 Relation to Original Bridge MIB .............................16 3.4.3.1 The dot1dBase Group .......................................16 3.4.3.2 The dot1dStp Group ........................................17 3.4.3.3 The dot1dTp Group .........................................17 3.4.3.4 The dot1dStatic Group .....................................17 3.4.3.5 Additions to the Original Bridge MIB ......................18 4 Definitions for Extended Bridge MIB .............................18 5 Definitions for Virtual Bridge MIB ..............................39 6 Acknowledgments .................................................80 7 Security Considerations .........................................80 8 References ......................................................81 9 Authors' Addresses ..............................................84 10 Intellectual Property ..........................................85 11 Full Copyright Statement .......................................86
ToP   noToC   RFC2674 - Page 3

1. The SNMP Management Framework

The SNMP Management Framework presently consists of five major components: o An overall architecture, described in an Architecture for Describing SNMP Management Frameworks [ARCH]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC 1215 [V1TRAPS]. The second version, called SMIv2, is described in STD 58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD 58, RFC 2580 [V2CONFORM]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [V1PROTO]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [V2COMMUNITY] and RFC 1906 [V2TRANS]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [V2TRANS], Message Processing and Dispatching [V3MPC] and User- based Security Model [V3USM]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [V1PROTO]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [V2PROTO]. o A set of fundamental applications described in SNMPv3 Applications [V3APPS] and the view-based access control mechanism described in View-based Access Control Model [V3VACM]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in
ToP   noToC   RFC2674 - Page 4
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

2. Overview

A common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the network layer. These devices are often known as 'layer 2 switches'. There are two major modes defined for this bridging: Source-Route and transparent. Source-Route bridging is described by IEEE 802.5 [802.5]. and is not discussed further in this document. The transparent method of bridging is defined by IEEE 802.1D-1998 [802.1D] which is an update to the original IEEE 802.1D specification [802.1D-ORIG]. Managed objects for that original specification of transparent bridging were defined in RFC 1493 [BRIDGEMIB]. The original IEEE 802.1D is augmented by IEEE 802.1Q-1998 [802.1Q] to provide support for 'virtual bridged LANs' where a single bridged physical LAN network may be used to support multiple logical bridged LANs, each of which offers a service approximately the same as that defined by IEEE 802.1D. Such virtual LANs (VLANs) are an integral feature of switched LAN networks. A VLAN can be viewed as a group of end-stations on multiple LAN segments and can communicate as if they were on a single LAN. IEEE 802.1Q defines port-based Virtual LANs where membership is determined by the bridge port on which data frames are received. This memo defines the objects needed for the management of port-based VLANs in bridge entities. This memo defines those objects needed for the management of a bridging entity operating in the transparent mode, as well as some objects applicable to all types of bridges. Managed objects for Source-Route bridging are defined in RFC 1525 [SRBRIDGEMIB].

2.1. Scope

This MIB includes a comprehensive set of managed objects which attempts to match the set defined in IEEE 802.1D and IEEE 802.1Q. However, to be consistent with the spirit of the SNMP Framework, a subjective judgement was made to omit the objects from those standards most 'costly' to implement in an agent and least 'essential' for fault and configuration management. The omissions are described in section 3 below.
ToP   noToC   RFC2674 - Page 5
   Historical note:

   The original bridge MIB [BRIDGEMIB] used the following principles for
   determining inclusion of an object in the BRIDGE-MIB module:

   (1)   Start with a small set of essential objects and add only as
         further objects are needed.

   (2)   Require objects be essential for either fault or configuration
         management.

   (3)   Consider evidence of current use and/or utility.

   (4)   Limit the total of objects.

   (5)   Exclude objects which are simply derivable from others in
         this or other MIBs.

   (6)   Avoid causing critical sections to be heavily instrumented.
         The  guideline that was followed is one counter per critical
         section per layer.

3. Structure of MIBs

This document defines additional objects, on top of those existing in the original BRIDGE-MIB module defined in [BRIDGEMIB]: that MIB module is to be maintained unchanged for backwards compatibility. Section 3.4.3 of the present document contains some recommendations regarding usage of objects in the original bridge MIB by devices implementing the enhancements defined here. Two MIB modules are defined here: (1) Managed objects for an extended bridge MIB module P-BRIDGE-MIB for the traffic class and multicast filtering enhancements defined by IEEE 802.1D-1998 [802.1D]. (2) Managed objects for a virtual bridge MIB module Q-BRIDGE-MIB for the Virtual LAN bridging enhancements defined by IEEE 802.1Q-1998 [802.1Q].

3.1. Structure of Extended Bridge MIB module

Objects in this MIB are arranged into groups. Each group is organized as a set of related objects. The overall structure and assignment of objects to their groups is shown below.
ToP   noToC   RFC2674 - Page 6

3.1.1. Relationship to IEEE 802.1D-1998 Manageable Objects

This section contains a cross-reference to the objects defined in IEEE 802.1D-1998 [802.1D]. It also details those objects that are not considered necessary in this MIB module. Some objects defined by IEEE 802.1D-1998 have been included in the virtual bridge MIB module rather than this one: entries in dot1qTpGroupTable, dot1qForwardAllTable and dot1qForwardUnregisteredTable are required for virtual bridged LANs with additional indexing (e.g. per-VLAN, per-FDB) and so are not defined here. Instead, devices which do not implement virtual bridged LANs but do implement the Extended Forwarding Services defined by IEEE 802.1D (i.e. dynamic learning of multicast group addresses and group service requirements in the filtering database) should implement these tables with a fixed value for dot1qFdbId (the value 1 is recommended) or dot1qVlanIndex (the value 1 is recommended). Devices which support Extended Filtering Services should support dot1qTpGroupTable, dot1qForwardAllTable and dot1qForwardUnregisteredTable.
ToP   noToC   RFC2674 - Page 7
   Extended Bridge MIB Name            IEEE 802.1D-1998 Name

   dot1dExtBase                        Bridge
     dot1dDeviceCapabilities
       dot1dExtendedFilteringServices
       dot1dTrafficClasses
     dot1dTrafficClassesEnabled
     dot1dGmrpStatus                    .ApplicantAdministrativeControl
   dot1dPriority
     dot1dPortPriorityTable
       dot1dPortDefaultUserPriority     .UserPriority
       dot1dPortNumTrafficClasses
     dot1dUserPriorityRegenTable        .UserPriorityRegenerationTable
       dot1dUserPriority
       dot1dRegenUserPriority
     dot1dTrafficClassTable             .TrafficClassTable
       dot1dTrafficClassPriority
       dot1dTrafficClass
     dot1dPortOutboundAccessPriorityTable
                                        .OutboundAccessPriorityTable
   dot1dPortOutboundAccessPriority
   dot1dGarp
     dot1dPortGarpTable
       dot1dPortGarpJoinTime            .JoinTime
       dot1dPortGarpLeaveTime           .LeaveTime
       dot1dPortGarpLeaveAllTime        .LeaveAllTime
   dot1dGmrp
     dot1dPortGmrpTable
       dot1dPortGmrpStatus             .ApplicantAdministrativeControl
       dot1dPortGmrpFailedRegistrations .FailedRegistrations
       dot1dPortGmrpLastPduOrigin       .OriginatorOfLastPDU
   dot1dTp
     dot1dTpHCPortTable
       dot1dTpHCPortInFrames            .BridgePort.FramesReceived
       dot1dTpHCPortOutFrames             .ForwardOutBound
       dot1dTpHCPortInDiscards            .DiscardInbound
     dot1dTpPortOverflowTable
       dot1dTpPortInOverflowFrames      .BridgePort.FramesReceived
       dot1dTpPortOutOverflowFrames       .ForwardOutBound
       dot1dTpPortInOverflowDiscards      .DiscardInbound
ToP   noToC   RFC2674 - Page 8
   The following IEEE 802.1D-1998 management objects have not been
   included in the Bridge MIB for the indicated reasons.

   IEEE 802.1D-1998 Object           Disposition

   Bridge.StateValue                 not considered useful
   Bridge.ApplicantAdministrativeControl
                                     not provided per-attribute
                                     (e.g. per-VLAN, per-Group).
                                     Only per-{device,port,application}
                                     control is provided in this MIB.

3.1.2. Relationship to IEEE 802.1Q Manageable Objects

This section contains section number cross-references to manageable objects defined in IEEE 802.1Q-1998 [802.1Q]. These objects have been included in this MIB as they provide a natural fit with the IEEE 802.1D objects with which they are co-located. Extended Bridge MIB Name IEEE 802.1Q-1998 Section and Name dot1dExtBase Bridge dot1dDeviceCapabilities dot1qStaticEntryIndividualPort 5.2 implementation options dot1qIVLCapable dot1qSVLCapable dot1qHybridCapable dot1qConfigurablePvidTagging 12.10.1.1 read bridge vlan config dot1dLocalVlanCapable dot1dPortCapabilitiesTable dot1dPortCapabilities dot1qDot1qTagging 5.2 implementation options dot1qConfigurableAcceptableFrameTypes 5.2 implementation options dot1qIngressFiltering 5.2 implementation options

3.1.3. The dot1dExtBase Group

This group contains the objects which are applicable to all bridges implementing the traffic class and multicast filtering features of IEEE 802.1D-1998 [802.1D]. It includes per-device configuration of GARP and GMRP protocols. This group will be implemented by all devices which implement the extensions defined in 802.1D-1998.
ToP   noToC   RFC2674 - Page 9

3.1.4. The dot1dPriority Group

This group contains the objects for configuring and reporting status of priority-based queuing mechanisms in a bridge. This includes per- port user_priority treatment, mapping of user_priority in frames into internal traffic classes and outbound user_priority and access_priority.

3.1.5. The dot1dGarp Group

This group contains the objects for configuring and reporting on operation of the Generic Attribute Registration Protocol (GARP).

3.1.6. The dot1dGmrp Group

This group contains the objects for configuring and reporting on operation of the GARP Multicast Registration Protocol (GMRP).

3.1.7. The dot1dTpHCPortTable

This table extends the dot1dTp group from the original bridge MIB [BRIDGEMIB] and contains the objects for reporting port bridging statistics for high capacity network interfaces.

3.1.8. The dot1dTpPortOverflowTable

This table extends the dot1dTp group from the original bridge MIB [BRIDGEMIB] and contains the objects for reporting the upper bits of port bridging statistics for high capacity network interfaces for when 32-bit counters are inadequate.

3.2. Structure of Virtual Bridge MIB module

Objects in this MIB are arranged into groups. Each group is organized as a set of related objects. The overall structure and assignment of objects to their groups is shown below. Some manageable objects defined in the original bridge MIB [BRIDGEMIB] need to be indexed differently when they are used in a VLAN bridging environment: these objects are, therefore, effectively duplicated by new objects with different indexing which are defined in the Virtual Bridge MIB.

3.2.1. Relationship to IEEE 802.1Q Manageable Objects

This section contains section-number cross-references to manageable objects defined in clause 12 of IEEE 802.1Q-1998 [802.1Q]. It also details those objects that are not considered necessary in this MIB module.
ToP   noToC   RFC2674 - Page 10
   Note: unlike IEEE 802.1D-1998, IEEE 802.1Q-1998 [802.1Q] did not
   define exact syntax for a set of managed objects: the following
   cross-references indicate the section numbering of the descriptions
   of management operations from clause 12 in the latter document.

   Virtual Bridge MIB object          IEEE 802.1Q-1998 Reference

   dot1qBase
     dot1qVlanVersionNumber           12.10.1.1 read bridge vlan config
     dot1qMaxVlanId                   12.10.1.1 read bridge vlan config
     dot1qMaxSupportedVlans           12.10.1.1 read bridge vlan config
     dot1qNumVlans
     dot1qGvrpStatus                  12.9.2.1/2 read/set garp
                                                applicant controls
   dot1qTp
     dot1qFdbTable
       dot1qFdbId
       dot1qFdbDynamicCount           12.7.1.1.3 read filtering d/base
     dot1qTpFdbTable
       dot1qTpFdbAddress
       dot1qTpFdbPort
       dot1qTpFdbStatus
     dot1qTpGroupTable                12.7.7.1 read filtering entry
       dot1qTpGroupAddress
       dot1qTpGroupEgressPorts
       dot1qTpGroupLearnt
     dot1qForwardAllTable             12.7.7.1 read filtering entry
       dot1qForwardAllPorts
       dot1qForwardAllStaticPorts
       dot1qForwardAllForbiddenPorts
     dot1qForwardUnregisteredTable    12.7.7.1 read filtering entry
       dot1qForwardUnregisteredPorts
       dot1qForwardUnregisteredStaticPorts
       dot1qForwardUnregisteredForbiddenPorts
   dot1qStatic
     dot1qStaticUnicastTable          12.7.7.1 create/delete/read
                                                filtering entry
                                      12.7.6.1 read permanent database
       dot1qStaticUnicastAddress
       dot1qStaticUnicastReceivePort
       dot1qStaticUnicastAllowedToGoTo
       dot1qStaticUnicastStatus
     dot1qStaticMulticastTable        12.7.7.1 create/delete/read
                                                filtering entry
                                      12.7.6.1 read permanent database
       dot1qStaticMulticastAddress
       dot1qStaticMulticastReceivePort
       dot1qStaticMulticastStaticEgressPorts
ToP   noToC   RFC2674 - Page 11
       dot1qStaticMulticastForbiddenEgressPorts
       dot1qStaticMulticastStatus
   dot1qVlan
     dot1qVlanNumDeletes
     dot1qVlanCurrentTable            12.10.2.1 read vlan configuration
                                      12.10.3.5 read VID to FID
                                                allocations
                                      12.10.3.6 read FID allocated to
                                                VID
                                      12.10.3.7 read VIDs allocated to
                                                FID
       dot1qVlanTimeMark
       dot1qVlanIndex
       dot1qVlanFdbId
       dot1qVlanCurrentEgressPorts
       dot1qVlanCurrentUntaggedPorts
       dot1qVlanStatus
       dot1qVlanCreationTime
     dot1qVlanStaticTable             12.7.7.1/2/3 create/delete/read
                                                filtering entry
                                      12.7.6.1 read permanent database
                                      12.10.2.2 create vlan config
                                      12.10.2.3 delete vlan config
       dot1qVlanStaticName            12.4.1.3 set bridge name
       dot1qVlanStaticEgressPorts
       dot1qVlanForbiddenEgressPorts
       dot1qVlanStaticUntaggedPorts
       dot1qVlanStaticRowStatus
     dot1qNextFreeLocalVlanIndex
     dot1qPortVlanTable               12.10.1.1 read bridge vlan
                                                configuration
       dot1qPvid                      12.10.1.2 configure PVID values
       dot1qPortAcceptableFrameTypes  12.10.1.3 configure acceptable
                                                frame types parameter
       dot1qPortIngressFiltering      12.10.1.4 configure ingress
                                                filtering parameters
       dot1qPortGvrpStatus            12.9.2.2 read/set garp applicant
                                                controls
       dot1qPortGvrpFailedRegistrations
       dot1qPortGvrpLastPduOrigin
     dot1qPortVlanStatisticsTable     12.6.1.1 read forwarding port
                                                counters
       dot1qTpVlanPortInFrames
       dot1qTpVlanPortOutFrames
       dot1qTpVlanPortInDiscards
       dot1qTpVlanPortInOverflowFrames
       dot1qTpVlanPortOutOverflowFrames
       dot1qTpVlanPortInOverflowDiscards
ToP   noToC   RFC2674 - Page 12
     dot1qPortVlanHCStatisticsTable   12.6.1.1 read forwarding port
                                                counters
       dot1qTpVlanPortHCInFrames
       dot1qTpVlanPortHCOutFrames
       dot1qTpVlanPortHCInDiscards
     dot1qLearningConstraintsTable    12.10.3.1/3/4 read/set/delete
                                              vlan learning constraints
                                      12.10.3.2 read vlan learning
                                              constraints for VID
       dot1qConstraintVlan
       dot1qConstraintSet
       dot1qConstraintType
       dot1qConstraintStatus
     dot1qConstraintSetDefault
     dot1qConstraintTypeDefault

   The following IEEE 802.1Q management objects have not been included
   in the Bridge MIB for the indicated reasons.

      IEEE 802.1Q-1998 Operation          Disposition

      reset bridge (12.4.1.4)             not considered useful

      reset vlan bridge (12.10.1.5)       not considered useful

      read forwarding port counters (12.6.1.1)
        discard on error details          not considered useful

      read permanent database (12.7.6.1)
        permanent database size           not considered useful
        number of static filtering        count rows in
           entries                          dot1qStaticUnicastTable +
                                            dot1qStaticMulticastTable
        number of static VLAN             count rows in
          registration entries              dot1qVlanStaticTable

      read filtering entry range          use GetNext operation.
         (12.7.7.4)

      read filtering database (12.7.1.1)
        filtering database size           not considered useful
        number of dynamic group address   count rows applicable to each
            entries (12.7.1.3)            FDB in dot1dTpGroupTable
ToP   noToC   RFC2674 - Page 13
      read garp state (12.9.3.1)          not considered useful

      notify vlan registration failure    not considered useful
        (12.10.1.6)

      notify learning constraint violation
        (12.10.3.10)                      not considered useful

3.2.2. The dot1qBase Group

This mandatory group contains the objects which are applicable to all bridges implementing IEEE 802.1Q virtual LANs.

3.2.3. The dot1qTp Group

This group contains objects that control the operation and report the status of transparent bridging. This includes management of the dynamic Filtering Databases for both unicast and multicast forwarding. This group will be implemented by all bridges that perform destination-address filtering.

3.2.4. The dot1qStatic Group

This group contains objects that control static configuration information for transparent bridging. This includes management of the static entries in the Filtering Databases for both unicast and multicast forwarding.

3.2.5. The dot1qVlan Group

This group contains objects that control configuration and report status of the Virtual LANs known to a bridge. This includes management of the statically configured VLANs as well as reporting VLANs discovered by other means e.g. GVRP. It also controls configuration and reports status of per-port objects relating to VLANs and reports traffic statistics. It also provides for management of the VLAN Learning Constraints.

3.3. Textual Conventions

The datatypes MacAddress, BridgeId, Timeout, EnabledStatus, PortList, VlanIndex and VlanId 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.
ToP   noToC   RFC2674 - Page 14

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
ToP   noToC   RFC2674 - Page 15
   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.
ToP   noToC   RFC2674 - Page 16
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.
ToP   noToC   RFC2674 - Page 17
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.
ToP   noToC   RFC2674 - Page 18
   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.


(page 18 continued on part 2)

Next Section