tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4363

 Errata 
Proposed STD
Pages: 99
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: BRIDGE

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

Part 1 of 4, p. 1 to 17
None       Next RFC Part

Obsoletes:    2674


Top       ToC       Page 1 
Network Working Group                                            D. Levi
Request for Comments: 4363                               Nortel Networks
Obsoletes: 2674                                            D. Harrington
Category: Standards Track                             Effective Software
                                                            January 2006


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

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
   capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC
   Bridges and the IEEE 802.1Q-2003 (TM) 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 and
   P802.1t-2001 (TM).  The other MIB module defines objects for managing
   VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v
   (TM).

   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 supplements RFC 4188 and obsoletes RFC 2674.

Top       Page 2 
Table of Contents

   1. The Internet-Standard Management Framework ......................3
   2. Overview ........................................................3
      2.1. Scope ......................................................3
   3. Structure of MIBs ...............................................4
      3.1. Structure of Extended Bridge MIB Module ....................5
           3.1.1. Relationship to IEEE 802.1D-1998 Manageable
                  Objects .............................................5
           3.1.2. Relationship to IEEE 802.1Q Manageable Objects ......6
           3.1.3. The dot1dExtBase Subtree ............................7
           3.1.4. The dot1dPriority Subtree ...........................7
           3.1.5. The dot1dGarp Subtree ...............................7
           3.1.6. The dot1dGmrp Subtree ...............................7
           3.1.7. The dot1dTpHCPortTable ..............................8
           3.1.8. The dot1dTpPortOverflowTable ........................8
      3.2. Structure of Virtual Bridge MIB module .....................8
           3.2.1. Relationship to IEEE 802.1Q Manageable Objects ......8
           3.2.2. The dot1qBase Subtree ..............................12
           3.2.3. The dot1qTp Subtree ................................12
           3.2.4. The dot1qStatic Subtree ............................12
           3.2.5. The dot1qVlan Subtree ..............................12
      3.3. Textual Conventions .......................................12
      3.4. Relationship to Other MIBs ................................13
           3.4.1. Relationship to the SNMPv2-MIB .....................13
           3.4.2. Relationship to the IF-MIB .........................13
                  3.4.2.1. Layering Model ............................14
                  3.4.2.2. ifStackTable ..............................15
                  3.4.2.3. ifRcvAddressTable .........................15
           3.4.3. Relationship to the BRIDGE-MIB .....................16
                  3.4.3.1. The dot1dBase Subtree .....................16
                  3.4.3.2. The dot1dStp Subtree ......................16
                  3.4.3.3. The dot1dTp Subtree .......................16
                  3.4.3.4. The dot1dStatic Subtree ...................17
                  3.4.3.5. Additions to the BRIDGE-MIB ...............17
   4. Definitions for Extended Bridge MIB ............................18
   5. Definitions for Virtual Bridge MIB .............................42
   6. Acknowledgements ...............................................91
   7. Security Considerations ........................................91
   8. Normative References ...........................................94
   9. Informative References .........................................95
   Appendix A. Email from Tony Jeffrey from IEEE .....................96

Top      ToC       Page 3 
1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

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

   The transparent method of bridging is defined by IEEE 802.1D-1998
   [802.1D].  Managed objects for transparent bridging are defined in
   the BRIDGE-MIB [BRIDGE-MIB].

   The original IEEE 802.1D is augmented by IEEE 802.1Q-2003 [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, and port-and-protocol-based Virtual LANs where
   membership is determined by the bridge port on which frames are
   received and the protocol identifier of the frame.  This memo defines
   the objects needed for the management of port-based VLANs in bridge
   entities.

   This memo supplements RFC 4188 [BRIDGE-MIB] and obsoletes RFC 2674
   [RFC2674].

2.1.  Scope

   The MIB modules defined in this document include a comprehensive set
   of managed objects that attempts to match the set defined in IEEE
   802.1D and IEEE 802.1Q.  However, to be consistent with the spirit of

Top      ToC       Page 4 
   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.

   Historical note:

   The original BRIDGE-MIB [RFC1493] 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 that objects be essential for either fault or
         configuration management.

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

   (4)   Limit the total number of objects.

   (5)   Exclude objects that 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 objects that supplement those in the BRIDGE-MIB
   module [BRIDGE-MIB].  Section 3.4.3 of the present document contains
   some recommendations regarding usage of objects in the BRIDGE-MIB by
   devices implementing the enhancements defined here.

   An extended bridge MIB module P-BRIDGE-MIB defines managed objects
   for the traffic class and multicast filtering enhancements defined by
   IEEE 802.1D-1998 [802.1D], including the Restricted Group
   Registration control defined by IEEE P802.1t [802.1t].

   A virtual bridge MIB module Q-BRIDGE-MIB defines managed objects for
   the Virtual LAN bridging enhancements defined by IEEE 802.1Q-2003
   [802.1Q], including the Restricted VLAN Registration control, defined
   by IEEE P802.1u [802.1u], and the VLAN Classification by Protocol and
   Port enhancement, defined by IEEE P802.1v [802.1v].

Top      ToC       Page 5 
3.1.  Structure of Extended Bridge MIB Module

   Objects in this MIB are arranged into subtrees.  Each subtree is
   organized as a set of related objects.  The overall structure and
   assignment of objects to their subtrees is shown below.

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-Filtering-Database
   (per-FDB)) and so are not defined here.  Instead, devices that 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 that support Extended Filtering
   Services should support dot1qTpGroupTable, dot1qForwardAllTable, and
   dot1qForwardUnregisteredTable.

   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

