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

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.

Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI].

This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) RFC 1525 [SBRIDGEMIB].

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:

• An overall architecture, described in an Architecture for Describing SNMP Management Frameworks [ARCH].
  
  
• Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC 1215 [V1TRAPS]. The second version, called SMIv2, is described in STD 58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD 58, RFC 2580 [V2CONFORM].
  
  
• Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [V1PROTO]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [V2COMMUNITY] and RFC 1906 [V2TRANS]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [V2TRANS], Message Processing and Dispatching [V3MPC] and User- based Security Model [V3USM].
  
  
• Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [V1PROTO]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [V2PROTO].
  
  
• 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 RFC 1493 [BRIDGEMIB].

The original IEEE 802.1D is augmented by IEEE 802.1Q-1998 [802.1Q] to provide support for 'virtual bridged LANs' where a single bridged physical LAN network may be used to support multiple logical bridged LANs, each of which offers a service approximately the same as that defined by IEEE 802.1D. Such virtual LANs (VLANs) are an integral feature of switched LAN networks. A VLAN can be viewed as a group of end-stations on multiple LAN segments and can communicate as if they were on a single LAN. IEEE 802.1Q defines port-based Virtual LANs where membership is determined by the bridge port on which data frames are received. This memo defines the objects needed for the management of port-based VLANs in bridge entities.

This memo defines those objects needed for the management of a bridging entity operating in the transparent mode, as well as some objects applicable to all types of bridges. Managed objects for Source-Route bridging are defined in RFC 1525 [SRBRIDGEMIB].

2.1. Scope

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

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.

dot1dPortOutboundAccessPriority
dot1dGarp

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

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.

dot1qForwardUnregisteredPorts dot1qForwardUnregisteredStaticPorts dot1qForwardUnregisteredForbiddenPorts

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 VID	FID allocated to
	12.10.3.7	read FID	VIDs allocated to

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 dot1qVlanStaticEgressPorts dot1qVlanForbiddenEgressPorts dot1qVlanStaticUntaggedPorts dot1qVlanStaticRowStatus	12.4.1.3 set bridge name
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 number of static filtering entries number of static VLAN registration entries	not considered useful count rows in dot1qStaticUnicastTable + dot1qStaticMulticastTable count rows in dot1qVlanStaticTable
read filtering entry range (12.7.7.4)	use GetNext operation.
read filtering database (12.7.1.1) filtering database size number of dynamic group address entries (12.7.1.3)	not considered useful count rows applicable to each 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 RFC 2674."

::= { dot1dBridge 6 }

pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 }

-- Textual Conventions

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

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,

"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

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

dot1dPortDefaultUserPriority INTEGER,
dot1dPortNumTrafficClasses

-- User Priority Regeneration Table

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 }

-- Traffic Class Table

REFERENCE

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

-- Outbound Access Priority Table

-- the dot1dGarp group

-- The GARP Port Table

-- The GMRP Port Configuration and Status Table

DESCRIPTION

"The administrative state of GMRP operation on this port. The value enabled(1) indicates that GMRP is enabled on this port in all VLANs as long as dot1dGmrpStatus is also enabled(1). A value of disabled(2) indicates that GMRP is disabled on this port in all VLANs: any GMRP packets received will be silently discarded and no GMRP registrations will be propagated from other ports. Setting this to a value of enabled(1) will be stored by the agent but will only take effect on the GMRP protocol operation if dot1dGmrpStatus also indicates the value enabled(1). This object affects all GMRP Applicant and Registrar state machines on this port. A transition from disabled(2) to enabled(1) will

-- High Capacity Port Table for Transparent Bridges

by this object if and only if it is for a protocol being processed by the local bridging function, including bridge management frames."

REFERENCE

by this object if and only if it is for a protocol being processed by the local bridging function, including bridge management frames."

REFERENCE

-- Upper part of High Capacity Port Table for Transparent Bridges

