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 RFC1493 [BRIDGEMIB] and (to a lesser extent)
RFC1525 [SBRIDGEMIB].
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
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, RFC1155 [V1SMI], STD 16, RFC1212 [V1CONCISE] and RFC1215
[V1TRAPS]. The second version, called SMIv2, is described in STD
58, RFC2578 [V2SMI], STD 58, RFC2579 [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, RFC1157 [V1PROTO]. A second version of the
SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901
[V2COMMUNITY] and RFC1906 [V2TRANS]. The third version of the
message protocol is called SNMPv3 and described in RFC1906
[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, RFC1157 [V1PROTO]. A second set of
protocol operations and associated PDU formats is described in
RFC1905 [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
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 RFC1493 [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 RFC1525 [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.
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.
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.
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
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.
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.
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
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
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
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.
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
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.
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.
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.
In a device supporting multiple Filtering Databases, this group is
interpreted as follows:
dot1dStaticTable
Entries read from this table include all static entries from all
of the Filtering Databases. Entries for the same MAC address
and receive port in more than one Filtering Database must appear
only once since these are the indices of this table. This table
should be implemented as read-only in devices that support
multiple Forwarding Databases - instead, write access should be
provided through dot1qStaticUnicastTable and
dot1qStaticMulticastTable, as defined in this document.
3.4.3.5. Additions to the Original Bridge MIB
In addition to the objects in the original bridge MIB [BRIDGEMIB],
this document contains:
(1) support for multiple traffic classes and dynamic multicast
filtering as per IEEE 802.1D-1998 [802.1D].
(2) support for bridged Virtual LANs as per IEEE 802.1Q-1998
[802.1Q].
(3) support for 64-bit versions of original bridge MIB [BRIDGEMIB]
port counters.
4. Definitions for Extended Bridge MIB
P-BRIDGE-MIB DEFINITIONS ::= BEGIN
-- -------------------------------------------------------------
-- MIB for IEEE 802.1p devices
-- -------------------------------------------------------------
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64
FROM SNMPv2-SMI
TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
dot1dTp, dot1dTpPort, dot1dBridge,
dot1dBasePortEntry, dot1dBasePort
FROM BRIDGE-MIB;
pBridgeMIB MODULE-IDENTITY
LAST-UPDATED "9908250000Z"
ORGANIZATION "IETF Bridge MIB Working Group"
CONTACT-INFO
" Les Bell
Postal: 3Com Europe Ltd.
3Com Centre, Boundary Way
Hemel Hempstead, Herts. HP2 7YU
UK
Phone: +44 1442 438025
Email: Les_Bell@3Com.com
Andrew Smith
Postal: Extreme Networks
3585 Monroe St.
Santa Clara CA 95051
USA
Phone: +1 408 579 2821
Email: andrew@extremenetworks.com
Paul Langille
Postal: Newbridge Networks
5 Corporate Drive
Andover, MA 01810
USA
Phone: +1 978 691 4665
Email: langille@newbridge.com
Anil Rijhsinghani
Postal: Cabletron Systems
50 Minuteman Road
Andover, MA 01810
USA
Phone: +1 978 684 1295
Email: anil@cabletron.com
Keith McCloghrie
Postal: cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5260
Email: kzm@cisco.com"
DESCRIPTION
"The Bridge MIB Extension module for managing Priority
and Multicast Filtering, defined by IEEE 802.1D-1998."
-- revision history
REVISION "9908250000Z"
DESCRIPTION
"Initial version, published as RFC2674."
::= { dot1dBridge 6 }
pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 }
-- -------------------------------------------------------------
-- Textual Conventions
-- -------------------------------------------------------------
EnabledStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A simple status value for the object."
SYNTAX INTEGER { enabled(1), disabled(2) }
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- groups in the P-BRIDGE MIB
-- -------------------------------------------------------------
dot1dExtBase OBJECT IDENTIFIER ::= { pBridgeMIBObjects 1 }
dot1dPriority OBJECT IDENTIFIER ::= { pBridgeMIBObjects 2 }
dot1dGarp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 3 }
dot1dGmrp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 4 }
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- the dot1dExtBase group
-- -------------------------------------------------------------
dot1dDeviceCapabilities OBJECT-TYPE
SYNTAX BITS {
dot1dExtendedFilteringServices(0),
-- can perform filtering of
-- individual multicast addresses
-- controlled by GMRP.
dot1dTrafficClasses(1),
-- can map user priority to
-- multiple traffic classes.
dot1qStaticEntryIndividualPort(2),
-- dot1qStaticUnicastReceivePort &
-- dot1qStaticMulticastReceivePort
-- can represent non-zero entries.
dot1qIVLCapable(3), -- Independent VLAN Learning.
dot1qSVLCapable(4), -- Shared VLAN Learning.
dot1qHybridCapable(5),
-- both IVL & SVL simultaneously.
dot1qConfigurablePvidTagging(6),
-- whether the implementation
-- supports the ability to
-- override the default PVID
-- setting and its egress status
-- (VLAN-Tagged or Untagged) on
-- each port.
dot1dLocalVlanCapable(7)
-- can support multiple local
-- bridges, outside of the scope
-- of 802.1Q defined VLANs.
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the optional parts of IEEE 802.1D and 802.1Q
that are implemented by this device and are manageable
through this MIB. Capabilities that are allowed on a
per-port basis are indicated in dot1dPortCapabilities."
REFERENCE
"ISO/IEC 15802-3 Section 5.2,
IEEE 802.1Q/D11 Section 5.2, 12.10.1.1.3/b/2"
::= { dot1dExtBase 1 }
dot1dTrafficClassesEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value true(1) indicates that Traffic Classes are
enabled on this bridge. When false(2), the bridge
operates with a single priority level for all traffic."
DEFVAL { true }
::= { dot1dExtBase 2 }
dot1dGmrpStatus OBJECT-TYPE
SYNTAX EnabledStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The administrative status requested by management for
GMRP. The value enabled(1) indicates that GMRP should
be enabled on this device, in all VLANs, on all ports
for which it has not been specifically disabled. When
disabled(2), GMRP is disabled, in all VLANs, on all
ports and all GMRP packets will be forwarded
transparently. This object affects both Applicant and
Registrar state machines. A transition from disabled(2)
to enabled(1) will cause a reset of all GMRP state
machines on all ports."
DEFVAL { enabled }
::= { dot1dExtBase 3 }
-- -------------------------------------------------------------
-- Port Capabilities Table
-- -------------------------------------------------------------
dot1dPortCapabilitiesTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dPortCapabilitiesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table that contains capabilities information about
every port that is associated with this bridge."
::= { dot1dExtBase 4 }
dot1dPortCapabilitiesEntry OBJECT-TYPE
SYNTAX Dot1dPortCapabilitiesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A set of capabilities information about this port
indexed by dot1dBasePort."
AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortCapabilitiesTable 1 }
Dot1dPortCapabilitiesEntry ::=
SEQUENCE {
dot1dPortCapabilities
BITS
}
dot1dPortCapabilities OBJECT-TYPE
SYNTAX BITS {
dot1qDot1qTagging(0), -- supports 802.1Q VLAN tagging of
-- frames and GVRP.
dot1qConfigurableAcceptableFrameTypes(1),
-- allows modified values of
-- dot1qPortAcceptableFrameTypes.
dot1qIngressFiltering(2)
-- supports the discarding of any
-- frame received on a Port whose
-- VLAN classification does not
-- include that Port in its Member
-- set.
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the parts of IEEE 802.1D and 802.1Q that are
optional on a per-port basis that are implemented by
this device and are manageable through this MIB."
REFERENCE
"ISO/IEC 15802-3 Section 5.2,
IEEE 802.1Q/D11 Section 5.2"
::= { dot1dPortCapabilitiesEntry 1 }
-- -------------------------------------------------------------
-- the dot1dPriority group
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- Port Priority Table
-- -------------------------------------------------------------
dot1dPortPriorityTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dPortPriorityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table that contains information about every port that
is associated with this transparent bridge."
::= { dot1dPriority 1 }
dot1dPortPriorityEntry OBJECT-TYPE
SYNTAX Dot1dPortPriorityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of Default User Priorities for each port of a
transparent bridge. This is indexed by dot1dBasePort."
AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortPriorityTable 1 }
Dot1dPortPriorityEntry ::=
SEQUENCE {
dot1dPortDefaultUserPriority
INTEGER,
dot1dPortNumTrafficClasses
INTEGER
}
dot1dPortDefaultUserPriority OBJECT-TYPE
SYNTAX INTEGER (0..7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default ingress User Priority for this port. This
only has effect on media, such as Ethernet, that do not
support native User Priority."
::= { dot1dPortPriorityEntry 1 }
dot1dPortNumTrafficClasses OBJECT-TYPE
SYNTAX INTEGER (1..8)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The number of egress traffic classes supported on this
port. This object may optionally be read-only."
::= { dot1dPortPriorityEntry 2 }
-- -------------------------------------------------------------
-- User Priority Regeneration Table
-- -------------------------------------------------------------
dot1dUserPriorityRegenTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dUserPriorityRegenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of Regenerated User Priorities for each received
User Priority on each port of a bridge. The Regenerated
User Priority value may be used to index the Traffic
Class Table for each input port. This only has effect
on media that support native User Priority. The default
values for Regenerated User Priorities are the same as
the User Priorities."
REFERENCE
"ISO/IEC 15802-3 Section 6.4"
::= { dot1dPriority 2 }
dot1dUserPriorityRegenEntry OBJECT-TYPE
SYNTAX Dot1dUserPriorityRegenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A mapping of incoming User Priority to a Regenerated
User Priority."
INDEX { dot1dBasePort, dot1dUserPriority }
::= { dot1dUserPriorityRegenTable 1 }
Dot1dUserPriorityRegenEntry ::=
SEQUENCE {
dot1dUserPriority
INTEGER,
dot1dRegenUserPriority
INTEGER
}
dot1dUserPriority OBJECT-TYPE
SYNTAX INTEGER (0..7)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The User Priority for a frame received on this port."
::= { dot1dUserPriorityRegenEntry 1 }
dot1dRegenUserPriority OBJECT-TYPE
SYNTAX INTEGER (0..7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The Regenerated User Priority the incoming User
Priority is mapped to for this port."
::= { dot1dUserPriorityRegenEntry 2 }
-- -------------------------------------------------------------
-- Traffic Class Table
-- -------------------------------------------------------------
dot1dTrafficClassTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dTrafficClassEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table mapping evaluated User Priority to Traffic
Class, for forwarding by the bridge. Traffic class is a
number in the range (0..(dot1dPortNumTrafficClasses-1))."
REFERENCE
"ISO/IEC 15802-3 Table 7-2"
::= { dot1dPriority 3 }
dot1dTrafficClassEntry OBJECT-TYPE
SYNTAX Dot1dTrafficClassEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"User Priority to Traffic Class mapping."
INDEX { dot1dBasePort, dot1dTrafficClassPriority }
::= { dot1dTrafficClassTable 1 }
Dot1dTrafficClassEntry ::=
SEQUENCE {
dot1dTrafficClassPriority
INTEGER,
dot1dTrafficClass
INTEGER
}
dot1dTrafficClassPriority OBJECT-TYPE
SYNTAX INTEGER (0..7)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Priority value determined for the received frame.
This value is equivalent to the priority indicated in
the tagged frame received, or one of the evaluated
priorities, determined according to the media-type.
For untagged frames received from Ethernet media, this
value is equal to the dot1dPortDefaultUserPriority value
for the ingress port.
For untagged frames received from non-Ethernet media,
this value is equal to the dot1dRegenUserPriority value
for the ingress port and media-specific user priority."
::= { dot1dTrafficClassEntry 1 }
dot1dTrafficClass OBJECT-TYPE
SYNTAX INTEGER (0..7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The Traffic Class the received frame is mapped to."
::= { dot1dTrafficClassEntry 2 }
-- -------------------------------------------------------------
-- Outbound Access Priority Table
-- -------------------------------------------------------------
dot1dPortOutboundAccessPriorityTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dPortOutboundAccessPriorityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table mapping Regenerated User Priority to Outbound
Access Priority. This is a fixed mapping for all port
types, with two options for 802.5 Token Ring."
REFERENCE
"ISO/IEC 15802-3 Table 7-3"
::= { dot1dPriority 4 }
dot1dPortOutboundAccessPriorityEntry OBJECT-TYPE
SYNTAX Dot1dPortOutboundAccessPriorityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Regenerated User Priority to Outbound Access Priority
mapping."
INDEX { dot1dBasePort, dot1dRegenUserPriority }
::= { dot1dPortOutboundAccessPriorityTable 1 }
Dot1dPortOutboundAccessPriorityEntry ::=
SEQUENCE {
dot1dPortOutboundAccessPriority
INTEGER
}
dot1dPortOutboundAccessPriority OBJECT-TYPE
SYNTAX INTEGER (0..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Outbound Access Priority the received frame is
mapped to."
::= { dot1dPortOutboundAccessPriorityEntry 1 }
-- -------------------------------------------------------------
-- the dot1dGarp group
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- The GARP Port Table
-- -------------------------------------------------------------
dot1dPortGarpTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dPortGarpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of GARP control information about every bridge
port. This is indexed by dot1dBasePort."
::= { dot1dGarp 1 }
dot1dPortGarpEntry OBJECT-TYPE
SYNTAX Dot1dPortGarpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"GARP control information for a bridge port."
AUGMENTS { dot1dBasePortEntry }