Top      ToC       Page 6 
   dot1dGarp
     dot1dPortGarpTable
       dot1dPortGarpJoinTime            .JoinTime
       dot1dPortGarpLeaveTime           .LeaveTime
       dot1dPortGarpLeaveAllTime        .LeaveAllTime
   dot1dGmrp
     dot1dPortGmrpTable
       dot1dPortGmrpStatus             .ApplicantAdministrativeControl
       dot1dPortGmrpFailedRegistrations .FailedRegistrations
       dot1dPortGmrpLastPduOrigin       .OriginatorOfLastPDU
       dot1dPortRestrictedGroupRegistration
                                        Restricted Group Registration
                                        (Ref. IEEE 802.1t 10.3.2.3)
   dot1dTp
     dot1dTpHCPortTable
       dot1dTpHCPortInFrames            .BridgePort.FramesReceived
       dot1dTpHCPortOutFrames             .ForwardOutBound
       dot1dTpHCPortInDiscards            .DiscardInbound
     dot1dTpPortOverflowTable
       dot1dTpPortInOverflowFrames      .BridgePort.FramesReceived
       dot1dTpPortOutOverflowFrames       .ForwardOutBound
       dot1dTpPortInOverflowDiscards      .DiscardInbound

   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.

   notify group registration failure    not considered useful
     (IEEE 802.1t 14.10.1.2)

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

Top      ToC       Page 7 
   Extended Bridge MIB Name            IEEE 802.1Q-2003 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 Subtree

   This subtree contains the objects that 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
   Generic Attribute Registration Protocol (GARP) and GARP Multicast
   Registration Protocol (GMRP) protocols.

3.1.4.  The dot1dPriority Subtree

   This subtree 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 Subtree

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

3.1.6.  The dot1dGmrp Subtree

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

Top      ToC       Page 8 
3.1.7.  The dot1dTpHCPortTable

   This table extends the dot1dTp subtree from the BRIDGE-MIB
   [BRIDGE-MIB] and contains the objects for reporting port-bridging
   statistics for high-capacity network interfaces.