defined in the conformance clauses for this table. This table is provided as a way to read 64-bit counters for agents which support only SNMPv1.

Note that the reporting of most-significant and least-significant counter bits separately runs the risk of missing an overflow of the lower bits in the interval between sampling. The manager must be aware of this possibility, even within the same varbindlist, when interpreting the results of

DESCRIPTION

"The number of times the associated dot1dTpPortInDiscards counter has overflowed."

REFERENCE

"ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpPortOverflowEntry 3 }

-- IEEE 802.1p MIB - Conformance Information

pBridgeConformance OBJECT IDENTIFIER ::= { pBridgeMIB 2 }

pBridgeGroups OBJECT IDENTIFIER ::= { pBridgeConformance 1 }

pBridgeCompliances OBJECT IDENTIFIER
    ::= { pBridgeConformance 2 }

-- units of conformance

pBridgeAccessPriorityGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortOutboundAccessPriority
    }
    STATUS      current
    DESCRIPTION
        "A collection of objects defining the media dependent
        outbound access level for each priority."
    ::= { pBridgeGroups 7 }

pBridgePortGarpGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortGarpJoinTime,
        dot1dPortGarpLeaveTime,
        dot1dPortGarpLeaveAllTime
    }
    STATUS      current
    DESCRIPTION
        "A collection of objects providing port level control
        and status information for GARP operation."
    ::= { pBridgeGroups 8 }

pBridgePortGmrpGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortGmrpStatus,
        dot1dPortGmrpFailedRegistrations,
        dot1dPortGmrpLastPduOrigin
    }
    STATUS      current
    DESCRIPTION
        "A collection of objects providing port level control
        and status information for GMRP operation."
    ::= { pBridgeGroups 9 }

pBridgeHCPortGroup OBJECT-GROUP
    OBJECTS {
        dot1dTpHCPortInFrames,
        dot1dTpHCPortOutFrames,
        dot1dTpHCPortInDiscards
    }
    STATUS      current
    DESCRIPTION
        "A collection of objects providing 64-bit statistics
         counters for high capacity bridge ports."
    ::= { pBridgeGroups 10 }

-- compliance statements

pBridgeCompliance MODULE-COMPLIANCE

STATUS current
DESCRIPTION

"The compliance statement for device support of Priority and Multicast Filtering extended bridging services."

MODULE
	MANDATORY-GROUPS { pBridgeExtCapGroup }
	GROUP pBridgeDeviceGmrpGroup DESCRIPTION "This group is mandatory for devices supporting the GMRP application, defined by IEEE 802.1D Extended Filtering Services."
	GROUP pBridgeDevicePriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by IEEE 802.1D."
	GROUP pBridgeDefaultPriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by the extended bridge services with media types, such as Ethernet, that do not support native User Priority."

GROUP pBridgeRegenPriorityGroup
DESCRIPTION
"This group is mandatory only for devices supporting
the priority forwarding operations defined by IEEE 802.1D
and which have interface media types that support
native User Priority e.g. IEEE 802.5."

GROUP pBridgePriorityGroup
DESCRIPTION
"This group is mandatory only for devices supporting
the priority forwarding operations defined by IEEE 802.1D."

GROUP pBridgeAccessPriorityGroup
DESCRIPTION
"This group is optional and is relevant only for devices
supporting the priority forwarding operations defined by
IEEE 802.1D and which have interface media types that support
native Access Priority e.g. IEEE 802.5."

GROUP pBridgePortGarpGroup
DESCRIPTION
"This group is mandatory for devices supporting any
of the GARP applications: e.g. GMRP, defined by the
extended filtering services of 802.1D; or GVRP,
defined by 802.1Q (refer to the Q-BRIDGE-MIB for
conformance statements for GVRP)."

GROUP pBridgePortGmrpGroup
DESCRIPTION
"This group is mandatory for devices supporting the
GMRP application, as defined by IEEE 802.1D Extended
Filtering Services."

