summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1525.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1525.txt')
-rw-r--r--doc/rfc/rfc1525.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc1525.txt b/doc/rfc/rfc1525.txt
new file mode 100644
index 0000000..627e38a
--- /dev/null
+++ b/doc/rfc/rfc1525.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group E. Decker
+Request for Comments: 1525 cisco Systems, Inc.
+Obsoletes: 1286 K. McCloghrie
+Category: Standards Track Hughes LAN Systems, Inc.
+ P. Langille
+ DEC
+ A. Rijsinghani
+ DEC
+ September 1993
+
+
+ Definitions of Managed Objects for
+ Source Routing Bridges
+
+Status of this Memo
+
+ This RFC 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" for the standardization state and status
+ of this protocol. Distribution of this memo is unlimited.
+
+Table of Contents
+
+ 1. Introduction ......................................... 2
+ 2. The Network Management Framework ..................... 2
+ 2.1 Object Definitions .................................. 2
+ 3. Overview ............................................. 2
+ 3.1 Structure of MIB .................................... 3
+ 3.1.1 The dot1dSr Group ................................. 4
+ 3.1.2 The dot1dPortPair Group ........................... 4
+ 3.2 Relationship to Other MIBs .......................... 5
+ 3.2.1 Relationship to the Bridge MIB .................... 5
+ 3.2.2 Relationship to the 'system' group ................ 5
+ 3.2.3 Relationship to the 'interfaces' group ............ 5
+ 4. Changes from RFC 1286 ................................ 6
+ 5. Definitions .......................................... 7
+ 5.1 Groups in the SR MIB ................................ 7
+ 5.2 The dot1dSr Group Definitions ....................... 7
+ 5.3 The dot1dPortPair Group Definitions ................. 14
+ 6. Acknowledgments ...................................... 16
+ 7. References ........................................... 16
+ 8. Security Considerations .............................. 18
+ 9. Authors' Addresses ................................... 18
+
+
+
+
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 1]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+1. Introduction
+
+ 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 source routing and
+ source routing transparent bridges. These bridges are also required
+ to implement relevant groups in the Bridge MIB [6].
+
+ This MIB supersedes the dot1dSr group of objects published in an
+ earlier version of the Bridge MIB, RFC 1286. Changes have primarily
+ been made to track changes in the IEEE 802.5M SRT Addendum to the
+ IEEE 802.1D Standard for MAC Bridges.
+
+2. The Network Management Framework
+
+ The Internet-standard Network Management Framework consists of three
+ components. They are:
+
+ o STD 16, RFC 1155 which defines the SMI, the mechanisms used for
+ describing and naming objects for the purpose of
+ management. STD 16, RFC 1212 defines a more concise description
+ mechanism, which is wholly consistent with the SMI.
+
+ o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
+ for the Internet suite of protocols.
+
+ o STD 15, RFC 1157 which defines the SNMP, the protocol used for
+ network access to managed objects.
+
+ The Framework permits new objects to be defined for the purpose of
+ experimentation and evaluation.
+
+2.1. Object Definitions
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. Objects in the MIB are
+ defined using the subset of Abstract Syntax Notation One (ASN.1)
+ defined in the SMI. In particular, each object object type is named
+ by an OBJECT IDENTIFIER, an administratively assigned name. 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
+ refer to the object type.
+
+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
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 2]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ 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 MAC Bridge specification [11]. Source
+ route bridging has been defined by I.B.M. and is described in the
+ Token Ring Architecture Reference [12], as well as the IEEE 802.5M
+ SRT Bridge Operations Addendum [14] to 802.1d. This memo defines
+ objects needed for management of a source routing bridge, and is an
+ extension to the SNMP Bridge MIB [6].
+
+ An explicit attempt was made to keep this MIB 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 objects be essential for either fault or
+ configuration management.
+
+ (3) Consider evidence of current use and/or utility.
+
+ (4) Limit the total of objects.
+
+ (5) Exclude objects which are simply derivable from others in
+ this or other MIBs.
+
+ (6) Avoid causing critical sections to be heavily
+ instrumented. The guideline that was followed is one
+ counter per critical section per layer.
+
+3.1. Structure of MIB
+
+ Objects in this MIB are arranged into groups. Each group is
+ organized as a set of related objects. The overall structure and
+ assignment of objects to their groups is shown below. Where
+ appropriate, the corresponding management object name found in IEEE
+ 802.1d [11] and IEEE 802.5M [14] is also included.
+
+ SR Bridge MIB Name IEEE Name
+
+ dot1dSr
+ PortTable
+ Port
+ HopCount SourceRoutingPort
+ .PortHopCount
+ LocalSegment .SegmentNumber
+ BridgeNum .BridgeNumber
+ TargetSegment
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 3]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ LargestFrame .LargestFrameSize
+ STESpanMode .LimitedBroadcastMode
+ SpecInFrames BridgePort
+ .ValidSRFramesReceived
+ SpecOutFrames .ValidSRForwardedOutbound
+ ApeInFrames
+ ApeOutFrames .BroadcastFramesForwarded
+ SteInFrames
+ SteOutFrames .BroadcastFramesForwarded
+ SegmentMismatchDiscards .DiscardInvalidRI
+ DuplicateSegmentDiscards .LanIdMismatch
+ HopCountExceededDiscards .FramesDiscardedHopCountExceeded
+
+ The following IEEE management objects have not been included in the
+ SR Bridge MIB for the indicated reasons.
+
+ IEEE Object Disposition
+
+ SourceRoutingPort
+ The following objects were NOT
+ included in this MIB because they
+ are redundant or not considered
+ useful.
+ .LimitedBroadcastEnable
+ .DiscardLackOfBuffers
+ .DiscardErrorDetails
+ .DiscardTargetLANInoperable
+ .ValidSRDiscardedInbound
+ .BroadcastBytesForwarded
+ .NonBroadcastBytesForwarded
+ .FramesNotReceivedDueToCongestion
+ .FramesDiscardedDueToInternalError
+
+3.1.1. The dot1dSr Group
+
+ This group contains the objects that describe the entity's state with
+ respect to source route bridging. If source routing is not
+ supported, this group will not be implemented. This group is
+ applicable to source route only, and SRT bridges.
+
+3.1.2. The dot1dPortPair Group
+
+ Implementation of this group is optional. This group is implemented
+ by those bridges that support the port-pair multiport model of the
+ source route bridging mode as defined in the IEEE 802.5M SRT Addendum
+ to 802.1d.
+
+
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 4]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+3.2. Relationship to Other MIBs
+
+ As described above, some IEEE 802.1d management objects have not been
+ included in this MIB because they overlap with objects in other MIBs
+ applicable to a bridge implementing this MIB. In particular, it is
+ assumed that a bridge implementing this MIB will also implement (at
+ least) the Bridge MIB and the 'system' group and the 'interfaces'
+ group defined in MIB-II [4].
+
+3.2.1. Relationship to the Bridge MIB
+
+ The Bridge MIB [6] must be implemented by all bridges, including
+ transparent, SR and SRT bridges. The SR bridge MIB is an extension
+ to the Bridge MIB.
+
+3.2.2. Relationship to the 'system' group
+
+ In MIB-II, the 'system' group is defined as being mandatory for all
+ systems such that each managed entity contains one instance of each
+ object in the 'system' group. Thus, those objects apply to the
+ entity as a whole irrespective of whether the entity's sole
+ functionality is bridging, or whether bridging is only a subset of
+ the entity's functionality.
+
+3.2.3. Relationship to the 'interfaces' group
+
+ In MIB-II, the 'interfaces' group is defined as being mandatory for
+ all systems and contains information on an entity's interfaces, where
+ each interface is thought of as being attached to a `subnetwork'.
+ (Note that this term is not to be confused with `subnet' which refers
+ to an addressing partitioning scheme used in the Internet suite of
+ protocols.) The term 'segment' is used in this memo to refer to such
+ a subnetwork.
+
+ Implicit in this MIB is the notion of ports on a bridge. Each of
+ these ports is associated with one interface of the 'interfaces'
+ group, and in most situations, each port is associated with a
+ different interface. However, there are situations in which multiple
+ ports are associated with the same interface. An example of such a
+ situation would be several ports, each corresponding one-to-one with
+ several X.25 virtual circuits, but all on the same interface.
+
+ Each port is uniquely identified by a port number. A port number has
+ no mandatory relationship to an interface number, but in the simple
+ case, a port number will have the same value as the corresponding
+ interface's interface number.
+
+
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 5]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ Some entities provide other services in addition to bridging with
+ respect to the data sent and received by their interfaces. In such
+ situations, only a subset of the data sent/received on an interface
+ is within the domain of the entity's bridging functionality. This
+ subset is considered to be delineated according to a set of
+ protocols, with some protocols being bridged, and other protocols not
+ being bridged. For example, in an entity which exclusively performed
+ bridging, all protocols would be considered as being bridged, whereas
+ in an entity which performed IP routing on IP datagrams and only
+ bridged other protocols, only the non-IP data would be considered as
+ being bridged.
+
+ Thus, this MIB (and in particular, its counters) are applicable only
+ to that subset of the data on an entity's interfaces which is
+ sent/received for a protocol being bridged. All such data is
+ sent/received via the ports of the bridge.
+
+4. Changes from RFC 1286
+
+ In addition to being separated from the Bridge MIB into a separate
+ document, the following changes were implemented as a result of
+ feedback from IEEE 802.5M:
+
+ (1) Changed syntax of dot1dSrPortLargestFrame to INTEGER in
+ order to allow for having 64 possible values as described
+ in draft 7 of the SR Addendum. Listed all legal values
+ in description.
+
+ (2) Updated syntax of dot1dSrPort, used to index into
+ dot1dSrPortTable, to use the range (1..65535).
+
+ (3) Added a counter to dot1dSrPortTable to count occurrences
+ of duplicate LAN IDs or Tree errors.
+
+ (4) Added a counter to dot1dSrPortTable to count LAN ID
+ mismatches.
+
+ (5) Added text to dot1dSrPortSpecInFrames and
+ dot1dSrPortSpecOutFrames clarifying that they are also
+ referred to as Source Routed Frames.
+
+ (6) Added text to dot1dSrPortApeInFrames and
+ dot1dSrPortApeOutFrames clarifying that they are also
+ referred to as All Routes Explorer frames.
+
+ (7) Added a scalar variable to the dot1dSr group to indicate
+ whether the bridge uses 3 bit or 6 bit length negotiation
+ fields.
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 6]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ (8) Added dot1dPortPairGroup to allow representation of port
+ pairs as defined in the IEEE 802.5M SRT Addendum.
+
+5. Definitions
+
+ SOURCE-ROUTING-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ Counter, Gauge
+ FROM RFC1155-SMI
+ dot1dBridge, dot1dSr
+ FROM BRIDGE-MIB
+ OBJECT-TYPE
+ FROM RFC-1212;
+
+
+
+ -- groups in the SR MIB
+
+ -- dot1dSr is imported from the Bridge MIB
+
+ dot1dPortPair OBJECT IDENTIFIER ::= { dot1dBridge 10 }
+
+ -- the dot1dSr group
+
+ -- this group is implemented by those bridges that
+ -- support the source route bridging mode, including Source
+ -- Routing and SRT bridges.
+
+
+ dot1dSrPortTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1dSrPortEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "A table that contains information about every
+ port that is associated with this source route
+ bridge."
+ ::= { dot1dSr 1 }
+
+ dot1dSrPortEntry OBJECT-TYPE
+ SYNTAX Dot1dSrPortEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "A list of information for each port of a source
+ route bridge."
+ INDEX { dot1dSrPort }
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 7]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ ::= { dot1dSrPortTable 1 }
+
+ Dot1dSrPortEntry ::=
+ SEQUENCE {
+ dot1dSrPort
+ INTEGER,
+ dot1dSrPortHopCount
+ INTEGER,
+ dot1dSrPortLocalSegment
+ INTEGER,
+ dot1dSrPortBridgeNum
+ INTEGER,
+ dot1dSrPortTargetSegment
+ INTEGER,
+ dot1dSrPortLargestFrame
+ INTEGER,
+ dot1dSrPortSTESpanMode
+ INTEGER,
+ dot1dSrPortSpecInFrames
+ Counter,
+ dot1dSrPortSpecOutFrames
+ Counter,
+ dot1dSrPortApeInFrames
+ Counter,
+ dot1dSrPortApeOutFrames
+ Counter,
+ dot1dSrPortSteInFrames
+ Counter,
+ dot1dSrPortSteOutFrames
+ Counter,
+ dot1dSrPortSegmentMismatchDiscards
+ Counter,
+ dot1dSrPortDuplicateSegmentDiscards
+ Counter,
+ dot1dSrPortHopCountExceededDiscards
+ Counter,
+ dot1dSrPortDupLanIdOrTreeErrors
+ Counter,
+ dot1dSrPortLanIdMismatches
+ Counter
+ }
+
+ dot1dSrPort OBJECT-TYPE
+ SYNTAX INTEGER (1..65535)
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The port number of the port for which this entry
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 8]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ contains Source Route management information."
+ ::= { dot1dSrPortEntry 1 }
+
+ dot1dSrPortHopCount OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The maximum number of routing descriptors allowed
+ in an All Paths or Spanning Tree Explorer frames."
+ ::= { dot1dSrPortEntry 2 }
+
+ dot1dSrPortLocalSegment OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The segment number that uniquely identifies the
+ segment to which this port is connected. Current
+ source routing protocols limit this value to the
+ range: 0 through 4095. (The value 0 is used by
+ some management applications for special test
+ cases.) A value of 65535 signifies that no segment
+ number is assigned to this port."
+ ::= { dot1dSrPortEntry 3 }
+
+ dot1dSrPortBridgeNum OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "A bridge number uniquely identifies a bridge when
+ more than one bridge is used to span the same two
+ segments. Current source routing protocols limit
+ this value to the range: 0 through 15. A value of
+ 65535 signifies that no bridge number is assigned
+ to this bridge."
+ ::= { dot1dSrPortEntry 4 }
+
+ dot1dSrPortTargetSegment OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The segment number that corresponds to the target
+ segment this port is considered to be connected to
+ by the bridge. Current source routing protocols
+ limit this value to the range: 0 through 4095.
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 9]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ (The value 0 is used by some management
+ applications for special test cases.) A value of
+ 65535 signifies that no target segment is assigned
+ to this port."
+ ::= { dot1dSrPortEntry 5 }
+
+ -- It would be nice if we could use ifMtu as the size of the
+ -- largest frame, but we can't because ifMtu is defined to be
+ -- the size that the (inter-)network layer can use which can
+ -- differ from the MAC layer (especially if several layers of
+ -- encapsulation are used).
+
+ dot1dSrPortLargestFrame OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The maximum size of the INFO field (LLC and
+ above) that this port can send/receive. It does
+ not include any MAC level (framing) octets. The
+ value of this object is used by this bridge to
+ determine whether a modification of the
+ LargestFrame (LF, see [14]) field of the Routing
+ Control field of the Routing Information Field is
+ necessary.
+
+ 64 valid values are defined by the IEEE 802.5M SRT
+ Addendum: 516, 635, 754, 873, 993, 1112, 1231,
+ 1350, 1470, 1542, 1615, 1688, 1761, 1833, 1906,
+ 1979, 2052, 2345, 2638, 2932, 3225, 3518, 3812,
+ 4105, 4399, 4865, 5331, 5798, 6264, 6730, 7197,
+ 7663, 8130, 8539, 8949, 9358, 9768, 10178, 10587,
+ 10997, 11407, 12199, 12992, 13785, 14578, 15370,
+ 16163, 16956, 17749, 20730, 23711, 26693, 29674,
+ 32655, 35637, 38618, 41600, 44591, 47583, 50575,
+ 53567, 56559, 59551, and 65535.
+
+ An illegal value will not be accepted by the
+ bridge."
+ ::= { dot1dSrPortEntry 6 }
+
+ dot1dSrPortSTESpanMode OBJECT-TYPE
+ SYNTAX INTEGER {
+ auto-span(1),
+ disabled(2),
+ forced(3)
+ }
+ ACCESS read-write
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 10]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ STATUS mandatory
+ DESCRIPTION
+ "Determines how this port behaves when presented
+ with a Spanning Tree Explorer frame. The value
+ 'disabled(2)' indicates that the port will not
+ accept or send Spanning Tree Explorer packets; any
+ STE packets received will be silently discarded.
+ The value 'forced(3)' indicates the port will
+ always accept and propagate Spanning Tree Explorer
+ frames. This allows a manually configured
+ Spanning Tree for this class of packet to be
+ configured. Note that unlike transparent
+ bridging, this is not catastrophic to the network
+ if there are loops. The value 'auto-span(1)' can
+ only be returned by a bridge that both implements
+ the Spanning Tree Protocol and has use of the
+ protocol enabled on this port. The behavior of the
+ port for Spanning Tree Explorer frames is
+ determined by the state of dot1dStpPortState. If
+ the port is in the 'forwarding' state, the frame
+ will be accepted or propagated. Otherwise, it
+ will be silently discarded."
+ ::= { dot1dSrPortEntry 7 }
+
+ dot1dSrPortSpecInFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of Specifically Routed frames, also
+ referred to as Source Routed Frames, that have
+ been received from this port's segment."
+ ::= { dot1dSrPortEntry 8 }
+
+ dot1dSrPortSpecOutFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of Specifically Routed frames, also
+ referred to as Source Routed Frames, that this
+ port has transmitted on its segment."
+ ::= { dot1dSrPortEntry 9 }
+
+ dot1dSrPortApeInFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 11]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ DESCRIPTION
+ "The number of All Paths Explorer frames, also
+ referred to as All Routes Explorer frames, that
+ have been received by this port from its segment."
+ ::= { dot1dSrPortEntry 10 }
+
+ dot1dSrPortApeOutFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of all Paths Explorer Frames, also
+ referred to as All Routes Explorer frames, that
+ have been transmitted by this port on its
+ segment."
+ ::= { dot1dSrPortEntry 11 }
+
+ dot1dSrPortSteInFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of spanning tree explorer frames that
+ have been received by this port from its segment."
+ ::= { dot1dSrPortEntry 12 }
+
+ dot1dSrPortSteOutFrames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of spanning tree explorer frames that
+ have been transmitted by this port on its
+ segment."
+ ::= { dot1dSrPortEntry 13 }
+
+ dot1dSrPortSegmentMismatchDiscards OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of explorer frames that have been
+ discarded by this port because the routing
+ descriptor field contained an invalid adjacent
+ segment value."
+ ::= { dot1dSrPortEntry 14 }
+
+ dot1dSrPortDuplicateSegmentDiscards OBJECT-TYPE
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 12]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of frames that have been discarded by
+ this port because the routing descriptor field
+ contained a duplicate segment identifier."
+ ::= { dot1dSrPortEntry 15 }
+
+ dot1dSrPortHopCountExceededDiscards OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of explorer frames that have been
+ discarded by this port because the Routing
+ Information Field has exceeded the maximum route
+ descriptor length."
+ ::= { dot1dSrPortEntry 16 }
+
+ dot1dSrPortDupLanIdOrTreeErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of duplicate LAN IDs or Tree errors.
+ This helps in detection of problems in networks
+ containing older IBM Source Routing Bridges."
+ ::= { dot1dSrPortEntry 17 }
+
+ dot1dSrPortLanIdMismatches OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The number of ARE and STE frames that were
+ discarded because the last LAN ID in the routing
+ information field did not equal the LAN-in ID.
+ This error can occur in implementations which do
+ only a LAN-in ID and Bridge Number check instead
+ of a LAN-in ID, Bridge Number, and LAN-out ID
+ check before they forward broadcast frames."
+ ::= { dot1dSrPortEntry 18 }
+
+
+ -- scalar object in dot1dSr
+
+ dot1dSrBridgeLfMode OBJECT-TYPE
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 13]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ SYNTAX INTEGER {
+ mode3(1),
+ mode6(2)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "Indicates whether the bridge operates using older
+ 3 bit length negotiation fields or the newer 6 bit
+ length field in its RIF."
+ ::= { dot1dSr 2 }
+
+
+ -- The Port-Pair Database
+
+ -- Implementation of this group is optional.
+
+ -- This group is implemented by those bridges that support
+ -- the direct multiport model of the source route bridging
+ -- mode as defined in the IEEE 802.5 SRT Addendum to
+ -- 802.1d.
+
+ -- Bridges implementing this group may report 65535 for
+ -- dot1dSrPortBridgeNumber and dot1dSrPortTargetSegment,
+ -- indicating that those objects are not applicable.
+
+ dot1dPortPairTableSize OBJECT-TYPE
+ SYNTAX Gauge
+ ACCESS read-only
+ STATUS mandatory
+ DESCRIPTION
+ "The total number of entries in the Bridge Port
+ Pair Database."
+ ::= { dot1dPortPair 1 }
+
+
+ -- the Bridge Port-Pair table
+
+ -- this table represents port pairs within a bridge forming
+ -- a unique bridge path, as defined in the IEEE 802.5M SRT
+ -- Addendum.
+
+ dot1dPortPairTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1dPortPairEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "A table that contains information about every
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 14]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ port pair database entity associated with this
+ source routing bridge."
+ ::= { dot1dPortPair 2 }
+
+ dot1dPortPairEntry OBJECT-TYPE
+ SYNTAX Dot1dPortPairEntry
+ ACCESS not-accessible
+ STATUS mandatory
+ DESCRIPTION
+ "A list of information for each port pair entity
+ of a bridge."
+ INDEX { dot1dPortPairLowPort, dot1dPortPairHighPort }
+ ::= { dot1dPortPairTable 1 }
+
+ Dot1dPortPairEntry ::=
+ SEQUENCE {
+ dot1dPortPairLowPort
+ INTEGER,
+ dot1dPortPairHighPort
+ INTEGER,
+ dot1dPortPairBridgeNum
+ INTEGER,
+ dot1dPortPairBridgeState
+ INTEGER
+ }
+
+ dot1dPortPairLowPort OBJECT-TYPE
+ SYNTAX INTEGER (1..65535)
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The port number of the lower numbered port for
+ which this entry contains port pair database
+ information."
+ ::= { dot1dPortPairEntry 1 }
+
+ dot1dPortPairHighPort OBJECT-TYPE
+ SYNTAX INTEGER (1..65535)
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The port number of the higher numbered port for
+ which this entry contains port pair database
+ information."
+ ::= { dot1dPortPairEntry 2 }
+
+ dot1dPortPairBridgeNum OBJECT-TYPE
+ SYNTAX INTEGER
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 15]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "A bridge number that uniquely identifies the path
+ provided by this source routing bridge between the
+ segments connected to dot1dPortPairLowPort and
+ dot1dPortPairHighPort. The purpose of bridge
+ number is to disambiguate between multiple paths
+ connecting the same two LANs."
+ ::= { dot1dPortPairEntry 3 }
+
+ dot1dPortPairBridgeState OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2),
+ invalid(3)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ DESCRIPTION
+ "The state of dot1dPortPairBridgeNum. Writing
+ 'invalid(3)' to this object removes the
+ corresponding entry."
+ ::= { dot1dPortPairEntry 4 }
+
+
+
+
+ END
+
+6. Acknowledgments
+
+ This document was produced on behalf of the Bridge MIB Working Group
+ in the NM area of the Internet Engineering Task Force.
+
+ The authors wish to thank the members of the Bridge MIB Working Group
+ for their many comments and suggestions which improved this effort.
+
+7. References
+
+ [1] Cerf, V., "IAB Recommendations for the Development of Internet
+ Network Management Standards", RFC 1052, NRI, April 1988.
+
+ [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
+ Group", RFC 1109, NRI, August 1989.
+
+ [3] Rose M., and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based internets", STD 16, RFC
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 16]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+ 1155, Performance Systems International, Hughes LAN Systems, May
+ 1990.
+
+ [4] McCloghrie K., and M. Rose, Editors, "Management Information Base
+ for Network Management of TCP/IP-based internets", STD 17, RFC
+ 1213, Performance Systems International, March 1991.
+
+ [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+ Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+ Performance Systems International, Performance Systems
+ International, MIT Laboratory for Computer Science, May 1990.
+
+ [6] Decker, E., Langille, P., Rijsinghani, A., and McCloghrie, K.,
+ "Definitions of Managed Objects for Bridges", RFC 1493, cisco
+ Systems, Digital Equipment Corporation, Digital Equipment
+ Corporation, Hughes LAN Systems, July 1993.
+
+ [7] Information processing systems - Open Systems Interconnection -
+ Specification of Abstract Syntax Notation One (ASN.1),
+ International Organization for Standardization, International
+ Standard 8824, December 1987.
+
+ [8] Information processing systems - Open Systems Interconnection -
+ Specification of Basic Encoding Rules for Abstract Notation One
+ (ASN.1), International Organization for Standardization,
+ International Standard 8825, December 1987.
+
+ [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+ STD 16, RFC 1212, Performance Systems International, Hughes LAN
+ Systems, March 1991.
+
+ [10] Rose, M., Editor, "A Convention for Defining Traps for use with
+ the SNMP", RFC 1215, Performance Systems International, March
+ 1991.
+
+ [11] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project 802
+ Local and Metropolitan Area Networks, (March 8, 1991).
+
+ [12] I.B.M. Token Ring Architecture Reference.
+
+ [13] ISO DIS 10038 MAC Bridges.
+
+ [14] ANSI/IEEE P802.5M-Draft 7, "Source Routing Transparent Bridge
+ Operation", IEEE Project 802 (1991).
+
+ [15] ANSI/IEEE 802.1y, "Source Routing Tutorial for End System
+ Operation", (September, 1990).
+
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 17]
+
+RFC 1525 Source Routing Bridge MIB September 1993
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Authors' Addresses
+
+ Eric B. Decker
+ cisco Systems, Inc.
+ 1525 O'Brien Dr.
+ Menlo Park, CA 94025
+
+ Phone: (415) 326-1941
+ Email: cire@cisco.com
+
+
+ Keith McCloghrie
+ Hughes LAN Systems, Inc.
+ 1225 Charleston Road
+ Mountain View, CA 94043
+
+ Phone: (415) 966-7934
+ EMail: kzm@hls.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
+
+
+
+
+
+
+
+
+
+
+
+Decker, McCloghrie, Langille & Rijsinghani [Page 18]
+ \ No newline at end of file