3.1.8.  The dot1dTpPortOverflowTable

   This table extends the dot1dTp subtree from the BRIDGE-MIB
   [BRIDGE-MIB] 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 subtrees.  Each subtree is
   organized as a set of related objects.  The overall structure and
   assignment of objects to their subtrees is shown below.  Some
   manageable objects defined in the BRIDGE-MIB [BRIDGE-MIB] 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-2003 [802.1Q].  It also
   details those objects that are not considered necessary in this MIB
   module.

   Note: Unlike IEEE 802.1D-1998, IEEE 802.1Q-2003 [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-2003 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

Top      ToC       Page 9 
       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
       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

Top      ToC       Page 10 
       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
       dot1qPortRestrictedVlanRegistration
                                      IEEE 802.1u 11.2.3.2.3
                                           Restricted VLAN Registration
     dot1qPortVlanStatisticsTable     12.6.1.1 read forwarding port
                                                counters
       dot1qTpVlanPortInFrames
       dot1qTpVlanPortOutFrames
       dot1qTpVlanPortInDiscards
       dot1qTpVlanPortInOverflowFrames
       dot1qTpVlanPortOutOverflowFrames
       dot1qTpVlanPortInOverflowDiscards
     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

Top      ToC       Page 11 
     dot1qConstraintTypeDefault

   dot1vProtocol                      IEEE 802.1v Reference:
     dot1vProtocolGroupTable            8.6.4 Protocol Group Database,
                                        8.6.2 Protocol Template
       dot1vProtocolTemplateFrameType
       dot1vProtocolTemplateProtocolValue
       dot1vProtocolGroupId             8.6.3 Protocol Group Identifier
       dot1vProtocolGroupRowStatus
     dot1vProtocolPortTable             8.4.4 VID Set for each Port
       dot1vProtocolPortGroupId
       dot1vProtocolGroupVid
       dot1vProtocolPortRowStatus


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

      IEEE 802.1Q-2003 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

      read garp state (12.9.3.1)          not considered useful

      notify vlan registration failure    not considered useful
        (12.10.1.6)

Top      ToC       Page 12 
      notify learning constraint violation
        (12.10.3.10)                      not considered useful

3.2.2.  The dot1qBase Subtree

   This subtree contains the objects that are applicable to all bridges
   implementing IEEE 802.1Q virtual LANs.

3.2.3.  The dot1qTp Subtree

   This subtree 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 subtree will be implemented by all bridges that
   perform destination-address filtering.

3.2.4.  The dot1qStatic Subtree

   This subtree 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 Subtree

   This subtree 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., GARP VLAN Registration
   Protocol (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

   Various Working Groups have defined standards-track MIB documents
   (for example, [RFC2613] and [RFC3318]), that contain objects and
   Textual Conventions to represent a Virtual Local Area Network
   Identifier (VLAN-ID) [802.1Q].  New definitions are showing up in
   various documents (for example, [RFC4323] and [RFC4149]).
   Unfortunately, the result is a set of different definitions for the
   same piece of management information.  This may lead to confusion and
   unnecessary complexity.  In order to address this situation, three
   new textual conventions are defined in the Q-BRIDGE-MIB, called
   VlanIdOrAny, VlanIdOrNone, and VlanIdOrAnyOrNone.  These new textual
   conventions should be (re)used in MIB modules so that they all
   represent a VLAN-ID in the same way.

Top      ToC       Page 13 
   These textual conventions provide a means to specify MIB objects that
   refer to a specific VLAN, to any VLAN, or to no VLAN.  For an example
   of how these textual conventions might be used, consider a MIB
   object, with SYNTAX of VlanIdOrAnyOrNone, that specifies the VLAN on
   which to accept incoming packets of a particular protocol.  Such an
   object would allow the device to be configured to accept packets of
   this protocol received with a specific 802.1q tag value, with any
   802.1q tag value, or with no 802.1q tag.  Note that a MIB object that
   is defined using one of these textual conventions should clarify the
   meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause.

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

3.4.1.  Relationship to the SNMPv2-MIB

   The SNMPv2-MIB [RFC3418] defines objects that are generally
   applicable to managed devices.  These objects apply to the device as
   a whole, irrespective of whether bridging is the device's sole
   functionality or only a subset of the device's functionality.

   Full support for the 802.1D management objects requires that the
   SNMPv2-MIB objects sysDescr and sysUpTime be implemented.  Note that
   compliance to the current SNMPv2-MIB module requires additional
   objects and notifications to be implemented as specified in RFC 3418
   [RFC3418].

3.4.2.  Relationship to the IF-MIB

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

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

   The IF-MIB [RFC2863] defines managed objects for managing network
   interfaces.  A network interface is considered 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

Top      ToC       Page 14 
   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.

   Full support for the 802.1D management objects requires that the
   IF-MIB objects ifIndex, ifType, ifDescr, ifPhysAddress, and
   ifLastChange are implemented.  Note that compliance to the current
   IF-MIB module requires additional objects and notifications to be
   implemented as specified in RFC 2863 [RFC2863].

   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' subtree (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
   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 delineated according to a set of protocols, with
   some protocols being bridged, and other protocols not being bridged.
   For example, in an entity that exclusively performed bridging, all
   protocols would be considered bridged, whereas in an entity that
   performed IP routing on IP datagrams and only bridged other
   protocols, only the non-IP data would be considered 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
   that 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 Subtree to be
   in accordance with the IF-MIB [RFC2863], 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.

Top      ToC       Page 15 
   This document does not make any assumption that within an entity,
   VLANs that are instantiated as an entry in dot1qVlanCurrentTable by
   either management configuration through dot1qVlanStaticTable or by
   dynamic means (e.g., through GVRP) are 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.

3.4.2.2.  ifStackTable

   In addition, the IF-MIB [RFC2863] 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 (for example) 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 that are
   accepted for possible forwarding out some other port.  This table is
   explicitly not intended to provide a bridge address filtering
   mechanism.

Top      ToC       Page 16 
3.4.3.  Relationship to the BRIDGE-MIB

   This section defines how objects in the BRIDGE-MIB module
   [BRIDGE-MIB] should be represented for devices that implement the
   extensions: some of the old objects are less useful in such devices
   but must still be implemented for reasons of backwards compatibility.

3.4.3.1.  The dot1dBase Subtree

   This subtree contains objects that are applicable to all types of
   bridges.  Interpretation of this subtree is unchanged.

3.4.3.2.  The dot1dStp Subtree

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

3.4.3.3.  The dot1dTp Subtree

   This subtree 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 subtree is unchanged.

   In a device supporting multiple Filtering Databases, this subtree 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 learned in.  If an address has
        been learned in multiple databases on a single port, report it
        only once.  If an address has been learned in multiple databases
        on more than one port, report the entry on any one of the valid
        ports.

Top      ToC       Page 17 
   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 conformance statements to indicate for which speeds
        of interface they are required.

3.4.3.4.  The dot1dStatic Subtree

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

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

   In a device supporting multiple Filtering Databases, this subtree 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 BRIDGE-MIB

   To supplement the BRIDGE-MIB [BRIDGE-MIB], this module 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-2003
         [802.1Q].

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


Next RFC Part