Network Working Group E. Decker Request for Comments: 1493 cisco Systems, Inc. Obsoletes: 1286 P. Langille Digital Equipment Corporation A. Rijsinghani Digital Equipment Corporation K. McCloghrie Hughes LAN Systems, Inc. July 1993 Definitions of Managed Objects for Bridges Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. 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. Table of Contents 1. The Network Management Framework ...................... 2 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 3 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 Decker, Langille, Rijsinghani & McCloghrie [Page 1] RFC 1493 Bridge MIB July 1993 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 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD16/RFC 1155 which defines the SMI, the mechanisms used for 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. 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. STD15/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. Objects 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) [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. Decker, Langille, Rijsinghani & McCloghrie [Page 2] RFC 1493 Bridge MIB July 1993 2.1. Format of Definitions Section 5 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [9,10]. 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 draft IEEE 802.1d specification [11]. This memo defines those objects needed for the management of a bridging entity operating in the transparent mode, as well as some objects applicable to all types of bridges. 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] management object name is also included. Decker, Langille, Rijsinghani & McCloghrie [Page 3] RFC 1493 Bridge MIB July 1993 Bridge MIB Name IEEE 802.1d Name dot1dBridge dot1dBase BridgeAddress Bridge.BridgeAddress NumPorts Bridge.NumberOfPorts Type PortTable Port BridgePort.PortNumber IfIndex Circuit DelayExceededDiscards .DiscardTransitDelay MtuExceededDiscards .DiscardOnError dot1dStp ProtocolSpecification Priority SpanningTreeProtocol .BridgePriority TimeSinceTopologyChange .TimeSinceTopologyChange TopChanges .TopologyChangeCount DesignatedRoot .DesignatedRoot RootCost .RootCost RootPort .RootPort MaxAge .MaxAge HelloTime .HelloTime HoldTime .HoldTime ForwardDelay .ForwardDelay BridgeMaxAge .BridgeMaxAge BridgeHelloTime .BridgeHelloTime BridgeForwardDelay .BridgeForwardDelay PortTable Port SpanningTreeProtocolPort .PortNumber Priority .PortPriority State .SpanningTreeState Enable PathCost .PortPathCost DesignatedRoot .DesignatedRoot DesignatedCost .DesignatedCost DesignatedBridge .DesignatedBridge DesignatedPort .DesignatedPort ForwardTransitions dot1dTp LearnedEntryDiscards BridgeFilter.DatabaseSize .NumDynamic,NumStatic AgingTime BridgeFilter.AgingTime FdbTable Address Port Decker, Langille, Rijsinghani & McCloghrie [Page 4] RFC 1493 Bridge MIB July 1993 Status PortTable Port MaxInfo InFrames BridgePort.FramesReceived OutFrames .ForwardOutbound InDiscards .DiscardInbound dot1dStatic StaticTable Address ReceivePort AllowedToGoTo Status The following IEEE 802.1d management objects have not been included in the Bridge MIB for the indicated reasons. IEEE 802.1d Object Disposition Bridge.BridgeName Same as sysDescr (MIB II) Bridge.BridgeUpTime Same as sysUpTime (MIB II) Bridge.PortAddresses Same as ifPhysAddress (MIB II) BridgePort.PortName Same as ifDescr (MIB II) BridgePort.PortType Same as ifType (MIB II) BridgePort.RoutingType Derivable from the implemented groups SpanningTreeProtocol .BridgeIdentifier Combination of dot1dStpPriority and dot1dBaseBridgeAddress .TopologyChange Since this is transitory, it is not considered useful. SpanningTreeProtocolPort .Uptime Same as ifLastChange (MIB II) .PortIdentifier Combination of dot1dStpPort and dot1dStpPortPriority .TopologyChangeAcknowledged Since this is transitory, it is not considered useful. .DiscardLackOfBuffers Redundant Transmission Priority These objects are not required as per the Pics Proforma and not considered useful. .TransmissionPriorityName .OutboundUserPriority .OutboundAccessPriority Decker, Langille, Rijsinghani & McCloghrie [Page 5] RFC 1493 Bridge MIB July 1993 3.1.1. The dot1dBase Group This mandatory group contains the objects which are applicable to all types of bridges. 3.1.2. The dot1dStp Group This group contains the objects that denote the bridge's state with respect to the Spanning Tree Protocol. If a node does not implemented the Spanning Tree Protocol, this group will not be implemented. 3.1.3. 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. This group will be described in a separate document applicable only to source route bridging. 3.1.4. The dot1dTp Group This group contains objects that describe the entity's state with respect to transparent bridging. If transparent bridging is not supported this group will not be implemented. This group is applicable to transparent only and SRT bridges. 3.1.5. The dot1dStatic Group This group contains objects that describe the entity's state with respect to destination-address filtering. If destination-address filtering is not supported this group will not be implemented. This group is applicable to any type of bridge which performs destination-address filtering. 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 'system' group and the 'interfaces' group defined in MIB- II [6]. 3.2.1. 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 Decker, Langille, Rijsinghani & McCloghrie [Page 6] RFC 1493 Bridge MIB July 1993 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.2. 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, whether it be an Ethernet segment, a 'ring', a WAN link, or even an X.25 virtual circuit. Implicit in this Bridge MIB is the notion of ports on a bridge. Each of these ports is associated with one interface of the 'interfaces' 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. Port numbers are in the range (1..dot1dBaseNumPorts). 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