GROUP pBridgeHCPortGroup
DESCRIPTION
"Support for this group in a device is mandatory for those
bridge ports which map to network interfaces that have the
value of the corresponding instance of ifSpeed
greater than 650,000,000 bits/second."

GROUP pBridgePortOverflowGroup
DESCRIPTION
"Support for this group in a device is mandatory for those
bridge ports which map to network interfaces that have the
value of the corresponding instance of ifSpeed
greater than 650,000,000 bits/second."

OBJECT dot1dPortNumTrafficClasses
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."

OBJECT dot1dTrafficClass
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."

OBJECT dot1dRegenUserPriority
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."

::= { pBridgeCompliances 1 }

END

5. Definitions for Virtual Bridge MIB

Q-BRIDGE-MIB DEFINITIONS ::= BEGIN

-- MIB for IEEE 802.1Q Devices

IMPORTS

MODULE-IDENTITY, OBJECT-TYPE,
Counter32, Counter64, Unsigned32, TimeTicks

FROM SNMPv2-SMI

RowStatus, TruthValue, TEXTUAL-CONVENTION, MacAddress

FROM SNMPv2-TC

SnmpAdminString

FROM SNMP-FRAMEWORK-MIB

MODULE-COMPLIANCE, OBJECT-GROUP

FROM SNMPv2-CONF

dot1dBridge, dot1dBasePortEntry, dot1dBasePort

FROM BRIDGE-MIB

EnabledStatus

FROM P-BRIDGE-MIB

TimeFilter

FROM RMON2-MIB;

qBridgeMIB 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 VLAN Bridge MIB module for managing Virtual Bridged Local Area Networks, as defined by IEEE 802.1Q-1998."

-- revision history

REVISION "9908250000Z"
DESCRIPTION

"Initial version, published as RFC 2674."

::= { dot1dBridge 7 }

qBridgeMIBObjects OBJECT IDENTIFIER ::= { qBridgeMIB 1 }

-- Textual Conventions

Within each octet, the most significant bit represents the lowest numbered port, and the least significant bit represents the highest numbered port. Thus, each port of the bridge is represented by a single bit within the value of this object. If that bit has a value of '1' then that port is included in the set of ports; the port

global scope within a given bridged domain (see VlanId textual convention). If the value is greater than 4095 then it represents a VLAN with scope local to the particular agent, i.e. one without a global VLAN-ID assigned to it. Such VLANs are outside the scope of IEEE 802.1Q but it is convenient to be able to manage them

in the same way using this MIB."
SYNTAX Unsigned32

-- dot1qBase group

not been specifically disabled. When disabled(2), GVRP is disabled on all ports and all GVRP packets will be forwarded transparently. This object affects all GVRP Applicant and Registrar state machines. A transition from disabled(2) to enabled(1) will cause a reset of all

GVRP state machines on all ports."
DEFVAL { enabled }
::= { dot1qBase 5 }

-- the dot1qTp group

-- the current Filtering Database Table

-- Multiple Forwarding Databases for 802.1Q Transparent devices -- This table is an alternative to the dot1dTpFdbTable, -- previously defined for 802.1D devices which only support a -- single Forwarding Database.

transparent bridging function in determining how to propagate a received frame."

REFERENCE

DESCRIPTION

"A unicast MAC address for which the device has

been seen. A value of '0' indicates that the port number has not been learned but that the device does have some forwarding/filtering information about this address (e.g. in the dot1qStaticUnicastTable). Implementors are encouraged to assign the port value to this object whenever it is learned even for addresses for which the corresponding value of dot1qTpFdbStatus is

self(4)

the value of the corresponding instance of dot1qTpFdbAddress represents one of the device's addresses. The corresponding instance of dot1qTpFdbPort indicates which of the device's ports has this address.

