RFC 4363
Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions
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.
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
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
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].
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
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.
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).
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
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
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
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)
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.
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
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.
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.
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.
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.