draft-ietf-bridge-objects-01.txt   rfc1493.txt 
Internet Draft Bridge MIB October 1992 Network Working Group E. Decker
Request for Comments: 1493 cisco Systems, Inc.
Definitions of Managed Objects Obsoletes: 1286 P. Langille
for Bridges Digital Equipment Corporation
A. Rijsinghani
26 October 17:53:30 EST 1992 Digital Equipment Corporation
K. McCloghrie
Draft Expiration Date: March 1993 Hughes LAN Systems, Inc.
July 1993
Eric B. Decker
cisco Systems, Inc.
cire@cisco.com
Paul Langille & Anil Rijsinghani
Digital Equipment Corporation
anil@levers.enet.dec.com
langille@edwin.enet.dec.com
Keith McCloghrie
Hughes LAN Systems, Inc.
kzm@hls.com
1. 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-1990 standard
between Local Area Network (LAN) segments. 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.
2. Status of this Memo
This document will be submitted to the RFC editor as an Definitions of Managed Objects
extension to the SNMP MIB. Distribution of this memo is for Bridges
unlimited. Please send comments to the authors.
This document is an Internet Draft. Internet Drafts are Status of this Memo
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six This RFC specifies an IAB standards track protocol for the Internet
months. Internet Drafts may be updated, replaced, or obsoleted community, and requests discussion and suggestions for improvements.
by other documents at any time. It is not appropriate to use Please refer to the current edition of the "IAB Official Protocol
Internet Drafts as reference material or to cite them other Standards" for the standardization state and status of this protocol.
than as a "working draft" or "work in progress." Distribution of this memo is unlimited.
Please check the I-D abstract listing contained in each Abstract
Internet Draft directory to learn the current status of this
or any other Internet Draft.
3. The Network Management Framework 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-1990 standard between Local Area Network (LAN)
segments. 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.
The Internet-standard Network Management Framework consists of Table of Contents
three components. They are:
RFC 1155 which defines the SMI, the mechanisms used for 1. The Network Management Framework ...................... 2
describing and naming objects for the purpose of 2. Objects ............................................... 2
management. RFC 1212 defines a more concise description 2.1 Format of Definitions ................................ 3
mechanism, which is wholly consistent with the SMI. 3. Overview .............................................. 3
3.1 Structure of MIB ..................................... 3
3.1.1 The dot1dBase Group ................................ 6
3.1.2 The dot1dStp Group ................................. 6
3.1.3 The dot1dSr Group .................................. 6
3.1.4 The dot1dTp Group .................................. 6
3.1.5 The dot1dStatic Group .............................. 6
3.2 Relationship to Other MIBs ........................... 6
3.2.1 Relationship to the 'system' group ................. 6
3.2.2 Relationship to the 'interfaces' group ............. 7
3.3 Textual Conventions .................................. 8
4. Changes from RFC 1286 ................................. 8
5. Definitions ........................................... 9
5.1 Groups in the Bridge MIB ............................. 11
5.2 The dot1dBase Group Definitions ...................... 11
5.3 The dot1dStp Group Definitions ....................... 14
5.4 The dot1dTp Group Definitions ........................ 22
5.5 The dot1dStatic Group Definitions .................... 28
5.6 Traps for use by Bridges ............................. 31
6. Acknowledgments ....................................... 31
7. References ............................................ 33
8. Security Considerations ............................... 33
9. Authors' Addresses .................................... 34
RFC 1156 which defines MIB-I, the core set of managed 1. The Network Management Framework
objects for the Internet suite of protocols. RFC 1213,
defines MIB-II, an evolution of MIB-I based on
implementation experience and new operational requirements.
RFC 1157 which defines the SNMP, the protocol used for The Internet-standard Network Management Framework consists of three
network access to managed objects. components. They are:
The Framework permits new objects to be defined for the STD16/RFC 1155 which defines the SMI, the mechanisms used for
purpose of experimentation and evaluation. describing and naming objects for the purpose of management.
STD16/RFC 1212 defines a more concise description mechanism, which
is wholly consistent with the SMI.
4. Objects RFC 1156 which defines MIB-I, the core set of managed objects for
the Internet suite of protocols. STD17/RFC 1213, defines MIB-II,
an evolution of MIB-I based on implementation experience and new
operational requirements.
Managed objects are accessed via a virtual information store, STD15/RFC 1157 which defines the SNMP, the protocol used for
termed the Management Information Base or MIB. Objects in the network access to managed objects.
MIB are defined using the subset of Abstract Syntax Notation
One (ASN.1) [7] defined in the SMI. In particular, each
object has a name, a syntax, and an encoding. The name is an
object identifier, an administratively assigned name, which
specifies an object type. The object type together with an
object instance serves to uniquely identify a specific
instantiation of the object. For human convenience, we often
use a textual string, termed the OBJECT DESCRIPTOR, to also
refer to the object type.
The syntax of an object type defines the abstract data The Framework permits new objects to be defined for the purpose of
structure corresponding to that object type. The ASN.1 experimentation and evaluation.
language is used for this purpose. However, the SMI [3]
purposely restricts the ASN.1 constructs which may be used.
These restrictions are explicitly made for simplicity.
The encoding of an object type is simply how that object type 2. Objects
is represented using the object type's syntax. Implicitly
tied to the notion of an object type's syntax and encoding is
how the object type is represented when being transmitted on
the network.
The SMI specifies the use of the basic encoding rules of ASN.1 Managed objects are accessed via a virtual information store, termed
[8], subject to the additional requirements imposed by the the Management Information Base or MIB. Objects in the MIB are
SNMP. defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
defined in the SMI. In particular, each object is named by an OBJECT
IDENTIFIER, an administratively assigned name, which specifies an
object type. The object type together with an object instance serves
to uniquely identify a specific instantiation of the object. For
human convenience, we often use a textual string, termed the
descriptor, to also refer to the object type.
4.1. Format of Definitions 2.1. Format of Definitions
Section 6 contains the specification of all object types Section 5 contains the specification of all object types contained in
contained in this MIB module. The object types are defined this MIB module. The object types are defined using the conventions
using the conventions defined in the SMI, as amended by the defined in the SMI, as amended by the extensions specified in [9,10].
extensions specified in [9,10].
5. Overview 3. Overview
A common device present in many networks is the Bridge. This A common device present in many networks is the Bridge. This device
device is used to connect Local Area Network segments below is used to connect Local Area Network segments below the network
the network layer. layer.
There are two major modes defined for this bridging; There are two major modes defined for this bridging; transparent and
transparent and source route. The transparent method of source route. The transparent method of bridging is defined in the
bridging is defined in the draft IEEE 802.1d draft IEEE 802.1d specification [11]. This memo defines those
specification[11]. This memo defines those objects needed for objects needed for the management of a bridging entity operating in
the management of a bridging entity operating in the the transparent mode, as well as some objects applicable to all types
transparent mode, as well as some objects applicable to all of bridges.
types of bridges.
To be consistent with IAB directives and good engineering To be consistent with IAB directives and good engineering practice,
practice, an explicit attempt was made to keep this MIB as an explicit attempt was made to keep this MIB as simple as possible.
simple as possible. This was accomplished by applying the This was accomplished by applying the following criteria to objects
following criteria to objects proposed for inclusion: proposed for inclusion:
(1) Start with a small set of essential objects and add only (1) Start with a small set of essential objects and add only
as further objects are needed. as further objects are needed.
(2) Require objects be essential for either fault or (2) Require objects be essential for either fault or
configuration management. configuration management.
(3) Consider evidence of current use and/or utility. (3) Consider evidence of current use and/or utility.
(4) Limit the total of objects. (4) Limit the total of objects.
(5) Exclude objects which are simply derivable from others in (5) Exclude objects which are simply derivable from others in
this or other MIBs. this or other MIBs.
(6) Avoid causing critical sections to be heavily (6) Avoid causing critical sections to be heavily
instrumented. The guideline that was followed is one instrumented. The guideline that was followed is one
counter per critical section per layer. counter per critical section per layer.
5.1. Structure of MIB 3.1. Structure of MIB
Objects in this MIB are arranged into groups. Each group is Objects in this MIB are arranged into groups. Each group is
organized as a set of related objects. The overall structure organized as a set of related objects. The overall structure and
and assignment of objects to their groups is shown below. assignment of objects to their groups is shown below. Where
Where appropriate the corresponding IEEE 802.1d[11] management appropriate the corresponding IEEE 802.1d [11] management object name
object name is also included. 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
NumPorts Bridge.NumberOfPorts NumPorts Bridge.NumberOfPorts
Type Type
PortTable PortTable
Port BridgePort.PortNumber Port BridgePort.PortNumber
skipping to change at page 6, line 26 skipping to change at page 5, line 18
InFrames BridgePort.FramesReceived InFrames BridgePort.FramesReceived
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 The following IEEE 802.1d management objects have not been included
included in the Bridge MIB for the indicated reasons. in the Bridge MIB 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 (MIB II)
Bridge.BridgeUpTime Same as sysUpTime (MIB II) Bridge.BridgeUpTime Same as sysUpTime (MIB II)
Bridge.PortAddresses Same as ifPhysAddress (MIB II) Bridge.PortAddresses Same as ifPhysAddress (MIB II)
BridgePort.PortName Same as ifDescr (MIB II) BridgePort.PortName Same as ifDescr (MIB II)
BridgePort.PortType Same as ifType (MIB II) BridgePort.PortType Same as ifType (MIB II)
BridgePort.RoutingType Derivable from the implemented BridgePort.RoutingType Derivable from the implemented
groups groups
skipping to change at page 7, line 16 skipping to change at page 6, line 5
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
5.1.1. The dot1dBase Group 3.1.1. The dot1dBase Group
This mandatory group contains the objects which are applicable This mandatory group contains the objects which are applicable to all
to all types of bridges. types of bridges.
5.1.2. The dot1dStp Group 3.1.2. The dot1dStp Group
This group contains the objects that denote the bridge's state This group contains the objects that denote the bridge's state with
with respect to the Spanning Tree Protocol. If a node does respect to the Spanning Tree Protocol. If a node does not
not implemented the Spanning Tree Protocol, this group will implemented the Spanning Tree Protocol, this group will not be
not be implemented. implemented.
5.1.3. The dot1dSr Group 3.1.3. The dot1dSr Group
This group contains the objects that describe the entity's This group contains the objects that describe the entity's state with
state with respect to source route bridging. If source respect to source route bridging. If source routing is not supported
routing is not supported this group will not be implemented. this group will not be implemented. This group is applicable to
This group is applicable to source route only, and SRT source route only, and SRT bridges. This group will be described in
bridges. This group will be described in a separate document a separate document applicable only to source route bridging.
applicable only to source route bridging.
5.1.4. The dot1dTp Group 3.1.4. The dot1dTp Group
This group contains objects that describe the entity's state This group contains objects that describe the entity's state with
with respect to transparent bridging. If transparent bridging respect to transparent bridging. If transparent bridging is not
is not supported this group will not be implemented. This supported this group will not be implemented. This group is
group is applicable to transparent only and SRT bridges. applicable to transparent only and SRT bridges.
5.1.5. The dot1dStatic Group 3.1.5. The dot1dStatic Group
This group contains objects that describe the entity's state This group contains objects that describe the entity's state with
with respect to destination-address filtering. If respect to destination-address filtering. If destination-address
destination-address filtering is not supported this group will filtering is not supported this group will not be implemented. This
not be implemented. This group is applicable to any type of group is applicable to any type of bridge which performs
bridge which performs destination-address filtering. destination-address filtering.
5.2. Relationship to Other MIBs 3.2. Relationship to Other MIBs
As described above, some IEEE 802.1d management objects have As described above, some IEEE 802.1d management objects have not been
not been included in this MIB because they overlap with included in this MIB because they overlap with objects in other MIBs
objects in other MIBs applicable to a bridge implementing this applicable to a bridge implementing this MIB. In particular, it is
MIB. In particular, it is assumed that a bridge implementing assumed that a bridge implementing this MIB will also implement (at
this MIB will also implement (at least) the 'system' group and least) the 'system' group and the 'interfaces' group defined in MIB-
the 'interfaces' group defined in MIB-II [6]. II [6].
5.2.1. Relationship to the 'system' group 3.2.1. Relationship to the 'system' group
In MIB-II, the 'system' group is defined as being mandatory In MIB-II, the 'system' group is defined as being mandatory for all
for all systems such that each managed entity contains one systems such that each managed entity contains one instance of each
instance of each object in the 'system' group. Thus, those object in the 'system' group. Thus, those objects apply to the
objects apply to the entity as a whole irrespective of whether entity as a whole irrespective of whether the entity's sole
the entity's sole functionality is bridging, or whether functionality is bridging, or whether bridging is only a subset of
bridging is only a subset of the entity's functionality. the entity's functionality.
5.2.2. Relationship to the 'interfaces' group 3.2.2. Relationship to the 'interfaces' group
In MIB-II, the 'interfaces' group is defined as being In MIB-II, the 'interfaces' group is defined as being mandatory for
mandatory for all systems and contains information on an all systems and contains information on an entity's interfaces, where
entity's interfaces, where each interface is thought of as each interface is thought of as being attached to a `subnetwork'.
being attached to a `subnetwork'. (Note that this term is not (Note that this term is not to be confused with `subnet' which refers
to be confused with `subnet' which refers to an addressing to an addressing partitioning scheme used in the Internet suite of
partitioning scheme used in the Internet suite of protocols.) protocols.) The term 'segment' is used in this memo to refer to such
The term 'segment' is used in this memo to refer to such a a subnetwork, whether it be an Ethernet segment, a 'ring', a WAN
subnetwork, whether it be an Ethernet segment, a 'ring', a WAN link, or even an X.25 virtual circuit.
link, or even an X.25 virtual circuit.
Implicit in this Bridge MIB is the notion of ports on a Implicit in this Bridge MIB is the notion of ports on a bridge. Each
bridge. Each of these ports is associated with one interface of these ports is associated with one interface of the 'interfaces'
of the 'interfaces' group, and in most situations, each port group, and in most situations, each port is associated with a
is associated with a different interface. However, there are different interface. However, there are situations in which multiple
situations in which multiple ports are associated with the ports are associated with the same interface. An example of such a
same interface. An example of such a situation would be situation would be several ports each corresponding one-to-one with
several ports each corresponding one-to-one with several X.25 several X.25 virtual circuits but all on the same interface.
virtual circuits but all on the same interface.
Each port is uniquely identified by a port number. A port Each port is uniquely identified by a port number. A port number has
number has no mandatory relationship to an interface number, no mandatory relationship to an interface number, but in the simple
but in the simple case a port number will have the same value case a port number will have the same value as the corresponding
as the corresponding interface's interface number. Port interface's interface number. Port numbers are in the range
numbers are in the range (1..dot1dBaseNumPorts). (1..dot1dBaseNumPorts).
Some entities perform other functionality as well as bridging Some entities perform other functionality as well as bridging through
through the sending and receiving of data on their interfaces. the sending and receiving of data on their interfaces. In such
In such situations, only a subset of the data sent/received on situations, only a subset of the data sent/received on an interface
an interface is within the domain of the entity's bridging is within the domain of the entity's bridging functionality. This
functionality. This subset is considered to be delineated subset is considered to be delineated according to a set of
according to a set of protocols, with some protocols being protocols, with some protocols being bridged, and other protocols not
bridged, and other protocols not being bridged. For example, being bridged. For example, in an entity which exclusively performed
in an entity which exclusively performed bridging, all bridging, all protocols would be considered as being bridged, whereas
protocols would be considered as being bridged, whereas in an in an entity which performed IP routing on IP datagrams and only
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 being bridged.
considered as 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 applicable only to that subset of the data on an entity's interfaces
interfaces which is sent/received for a protocol being which is sent/received for a protocol being bridged. All such data
bridged. All such data is sent/received via the ports of the is sent/received via the ports of the bridge.
bridge.
5.3. Textual Conventions 3.3. Textual Conventions
The datatypes, MacAddress, BridgeId and Timeout, are used as The datatypes, MacAddress, BridgeId and Timeout, are used as textual
textual conventions in this document. These textual conventions in this document. These textual conventions have NO
conventions have NO effect on either the syntax nor the effect on either the syntax nor the semantics of any managed object.
semantics of any managed object. Objects defined using these Objects defined using these conventions are always encoded by means
conventions are always encoded by means of the rules that of the rules that define their primitive type. Hence, no changes to
define their primitive type. Hence, no changes to the SMI or the SMI or the SNMP are necessary to accommodate these textual
the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers.
conventions which are adopted merely for the convenience of
readers.
6. Changes from RFC 1286 4. Changes from RFC 1286
(1) Updated all text to remove references to source route (1) Updated all text to remove references to source route
bridging where not applicable. SR MIB will be a separate bridging where not applicable. SR MIB will be a separate
document. document.
(2) Removed dot1dSrPortTable. Retained OID definition of (2) Removed dot1dSrPortTable. Retained OID definition of
dot1dSr. dot1dSr.
(3) Updated all references of "draft P802.1d/D9" to "IEEE (3) Updated all references of "draft P802.1d/D9" to "IEEE
802.1D-1990". 802.1D-1990".
skipping to change at page 11, line 5 skipping to change at page 9, line 5
use the range (1..65535). use the range (1..65535).
(10) Updated definition of dot1dTpPortInFrames and (10) Updated definition of dot1dTpPortInFrames and
dot1dTpPortOutFrames. dot1dTpPortOutFrames.
(11) Added text to the traps indicating that they are (11) Added text to the traps indicating that they are
optional. optional.
(12) Clarified definition of dot1dStpForwardDelay. (12) Clarified definition of dot1dStpForwardDelay.
7. Definitions 5. Definitions
RFCXXXX-MIB DEFINITIONS ::= BEGIN BRIDGE-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
Counter, TimeTicks Counter, TimeTicks
FROM RFC1155-SMI FROM RFC1155-SMI
mib-2 mib-2
FROM RFC1213-MIB FROM RFC1213-MIB
OBJECT-TYPE OBJECT-TYPE
FROM RFC-1212 FROM RFC-1212
TRAP-TYPE TRAP-TYPE
FROM RFC-1215; FROM RFC-1215;
-- All representations of MAC addresses in this MIB Module use, -- All representations of MAC addresses in this MIB Module
-- as a textual convention (i.e. this convention does not affect -- use, as a textual convention (i.e. this convention does
-- their encoding), the data type: -- not affect their encoding), the data type:
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address in MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address
-- the "canonical" order -- in the
-- defined by IEEE 802.1a, i.e., as if it were transmitted least -- "canonical"
-- significant bit first, even though 802.5 (in contrast to other -- order
-- 802.x protocols) requires MAC addresses to be transmitted most -- defined by IEEE 802.1a, i.e., as if it were transmitted
-- significant bit first. -- least significant bit first, even though 802.5 (in
-- contrast to other n802.x protocols) requires MAC
-- addresses to be transmitted most significant bit first.
-- --
-- 16-bit addresses, if needed, are represented by setting their -- 16-bit addresses, if needed, are represented by setting
-- upper 4 octets to all 0's, i.e., AAFF would be represented -- their upper 4 octets to all 0's, i.e., AAFF would be
-- as 00000000AAFF. -- represented as 00000000AAFF.
-- Similarly, all representations of Bridge-Id in this MIB Module -- Similarly, all representations of Bridge-Id in this MIB
-- use, as a textual convention (i.e. this convention does not affect -- Module use, as a textual convention (i.e. this
-- their encoding), the data type: -- convention does not affect their encoding), the data
-- type:
BridgeId ::= OCTET STRING (SIZE (8)) -- the Bridge-Identifier as BridgeId ::= OCTET STRING (SIZE (8)) -- the
-- used in the Spanning Tree -- Bridge-Identifier
-- Protocol to uniquely identify a bridge. Its first two octets -- as used in the
-- (in network byte order) contain a priority value and its last -- Spanning Tree
-- 6 octets contain the MAC address used to refer to a bridge in a -- Protocol to uniquely identify a bridge. Its first two
-- unique fashion (typically, the numerically smallest MAC address -- 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). -- of all ports on the bridge).
-- Several objects in this MIB module represent values of timers -- Several objects in this MIB module represent values of
-- used by the Spanning Tree Protocol. In this MIB, these timers -- timers used by the Spanning Tree Protocol. In this
-- have values in units of hundreths of a second (i.e. 1/100 secs). -- MIB, these timers have values in units of hundreths of
-- These timers, when stored in a Spanning Tree Protocol's BPDU, -- a second (i.e. 1/100 secs).
-- are in units of 1/256 seconds. Note, however, that 802.1D-1990 -- These timers, when stored in a Spanning Tree Protocol's
-- specifies a settable granularity of no more than 1 second for -- BPDU, are in units of 1/256 seconds. Note, however,
-- these timers. To avoid ambiguity, a data type is defined here -- that 802.1D-1990 specifies a settable granularity of
-- as a textual convention and all representation of these timers -- no more than 1 second for these timers. To avoid
-- in this MIB module are defined using this data type. An algorithm -- ambiguity, a data type is defined here as a textual
-- is also defined for converting between the different units, to -- convention and all representation of these timers
-- ensure a timer's value is not distorted by multiple conversions. -- in this MIB module are defined using this data type. An
-- algorithm is also defined for converting between the
-- different units, to ensure a timer's value is not
-- distorted by multiple conversions.
-- The data type is: -- The data type is:
Timeout ::= INTEGER -- a STP timer in units of 1/100 seconds Timeout ::= INTEGER -- a STP timer in units of 1/100 seconds
-- To convert a Timeout value into a value in units of -- To convert a Timeout value into a value in units of
-- 1/256 seconds, the following algorithm should be used: -- 1/256 seconds, the following algorithm should be used:
-- --
-- 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
skipping to change at page 12, line 41 skipping to change at page 10, line 44
-- 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 non-zero]
-- 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 done -- Note: it is important that the arithmetic operations are
-- in the order specified (i.e., multiply first, divide second). -- done in the order specified (i.e., multiply first, divide
-- second).
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 }
skipping to change at page 36, line 4 skipping to change at page 31, line 36
"A topologyChange trap is sent by a bridge when "A topologyChange trap is sent by a bridge when
any of its configured ports transitions from the any of its configured ports transitions from the
Learning state to the Forwarding state, or from Learning state to the Forwarding state, or from
the Forwarding state to the Blocking state. The the Forwarding state to the Blocking state. The
trap is not sent if a newRoot trap is sent for the trap is not sent if a newRoot trap is sent for the
same transition. Implementation of this trap is same transition. Implementation of this trap is
optional." optional."
::= 2 ::= 2
END END
8. Acknowledgments
This document was produced on behalf of the Bridge Sub-Working 6. Acknowledgments
Group of the SNMP Working Group of the Internet Engineering
Task Force. Over the course of its deliberations, the working
group received four separate documents for consideration as
the basis for its work. The first was submitted by Stan Froyd
of Advanced Computer Communications; the second by Richard Fox
of SynOptics; the third by Eric Decker of cisco Inc. and Keith
McCloghrie of Hughes LAN Systems; and the fourth by Paul
Langille and Anil Rijsinghani of Digital Equipment Corp. After
considering the submissions, the working group chose to
proceed with a document formed as a conjunction of the latter
two submissions. This document is the result.
The authors wish to thank the members of the Bridge Working This document was produced on behalf of the Bridge Sub-Working Group
Group for their many comments and suggestions which improved of the SNMP Working Group of the Internet Engineering Task Force.
this effort. In particular, Fred Baker (chairman of the Over the course of its deliberations, the working group received four
working group) of ACC, Steve Sherry of Xyplex, and Frank separate documents for consideration as the basis for its work. The
Kastenholz of Clearpoint Research Corp. Others members of the first was submitted by Stan Froyd of Advanced Computer
Bridge Working Group who contributed to this effort are: Communications; the second by Richard Fox of SynOptics; the third by
Eric Decker of cisco Inc. and Keith McCloghrie of Hughes LAN Systems;
and the fourth by Paul Langille and Anil Rijsinghani of Digital
Equipment Corp. After considering the submissions, the working group
chose to proceed with a document formed as a conjunction of the
latter two submissions. This document is the result.
The authors wish to thank the members of the Bridge Working Group for
their many comments and suggestions which improved this effort. In
particular, Fred Baker (chairman of the working group) of ACC, Steve
Sherry of Xyplex, and Frank Kastenholz of Clearpoint Research Corp.
Others members of the Bridge Working Group who contributed to this
effort are:
Bill Anderson, Mitre Bill Anderson, Mitre
Karl Auerbach, Epilogue Karl Auerbach, Epilogue
Fred Baker, ACC (chair) Fred Baker, ACC (chair)
Terry Bradley, Wellfleet Terry Bradley, Wellfleet
Ted Brunner, Bellcore Ted Brunner, Bellcore
Jeffrey Buffum, Apollo Jeffrey Buffum, Apollo
Chris ChioTasso, Fibronics Chris ChioTasso, Fibronics
Anthony Chung, HLS Anthony Chung, HLS
Chuck Davin, MIT-LCS Chuck Davin, MIT-LCS
skipping to change at page 38, line 5 skipping to change at page 33, line 5
Anil Rijsinghani, Digital Anil Rijsinghani, Digital
Mark Schaefer, David Systems Mark Schaefer, David Systems
Steve Sherry, Xyplex Steve Sherry, Xyplex
Bob Stewart, Xyplex Bob Stewart, Xyplex
Emil Sturniolo, Emil Sturniolo,
Kevin Synott, Retix Kevin Synott, Retix
Ian Thomas, Chipcom Ian Thomas, Chipcom
Maurice Turcott, Racal Maurice Turcott, Racal
Fei Xu, Fei Xu,
9. References 7. References
[1] V. Cerf, IAB Recommendations for the Development of [1] Cerf, V., "IAB Recommendations for the Development of Internet
Internet Network Management Standards. Internet Working Network Management Standards", RFC 1052, NRI, April 1988.
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
(April, 1988).
[2] V. Cerf, Report of the Second Ad Hoc Network Management [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
Review Group, Internet Working Group Request for Comments Group", RFC 1109, NRI, August 1989.
1109. Network Information Center, SRI International,
Menlo Park, California, (August, 1989).
[3] M.T. Rose and K. McCloghrie, Structure and Identification [3] Rose M., and K. McCloghrie, "Structure and Identification of
of Management Information for TCP/IP-based internets, Management Information for TCP/IP-based internets", STD 16, RFC
Internet Working Group Request for Comments 1155. 1155, Performance Systems International, Hughes LAN Systems, May
Network Information Center, SRI International, Menlo 1990.
Park, California, (May, 1990).
[4] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Simple Network Management Protocol, Internet Working Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Group Request for Comments 1157. Network Information Performance Systems International, Performance Systems
Center, SRI International, Menlo Park, California, (May, International, MIT Laboratory for Computer Science, May 1990.
1990).
[5] K. McCloghrie and M.T. Rose (editors), Management [5] McCloghrie K., and M. Rose, Editors, "Management Information Base
Information Base for Network Management of TCP/IP-based for Network Management of TCP/IP-based internets", STD 17, RFC
internets: MIB-II, Internet Working Group Request for 1213, Performance Systems International, March 1991.
Comments 1213. Network Information Center, SRI
International, Menlo Park, California, (March, 1991).
[6] Information processing systems - Open Systems [6] Information processing systems - Open Systems Interconnection -
Interconnection - Specification of Abstract Syntax Specification of Abstract Syntax Notation One (ASN.1),
Notation One (ASN.1), International Organization for International Organization for Standardization, International
Standardization. International Standard 8824, (December, Standard 8824, December 1987.
1987).
[7] Information processing systems - Open Systems [7] Information processing systems - Open Systems Interconnection -
Interconnection - Specification of Basic Encoding Rules Specification of Basic Encoding Rules for Abstract Notation One
for Abstract Notation One (ASN.1), International (ASN.1), International Organization for Standardization,
Organization for Standardization. International Standard International Standard 8825, December 1987.
8825, (December, 1987).
[8] M.T. Rose, K. McCloghrie (editors), Concise MIB [8] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
Definitions, Internet Working Group Request for Comments STD 16, RFC 1212, Performance Systems International, Hughes LAN
1212. Network Information Center, SRI International, Systems, March 1991.
Menlo Park, California, (March, 1991).
[9] M.T. Rose (editor), A Convention for Defining Traps for [9] Rose, M., Editor, "A Convention for Defining Traps for use with
use with the SNMP, Internet Working Group Request for the SNMP", RFC 1215, Performance Systems International, March
Comments 1215. Network Information Center, SRI 1991.
International, Menlo Park, California, (March, 1991).
[10] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project [10] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project 802
802 Local and Metropolitan Area Networks, (March 8, Local and Metropolitan Area Networks, (March 8, 1991).
1991).
[11] ISO DIS 10038 MAC Bridges [11] ISO DIS 10038 MAC Bridges.
Table of Contents
1 Abstract .............................................. 1 8. Security Considerations
2 Status of this Memo ................................... 1
3 The Network Management Framework ...................... 2
4 Objects ............................................... 2
4.1 Format of Definitions ............................... 3
5 Overview .............................................. 4
5.1 Structure of MIB .................................... 4
5.1.1 The dot1dBase Group ............................... 7
5.1.2 The dot1dStp Group ................................ 7
5.1.3 The dot1dSr Group ................................. 7
5.1.4 The dot1dTp Group ................................. 7
5.1.5 The dot1dStatic Group ............................. 7
5.2 Relationship to Other MIBs .......................... 8
5.2.1 Relationship to the 'system' group ................ 8
5.2.2 Relationship to the 'interfaces' group ............ 8
5.3 Textual Conventions ................................. 9
6 Changes from RFC 1286 ................................. 9
7 Definitions ........................................... 11
7.1 Groups in the Bridge MIB ............................ 12
7.2 The dot1dBase Group Definitions ..................... 13
7.3 The dot1dStp Group Definitions ...................... 17
7.4 The dot1dTp Group Definitions ....................... 26
7.5 The dot1dStatic Group Definitions ................... 32
7.6 Traps for use by Bridges ............................ 35
8 Acknowledgments ....................................... 36
9 References ............................................ 38
Draft Expiration Date: March 1993 Security issues are not discussed in this memo.
9. Authors' Addresses
Eric B. Decker
cisco Systems, Inc.
1525 O'Brien Dr.
Menlo Park, CA 94025
Phone: (415) 326-1941
Email: cire@cisco.com
Paul Langille
Digital Equipment Corporation
Digital Drive, MK02-2/K03
Merrimack, NH 03054
Phone: (603) 884-4045
EMail: langille@edwin.enet.dec.com
Anil Rijsinghani
Digital Equipment Corporation
550 King Street
Littleton, MA 01460
Phone: (508) 486-6786
EMail: anil@levers.enet.dec.com
Keith McCloghrie
Hughes LAN Systems, Inc.
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.com
 End of changes. 75 change blocks. 
339 lines changed or deleted 287 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/