mgmt(5) - the value of the corresponding instance of

	dot1qTpFdbAddress is also the value of an existing instance of dot1qStaticAddress."
::= {	dot1qTpFdbEntry 3 }

-- Dynamic Group Registration Table

ports to which frames received on a VLAN for this FDB and containing a specific Group destination address are

a specific Group destination address, are allowed to be forwarded. The subset of these ports learnt dynamically

dot1qTpGroupLearnt

-- Service Requirements Group

management or dynamically by GMRP. An entry appears in this table for all VLANs that are currently

instantiated."

REFERENCE

DESCRIPTION

"The set of ports configured by management in this VLAN to which all multicast group-addressed frames are to be forwarded. Ports entered in this list will also appear in the complete set shown by dot1qForwardAllPorts. This value will be restored after the device is reset. This only applies to ports that are members of the VLAN, defined by dot1qVlanCurrentEgressPorts. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardAllForbiddenPorts. The default value is a string of ones of appropriate length, to indicate standard non-EFS behaviour, i.e. forward

GMRP. This value will be restored after the device is reset. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardAllStaticPorts. The default value is a

more specific forwarding information applies. This is configured statically by management and determined dynamically by GMRP. An entry appears in this table for all VLANs that are currently instantiated."

REFERENCE

"IEEE 802.1Q/D11 Section 12.7.2, 12.7.7"
::= { dot1qTp 5 }

dot1qForwardUnregisteredEntry OBJECT-TYPE
SYNTAX Dot1qForwardUnregisteredEntry

This includes ports for which this need has been determined dynamically by GMRP, or configured statically

are to be forwarded. Ports entered in this list will also appear in the complete set shown by dot1qForwardUnregisteredPorts. This value will be restored after the device is reset. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardUnregisteredForbiddenPorts. The

default value is a string of zeros of appropriate length, although this has no effect with the default

registered by GMRP. This value will be restored after the device is reset. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardUnregisteredStaticPorts. The default value

is a string of zeros of appropriate length."
::= { dot1qForwardUnregisteredEntry 3 }

-- The Static (Destination-Address Filtering) Database

specifying the set of ports to which frames received from specific ports and containing specific unicast destination addresses are allowed to be forwarded. A value of zero in this table as the port number from which frames with a specific destination address are received, is used to specify all ports for which there is no specific entry in this table for that particular destination address. Entries are valid for unicast addresses only."

REFERENCE

"IEEE 802.1Q/D11 Section 12.7.7,

ISO/IEC 15802-3 Section 7.9.1"
::= { dot1qStatic 1 }

dot1qStaticUnicastAllowedToGoTo PortList,
dot1qStaticUnicastStatus

indicates that this entry applies on all ports of the

ports a specific unicast address may be dynamically learnt on. The dot1qTpFdbTable will have an equivalent entry with a dot1qTpFdbPort value of '0' until this address has been learnt, when it will be updated with the port the address has been seen on. This only applies to ports that are members of the VLAN, defined by dot1qVlanCurrentEgressPorts. The default value of this object is a string of ones of appropriate length."

REFERENCE

deleteOnTimeout(5) - this entry is currently in

specifying the set of ports to which frames received from specific ports and containing specific Multicast and Broadcast destination addresses are allowed to be forwarded. A value of zero in this table as the port number from which frames with a specific destination address are received, is used to specify all ports for which there is no specific entry in this table for that particular destination address. Entries are valid for Multicast and Broadcast addresses only."

REFERENCE

"IEEE 802.1Q/D11 Section 12.7.7,

dot1qStaticMulticastStaticEgressPorts PortList,
dot1qStaticMulticastForbiddenEgressPorts PortList,
dot1qStaticMulticastStatus

DESCRIPTION

"The set of ports to which frames received from a specific port and destined for a specific Multicast or Broadcast MAC address must be forwarded, regardless of any dynamic information e.g. from GMRP. A port may not be added in this set if it is already a member of the set of ports in dot1qStaticMulticastForbiddenEgressPorts. The default value of this object is a string of ones of

