Request for Comments: 4188 L-3 Communications
Obsoletes: 1493 E. Bell, Ed.
Category: Standards Track 3Com Europe Limited
September 2005
Definitions of Managed Objects for Bridges
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 (2005).
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 objects for managing MAC bridges based on
the IEEE 802.1D-1998 standard between Local Area Network (LAN)
segments. Provisions are made for the support of transparent
bridging. Provisions are also made so that these objects apply to
bridges connected by subnetworks other than LAN segments.
The MIB module presented in this memo is a translation of the
BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.
This memo obsoletes RFC 1493.
Table of Contents
1. The Internet-Standard Management Framework ......................2
2. Conventions .....................................................2
3. Overview ........................................................3
3.1. Structure of the MIB Module ................................3
3.1.1. The dot1dBase Subtree ...............................6
3.1.2. The dot1dStp Subtree ................................6
3.1.3. The dot1dSr Subtree .................................6
3.1.4. The dot1dTp Subtree .................................6
3.1.5. The dot1dStatic Subtree .............................6
3.2. Relationship to Other MIB Modules ..........................6
3.2.1. Relationship to the SNMPv2-MIB ......................7
3.2.2. Relationship to the IF-MIB ..........................7
4. Definitions .....................................................8
5. IANA Considerations ............................................39
6. Security Considerations ........................................39
7. Acknowledgements ...............................................40
8. Contact Information ............................................41
9. Changes from RFC 1493 ..........................................42
10. References ....................................................42
10.1. Normative References .....................................42
10.2. Informative References ...................................43
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when they appear in this document, are to be interpreted
as described in BCP 14, RFC 2119 [RFC2119].
3. 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.
There are two major modes defined for this bridging: transparent and
source route. The transparent method of bridging is defined in the
IEEE 802.1D specification [IEEE8021D]. This memo defines those
objects needed for the management of a bridging entity that operates
in the transparent mode, as well as some objects that apply to all
types of bridges.
To be consistent with IAB directives and good engineering practices,
an explicit attempt was made to keep this MIB module as simple as
possible. This was accomplished by applying the following criteria
to objects proposed for inclusion:
1. Start with a small set of essential objects and add only as
further objects are needed.
2. Require that objects be essential for either fault or
configuration management.
3. Consider evidence of current use and/or utility.
4. Limit the total number of objects.
5. Exclude objects that are simply derivable from others in this or
other MIB modules.
6. Avoid causing critical sections to be heavily instrumented. The
guideline that was followed is one counter per critical section
per layer.
3.1 Structure of the MIB Module
Objects in this MIB module are arranged into subtrees. Each subtree
is organized as a set of related objects. The overall structure and
assignment of objects to their subtrees is shown below. Where
appropriate, the corresponding IEEE 802.1D [IEEE8021D] management
object name is also included.
Bridge MIB Name IEEE 802.1D Name
dot1dBridge
dot1dBase
BridgeAddress Bridge.BridgeAddress
NumPorts Bridge.NumberOfPorts
Type
PortTable
Port BridgePort.PortNumber
IfIndex
Circuit
DelayExceededDiscards .DiscardTransitDelay
MtuExceededDiscards .DiscardOnError
dot1dStp
ProtocolSpecification
Priority SpanningTreeProtocol
.BridgePriority
TimeSinceTopologyChange .TimeSinceTopologyChange
TopChanges .TopologyChangeCount
DesignatedRoot .DesignatedRoot
RootCost .RootCost
RootPort .RootPort
MaxAge .MaxAge
HelloTime .HelloTime
HoldTime .HoldTime
ForwardDelay .ForwardDelay
BridgeMaxAge .BridgeMaxAge
BridgeHelloTime .BridgeHelloTime
BridgeForwardDelay .BridgeForwardDelay
PortTable
Port SpanningTreeProtocolPort
.PortNumber
Priority .PortPriority
State .SpanningTreeState
Enable
PathCost .PortPathCost
DesignatedRoot .DesignatedRoot
DesignatedCost .DesignatedCost
DesignatedBridge .DesignatedBridge
DesignatedPort .DesignatedPort
ForwardTransitions
dot1dTp
LearnedEntryDiscards BridgeFilter.DatabaseSize
.NumDynamic,NumStatic
AgingTime BridgeFilter.AgingTime
FdbTable
Address
Port
Status
PortTable
Port
MaxInfo
InFrames BridgePort.FramesReceived
OutFrames .ForwardOutbound
InDiscards .DiscardInbound
dot1dStatic
StaticTable
Address
ReceivePort
AllowedToGoTo
Status
The following IEEE 802.1D management objects have not been included
in the BRIDGE-MIB module for the indicated reasons.
IEEE 802.1D Object Disposition
Bridge.BridgeName Same as sysDescr (SNMPv2-MIB)
Bridge.BridgeUpTime Same as sysUpTime (SNMPv2-MIB)
Bridge.PortAddresses Same as ifPhysAddress (IF-MIB)
BridgePort.PortName Same as ifDescr (IF-MIB)
BridgePort.PortType Same as ifType (IF-MIB)
BridgePort.RoutingType Derivable from the implemented
subtrees
SpanningTreeProtocol
.BridgeIdentifier Combination of dot1dStpPriority
and dot1dBaseBridgeAddress
.TopologyChange Since this is transitory, it
is not considered useful.
SpanningTreeProtocolPort
.Uptime Same as ifLastChange (IF-MIB)
.PortIdentifier Combination of dot1dStpPort
and dot1dStpPortPriority
.TopologyChangeAcknowledged Since this is transitory, it
is not considered useful.
.DiscardLackOfBuffers Redundant
Transmission Priority These objects are not required
as per the Pics Proforma and
are not considered useful.
.TransmissionPriorityName
.OutboundUserPriority
.OutboundAccessPriority
3.1.1 The dot1dBase Subtree
This subtree contains the objects that are applicable to all types of
bridges.
3.1.2 The dot1dStp Subtree
This subtree contains the objects that denote the bridge’s state with
respect to the Spanning Tree Protocol. If a node does not implement
the Spanning Tree Protocol, this subtree will not be implemented.
3.1.3 The dot1dSr Subtree
This subtree contains the objects that describe the entity’s state
with respect to source route bridging. This subtree described in RFC
1525 [RFC1525] is applicable only to source route bridging.
3.1.4 The dot1dTp Subtree
This subtree contains objects that describe the entity’s state with
respect to transparent bridging. If transparent bridging is not
supported, this subtree will not be implemented. This subtree is
applicable to transparent-only and SRT bridges.
3.1.5 The dot1dStatic Subtree
This subtree contains objects that describe the entity’s state with
respect to destination-address filtering. If destination-address
filtering is not supported, this subtree will not be implemented.
This subtree is applicable to any type of bridge that performs
destination-address filtering.
3.2 Relationship to Other MIB Modules
As described above, some IEEE 802.1D management objects have not been
included in this MIB module because they overlap with objects in
other MIB modules that are applicable to a bridge implementing this
MIB module.
3.2.1 Relationship to the SNMPv2-MIB
The SNMPv2-MIB [RFC3418] defines objects that are generally
applicable to managed devices. These objects apply to the device as
a whole, irrespective of whether the device’s sole functionality is
bridging, or whether bridging is only a subset of the device’s
functionality.
As explained in Section 3.1, full support for the 802.1D management
objects requires that the SNMPv2-MIB objects sysDescr and sysUpTime
be implemented. Note that compliance with the current SNMPv2-MIB
module requires additional objects and notifications to be
implemented, as specified in RFC 3418 [RFC3418].
3.2.2 Relationship to the IF-MIB
The IF-MIB [RFC2863] defines managed objects for managing network
interfaces. A network 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.
As explained in Section 3.1, full support for the 802.1D management
objects requires that the IF-MIB objects ifIndex, ifType, ifDescr,
ifPhysAddress, and ifLastChange are implemented. Note that
compliance to the current IF-MIB module requires additional objects
and notifications to be implemented as specified in RFC 2863
[RFC2863].
Implicit in this BRIDGE-MIB is the notion of ports on a bridge. Each
of these ports is associated with one interface of the ’interfaces’
subtree, 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 that are 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 functionalities 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 that
exclusively performs bridging, all protocols would be considered as
bridged, whereas in an entity that performs IP routing on IP
datagrams and only bridges other protocols, only the non-IP data
would be considered as having been bridged.
Thus, this BRIDGE-MIB (and in particular, its counters) are
applicable only to that subset of the data on an entity’s interfaces
that is sent/received for a protocol being bridged. All such data is
sent/received via the ports of the bridge.
4. Definitions
BRIDGE-MIB DEFINITIONS ::= BEGIN
-- ---------------------------------------------------------- --
-- MIB for IEEE 802.1D devices
-- ---------------------------------------------------------- --
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Integer32, TimeTicks, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, MacAddress
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
InterfaceIndex FROM IF-MIB
;
dot1dBridge MODULE-IDENTITY
LAST-UPDATED "200509190000Z"
ORGANIZATION "IETF Bridge MIB Working Group"
CONTACT-INFO
"Email: bridge-mib@ietf.org
K.C. Norseth (Editor)
L-3 Communications
Tel: +1 801-594-2809
Email: kenyon.c.norseth@L-3com.com
Postal: 640 N. 2200 West.
Salt Lake City, Utah 84116-0850
Les Bell (Editor)
3Com Europe Limited
Phone: +44 1442 438025
Email: elbell@ntlworld.com
Postal: 3Com Centre, Boundary Way
Hemel Hempstead
Herts. HP2 7YU
UK
Send comments to <bridge-mib@ietf.org>"
DESCRIPTION
"The Bridge MIB module for managing devices that support
IEEE 802.1D.
Copyright (C) The Internet Society (2005). This version of
this MIB module is part of RFC 4188; see the RFC itself for
full legal notices."
REVISION "200509190000Z"
DESCRIPTION
"Third revision, published as part of RFC 4188.
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"
DESCRIPTION
"Second revision, published as part of RFC 1493."
REVISION "199112310000Z"
DESCRIPTION
"Initial revision, published as part of RFC 1286."
::= { mib-2 17 }
-- ---------------------------------------------------------- --
-- Textual Conventions
-- ---------------------------------------------------------- --
BridgeId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Bridge-Identifier, as used in the Spanning Tree
Protocol, to uniquely identify a bridge. Its first two
octets (in network byte order) contain a priority value,
and its last 6 octets contain the MAC address used to
refer to a bridge in a unique fashion (typically, the
numerically smallest MAC address of all ports on the
bridge)."
SYNTAX OCTET STRING (SIZE (8))
Timeout ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A Spanning Tree Protocol (STP) timer in units of 1/100
seconds. Several objects in this MIB module represent
values of timers 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).
These timers, when stored in a Spanning Tree Protocol’s
BPDU, are in units of 1/256 seconds. Note, however, that
802.1D-1998 specifies a settable granularity of no more
than one second for these timers. To avoid ambiguity,
a conversion algorithm is defined below for converting
between the different units, which ensures a timer’s
value is not distorted by multiple conversions.
To convert a Timeout value into a value in units of
1/256 seconds, the following algorithm should be used:
b = floor( (n * 256) / 100)
where:
floor = quotient [ignore remainder]
n is the value in 1/100 second units
b is the value in 1/256 second units
To convert the value from 1/256 second units back to
1/100 seconds, the following algorithm should be used:
n = ceiling( (b * 100) / 256)
where:
ceiling = quotient [if remainder is 0], or
quotient + 1 [if remainder is nonzero]
n is the value in 1/100 second units
b is the value in 1/256 second units
Note: it is important that the arithmetic operations are
done in the order specified (i.e., multiply first,
divide second)."
SYNTAX Integer32
-- ---------------------------------------------------------- --
-- subtrees in the Bridge MIB
-- ---------------------------------------------------------- --
dot1dNotifications OBJECT IDENTIFIER ::= { dot1dBridge 0 }
dot1dBase OBJECT IDENTIFIER ::= { dot1dBridge 1 }
dot1dStp OBJECT IDENTIFIER ::= { dot1dBridge 2 }
dot1dSr OBJECT IDENTIFIER ::= { dot1dBridge 3 }
-- documented in RFC 1525
dot1dTp OBJECT IDENTIFIER ::= { dot1dBridge 4 }
dot1dStatic OBJECT IDENTIFIER ::= { dot1dBridge 5 }
-- Subtrees used by Bridge MIB Extensions:
-- pBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 6 }
-- qBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 7 }
-- Note that the practice of registering related MIB modules
-- below dot1dBridge has been discouraged since there is no
-- robust mechanism to track such registrations.
dot1dConformance OBJECT IDENTIFIER ::= { dot1dBridge 8 }
-- ---------------------------------------------------------- --
-- the dot1dBase subtree
-- ---------------------------------------------------------- --
-- Implementation of the dot1dBase subtree is mandatory for all