draft-ietf-bridge-bridgemib-smiv2-06.txt   draft-ietf-bridge-bridgemib-smiv2-07.txt 
Internet Draft K.C. Norseth Network Working Group K. Norseth, Ed.
Expires October 2004 L-3 Communications Internet-Draft L-3 Communications
draft-ietf-bridge-bridgemib-smiv2-06.txt E. Bell Obsoletes: 1493 (if approved) E. Bell, Ed.
Obsoletes: 1493 3Com Corp. Expires: April 25, 2005 3Com Europe Limited
April 2004 October 25, 2004
Definitions of Managed Objects for Bridges Definitions of Managed Objects for Bridges
draft-ietf-bridge-bridgemib-smiv2-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets. for use with network management protocols in TCP/IP based internets.
In particular it defines objects for managing MAC bridges based on In particular it defines objects for managing MAC bridges based on
the IEEE 802.1D-1998 standard between Local Area Network (LAN) the IEEE 802.1D-1998 standard between Local Area Network (LAN)
segments. Provisions are made for support of transparent bridging. segments. Provisions are made for support of transparent bridging.
Provisions are also made so that these objects apply to bridges Provisions are also made so that these objects apply to bridges
connected by subnetworks other than LAN segments. connected by subnetworks other than LAN segments.
The MIB presented in this memo is a direct translation of the BRIDGE The MIB module presented in this memo is a translation of the
MIB defined in [RFC1493], to the SMIv2 syntax required for current BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.
IETF MIB standards. This memo obsoletes RFC 1493.
Table of Contents
1. The SNMP Management Framework ........................ 2
2. Overview ............................................. 3
2.1. Structure of MIB ..................................... 3
2.1.1. The dot1dBase Group .................................. 5
2.1.2. The dot1dStp Group ................................... 5
2.1.3. The dot1dSr Group .................................... 6
2.1.4. The dot1dTp Group .................................... 6
2.1.5. The dot1dStatic Group ................................ 6
2.2. Relationship to Other MIBs ........................... 6
2.2.1. Relationship to the 'system' group ................... 6
2.2.2. Relationship to the 'interfaces' group ............... 6
2.3. Textual Conventions .................................. 7
3. Definitions .......................................... 7
4. Security Considerations .............................. 34
5. Acknowledgments ...................................... 34
6. Normative References ................................. 35
7. Informative References ............................... 36
8. Changes from RFC 1493 ................................. 36
9. Authors' Addresses ................................... 37
10. Full Copyright Statement ............................. 37
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major This memo obsoletes RFC 1493.
components:
o An overall architecture, described in RFC 2571 [RFC2571]. Table of Contents
o Mechanisms for describing and naming objects and events for the 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
purpose of management. The first version of this Structure of 2. The Internet-Standard Management Framework . . . . . . . . . . 3
Management Information (SMI) is called SMIv1 and described in 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 3.1 Structure of the MIB Module . . . . . . . . . . . . . . . 4
1215 [RFC1215]. The second version, called SMIv2, is described 3.1.1 The dot1dBase Group . . . . . . . . . . . . . . . . . 6
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 3.1.2 The dot1dStp Group . . . . . . . . . . . . . . . . . . 6
STD 58, RFC 2580 [RFC2580]. 3.1.3 The dot1dSr Group . . . . . . . . . . . . . . . . . . 6
3.1.4 The dot1dTp Group . . . . . . . . . . . . . . . . . . 7
3.1.5 The dot1dStatic Group . . . . . . . . . . . . . . . . 7
3.2 Relationship to Other MIB Modules . . . . . . . . . . . . 7
3.2.1 Relationship to the SNMPv2-MIB . . . . . . . . . . . . 7
3.2.2 Relationship to the IF-MIB . . . . . . . . . . . . . . 7
3.3 Textual Conventions . . . . . . . . . . . . . . . . . . . 8
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 39
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
7. Changes from RFC 1493 . . . . . . . . . . . . . . . . . . . . 41
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 41
9.2 Informative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . 44
o Message protocols for transferring management information. The 1. Conventions
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
first set of protocol operations and associated PDU formats is "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
described in STD 15, RFC 1157 [RFC1157]. A second set of "OPTIONAL", when they appear in this document, are to be interpreted
protocol operations and associated PDU formats is described in as described in BCP 14, RFC 2119 [RFC2119].
RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573 2. The Internet-Standard Management Framework
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework For a detailed overview of the documents that describe the current
can be found in RFC 2570 [RFC2570]. Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. MIB objects are generally
defined using the mechanisms defined in the SMI. accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
This memo specifies a MIB module that is compliant to the SMIv2. A Structure of Management Information (SMI). This memo specifies a MIB
MIB conforming to the SMIv1 can be produced through the appropriate module that is compliant to the SMIv2, which is described in STD 58,
translations. The resulting translated MIB must be semantically RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
equivalent, except where objects or events are omitted because no [RFC2580].
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 3. Overview
A common device present in many networks is the Bridge. This device A common device present in many networks is the Bridge. This device
is used to connect Local Area Network segments below the network is used to connect Local Area Network segments below the network
layer. layer.
There are two major modes defined for this bridging; transparent and There are two major modes defined for this bridging; transparent and
source route. The transparent method of bridging is defined in the source route. The transparent method of bridging is defined in the
IEEE 802.1D specification [IEEE8021D]. This memo defines those IEEE 802.1D specification [IEEE8021D]. This memo defines those
objects needed for the management of a bridging entity operating in objects needed for the management of a bridging entity operating in
the transparent mode, as well as some objects applicable to all types the transparent mode, as well as some objects applicable to all types
of bridges. of bridges.
To be consistent with IAB directives and good engineering practice, To be consistent with IAB directives and good engineering practice,
an explicit attempt was made to keep this MIB as simple as possible. an explicit attempt was made to keep this MIB module as simple as
This was accomplished by applying the following criteria to objects possible. This was accomplished by applying the following criteria
proposed for inclusion: to objects proposed for inclusion:
(1) Start with a small set of essential objects and add only as 1. Start with a small set of essential objects and add only as
further objects are needed. further objects are needed.
2. Require objects be essential for either fault or configuration
(2) Require objects be essential for either fault or configuration
management. 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 MIB modules.
(3) Consider evidence of current use and/or utility. 6. Avoid causing critical sections to be heavily instrumented. The
(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 guideline that was followed is one counter per critical section
per layer. per layer.
2.1. Structure of MIB 3.1 Structure of the MIB Module
Objects in this MIB are arranged into groups. Each group is Objects in this MIB module are arranged into groups. Each group is
organized as a set of related objects. The overall structure and organized as a set of related objects. The overall structure and
assignment of objects to their groups is shown below. Where assignment of objects to their groups is shown below. Where
appropriate the corresponding IEEE 802.1D [IEEE8021D] management appropriate the corresponding IEEE 802.1D [IEEE8021D] management
object name is also included. object name is also included.
Bridge MIB Name IEEE 802.1D Name Bridge MIB Name IEEE 802.1D Name
dot1dBridge dot1dBridge
dot1dBase dot1dBase
BridgeAddress Bridge.BridgeAddress BridgeAddress Bridge.BridgeAddress
skipping to change at page 5, line 18 skipping to change at page 5, line 31
OutFrames .ForwardOutbound OutFrames .ForwardOutbound
InDiscards .DiscardInbound InDiscards .DiscardInbound
dot1dStatic dot1dStatic
StaticTable StaticTable
Address Address
ReceivePort ReceivePort
AllowedToGoTo AllowedToGoTo
Status Status
The following IEEE 802.1D management objects have not been included The following IEEE 802.1D management objects have not been included
in the Bridge MIB for the indicated reasons. in the BRIDGE-MIB module for the indicated reasons.
IEEE 802.1D Object Disposition IEEE 802.1D Object Disposition
Bridge.BridgeName Same as sysDescr (MIB II) Bridge.BridgeName Same as sysDescr (SNMPv2-MIB)
Bridge.BridgeUpTime Same as sysUpTime (MIB II) Bridge.BridgeUpTime Same as sysUpTime (SNMPv2-MIB)
Bridge.PortAddresses Same as ifPhysAddress (MIB II) Bridge.PortAddresses Same as ifPhysAddress (IF-MIB)
BridgePort.PortName Same as ifDescr (MIB II) BridgePort.PortName Same as ifDescr (IF-MIB)
BridgePort.PortType Same as ifType (MIB II) BridgePort.PortType Same as ifType (IF-MIB)
BridgePort.RoutingType Derivable from the implemented BridgePort.RoutingType Derivable from the implemented
groups groups
SpanningTreeProtocol SpanningTreeProtocol
.BridgeIdentifier Combination of dot1dStpPriority .BridgeIdentifier Combination of dot1dStpPriority
and dot1dBaseBridgeAddress and dot1dBaseBridgeAddress
.TopologyChange Since this is transitory, it .TopologyChange Since this is transitory, it
is not considered useful. is not considered useful.
SpanningTreeProtocolPort SpanningTreeProtocolPort
.Uptime Same as ifLastChange (MIB II) .Uptime Same as ifLastChange (IF-MIB)
.PortIdentifier Combination of dot1dStpPort .PortIdentifier Combination of dot1dStpPort
and dot1dStpPortPriority and dot1dStpPortPriority
.TopologyChangeAcknowledged Since this is transitory, it .TopologyChangeAcknowledged Since this is transitory, it
is not considered useful. is not considered useful.
.DiscardLackOfBuffers Redundant .DiscardLackOfBuffers Redundant
Transmission Priority These objects are not required Transmission Priority These objects are not required
as per the Pics Proforma and as per the Pics Proforma and
not considered useful. not considered useful.
.TransmissionPriorityName .TransmissionPriorityName
.OutboundUserPriority .OutboundUserPriority
.OutboundAccessPriority .OutboundAccessPriority
2.1.1. The dot1dBase Group 3.1.1 The dot1dBase Group
This mandatory group contains the objects which are applicable to all This mandatory group contains the objects which are applicable to all
types of bridges. types of bridges.
2.1.2. The dot1dStp Group 3.1.2 The dot1dStp Group
This group contains the objects that denote the bridge's state with This group contains the objects that denote the bridge's state with
respect to the Spanning Tree Protocol. If a node does not respect to the Spanning Tree Protocol. If a node does not
implemented the Spanning Tree Protocol, this group will not be implemented the Spanning Tree Protocol, this group will not be
implemented. implemented.
2.1.3. The dot1dSr Group 3.1.3 The dot1dSr Group
This group contains the objects that describe the entity's state with This group contains the objects that describe the entity's state with
respect to source route bridging. If source routing is not supported respect to source route bridging. If source routing is not supported
this group will not be implemented. This group is applicable to this group will not be implemented. This group is applicable to
source route only, and SRT bridges. This group will be described in source route only, and SRT bridges. This group will be described in
a separate document applicable only to source route bridging. a separate document applicable only to source route bridging.
2.1.4. The dot1dTp Group 3.1.4 The dot1dTp Group
This group contains objects that describe the entity's state with This group contains objects that describe the entity's state with
respect to transparent bridging. If transparent bridging is not respect to transparent bridging. If transparent bridging is not
supported this group will not be implemented. This group is supported this group will not be implemented. This group is
applicable to transparent only and SRT bridges. applicable to transparent only and SRT bridges.
2.1.5. The dot1dStatic Group 3.1.5 The dot1dStatic Group
This group contains objects that describe the entity's state with This group contains objects that describe the entity's state with
respect to destination-address filtering. If destination-address respect to destination-address filtering. If destination-address
filtering is not supported this group will not be implemented. This filtering is not supported this group will not be implemented. This
group is applicable to any type of bridge which performs destination- group is applicable to any type of bridge which performs destination-
address filtering. address filtering.
2.2. Relationship to Other MIBs 3.2 Relationship to Other MIB Modules
As described above, some IEEE 802.1D management objects have not been As described above, some IEEE 802.1D management objects have not been
included in this MIB because they overlap with objects in other MIBs included in this MIB module because they overlap with objects in
applicable to a bridge implementing this MIB. In particular, it is other MIB modules applicable to a bridge implementing this MIB. In
assumed that a bridge implementing this MIB will also implement (at particular, it is assumed that a bridge implementing the BRIDGE-MIB
least) the 'system' group and the 'interfaces' group defined in MIB- module will also implement (at least) the 'system' group of the
II [RFC1213]. SNMPv2-MIB [RFC3418] the 'interfaces' group of the IF-MIB [RFC2863].
2.2.1. Relationship to the 'system' group 3.2.1 Relationship to the SNMPv2-MIB
In MIB-II [RFC1907], the 'system' group is defined as being mandatory In the SNMPv2-MIB [RFC3418], the 'system' group is defined as being
for all systems such that each managed entity contains one instance mandatory for all systems. Thus, those objects apply to the entity
of each object in the 'system' group. Thus, those objects apply to as a whole irrespective of whether the entity's sole functionality is
the entity as a whole irrespective of whether the entity's sole bridging, or whether bridging is only a subset of the entity's
functionality is bridging, or whether bridging is only a subset of functionality.
the entity's functionality.
2.2.2. Relationship to the 'interfaces' group 3.2.2 Relationship to the IF-MIB
In the Interfaces Group MIB [RFC2863], the 'interfaces' group is In the Interfaces Group MIB [RFC2863], the 'interfaces' group is
defined as being mandatory for all systems and contains information defined as being mandatory for all systems and contains information
on an entity's interfaces, where each interface is thought of as 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 being attached to a `subnetwork'. (Note that this term is not to be
confused with `subnet' which refers to an addressing partitioning confused with `subnet' which refers to an addressing partitioning
scheme used in the Internet suite of protocols.) The term 'segment' 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 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 Ethernet segment, a 'ring', a WAN link, or even an X.25 virtual
circuit. circuit.
Implicit in this Bridge MIB is the notion of ports on a bridge. Each Implicit in this BRIDGE-MIB is the notion of ports on a bridge. Each
of these ports is associated with one interface of the 'interfaces' of these ports is associated with one interface of the 'interfaces'
group, and in most situations, each port is associated with a group, and in most situations, each port is associated with a
different interface. However, there are situations in which multiple different interface. However, there are situations in which multiple
ports are associated with the same interface. An example of such a ports are associated with the same interface. An example of such a
situation would be several ports each corresponding one-to-one with situation would be several ports each corresponding one-to-one with
several X.25 virtual circuits but all on the same interface. several X.25 virtual circuits but all on the same interface.
Each port is uniquely identified by a port number. A port number has Each port is uniquely identified by a port number. A port number has
no mandatory relationship to an interface number, but in the simple no mandatory relationship to an interface number, but in the simple
case a port number will have the same value as the corresponding case a port number will have the same value as the corresponding
skipping to change at page 7, line 35 skipping to change at page 8, line 29
situations, only a subset of the data sent/received on an interface situations, only a subset of the data sent/received on an interface
is within the domain of the entity's bridging functionality. This is within the domain of the entity's bridging functionality. This
subset is considered to be delineated according to a set of subset is considered to be delineated according to a set of
protocols, with some protocols being bridged, and other protocols not protocols, with some protocols being bridged, and other protocols not
being bridged. For example, in an entity which exclusively performed being bridged. For example, in an entity which exclusively performed
bridging, all protocols would be considered as being bridged, whereas bridging, all protocols would be considered as being bridged, whereas
in an entity which performed IP routing on IP datagrams and only in an entity which performed IP routing on IP datagrams and only
bridged other protocols, only the non-IP data would be considered as bridged other protocols, only the non-IP data would be considered as
being bridged. being bridged.
Thus, this Bridge MIB (and in particular, its counters) are Thus, this BRIDGE-MIB (and in particular, its counters) are
applicable only to that subset of the data on an entity's interfaces 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 which is sent/received for a protocol being bridged. All such data
is sent/received via the ports of the bridge. is sent/received via the ports of the bridge.
2.3. Textual Conventions 3.3 Textual Conventions
The datatypes, MacAddress, BridgeId and Timeout, are used as textual This document introduces the textual conventions BridgeId and Timeout
conventions in this document. Objects defined using these and imports the MacAddress textual convention from RFC 2579
conventions are always encoded by means of the rules that define [RFC2579]. Objects defined using these conventions are always
their primitive type. Hence, no changes to the SMI or the SNMP are encoded by means of the rules that define their primitive type.
necessary to accommodate these textual conventions which are adopted These textual conventions are adopted merely for the convenience of
merely for the convenience of readers. readers.
3. Definitions 4. Definitions
BRIDGE-MIB DEFINITIONS ::= BEGIN BRIDGE-MIB DEFINITIONS ::= BEGIN
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- MIB for IEEE 802.1D devices -- MIB for IEEE 802.1D devices
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Integer32, TimeTicks, mib-2 Counter32, Integer32, TimeTicks, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION, MacAddress TEXTUAL-CONVENTION, MacAddress
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
InterfaceIndex FROM IF-MIB InterfaceIndex FROM IF-MIB
; ;
bridgeMIB MODULE-IDENTITY bridgeMIB MODULE-IDENTITY
LAST-UPDATED "200307240000Z" LAST-UPDATED "200410220000Z"
ORGANIZATION "IETF Bridge MIB Working Group" ORGANIZATION "IETF Bridge MIB Working Group"
CONTACT-INFO CONTACT-INFO
"Email: Bridge-mib@ietf.org "Email: bridge-mib@ietf.org
K.C. Norseth K.C. Norseth (Editor)
L-3 Communications L-3 Communications
Tel: +1 801-594-2809 Tel: +1 801-594-2809
Email: kenyon.c.norseth@L-3com.com Email: kenyon.c.norseth@L-3com.com
Postal: 640 N. 2200 West. Postal: 640 N. 2200 West.
Salt Lake City, Utah 84116-0850 Salt Lake City, Utah 84116-0850
Les Bell Les Bell (Editor)
3Com Europe Limited 3Com Europe Limited
Phone: +44 1442 438025 Phone: +44 1442 438025
Email: Les_Bell@3Com.com Email: Les_Bell@3Com.com
Postal: 3Com Centre, Boundary Way Postal: 3Com Centre, Boundary Way
Hemel Hempstead Hemel Hempstead
Herts. HP2 7YU Herts. HP2 7YU
UK UK
Send comments to <bridge-mib@ietf.org>" Send comments to <bridge-mib@ietf.org>"
DESCRIPTION DESCRIPTION
"The Bridge MIB module for managing devices that support "The Bridge MIB module for managing devices that support
IEEE 802.1D. IEEE 802.1D.
Copyright (C) The Internet Society (2003). This version of Copyright (C) The Internet Society (2004). This version of
this MIB module is part of RFC xxxx; see the RFC itself for this MIB module is part of RFC XXXX; see the RFC itself for
full legal notices." full legal notices."
REVISION "200307240000Z" REVISION "200410220000Z"
-- RFC Ed.: replace XXXX with actual RFC number and remove this note
DESCRIPTION DESCRIPTION
"Translation of RFC 1493 to SMIv2." "Third revision, published as part of RFC XXXX.
The MIB module has been converted to SMIv2 format.
Conformance statements have been added and some
description and reference clauses have been updated.
The object dot1dStpPortPathCost32 was added to
support IEEE 802.1t and the permissible values of
dot1dStpPriority and dot1dStpPortPriority have been
clarified for bridges supporting IEEE 802.1t or
IEEE 802.1w.
The interpretation of dot1dStpTimeSinceTopologyChange
has been clarified for bridges supporting the rapid
spanning tree protocol (RSTP)."
REVISION "199307310000Z" REVISION "199307310000Z"
DESCRIPTION DESCRIPTION
"RFC 1493: SMIv1 version." "Second revision, published as part of RFC 1493."
REVISION "199112310000Z"
DESCRIPTION
"Initial revision, published as part of RFC 1286."
::= { dot1dBridge 8 } ::= { dot1dBridge 8 }
dot1dNotification OBJECT IDENTIFIER ::= { dot1dBridge 0 } dot1dNotification OBJECT IDENTIFIER ::= { dot1dBridge 0 }
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- Textual Conventions -- Textual Conventions
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- All representations of MAC addresses in this MIB Module use, -- All representations of MAC addresses in this MIB Module use,
-- as a textual convention (i.e. this convention does not affect -- as a textual convention (i.e. this convention does not affect
-- their encoding), the data type MacAddress, defined in -- their encoding), the data type MacAddress, defined in
-- SNMPv2-TC. -- SNMPv2-TC.
-- Similarly, all representations of Bridge-Id in this MIB -- Similarly, all representations of Bridge-Id in this MIB
-- module use, as a textual convention (i.e. this convention
-- does not affect their encoding), the data type: -- does not affect their encoding), the data type:
BridgeId ::= TEXTUAL-CONVENTION BridgeId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Bridge-Identifier as used in the Spanning Tree "The Bridge-Identifier as used in the Spanning Tree
Protocol to uniquely identify a bridge. Its first two Protocol to uniquely identify a bridge. Its first two
octets (in network byte order) contain a priority value octets (in network byte order) contain a priority value
and its last 6 octets contain the MAC address used to and its last 6 octets contain the MAC address used to
refer to a bridge in a unique fashion (typically, the refer to a bridge in a unique fashion (typically, the
numerically smallest MAC address of all ports on the numerically smallest MAC address of all ports on the
bridge)." bridge)."
SYNTAX OCTET STRING (SIZE (8)) SYNTAX OCTET STRING (SIZE (8))
-- Several objects in this MIB module represent values of timers -- Several objects in this MIB module represent values of timers
-- used by the Spanning Tree Protocol. In this MIB, these -- used by the Spanning Tree Protocol. In this MIB, these
-- timers have values in units of hundredths of a second (i.e.
-- 1/100 secs). -- 1/100 secs).
-- These timers, when stored in a Spanning Tree Protocol's BPDU, -- These timers, when stored in a Spanning Tree Protocol's BPDU,
-- are in units of 1/256 seconds. Note, however, that -- are in units of 1/256 seconds. Note, however, that
-- 802.1D-1998 specifies a settable granularity of no more -- 802.1D-1998 specifies a settable granularity of no more
-- than 1 second for these timers. To avoid ambiguity, a data -- than 1 second for these timers. To avoid ambiguity, a data
-- type is defined here as a textual convention and all -- type is defined here as a textual convention and all
-- representation of these timers in this MIB module are defined -- representation of these timers in this MIB module are defined
-- using this data type. An algorithm is also defined for -- using this data type. An algorithm is also defined for
-- converting between the different units, to ensure a timer's -- converting between the different units, to ensure a timer's
-- value is not distorted by multiple conversions. -- value is not distorted by multiple conversions.
-- The data type is: -- The data type is:
skipping to change at page 10, line 4 skipping to change at page 11, line 32
b = floor( (n * 256) / 100) b = floor( (n * 256) / 100)
where: where:
floor = quotient [ignore remainder] floor = quotient [ignore remainder]
n is the value in 1/100 second units n is the value in 1/100 second units
b is the value in 1/256 second units b is the value in 1/256 second units
To convert the value from 1/256 second units back to To convert the value from 1/256 second units back to
1/100 seconds, the following algorithm should be used: 1/100 seconds, the following algorithm should be used:
n = ceiling( (b * 100) / 256) n = ceiling( (b * 100) / 256)
where: where:
ceiling = quotient [if remainder is 0], or ceiling = quotient [if remainder is 0], or
quotient + 1 [if remainder is non-zero] quotient + 1 [if remainder is nonzero]
n is the value in 1/100 second units n is the value in 1/100 second units
b is the value in 1/256 second units b is the value in 1/256 second units
Note: it is important that the arithmetic operations are Note: it is important that the arithmetic operations are
done in the order specified (i.e., multiply first, done in the order specified (i.e., multiply first,
divide second)." divide second)."
SYNTAX Integer32 SYNTAX Integer32
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
dot1dBridge OBJECT IDENTIFIER ::= { mib-2 17 } dot1dBridge OBJECT IDENTIFIER ::= { mib-2 17 }
skipping to change at page 10, line 25 skipping to change at page 12, line 4
divide second)." divide second)."
SYNTAX Integer32 SYNTAX Integer32
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
dot1dBridge OBJECT IDENTIFIER ::= { mib-2 17 } dot1dBridge OBJECT IDENTIFIER ::= { mib-2 17 }
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- groups in the Bridge MIB -- groups in the Bridge MIB
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
dot1dBase OBJECT IDENTIFIER ::= { dot1dBridge 1 } dot1dBase OBJECT IDENTIFIER ::= { dot1dBridge 1 }
dot1dStp OBJECT IDENTIFIER ::= { dot1dBridge 2 } dot1dStp OBJECT IDENTIFIER ::= { dot1dBridge 2 }
dot1dSr OBJECT IDENTIFIER ::= { dot1dBridge 3 } dot1dSr OBJECT IDENTIFIER ::= { dot1dBridge 3 }
-- separately documented -- separately documented
dot1dTp OBJECT IDENTIFIER ::= { dot1dBridge 4 } dot1dTp OBJECT IDENTIFIER ::= { dot1dBridge 4 }
dot1dStatic OBJECT IDENTIFIER ::= { dot1dBridge 5 } dot1dStatic OBJECT IDENTIFIER ::= { dot1dBridge 5 }
-- Groups defined in the Bridge MIB Extensions:
-- pBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 6 } -- pBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 6 }
-- qBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 7 } -- qBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 7 }
-- The MODULE-IDENTITY for this MIB has been defined above as: -- The MODULE-IDENTITY for this MIB has been defined above as:
-- bridgeMIB MODULE-IDENTITY ::= { dot1dBridge 8 } -- bridgeMIB MODULE-IDENTITY ::= { dot1dBridge 8 }
-- The MODULE-IDENTITY for the Source Routing MIB has been -- The MODULE-IDENTITY for the Source Routing MIB has been
-- defined in that MIB as: -- defined in that MIB as:
-- srMIB MODULE-IDENTITY ::= { dot1dBridge 9 } -- srMIB MODULE-IDENTITY ::= { dot1dBridge 9 }
skipping to change at page 11, line 18 skipping to change at page 13, line 4
"The MAC address used by this bridge when it must be "The MAC address used by this bridge when it must be
referred to in a unique fashion. It is recommended referred to in a unique fashion. It is recommended
that this be the numerically smallest MAC address of all that this be the numerically smallest MAC address of all
ports that belong to this bridge. However it is only ports that belong to this bridge. However it is only
required to be unique. When concatenated with required to be unique. When concatenated with
dot1dStpPriority a unique BridgeIdentifier is formed dot1dStpPriority a unique BridgeIdentifier is formed
which is used in the Spanning Tree Protocol." which is used in the Spanning Tree Protocol."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clauses 14.4.1.1.3 and 7.12.5" "IEEE 802.1D-1998: clauses 14.4.1.1.3 and 7.12.5"
::= { dot1dBase 1 } ::= { dot1dBase 1 }
dot1dBaseNumPorts OBJECT-TYPE dot1dBaseNumPorts OBJECT-TYPE
SYNTAX Integer32 SYNTAX Integer32
UNITS "ports"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of ports controlled by this bridging "The number of ports controlled by this bridging
entity." entity."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 14.4.1.1.3" "IEEE 802.1D-1998: clause 14.4.1.1.3"
::= { dot1dBase 2 } ::= { dot1dBase 2 }
dot1dBaseType OBJECT-TYPE dot1dBaseType OBJECT-TYPE
skipping to change at page 14, line 29 skipping to change at page 16, line 34
given by the value of dot1dBaseBridgeAddress. given by the value of dot1dBaseBridgeAddress.
On bridges supporting IEEE 802.1t or IEEE 802.1w, On bridges supporting IEEE 802.1t or IEEE 802.1w,
permissible values are 0-61440, in steps of 4096." permissible values are 0-61440, in steps of 4096."
REFERENCE REFERENCE
"IEEE 802.1D-1998 clause 8.10.2, Table 8-4, "IEEE 802.1D-1998 clause 8.10.2, Table 8-4,
IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3." IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."
::= { dot1dStp 2 } ::= { dot1dStp 2 }
dot1dStpTimeSinceTopologyChange OBJECT-TYPE dot1dStpTimeSinceTopologyChange OBJECT-TYPE
SYNTAX TimeTicks SYNTAX TimeTicks
UNITS "centi-seconds"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The time (in hundredths of a second) since the "The time (in hundredths of a second) since the
last time a topology change was detected by the last time a topology change was detected by the
bridge entity. bridge entity.
For RSTP, this reports the time since the tcWhile For RSTP, this reports the time since the tcWhile
timer for any port on this Bridge was non-zero." timer for any port on this Bridge was nonzero."
REFERENCE REFERENCE
"IEEE 802.1D-1998 clause 14.8.1.1., "IEEE 802.1D-1998 clause 14.8.1.1.,
IEEE 802.1w clause 14.8.1.1." IEEE 802.1w clause 14.8.1.1."
::= { dot1dStp 3 } ::= { dot1dStp 3 }
dot1dStpTopChanges OBJECT-TYPE dot1dStpTopChanges OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 15, line 38 skipping to change at page 17, line 50
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The port number of the port which offers the lowest "The port number of the port which offers the lowest
cost path from this bridge to the root bridge." cost path from this bridge to the root bridge."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.3.3" "IEEE 802.1D-1998: clause 8.5.3.3"
::= { dot1dStp 7 } ::= { dot1dStp 7 }
dot1dStpMaxAge OBJECT-TYPE dot1dStpMaxAge OBJECT-TYPE
SYNTAX Timeout SYNTAX Timeout
UNITS "centi-seconds"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum age of Spanning Tree Protocol information "The maximum age of Spanning Tree Protocol information
learned from the network on any port before it is learned from the network on any port before it is
discarded, in units of hundredths of a second. This is discarded, in units of hundredths of a second. This is
the actual value that this bridge is currently using." the actual value that this bridge is currently using."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.3.4" "IEEE 802.1D-1998: clause 8.5.3.4"
::= { dot1dStp 8 } ::= { dot1dStp 8 }
dot1dStpHelloTime OBJECT-TYPE dot1dStpHelloTime OBJECT-TYPE
SYNTAX Timeout SYNTAX Timeout
UNITS "centi-seconds"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The amount of time between the transmission of "The amount of time between the transmission of
Configuration bridge PDUs by this node on any port when Configuration bridge PDUs by this node on any port when
it is the root of the spanning tree or trying to become it is the root of the spanning tree or trying to become
so, in units of hundredths of a second. This is the so, in units of hundredths of a second. This is the
actual value that this bridge is currently using." actual value that this bridge is currently using."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.3.5" "IEEE 802.1D-1998: clause 8.5.3.5"
::= { dot1dStp 9 } ::= { dot1dStp 9 }
dot1dStpHoldTime OBJECT-TYPE dot1dStpHoldTime OBJECT-TYPE
SYNTAX Integer32 SYNTAX Integer32
UNITS "centi-seconds"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This time value determines the interval length "This time value determines the interval length
during which no more than two Configuration bridge during which no more than two Configuration bridge
PDUs shall be transmitted by this node, in units PDUs shall be transmitted by this node, in units
of hundredths of a second." of hundredths of a second."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.3.14" "IEEE 802.1D-1998: clause 8.5.3.14"
::= { dot1dStp 10 } ::= { dot1dStp 10 }
dot1dStpForwardDelay OBJECT-TYPE dot1dStpForwardDelay OBJECT-TYPE
SYNTAX Timeout SYNTAX Timeout
UNITS "centi-seconds"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This time value, measured in units of hundredths of a "This time value, measured in units of hundredths of a
second, controls how fast a port changes its spanning second, controls how fast a port changes its spanning
state when moving towards the Forwarding state. The state when moving towards the Forwarding state. The
value determines how long the port stays in each of the value determines how long the port stays in each of the
Listening and Learning states, which precede the Listening and Learning states, which precede the
Forwarding state. This value is also used, when a Forwarding state. This value is also used, when a
topology change has been detected and is underway, to topology change has been detected and is underway, to
skipping to change at page 16, line 46 skipping to change at page 19, line 20
currently using, in contrast to currently using, in contrast to
dot1dStpBridgeForwardDelay which is the value that this dot1dStpBridgeForwardDelay which is the value that this
bridge and all others would start using if/when this bridge and all others would start using if/when this
bridge were to become the root.]" bridge were to become the root.]"
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.3.6" "IEEE 802.1D-1998: clause 8.5.3.6"
::= { dot1dStp 11 } ::= { dot1dStp 11 }
dot1dStpBridgeMaxAge OBJECT-TYPE dot1dStpBridgeMaxAge OBJECT-TYPE
SYNTAX Timeout (600..4000) SYNTAX Timeout (600..4000)
UNITS "centi-seconds"
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value that all bridges use for MaxAge when this "The value that all bridges use for MaxAge when this
bridge is acting as the root. Note that 802.1D-1998 bridge is acting as the root. Note that 802.1D-1998
specifies that the range for this parameter is related specifies that the range for this parameter is related
to the value of dot1dStpBridgeHelloTime. The to the value of dot1dStpBridgeHelloTime. The
granularity of this timer is specified by 802.1D-1998 to granularity of this timer is specified by 802.1D-1998 to
be 1 second. An agent may return a badValue error if a be 1 second. An agent may return a badValue error if a
set is attempted to a value which is not a whole number set is attempted to a value which is not a whole number
of seconds." of seconds."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.3.8" "IEEE 802.1D-1998: clause 8.5.3.8"
::= { dot1dStp 12 } ::= { dot1dStp 12 }
dot1dStpBridgeHelloTime OBJECT-TYPE dot1dStpBridgeHelloTime OBJECT-TYPE
SYNTAX Timeout (100..1000) SYNTAX Timeout (100..1000)
UNITS "centi-seconds"
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value that all bridges use for HelloTime when this "The value that all bridges use for HelloTime when this
bridge is acting as the root. The granularity of this bridge is acting as the root. The granularity of this
timer is specified by 802.1D-1998 to be 1 second. An timer is specified by 802.1D-1998 to be 1 second. An
agent may return a badValue error if a set is attempted agent may return a badValue error if a set is attempted
to a value which is not a whole number of seconds." to a value which is not a whole number of seconds."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.3.9" "IEEE 802.1D-1998: clause 8.5.3.9"
::= { dot1dStp 13 } ::= { dot1dStp 13 }
dot1dStpBridgeForwardDelay OBJECT-TYPE dot1dStpBridgeForwardDelay OBJECT-TYPE
SYNTAX Timeout (400..3000) SYNTAX Timeout (400..3000)
UNITS "centi-seconds"
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value that all bridges use for ForwardDelay when "The value that all bridges use for ForwardDelay when
this bridge is acting as the root. Note that this bridge is acting as the root. Note that
802.1D-1998 specifies that the range for this parameter 802.1D-1998 specifies that the range for this parameter
is related to the value of dot1dStpBridgeMaxAge. The is related to the value of dot1dStpBridgeMaxAge. The
granularity of this timer is specified by 802.1D-1998 to granularity of this timer is specified by 802.1D-1998 to
be 1 second. An agent may return a badValue error if a be 1 second. An agent may return a badValue error if a
set is attempted to a value which is not a whole number set is attempted to a value which is not a whole number
skipping to change at page 18, line 9 skipping to change at page 20, line 46
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A list of information maintained by every port about "A list of information maintained by every port about
the Spanning Tree Protocol state for that port." the Spanning Tree Protocol state for that port."
INDEX { dot1dStpPort } INDEX { dot1dStpPort }
::= { dot1dStpPortTable 1 } ::= { dot1dStpPortTable 1 }
Dot1dStpPortEntry ::= Dot1dStpPortEntry ::=
SEQUENCE { SEQUENCE {
dot1dStpPort dot1dStpPort
Integer32, Integer32,
dot1dStpPortPriority dot1dStpPortPriority
Integer32, Integer32,
dot1dStpPortState dot1dStpPortState
INTEGER, INTEGER,
dot1dStpPortEnable dot1dStpPortEnable
INTEGER, INTEGER,
dot1dStpPortPathCost dot1dStpPortPathCost
INTEGER, Integer32,
dot1dStpPortDesignatedRoot dot1dStpPortDesignatedRoot
BridgeId, BridgeId,
dot1dStpPortDesignatedCost dot1dStpPortDesignatedCost
Integer32, Integer32,
dot1dStpPortDesignatedBridge dot1dStpPortDesignatedBridge
BridgeId, BridgeId,
dot1dStpPortDesignatedPort dot1dStpPortDesignatedPort
OCTET STRING, OCTET STRING,
dot1dStpPortForwardTransitions dot1dStpPortForwardTransitions
Counter32, Counter32,
skipping to change at page 19, line 43 skipping to change at page 22, line 39
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The enabled/disabled status of the port." "The enabled/disabled status of the port."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.5.2" "IEEE 802.1D-1998: clause 8.5.5.2"
::= { dot1dStpPortEntry 4 } ::= { dot1dStpPortEntry 4 }
dot1dStpPortPathCost OBJECT-TYPE dot1dStpPortPathCost OBJECT-TYPE
SYNTAX INTEGER (1..65535) SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The contribution of this port to the path cost of "The contribution of this port to the path cost of
paths towards the spanning tree root which include paths towards the spanning tree root which include
this port. 802.1D-1998 recommends that the this port. 802.1D-1998 recommends that the default
default value of this parameter be in inverse value of this parameter be in inverse proportion to
proportion to the speed of the attached LAN. the speed of the attached LAN.
New implementations should use dot1dStpPortPathCost32" New implementations should use dot1dStpPortPathCost32"
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 8.5.5.3" "IEEE 802.1D-1998: clause 8.5.5.3"
::= { dot1dStpPortEntry 5 } ::= { dot1dStpPortEntry 5 }
dot1dStpPortDesignatedRoot OBJECT-TYPE dot1dStpPortDesignatedRoot OBJECT-TYPE
SYNTAX BridgeId SYNTAX BridgeId
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
skipping to change at page 21, line 14 skipping to change at page 24, line 22
from the Learning state to the Forwarding state." from the Learning state to the Forwarding state."
::= { dot1dStpPortEntry 10 } ::= { dot1dStpPortEntry 10 }
dot1dStpPortPathCost32 OBJECT-TYPE dot1dStpPortPathCost32 OBJECT-TYPE
SYNTAX Integer32 (1..200000000) SYNTAX Integer32 (1..200000000)
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The contribution of this port to the path cost of "The contribution of this port to the path cost of
paths towards the spanning tree root which include paths towards the spanning tree root which include
this port. 802.1D-1998 recommends that the this port. 802.1D-1998 recommends that the default
default value of this parameter be in inverse value of this parameter be in inverse proportion to
proportion to the speed of the attached LAN. the speed of the attached LAN.
Replacement for deprecated object dot1dStpPortPathCost." Replacement for deprecated object dot1dStpPortPathCost."
REFERENCE REFERENCE
"IEEE 802.1t clause 8.10.2, Table 8-5." "IEEE 802.1t clause 8.10.2, Table 8-5."
::= { dot1dStpPortEntry 11 } ::= { dot1dStpPortEntry 11 }
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- the dot1dTp group -- the dot1dTp group
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- Implementation of the dot1dTp group is optional. It is -- Implementation of the dot1dTp group is optional. It is
skipping to change at page 21, line 53 skipping to change at page 25, line 13
performance effects on the subnetwork). If this counter performance effects on the subnetwork). If this counter
has a significant value but is not presently increasing, has a significant value but is not presently increasing,
it indicates that the problem has been occurring but is it indicates that the problem has been occurring but is
not persistent." not persistent."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 14.7.1.1.3" "IEEE 802.1D-1998: clause 14.7.1.1.3"
::= { dot1dTp 1 } ::= { dot1dTp 1 }
dot1dTpAgingTime OBJECT-TYPE dot1dTpAgingTime OBJECT-TYPE
SYNTAX Integer32 (10..1000000) SYNTAX Integer32 (10..1000000)
UNITS "seconds"
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The timeout period in seconds for aging out "The timeout period in seconds for aging out
dynamically learned forwarding information. dynamically learned forwarding information.
802.1D-1998 recommends a default of 300 seconds." 802.1D-1998 recommends a default of 300 seconds."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 14.7.1.1.3" "IEEE 802.1D-1998: clause 14.7.1.1.3"
::= { dot1dTp 2 } ::= { dot1dTp 2 }
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- The Forwarding Database for Transparent Bridges -- The Forwarding Database for Transparent Bridges
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
dot1dTpFdbTable OBJECT-TYPE dot1dTpFdbTable OBJECT-TYPE
skipping to change at page 25, line 13 skipping to change at page 28, line 47
SYNTAX Integer32 SYNTAX Integer32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum size of the INFO (non-MAC) field that "The maximum size of the INFO (non-MAC) field that
this port will receive or transmit." this port will receive or transmit."
::= { dot1dTpPortEntry 2 } ::= { dot1dTpPortEntry 2 }
dot1dTpPortInFrames OBJECT-TYPE dot1dTpPortInFrames OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of frames that have been received by this "The number of frames that have been received by this
port from its segment. Note that a frame received on the port from its segment. Note that a frame received on the
interface corresponding to this port is only counted by interface corresponding to this port is only counted by
this object if and only if it is for a protocol being this object if and only if it is for a protocol being
processed by the local bridging function, including processed by the local bridging function, including
bridge management frames." bridge management frames."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 14.6.1.1.3" "IEEE 802.1D-1998: clause 14.6.1.1.3"
::= { dot1dTpPortEntry 3 } ::= { dot1dTpPortEntry 3 }
dot1dTpPortOutFrames OBJECT-TYPE dot1dTpPortOutFrames OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of frames that have been transmitted by this "The number of frames that have been transmitted by this
port to its segment. Note that a frame transmitted on port to its segment. Note that a frame transmitted on
the interface corresponding to this port is only counted the interface corresponding to this port is only counted
by this object if and only if it is for a protocol being by this object if and only if it is for a protocol being
processed by the local bridging function, including processed by the local bridging function, including
bridge management frames." bridge management frames."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 14.6.1.1.3" "IEEE 802.1D-1998: clause 14.6.1.1.3"
::= { dot1dTpPortEntry 4 } ::= { dot1dTpPortEntry 4 }
dot1dTpPortInDiscards OBJECT-TYPE dot1dTpPortInDiscards OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
UNITS "frames"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Count of valid frames received which were discarded "Count of valid frames received which were discarded
(i.e., filtered) by the Forwarding Process." (i.e., filtered) by the Forwarding Process."
REFERENCE REFERENCE
"IEEE 802.1D-1998: clause 14.6.1.1.3" "IEEE 802.1D-1998: clause 14.6.1.1.3"
::= { dot1dTpPortEntry 5 } ::= { dot1dTpPortEntry 5 }
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
skipping to change at page 27, line 41 skipping to change at page 31, line 42
represents the highest numbered port. Thus, each port represents the highest numbered port. Thus, each port
of the bridge is represented by a single bit within the of the bridge is represented by a single bit within the
value of this object. If that bit has a value of '1' value of this object. If that bit has a value of '1'
then that port is included in the set of ports; the port then that port is included in the set of ports; the port
is not included if its bit has a value of '0'. (Note is not included if its bit has a value of '0'. (Note
that the setting of the bit corresponding to the port that the setting of the bit corresponding to the port
from which a frame is received is irrelevant.) The from which a frame is received is irrelevant.) The
default value of this object is a string of ones of default value of this object is a string of ones of
appropriate length. appropriate length.
This exceeds the minimum required SNMP packet size The value of this object may exceed the required minimum
supported. This is sufficient to allow the maximum maximum message size of some SNMP transport (484 bytes
4096 ports now supported." in case of SNMP over UDP, see RFC 3417 section 3.2).
SNMP engines on bridges supporting a large number of
ports must support appropriate maximum message sizes."
::= { dot1dStaticEntry 3 } ::= { dot1dStaticEntry 3 }
dot1dStaticStatus OBJECT-TYPE dot1dStaticStatus OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
other(1), other(1),
invalid(2), invalid(2),
permanent(3), permanent(3),
deleteOnReset(4), deleteOnReset(4),
deleteOnTimeout(5) deleteOnTimeout(5)
} }
skipping to change at page 31, line 46 skipping to change at page 36, line 26
dot1dStaticAllowedToGoTo, dot1dStaticAllowedToGoTo,
dot1dStaticStatus dot1dStaticStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Static Filtering Database information for each port of "Static Filtering Database information for each port of
the Bridge." the Bridge."
::= { dot1dGroups 9 } ::= { dot1dGroups 9 }
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
-- The Trap Notification Group
-- ---------------------------------------------------------- -- -- ---------------------------------------------------------- --
dot1dNotificationGroup NOTIFICATION-GROUP dot1dNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { NOTIFICATIONS {
newRoot, newRoot,
topologyChange topologyChange
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Group of objects describing notifications (traps)." "Group of objects describing notifications (traps)."
skipping to change at page 34, line 20 skipping to change at page 39, line 18
"Implementation of this group is optional." "Implementation of this group is optional."
GROUP dot1dNotificationGroup GROUP dot1dNotificationGroup
DESCRIPTION DESCRIPTION
"Implementation of this group is optional." "Implementation of this group is optional."
::= { dot1dCompliances 2 } ::= { dot1dCompliances 2 }
END END
4. Security Considerations 5. Security Considerations
There are a number of management objects defined in this MIB that There are a number of management objects defined in this MIB module
have a MAX-ACCESS clause of read-write and/or read-create. Such that have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. network operations.
SNMPv1 by itself is not a secure environment. Even if the network Some of the readable objects in this MIB module (i.e., objects with a
itself is secure (for example by using IPSec), even then, there is no MAX-ACCESS other than not-accessible) may be considered sensitive or
control as to who on the secure network is allowed to access and vulnerable in some network environments. It is thus important to
GET/SET (read/change/create/delete) the objects in this MIB. control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
It is recommended that the implementers consider the security the network via SNMP.
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [RFC2574] and the View-
based Access Control Model RFC 2575 [RFC2575] 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.
5. Acknowledgments
The MIB presented in this memo is a direct translation of the BRIDGE
MIB defined in [RFC1493], to the SMIv2 syntax required for current
IETF MIB standards.
The original authors were E. Decker, P. Langille, A Rijsinghani and
K. McCloghrie. Further acknowledgement is given to the members of
the original Bridge Working Group in [RFC1493].
This document was produced on behalf of the Bridge MIB Working Group
in the Operations and Management area of the Internet Engineering
Task Force.
The authors wish to thank the members of the Bridge MIB Working Group
, especially Mike MacFadden and Bert Visscher for their many comments
and suggestions which improved this effort.
6. Normative References
[RFC1905] 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.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", RFC 2571, April
1999.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[IEEE8021D] ANSI/IEEE Standard 802.1D-1998 MAC Bridges, IEEE Project 802 These are the tables and objects and their sensitivity/vulnerability:
Local and Metropolitan Area Networks, (March 8, 1998).
[ISO8021D] ISO DIS 10038 MAC Bridges. o The writable objects dot1dStpPriority, dot1dStpBridgeMaxAge,
dot1dStpBridgeHelloTime, dot1dStpBridgeForwardDelay,
dot1dStpPortPriority, dot1dStpPortEnable, and dot1dStpPortPathCost
influence the spanning tree protocol. Unauthorized write access
to these objects can cause the spanning tree protocol to compute
other default topologies or it can change the speed in which the
spanning tree protocol reacts to failures.
o The writable object dot1dTpAgingTime controls how fast dynamically
learned forwarding information is aged out. Setting this object
to a large value may simplify forwarding table overflow attacks.
o The writable dot1dStaticTable provides a filtering mechanism
controlling to which ports frames originating from a specific
source may be forwarded. Write access to this table can be used
to turn provisioned filtering off or to add filters to prevent
rightful use of the network.
7. Informative References o The readable objects defined in the BRIDGE-MIB module provide
information about the topology of a bridged network and the
attached active stations. The addresses listed in the
dot1dTpFdbTable usually reveal information about the manufacturer
of the MAC hardware, which can be useful information for mounting
other specific attacks.
o The two notifications newRoot and topologyChange are emitted
during spanning tree computation and may trigger management
systems to inspect the status of bridges and to recompute internal
topology information. Hence, forged notifications may cause
management systems to perform unnecessary computations and to
generate additional SNMP traffic directed to the bridges in a
network. Forged notifications therefore may be part of a denial
of service attack.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification SNMP versions prior to SNMPv3 did not include adequate security.
of Management Information for TCP/IP-based Internets", STD Even if the network itself is secure (for example by using IPSec),
16, RFC 1155, May 1990. 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 module.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple It is RECOMMENDED that implementers consider the security features as
Network Management Protocol", STD 15, RFC 1157, May 1990. provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD Further, deployment of SNMP versions prior to SNMPv3 is NOT
16, RFC 1212, March 1991. RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module 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.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with the 6. Acknowledgments
SNMP", RFC 1215, March 1991.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, The MIB module presented in this memo is a translation of the
"Introduction to Community-based SNMPv2", RFC 1901, January BRIDGE-MIB defined in [RFC1493] to the SMIv2 syntax. The original
1996. authors of the SMIv1 module were E. Decker, P. Langille, A
Rijsinghani and K. McCloghrie. Further acknowledgement is given to
the members of the original Bridge Working Group in [RFC1493].
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, This document was produced on behalf of the Bridge MIB Working Group
"Transport Mappings for Version 2 of the Simple Network in the Operations and Management area of the Internet Engineering
Management Protocol (SNMPv2)", RFC 1906, January 1996. Task Force. The editors wish to thank the members of the Bridge MIB
Working Group, especially Mike MacFadden and Bert Visscher for their
many comments and suggestions which improved this effort. Juergen
Schoenwaelder helped in finalizing the draft for publication.
[RFC1907] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 7. Changes from RFC 1493
"Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1907, January
1996.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, The following changes have been made from RFC 1493.
"Introduction to Version 3 of the Internet-standard Network
Management Framework", RFC 2570, April 1999.
8. Changes from RFC 1493 1. Translated the MIB definitions to use SMIv2. This includes the
introduction of conformance statements. ASN.1 type definitions
have been converted into textual-conventions and several units
clauses were added.
2. The object dot1dStpPortPathCost32 was added to support IEEE
802.1t.
3. Permissible values for dot1dStpPriority and dot1dStpPortPriority
have been clarified for bridges supporting IEEE 802.1t or IEEE
802.1w.
4. Interpretation of dot1dStpTimeSinceTopologyChange has been
clarified for bridges supporting the rapid spanning tree protocol
(RSTP).
5. Updated the introductionary boilerplate text, the security
considerations section and the references to comply with the
current IETF standards and guidelines.
6. Updated references to point to newer IEEE 802.1d documents.
7. Additions and clarifications in various description clauses.
The following changes have been made from RFC 1493. 8. Open Issues
(1) Translated the MIB definition to use SMIv2. This list of open issues should be cleared and removed before this
document hits the IESG.
(2) Updated the SNMP Framework and references to comply with the 1. The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes it
current IETF guidelines. mandatory. I think this is broken since existing deployed
implementations won't support that object and thus are not
compliant. Can someone please explain in which situations the
increased range of dot1dStpPortPathCost32 is actually needed? Is
this only relevant for rapid spanning tree? In that case, I think
the object should be conditionally mandatory for boxes that do
rapid spanning tree and the old one stays current, probably with
a special value to use in case dot1dStpPortPathCost32 actually
has the larger path cost.
2. Rename "Authors' Addresses" to "Contact Information" and add
original authors to the contact information section.
3. Is the unit of dot1dTpPortMaxInfo bytes? I guess so but it was
never spelled out. Reading this object from bridges from
different vendors lead to rather large and varying numbers...
(3) Updated the Security section to comply with current IETF 9. References
guidelines.
The following chnages have been made from 9.1 Normative References
draft-ietf-bridge-bridgemib-smiv2-00.txt
(1) Misc. description refernces to IEEE 802.1d documents [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
(2) dot1dNotificationGroup changed from dot1dTrapGroup [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
(3) Misc. additions to some descriptions [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
The following chnages have been made from Conventions for SMIv2", STD 58, RFC 2579, April 1999.
draft-ietf-bridge-bridgemib-smiv2-01.txt
(1) corrections to objects that were made not-accessible in the [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
draft-00 version that were read /read-write in rfc 1493 "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
(2) Misc. additions to some descriptions [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
The following chnages have been made from [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
draft-ietf-bridge-bridgemib-smiv2-02.txt MIB", RFC 2863, June 2000.
(1) Updated references of IEEE 802.1d draft from [IEEE8021D]
1990 document to 1998 document. IEEE Project 802 Local and Metropolitan Area Networks,
"ANSI/IEEE Standard 802.1D-1998 MAC Bridges", March 1998.
The following chnages have been made from 9.2 Informative References
draft-ietf-bridge-bridgemib-smiv2-03.txt
(1) Adapted the current conformance statement. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
No changes have been made between version 4 and version 5 [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K.
of this draft. McCloghrie, "Definitions of Managed Objects for Bridges",
RFC 1493.
9. Authors' Addresses Authors' Addresses
K.C. Norseth Kenyon C. Norseth (editor)
L-3 Communications L-3 Communications
640 N. 2200 West. 640 N. 2200 West
Salt Lake City, Utah 84116-0850 Salt Lake City, Utah 84116-0850
Email: kenyon.c.norseth@L-3com.com USA
kcn@norseth.com
Les Bell Phone: +1 801-594-2809
EMail: kenyon.c.norseth@L-3com.com
E. Bell (editor)
3Com Europe Limited 3Com Europe Limited
3Com Centre, Boundary Way 3Com Centre, Boundary Way
Hemel Hempstead Hemel Hempstead Herts. HP2 7YU
Herts. HP2 7YU
UK UK
Phone: +44 1442 438025 Phone: +44 1442 438025
Email: Les_Bell@3Com.com EMail: Les_Bell@3Com.com
10. Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use of
and distributed, in whole or in part, without restriction of any such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph are specification can be obtained from the IETF on-line IPR repository at
included on all such copies and derivative works. However, this http://www.ietf.org/ipr.
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 The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
This document and the information contained herein is provided on an Disclaimer of Validity
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING This document and the information contained herein are provided on an
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/