of any dynamic information e.g. from GMRP. A port may not be added in this set if it is already a member of the set of ports in dot1qStaticMulticastStaticEgressPorts. The default value of this object is a string of zeros of

deleteOnReset(4)

this entry is currently in use and will remain so until the next reset of the bridge.

deleteOnTimeout(5) - this entry is currently in

use and will remain so until it is aged out."
DEFVAL { permanent }
::= { dot1qStaticMulticastEntry 5 }

-- The Current VLAN Database

dot1qVlanNumDeletes OBJECT-TYPE

SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION

"The number of times a VLAN entry has been deleted from the dot1qVlanCurrentTable (for any reason). If an entry is deleted, then inserted, and then deleted, this

dot1qVlanFdbId
Unsigned32,
dot1qVlanCurrentEgressPorts
PortList,
dot1qVlanCurrentUntaggedPorts PortList,
dot1qVlanStatus
INTEGER,
dot1qVlanCreationTime

the VLAN is created: either dynamically by GVRP, or by

management, in dot1qVlanStaticTable. Allocation of this value follows the learning constraints defined for this

-- The Static VLAN Database

dot1qVlanForbiddenEgressPorts PortList,

dot1qVlanStaticUntaggedPorts PortList,
dot1qVlanStaticRowStatus

Registrar control for Registration Fixed for the relevant GVRP state machine on each port. A port may not be added in this set if it is already a member of the set of ports in dot1qVlanForbiddenEgressPorts. The default value of this object is a string of zeros of appropriate length, indicating not fixed."

REFERENCE

or excluded affect the per-port per-VLAN Registrar

control for Registration Forbidden for the relevant GVRP state machine on each port. A port may not be added in this set if it is already a member of the set of ports in dot1qVlanStaticEgressPorts. The default value of this object is a string of zeros of appropriate length, excluding all ports from the forbidden set."

REFERENCE

of appropriate length including all ports. There is no specified default for other VLANs. If a device agent cannot support the set of ports being set then it will reject the set operation with an error. An example might be if a manager attempts to set more than one VLAN to be untagged on egress where the device does not support this IEEE 802.1Q option."

REFERENCE

the value 0 if this is not possible.

A row creation operation in this table for an entry with a local VlanIndex value may fail if the current value of this object is not used as the index. Even if the value read is used, there is no guarantee that it will still be the valid index when the create operation is attempted - another manager may have already got in during the intervening time interval. In this case, dot1qNextFreeLocalVlanIndex should be re-read and the creation re-tried with the new value.

This value will automatically change when the current value is

used to create a new row."
::= { dot1qVlan 4 }

-- The VLAN Port Configuration Table

dot1qPortIngressFiltering
TruthValue,
dot1qPortGvrpStatus
EnabledStatus,

dot1qPortGvrpFailedRegistrations Counter32,
dot1qPortGvrpLastPduOrigin

frames or Priority-Tagged frames received on this port will be accepted and assigned to the PVID for this port.

This control does not affect VLAN independent BPDU frames, such as GVRP and STP. It does affect VLAN dependent BPDU frames, such as GMRP."

REFERENCE

DESCRIPTION

"When this is true(1) the device will discard incoming frames for VLANs which do not include this Port in its Member set. When false(2), the port will accept all incoming frames.

This control does not affect VLAN independent BPDU frames, such as GVRP and STP. It does affect VLAN dependent BPDU frames, such as GMRP."

REFERENCE

device. When disabled(2) but dot1qGvrpStatus is still enabled for the device, GVRP is disabled on this port: any GVRP packets received will be silently discarded and no GVRP registrations will be propagated from other ports. This object affects all GVRP Applicant and Registrar state machines on this port. A transition from disabled(2) to enabled(1) will cause a reset of all

