Definitions of Managed Objects for Source Routing Bridges Mon June 21 14:45:25 EST 1993 Draft Expiration Date: December 1993 Eric B. Decker cisco Systems, Inc. cire@cisco.com Keith McCloghrie Hughes LAN Systems, Inc. kzm@hls.com Paul Langille & Anil Rijsinghani Digital Equipment Corporation anil@levers.enet.dec.com langille@edwin.enet.dec.com Status of this Memo This document is an Internet Draft. Internet Drafts are 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 valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Internet Draft Source Routing Bridge MIB June 1993 1. Introduction This memo defines an experimental 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 bridges. The MIB was originally published in RFC 1286 section 4.1.3 as "The dot1dSr Group." IEEE 802.5 revised its addendum to RFC 802.1(d) several times since the original MIB was published, and in the process also changed its MIB. For procedural reasons, the group was split apart from the main MIB, allowing the major portion of the Bridge MIB to advance in the standards process largely unchanged, while the Source Routing Group iterated at the Proposed Standard step. Implementors are advised to consider the two documents together. Decker/McCloghrie/Langille/Rijsinghani [Page 2] Internet Draft Source Routing Bridge MIB June 1993 2. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: o RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o 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. Decker/McCloghrie/Langille/Rijsinghani [Page 3] Internet Draft Source Routing Bridge MIB June 1993 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 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 [7]. To be consistent with IAB directives and good engineering practice, 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 IEEE 802.1d[11] and IEEE 802.5M [14] management object name is also included. Decker/McCloghrie/Langille/Rijsinghani [Page 4] Internet Draft Source Routing Bridge MIB June 1993 SR Bridge MIB Name IEEE Name dot1dSr PortTable Port HopCount SourceRoutingPort .PortHopCount LocalSegment .SegmentNumber BridgeNum .BridgeNumber TargetSegment 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 Decker/McCloghrie/Langille/Rijsinghani [Page 5] Internet Draft Source Routing Bridge MIB June 1993 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. 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 [6]. 3.2.1. Relationship to the Bridge MIB The Bridge MIB [7] 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. Decker/McCloghrie/Langille/Rijsinghani [Page 6] Internet Draft Source Routing Bridge MIB June 1993 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. Some entities perform other functionality as well as bridging through the sending and receiving of data on their interfaces. In such situations, only a subset of the data sent/received on an interface is within the domain of the entity's bridging functionality. This subset is considered to be delineated according to a set of protocols, with some protocols being bridged, and other protocols not being bridged. For example, in an entity which exclusively performed bridging, all protocols would be considered as being bridged, whereas in an entity which performed IP routing on IP datagrams and only bridged other protocols, only the non-IP data would be considered as being bridged. Thus, this 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. Decker/McCloghrie/Langille/Rijsinghani [Page 7] Internet Draft Source Routing Bridge MIB June 1993 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 occurences 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 ngotiation fields. (8) Added dot1dPortPairGroup to allow representation of port pairs as defined in the IEEE 802.5M SRT Addendum. Decker/McCloghrie/Langille/Rijsinghani [Page 8] Internet Draft Source Routing Bridge MIB June 1993 5. Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, Gauge FROM RFC1155-SMI dot1dBridge, dot1dSr FROM RFCBRIDGE-MIB -- to be replaced by DS -- ver. of Bridge MIB RFC OBJECT-TYPE FROM RFC-1212; -- groups in the SR MIB -- dot1dSr is imported from the Bridge MIB dot1dPortPair OBJECT IDENTIFIER ::= { dot1dBridge 10 } -- use 10, to be safe Decker/McCloghrie/Langille/Rijsinghani [Page 9] Internet Draft Source Routing Bridge MIB June 1993 -- 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 } ::= { dot1dSrPortTable 1 } Dot1dSrPortEntry ::= SEQUENCE { dot1dSrPort INTEGER, dot1dSrPortHopCount INTEGER, dot1dSrPortLocalSegment INTEGER, dot1dSrPortBridgeNum INTEGER, dot1dSrPortTargetSegment INTEGER, dot1dSrPortLargestFrame INTEGER, dot1dSrPortSTESpanMode INTEGER, dot1dSrPortSpecInFrames Counter, Decker/McCloghrie/Langille/Rijsinghani [Page 10] Internet Draft Source Routing Bridge MIB June 1993 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 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 Decker/McCloghrie/Langille/Rijsinghani [Page 11] Internet Draft Source Routing Bridge MIB June 1993 "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. (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 Decker/McCloghrie/Langille/Rijsinghani [Page 12] Internet Draft Source Routing Bridge MIB June 1993 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. Behavior of the port when an illegal value is written is implementation specific. It is recommended that a reasonable legal value be chosen." ::= { dot1dSrPortEntry 6 } dot1dSrPortSTESpanMode OBJECT-TYPE SYNTAX INTEGER { auto-span(1), disabled(2), forced(3) } ACCESS read-write 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 Decker/McCloghrie/Langille/Rijsinghani [Page 13] Internet Draft Source Routing Bridge MIB June 1993 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 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 } Decker/McCloghrie/Langille/Rijsinghani [Page 14] Internet Draft Source Routing Bridge MIB June 1993 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 SYNTAX Counter ACCESS read-only STATUS mandatory Decker/McCloghrie/Langille/Rijsinghani [Page 15] Internet Draft Source Routing Bridge MIB June 1993 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 } Decker/McCloghrie/Langille/Rijsinghani [Page 16] Internet Draft Source Routing Bridge MIB June 1993 -- scalar object in dot1dSr dot1dSrBridgeLfMode OBJECT-TYPE 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 } Decker/McCloghrie/Langille/Rijsinghani [Page 17] Internet Draft Source Routing Bridge MIB June 1993 -- 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 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." Decker/McCloghrie/Langille/Rijsinghani [Page 18] Internet Draft Source Routing Bridge MIB June 1993 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 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 Decker/McCloghrie/Langille/Rijsinghani [Page 19] Internet Draft Source Routing Bridge MIB June 1993 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 Decker/McCloghrie/Langille/Rijsinghani [Page 20] Internet Draft Source Routing Bridge MIB June 1993 6. Acknowledgments This document was produced on behalf of the Bridge Sub-Working Group of the SNMP Working Group of the Internet Engineering Task Force. 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, Frank Kastenholz of Clearpoint Research Corp, and Richard Sweatt of Synoptics who was also IEEE 802.5's designated liaison to this WG in drafting this SR MIB. Others members of the Bridge Working Group who contributed to this effort are: Bill Anderson, Mitre Karl Auerbach, Epilogue Fred Baker, ACC (chair) Terry Bradley, Wellfleet Ted Brunner, Bellcore Jeffrey Buffum, Apollo Chris ChioTasso, Fibronics Anthony Chung, HLS Chuck Davin, MIT-LCS Andy Davis, Spider Eric Decker, cisco Nadya El-Afandi, Network Systems Gary Ellis,HP/Apollo Richard Fox, SynOptics Stan Froyd, ACC Frank Kastenholz, Clearpoint Research Shirnshon Kaufman, Jim Kinder, Fibercom Cheryl Krupczak,NCR Paul Langille, Digital Peter Lin,Vitalink Keith McCloghrie, HLS Donna McMaster, SynOptics Dave Perkins, 3Com Jim Reinstedler, Ungermann Bass Anil Rijsinghani, Digital Mark Schaefer, David Systems Steve Sherry, Xyplex Bob Stewart, Xyplex Emil Sturniolo, Decker/McCloghrie/Langille/Rijsinghani [Page 21] Internet Draft Source Routing Bridge MIB June 1993 Richard Sweatt, SynOptics Kevin Synott, Retix Ian Thomas, Chipcom Maurice Turcott, Racal Fei Xu Decker/McCloghrie/Langille/Rijsinghani [Page 22] Internet Draft Source Routing Bridge MIB June 1993 7. References [1] V. Cerf, IAB Recommendations for the Development of Internet Network Management Standards. Internet Working 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 Review Group, Internet Working Group Request for Comments 1109. Network Information Center, SRI International, Menlo Park, California, (August, 1989). [3] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [4] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1156. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [6] K. McCloghrie and M.T. Rose (editors), Management Information Base for Network Management of TCP/IP-based internets: MIB-II, Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [7] E. Decker, P. Langille, A. Rijsinghani, and K. McCloghrie Definitions of Managed Objects for Bridges, Internet Draft work in progress, (May, 1993). [Update reference to DS ver of Bridge MIB --agr] [8] Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). Decker/McCloghrie/Langille/Rijsinghani [Page 23] Internet Draft Source Routing Bridge MIB June 1993 [9] 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). [10] M.T. Rose, K. McCloghrie (editors), Concise MIB Definitions, Internet Working Group Request for Comments 1212. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [11] M.T. Rose (editor), A Convention for Defining Traps for use with the SNMP, Internet Working Group Request for Comments 1215. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [12] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project 802 Local and Metropolitan Area Networks, (March 8, 1991). [13] I.B.M. Token Ring Architecture Reference [14] ISO DIS 10038 MAC Bridges [15] ANSI/IEEE P802.5M-Draft 7, Source Routing Transparent Bridge Operation, IEEE Project 802 (1991). [16] ANSI/IEEE 802.1y, Source Routing Tutorial for End System Operation, (September, 1990) Decker/McCloghrie/Langille/Rijsinghani [Page 24] Internet Draft Source Routing Bridge MIB June 1993 Table of Contents 1 Introduction .......................................... 2 2 The Network Management Framework ...................... 3 2.1 Object Definitions .................................. 3 3 Overview .............................................. 4 3.1 Structure of MIB .................................... 4 3.1.1 The dot1dSr Group ................................. 6 3.1.2 The dot1dPortPair Group ........................... 6 3.2 Relationship to Other MIBs .......................... 6 3.2.1 Relationship to the Bridge MIB .................... 6 3.2.2 Relationship to the 'system' group ................ 6 3.2.3 Relationship to the 'interfaces' group ............ 7 4 Changes from RFC 1286 ................................. 8 5 Definitions ........................................... 9 5.1 Groups in the SR MIB ................................ 9 5.2 The dot1dSr Group Definitions ....................... 10 5.3 The dot1dPortPair Group Definitions ................. 18 6 Acknowledgments ....................................... 21 7 References ............................................ 23 Decker/McCloghrie/Langille/Rijsinghani [Page 25]