DESCRIPTION

"The Source MAC Address of the last GVRP message

received on this port."
::= { dot1qPortVlanEntry 6 }

-- Per port VLAN Statistics Table

counters for ports that are associated with this transparent bridge. The most-significant bit objects are only required on high capacity interfaces, as defined in the conformance clauses for these objects. This mechanism is provided as a way to read 64-bit counters for agents which support only SNMPv1.

Note that the reporting of most-significant and least- significant counter bits separately runs the risk of missing an overflow of the lower bits in the interval between sampling. The manager must be aware of this possibility, even within the same varbindlist, when interpreting the results of a request or

dot1qTpVlanPortInFrames
Counter32,
dot1qTpVlanPortOutFrames
Counter32,
dot1qTpVlanPortInDiscards
Counter32,
dot1qTpVlanPortInOverflowFrames Counter32,
dot1qTpVlanPortOutOverflowFrames Counter32,
dot1qTpVlanPortInOverflowDiscards

counted by this object if and only if it is for a protocol being processed by the local forwarding process for this VLAN. This object includes received bridge management frames classified as belonging to this VLAN (e.g. GMRP, but not GVRP or STP)."

REFERENCE

by this device which are classified as belonging to this VLAN (e.g. GMRP, but not GVRP or STP)."

REFERENCE

"IEEE 802.1Q/D11 Section 12.6.1.1.3(d)"
::= { dot1qPortVlanStatisticsEntry 2 }

Specifically, the IEEE 802.1Q counters for Discard Inbound and Discard on Ingress Filtering."

REFERENCE

counted by this object if and only if it is for a protocol being processed by the local forwarding process for this VLAN. This object includes received bridge management frames classified as belonging to this VLAN (e.g. GMRP, but not GVRP or STP)."

REFERENCE

"IEEE 802.1Q/D11 Section 12.6.1.1.3(a)"
::= { dot1qPortVlanHCStatisticsEntry 1 }

by this device which are classified as belonging to this VLAN (e.g. GMRP, but not GVRP or STP)."

REFERENCE

Specifically, the IEEE 802.1Q counters for Discard Inbound and Discard on Ingress Filtering."

REFERENCE

"IEEE 802.1Q/D11 Section 12.6.1.1.3"
::= { dot1qPortVlanHCStatisticsEntry 3 }

-- The VLAN Learning Constraints Table

DESCRIPTION

dot1qConstraintType
INTEGER,
dot1qConstraintStatus

other VLANs in the same set, defined by dot1qConstraintSet.
shared(2) - the VLAN, dot1qConstraintVlan, shares

-- IEEE 802.1Q MIB - Conformance Information

qBridgeConformance OBJECT IDENTIFIER ::= { qBridgeMIB 2 }

qBridgeGroups OBJECT IDENTIFIER ::= { qBridgeConformance 1 }

qBridgeCompliances OBJECT IDENTIFIER
    ::= { qBridgeConformance 2 }

-- units of conformance

STATUS current
DESCRIPTION
"A collection of objects defining the default Filtering
Database constraints for VLANs which have no specific
constraints defined."
::= { qBridgeGroups 13 }

-- compliance statements

qBridgeCompliance MODULE-COMPLIANCE

STATUS current
DESCRIPTION

"The compliance statement for device support of Virtual LAN Bridge services."

MODULE
	MANDATORY-GROUPS { qBridgeBaseGroup, qBridgeVlanGroup, qBridgeVlanStaticGroup, qBridgePortGroup }
	GROUP qBridgeFdbUnicastGroup DESCRIPTION "This group is mandatory for bridges that implement 802.1Q transparent bridging."
	GROUP qBridgeFdbMulticastGroup DESCRIPTION "This group is mandatory for bridges that implement 802.1Q transparent bridging."
	GROUP qBridgeServiceRequirementsGroup DESCRIPTION "This group is mandatory for bridges that implement extended filtering services. All objects must be read-write if extended-filtering services are enabled."
	GROUP qBridgeFdbStaticGroup DESCRIPTION "This group is optional."

GROUP qBridgeVlanStatisticsGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support."

GROUP qBridgeVlanStatisticsOverflowGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support. It is most
relevant for high capacity interfaces where the SNMP agent
supports only SNMPv1."

GROUP qBridgeVlanHCStatisticsGroup
DESCRIPTION
"This group is optional as there may be significant
implementation cost associated with its support. It is most
relevant for high capacity interfaces."

GROUP qBridgeLearningConstraintsGroup
DESCRIPTION
"This group is mandatory for devices implementing
both Independent VLAN Learning (IVL) and Shared
VLAN Learning (SVL) modes of operation of the
filtering database, as defined by IEEE 802.1Q."

GROUP qBridgeLearningConstraintDefaultGroup
DESCRIPTION
"This group is mandatory for devices implementing
both Independent VLAN Learning (IVL) and Shared
VLAN Learning (SVL) modes of operation of the
filtering database, as defined by IEEE 802.1Q."

OBJECT dot1qPortAcceptableFrameTypes
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."

OBJECT dot1qPortIngressFiltering
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."

OBJECT dot1qConstraintSetDefault
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."

OBJECT dot1qConstraintTypeDefault
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."

::= { qBridgeCompliances 1 }

END

6. Acknowledgments

This document expands upon previous work which resulted in the original bridge MIB [BRIDGEMIB].

Much of the groundwork for this document was performed by the IEEE 802.1 working group during the definition of the IEEE 802.1D updates [802.1D] and IEEE 802.1Q [802.1Q].

The authors wish to thank the members of the Bridge Working Group and David Harrington in particular for their many comments and suggestions which improved this effort.

7. Security Considerations

There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.

SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB.

It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [USM] and the View-based Access Control Model [VACM] is recommended.

It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.

8. References

[ARCH]

Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.

[V1PROTO]

Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.

[V1SMI]

Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.

[V1CONCISE]

Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.

[V1TRAPS]

Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.

[V2SMI]

McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,

13. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[V2TC]

McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,

13. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[V2CONFORM]

McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,

13. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

[V2COMMUNITY]

Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.

[V2TRANS]

Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

[V2PROTO]

Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[V3INTRO]

Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.

[V3MPC]

Case, J., Harrington D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.

[V3USM]

Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.

[V3APPS]

Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.

[V3VACM]

Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.

[ASN1]

Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987.

[ASN1BER]

Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987.

[802.1D-ORIG]

ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges".

[802.1D]

"Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks

• Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998.

[802.1Q]

ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998.

[BRIDGEMIB]

Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993.

[INTERFACEMIB]

McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.

[SRBRIDGEMIB]

Decker, E., McCloghrie, K., Langille, P. and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, September 1993.

[MIB2]

McCloghrie K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, March 1991.

9. Authors' Addresses

Les Bell
3Com Europe Limited
3Com Centre, Boundary Way
Hemel Hempstead
Herts. HP2 7YU
UK

Phone: +44 1442 438025

EMail: Les_Bell@3Com.com

Andrew Smith
Extreme Networks
3585 Monroe St.
Santa Clara, CA 95051
USA

Phone: +1 408 579 2821

EMail: andrew@extremenetworks.com

Paul Langille
Newbridge Networks
5 Corporate Drive
Andover, MA 01810
USA

Phone: +1 978 691 4665

EMail: langille@newbridge.com

Anil Rijhsinghani
Cabletron Systems
50 Minuteman Road
Andover, MA 01810
USA

Phone: +1 978 684 1295

EMail: anil@cabletron.com

Keith McCloghrie
cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA

Phone: +1 408 526 5260

EMail: kzm@cisco.com

10. Intellectual Property

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

11. Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

Bell, et al. Standards Track [Page 86]