INTERNET DRAFT Sean Harnedy InfiniSwitch Corp. Expiration Date: December 2002 Bill Anderson June 2002 Definitions of Managed Objects for InfiniBand Interface Types Please send comments to ipoverib@ietf.org Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 draft documents 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 ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture to deliver scalable performance in data centers. This memo defines a portion of Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IBA defined InfiniBand interfaces. Expires December 2002 [Page 1] Internet Draft IPOVERIB IF MIB June 2002 Table of Contents 1.0 The SNMP Management Framework ............................. 2 1.1 Conventions used in this document ......................... 3 1.2 IANA Considerations ....................................... 3 2.0 Introduction to InfiniBand ................................ 3 2.1 Relation to MIB-2 ......................................... 5 2.2 Relation to the Interfaces MIB ............................ 5 2.2.1 Layering Model .......................................... 5 2.2.2 Virtual Circuits ........................................ 5 2.2.3 ifTestTable ............................................. 5 2.2.4 ifRcvAddressTable ....................................... 6 2.2.5 ifPhysAddress ........................................... 6 2.2.6 ifType .................................................. 6 2.2.7 Specific Interface MIB Objects .......................... 6 2.3 Structure of the MIB ...................................... 10 2.4 Mapping of IBA managed attribute fields ................... 10 2.4 Case Diagram .............................................. 13 3.0 InfiniBand Interface MIB Definitions ...................... 14 4.0 Revision History .......................................... 25 4.1 Changes from ........... 25 4.2 Changes from ........... 25 4.3 Changes from ........... 25 5.0 Security Considerations ................................... 25 6.0 Full Copyright Statement .................................. 26 7.0 Intellectual Property ..................................... 26 8.0 Authors' Addresses ........................................ 27 9.0 References ................................................ 27 1.0 The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. Expires December 2002 [Page 2] Internet Draft IPOVERIB IF MIB June 2002 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 1.2 IANA Considerations This memo does NOT define any new name spaces which must be maintained by IANA. This memo DOES consume an IfType assignment that has been made by IANA infiniband(ianaIfType 199) -- Assigned by IANA as well as an experimental MIB registration space. infinibandMIB ::= { experimental 117 } -- Assigned by IANA The infinibandMIB name space will be locally administered by the IPOIB Working group as new MIBS are created by the group. 2.0 Introduction to InfiniBand This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing InfiniBand interfaces. Expires December 2002 [Page 3] Internet Draft IPOVERIB IF MIB June 2002 The managed objects provide extensions to the objects defined in the interface group mib [RFC2863]. This memo provides managed objects based on Sections 14 - 16 of the InfiniBand Architecture specification [Infini v1.0a] The intent of this memo is to define value added manageability of IBA devices by defining SNMP managed objects and at the same time avoid making SNMP management a requirement for device operation. IBA, unlike most physical layer network protocols, specifies a non-SNMP external management protocol which controls a wide range of functions necessary for IBA devices to operate. The functions performed by the InfiniBand managers and agents, including the IBA Subnet Manager(SM) and Subnet Management Agents (SMA) in the managed devices include, but are not limited to device configuration, fault detection, performance monitoring, and device configuration persistence. Even given this native management capability SNMP manageability of any networking components in today's networks is highly desirable or even a requirement especially in the area of fault and performance management. Obviously having two management paradigms simultaneously controlling a device or portions there of would require a high degree of cooperation between paradigms to avoid conflicts. Therefore, to give maximum visibility but avoid these conflicts the managed objects defined in this memo offer read-only access to the attributes define by InfiniBand native management wherever a conflicts with IBA defined management exists. The counters defined in this memo are based on IBA defined counters. But in order to support the semantic behavior defined by SNMP SMI [RFC2578] conversions are required in several aspects of numerous InfiniBand specified counters. These changes deal primarily with counter width differences, latch-on-wrap (aka saturate at all 1's), clear-on-read (reset to zero) and writeability of the InfiniBand Architecture native counters as defined in [Infini v1.0a]. Mechanisms for doing the required conversion are not defined by this memo. Instances of the managed object types defined herein represent attributes of a port on an InfiniBand communications medium device (IBA specification prefers the term port to interface). IBA defined ports can be paralleled/striped over multiple physical links called "physical lanes" . Aggregations of 1x, 4x, and 12x physical lanes are defined by the IBA. The IBA treats these aggregations as one port. The objects defined herein do the same. Thus no exposure to per physical lane info is defined. At present, Inifinband media are identified by the following values of the ifType object in the Interfaces Group MIB [RFC2863]: infiniband(ianaIfType 199) -- Assigned by IANA Expires December 2002 [Page 4] Internet Draft IPOVERIB IF MIB June 2002 2.1 Relation to MIB-2 This section applies only when this MIB is used in conjunction with the "old" (RFC 1213) interface group. The relationship between an InfiniBand interface and an interface in the context of MIB-2 is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. For agents which implement the (now deprecated) ifSpecific object, an instance of that object that is associated with an InfiniBand interface has the OBJECT IDENTIFIER value: infiniband OBJECT IDENTIFER ::= { transmission ianaIfType-TBD } --To be assigned by IANA 2.2 Relation to the Interfaces MIB The Interface MIB [RFC2863] requires that any MIB which is an adjunct of the Interface MIB clarify specific areas within the Interface MIB. These areas were intentionally left vague in the Interface MIB to avoid over constraining the MIB, thereby precluding management of certain media-types. Section 4.0 of [RFC2863] enumerates several areas which a media-specific MIB must clarify. Each of these areas is addressed in a following subsection. The implementor is referred to [RFC2863] in order to understand the general intent of these areas. 2.2.1. Layering Model This MIB does not provide for layering. There are no sublayers defined by this memo. Higher Layer protocol stacking on the interfaces is not defined by this memo. 2.2.2. Virtual Circuits This medium does not support virtual circuits and this area is not applicable to this MIB. 2.2.3. ifTestTable This MIB defines no tests for media which are instrumented with this MIB. Expires December 2002 [Page 5] Internet Draft IPOVERIB IF MIB June 2002 2.2.4. ifRcvAddressTable For IBA Routers and Channel Adapters (CAs): Routers and CAs which have been programmed by IBA Subnet Manager to have more than one address use this table to display the set of additional address beyond the "base" Local Identifier (LID) for which the interface will receive packets. If desired to avoid conflicts with the IBA Subnet Manager configuration of this table, this table may be implemented as read-only. See 2.2.5 for encoding of the Physical Address. For IBA Switches: Additionally for switches since the ifRcvAddressTable table is explicitly not intended to provide a bridge address filtering mechanism there is no need to expose the multicast and unicast forwarding table address here. 2.2.5. ifPhysAddress This object contains the 16 bit "base" Local Identifier (LID) currently in effect, on this port. Whether the address was assigned by the IBA Subnet Manager or through some other mechanism does not matter. In the Event that no LID is currently in affect an Octet String of zero length is returned. For switches the "base" LID of the (conceptual) management port (port 0) shall be used. The address is stored in binary in this object. The address is stored in IBA defined bit order, that is, the High Order Bit of the Local Identifier byte 0 is positioned as the high-order bit of the first byte of ifPhysAddress. 2.2.6. ifType This MIB applies to interfaces which have any of the following ifType values: infiniband(ianaIfType 199) -- Assigned by IANA Information regarding the number of physical lanes that comprise the port may be included in the ifDescr object. (i.e. 1x, 4x, or 12x) 2.2.7. Specific Interface MIB Objects The following table provides specific implementation guidelines for applying the interface group objects to InfiniBand media. Object Guidelines ifIndex Each InfiniBand interface is represented by an ifEntry. ifDescr Refer to [RFC2863]. ifType Refer to section 2.2.6. Expires December 2002 [Page 6] Internet Draft IPOVERIB IF MIB June 2002 ifMtu The size of the largest packet that is capable of being either sent/received over this interface specified in octets. Actual MTU in use is determined by examining device MTU capability or NeighborMTU value (if valid) in the portInfo table. ifSpeed The current effective operational speed of the interface in bits per second. The speed reported compensates for the 8B10B encoding used on the links. For current infiniband interfaces, this will be equal to 2,000,000,000 (2 billion), 8,000,000,000 (8 billion), or 24,000,000,000 (24 billion) for the 1x, 4x, and 12x ports respectively. Since both the 4x and 12x value are greater than the maximum reportable by this object then this object should report its maximum value (4,294,967,295) and ifHighSpeed must be used to report the interface's speed. Actual Speed in use is determined by examining device linkWidthSuported or linkWidthActive value (if valid) in the portInfo table. ifPhysAddress Refer to section 2.2.5. ifAdminStatus Default value is "up". If write access is implemented the default value for this attribute should be "up" to avoid requiring the use of a SNMP manager to enable the interface. Support for "testing" is not required. Providing read-write access to this object can potentially cause conflicts with the IBA Subnet Manager which also controls Port State. ifOperStatus The operational state of the interface. Support for "testing" is not required. ifLastChange Refer to [RFC2863]. Expires December 2002 [Page 7] Internet Draft IPOVERIB IF MIB June 2002 ifInOctets The number of octets in valid packets received on this interface, including the START and END delimiters and the VCRC. This count should also include the number of octets in valid Link packets received on this interface. ifInUcastPkts Refer to [RFC2863]. Note that this does not include Link packets, since link Control packets are consumed by the interface layer and are not passed to any higher layer protocol. ifInDiscards Refer to [RFC2863]. ifInErrors Total number of packets received that were discarded. ifInUnknownProtos Always zero. Refer to [RFC2863]. ifOutOctets The number of octets transmitted in valid packets on this interface, including the START and END delimiters and the VCRC. This count should also include the number of octets in valid Link packets sent on this interface. ifOutUcastPkts Refer to [RFC2863]. Note that this does not include link packets, since link packets are generated by the interface layer, and are not passed down from any higher layer protocol. ifOutDiscards Refer to [RFC2863]. ifOutErrors Refer to [RFC2863]. ifName Locally-significant textual name for the interface (e.g. lan0). ifInMulticastPkts Refer to [RFC2863]. Note that this does not include Link packets, since link Control packets are consumed by the interface layer and are not passed to any higher layer protocol. Always 0 unless proprietary counters implemented. Expires December 2002 [Page 8] Internet Draft IPOVERIB IF MIB June 2002 ifOutMulticastPkts Refer to [RFC2863]. Note that this does not include Link packets, since Link packets are created by the interface layer and are not passed in by any higher layer protocol. Always 0 unless proprietary counters implemented. ifInBroadcastPkts Always zero. Refer to [RFC2863]. ifOutBroadcastPkts ifHCInBroadcastPkts Always zero. ifHCOutBroadcastPkts Always zero. ifHCInOctets 64-bit versions of counters. Required ifHCOutOctets for interfaces that are capable of operating at 20Mbit/sec or faster, even if the interface is currently operating at less than 20Mbit/sec. ifHCInUcastPkts 64-bit versions of packet counters. ifHCInMulticastPkts Required for interfaces ifHCOutUcastPkts that are capable of operating at ifHCOutMulticastPkts 640Mbit/sec or faster, even if the interface is currently operating at less than 640Mbit/sec. Always 0 unless proprietary counters implemented. ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is "enabled". ifHighSpeed The current effective operational speed of the interface in millions of bits per second. For current InfiniBand interfaces, this will be equal to 2,000, 8,000, or 24,000. ifPromiscuousMode Usually "false" but one could create a promiscuous device conceivably. Refer to [RFC2863]. ifConnectorPresent This will be "true". ifAlias Refer to [RFC2863]. ifCounterDiscontinuityTime Refer to [RFC2863]. Note that a discontinuity in the Interface MIB counters may also indicate a discontinuity in some or all of the counters in this MIB that are associated with that interface. Expires December 2002 [Page 9] Internet Draft IPOVERIB IF MIB June 2002 ifStackHigherLayer Refer to section 2.2.1. ifStackLowerLayer ifStackStatus ifRcvAddressAddress Refer to section 2.2.4. ifRcvAddressStatus ifRcvAddressType 2.3 Structure of the MIB This MIB is structured as three groups: o Detail error statistics on a per interface basis (ibIfPortStats). This table provides visibility into error counters defined by the IBA. o Detail traffic statistics on a per interface and virtual lane pair basis (ibIfVLTraffic). This table provides visibility into data flow counters kept on a per VL basis defined by the IBA. o Information that associates the IP over IB link layer addresses with Infiniband interfaces (ports). 2.4 Mapping of IBA managed attribute fields This section lists the correlation and conversion between the SNMP managed objects defined by this memo and the IBA defined attributes they are based on. Note that the relationship expressed below does not address issues relating to counter widths, latching and reset ability differences between the SNMP SMI and IBA object definitions. Note, that since multicast counters have not been defined by the IBA specification, IF-MIB multicast counters should be set to 0 (in the absence of any proprietary IBA multicast counters). Also, based on the IBA counter definitions, multicast (packets and bytes) will be part of the IF-MIB unicast counters. The following table is organized by the IBA Attributes that fields belong in. In the case where fields from multiple attributes are required the supplemental attributes are then fully qualified in the formula below. A second section covering Port Sample counters is also included. Some Abbreviations used: POH = packet overhead = 4 = 1 START + 1 END + 2 VCRC Octets; SLP = size link flowcntl packet = 8 = 1 START + 1 END + 6 Flow cntrl Octets; MHB = max header bytes = 126 Octets; includes all packet fields except framing characters --see [Infini v1.0a] sec 7.7.8 Expires December 2002 [Page 10] Internet Draft IPOVERIB IF MIB June 2002 _____________________________________________________________________ IBA Attribute and Field Corresponding SNMP Object _____________________________________________________________________ ------------ PortCounters see [Infini v1.0a] table:189 ------------ (.PortRcvData * 4) + (.PortRcvPkts * POH) + (PortFlowCtlCounters. PortRcvFlowPkts * SLP ) = IF-MIB:ifInOctets .PortRcvConstraintErrors + .VL15Dropped = IF-MIB:ifInDiscards .PortRcvRemotePhysicalErrors + PortCounters.PortRcvErrors = IF-MIB:ifInErrors .PortRcvPkts = IF-MIB:ifInUcastPkts .PortXmitData * 4 + (PortFlowCtlCounters.PortXmitFlowPkts * SLP) + (.PortXmitPkts * POH) = IF-MIB:ifOutOctets .PortXmitDiscards + .PortXmitConstraintErrors = IF-MIB:ifOutDiscards .PortXmitPkts + .PortXmitDiscards + .PortXmitConstraintErrors = IF-MIB:ifOutUcastPkts .SymbolErrorCounter = ibIfPortSymbolErrs .LinkErrorRecoveryCounter = ibIfPortLinkErrRecovery .PortRcvRemotePhysicalErrors = ibIfPortStatRcvRemPhyErrs .LinkDownedCounter = ibIfPortLinkDowned .LocalLinkIntegrityErrors = ibIfPortStatLinkIntegrityErrs .ExcessiveBufferOverrunErrors = ibIfPortStatExcBufOverrunErrs .VL15Dropped = ibIfPortStatVL15Dropped ----------------- PortRcvErrDetails see [Infini v1.0a] table:192 ----------------- .PortLocalPhysicalErrors = ibIfPortStatLocalPhyErrs .PortMalformedPacketErrors = ibIfPortStatMalPktErrs Expires December 2002 [Page 11] Internet Draft IPOVERIB IF MIB June 2002 ---------------------- PortXmitDiscardDetails see [Infini v1.0a] table:193 ---------------------- .PortInactiveDiscards = ibIfPortStatInactDiscards .PortNeighborMTUDiscards = ibIfPortStatNeighMTUDiscards .PortSwLifetimeLimitDiscards = ibIfPortStatSwLifetimeDiscards .PortSwHOQLimitDiscards = ibIfPortStatHOQLifetimeDiscards -------- PortInfo see [Infini v1.0a] table:127 -------- .NeighborMTU = IF-MIB:ifMtu .linkWidthActive = IF-MIB:ifSpeed _____________________________________________________________________ IBA Port Sample Counter Corresponding SNMP Object _____________________________________________________________________ -------------------- Sample Select Values see [Infini v1.0a] table:187 -------------------- PortRcvDataVL * 4 + ( PortXmitPktsVL * POH) = ibIfVLInOctets PortRcvPktsVL = ibIfVLInPkts PortXmitDataVL * 4 + ( PortXmitPktsVL * POH) = ibIfVLOutOctets PortXmitPktsVL = ibIfVLOutPkts Note that PortCounters.PortRcvSwitchRelayErrors is not counted in either IF-MIB:ifInDiscards or IF-MIB:ifOutDiscards. These discards counters will someday probably go into a separate Switch MIB. Expires December 2002 [Page 12] Internet Draft IPOVERIB IF MIB June 2002 2.5 Case Diagram The following "Case Diagram" visually depicts the mapping described in section 2.4. Again it should be noted that since no Multicast counters are defined by the IBA specification they are not covered here. ^ v | | Layer 3 ====|=========================================|======================== | .................... | Layer 2 |----------->. forwarding engine.-------->| | . . | | . (Switches Only) . | | .................... | | | | | V | | PC.PortRcvSwitchRelayErrors | | | --- IfInUcast = PC.PortRcvPkts --- IfOutUCasts = | | PC.PortXmitPkts + | | PC.PortXmitDiscards + | | PC.PortXmitConstraint- | | Errors | | |--> IfInDiscards = |--> IfOutDiscards = | PC.PortRcvConstraintErrs + | PC.PortXmitDiscards + | PC.VL15Dropped | PC.PortXmitConstraint- | | Errors --- IfInOctets = | | PC.PortRcvData * 4 + | | PC.PortRcvPkts * POH + |--> IfOutErrors = 0 | PFCC.PortRcvFloPkts * SLP | | | |--> IfInUnknownProtos = 0 |--> IfOutOctets = | | (PC.PortXmitData * 4)+ |--> IfInErrors = | (PFCC.PortXmitFlowPkts | PC.PortRcvRemotePhysicalErrors + | * SLP) + | PC.PortRcvErrors | (PC.PortXmitPkts * POH) | | ====|=========================================|======================== ^ | Layer 1 V Abbreviations: PRED = PortRcvErrorDetails Table PC = Port Counters Table PFCC = PortFlowCtlCounters Table POH = Packet Overhead = 4bytes SLP = Size Link FlowCtl Packt = 8 MB = MaxHeader bytes = 126 PC.PortXmitDiscards = PortInactiveDiscards + PortNeighborMTUDiscards + PortSwLifeTimeLimitDiscard + PortSwHOQLifetimeLimitDiscards Expires December 2002 [Page 13] Internet Draft IPOVERIB IF MIB June 2002 PC.PortRcvErrors = PRED.PortLocalPhysicalErrors + PRED.PortMalformedPacketErrors + PRED.PortBufferOverrunErrors PC.PortRcvSwitchRelayErrors = PRED.PortDLIDMapErrs + PRED.PortVLMapErrs + PRED.PortLoopingErr 3.0 InfiniBand Interface MIB Definitions IB-IF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64 FROM SNMPv2-SMI InterfaceIndex FROM IF-MIB IbVirtualLane, infinibandMIB, IbIpoibClientIdentifier FROM IB-TC-MIB; ibIfMIB MODULE-IDENTITY LAST-UPDATED "200206231200Z" -- 23 June 2002 12:00:00 ORGANIZATION "IETF IP over IB Working Group Email: ipoverib@ietf.org" CONTACT-INFO "Sean Harnedy (sharnedy@infiniswitch.com) InfiniSwitch Corporation" DESCRIPTION "This MIB contains managed object definitions for managing InfiniBand interfaces." REVISION "200206231200Z" -- 23 June 2002 12:00:00 EST DESCRIPTION "Corrected syntax bug in IPOIB Link Layer Address Entry." REVISION "200205101200Z" -- 10 May 2002 12:00:00 EST DESCRIPTION "Added IPOIB Link Layer Address Table." REVISION "200111131200Z" -- 13 November 2001 12:00:00 EST DESCRIPTION "Added IANA SMI and ifType values; moved TCs to separate ID." REVISION "200110031200Z" -- 3 October 2001 12:00:00 EST DESCRIPTION "First Working Group Draft." REVISION "200107121200Z" -- 12 July 2001 12:00:00 DESCRIPTION "Initial draft version." ::= { infinibandMIB 2 } Expires December 2002 [Page 14] Internet Draft IPOVERIB IF MIB June 2002 -- -- Object Identifier Assignments -- ibIfObjects OBJECT IDENTIFIER ::= { ibIfMIB 1 } ibIfNotifications OBJECT IDENTIFIER ::= { ibIfMIB 2 } --**************************************************************** -- IPoIB Detailed per interface/port statistics -- ibIfPortStat --**************************************************************** ibIfPortStatTable OBJECT-TYPE SYNTAX SEQUENCE OF IbIfPortStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides detail statistics for all InfiniBand interfaces attached to a particular system. There will be one row in this table for each InfiniBand interface in the system." ::= { ibIfObjects 1 } ibIfPortStatEntry OBJECT-TYPE SYNTAX IbIfPortStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for a particular interface to an InfiniBand medium." INDEX { ibIfPortStatIfIndex } ::= { ibIfPortStatTable 1 } IbIfPortStatEntry ::= SEQUENCE { ibIfPortStatIfIndex InterfaceIndex, ibIfPortSymbolErrs Counter32, ibIfPortLinkErrRecovery Counter32, ibIfPortLinkDowned Counter32, ibIfPortStatLocalPhyErrs Counter32, ibIfPortStatMalPktErrs Counter32, ibIfPortStatRcvRemPhyErrs Counter32, ibIfPortStatRcvConstrErrs Counter32, ibIfPortStatInactDiscards Counter32, ibIfPortStatNeighMTUDiscards Counter32, ibIfPortStatSwLifetimeDiscards Counter32, ibIfPortStatHOQLifetimeDiscards Counter32, ibIfPortStatLinkIntergrityErrs Counter32, ibIfPortStatExcBufOverrunErrs Counter32, ibIfPortStatVL15Dropped Counter32 } Expires December 2002 [Page 15] Internet Draft IPOVERIB IF MIB June 2002 ibIfPortStatIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the InfiniBand interface to which these port statistics apply." ::= { ibIfPortStatEntry 1 } ibIfPortSymbolErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of symbol errors detected on one or more virtual lanes." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::SymbolErrorCounter." ::= { ibIfPortStatEntry 2 } ibIfPortLinkErrRecovery OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of times the Port Training state machine has successfully completed the link error recovery process." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::LinkErrorRecoveryCounter." ::= { ibIfPortStatEntry 3 } ibIfPortLinkDowned OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of times the Port Training state machine has failed the link error recovery process and downed the link." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::LinkDownedCounter." ::= { ibIfPortStatEntry 4 } Expires December 2002 [Page 16] Internet Draft IPOVERIB IF MIB June 2002 ibIfPortStatLocalPhyErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of packets received on the port that contain local physical errors (ICRC, VCRC, FCCRC, and all physical errors that cause entry into the BAD PACKET or BAD PACKET DISCARD states of the packet receiver state machine)." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::PortRcvErrors." ::= { ibIfPortStatEntry 5 } ibIfPortStatMalPktErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of packets received on the port that contain malformed packet errors - data packets: LVer, length, VL - link packets: operand, length, VL" REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::PortRcvErrors." ::= { ibIfPortStatEntry 6 } ibIfPortStatRcvRemPhyErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of packets marked with the EBP delimiter received on the port." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::PortRcvRemotePhysicalErrors." ::= { ibIfPortStatEntry 7 } Expires December 2002 [Page 17] Internet Draft IPOVERIB IF MIB June 2002 ibIfPortStatRcvConstrErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of packets received on the port that are discarded for the following reasons: - FilterRawInbound is true and packet is raw - PartitionEnforcementInbound is true and packet fails partition key check, IP version check, or transport header version check." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::PortRcvConstraintErrors." ::= { ibIfPortStatEntry 8 } ibIfPortStatInactDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of outbound packets discarded by the port because it is in the inactive state." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.4.2; Table 192 PortXmitDiscardDetails::PortInactiveDiscards." ::= { ibIfPortStatEntry 9 } ibIfPortStatNeighMTUDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of outbound packets discarded by the port because packet length exceeded the neighbor MTU." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.4.2; Table 192 PortXmitDiscardDetails::PortNeighborMTUDiscards." ::= { ibIfPortStatEntry 10 } ibIfPortStatSwLifetimeDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of outbound packets discarded by the port because the switch lifetime limit was exceeded. Note, applies only to switches." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.4.2; Table 192 PortXmitDiscardDetails::PortSwLifetimeLimitDiscards." ::= { ibIfPortStatEntry 11 } Expires December 2002 [Page 18] Internet Draft IPOVERIB IF MIB June 2002 ibIfPortStatHOQLifetimeDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of outbound packets discarded by the port because the switch HOQ lifetime was exceeded. Note, applies only to switches." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.4.2; Table 192 PortXmitDiscardDetails::PortSwHOQLimitDiscards." ::= { ibIfPortStatEntry 12 } ibIfPortStatLinkIntergrityErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the frequency of packets containing local physical errors exceeded local_phy_errors." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::LocalLinkIntegrityErrors.; Also see Table 125 PortInfo." ::= { ibIfPortStatEntry 13 } ibIfPortStatExcBufOverrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that overrun_errors consecutive flow control update periods occurred with at least one overrun error in each period." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::ExcessiveBufferOverrunErrors.; Also see Table 125 PortInfo." ::= { ibIfPortStatEntry 14 } ibIfPortStatVL15Dropped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of incoming VL15 packets dropped due to resource limitations on port selected by the port selected (due to lack of buffers)." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.3.5; Table 188 PortCounters::VL15Dropped." ::= { ibIfPortStatEntry 15 } Expires December 2002 [Page 19] Internet Draft IPOVERIB IF MIB June 2002 --**************************************************************** -- IPoIB per port VL Traffic Objects -- ibIfVLTraffic --**************************************************************** ibIfVLTrafficTable OBJECT-TYPE SYNTAX SEQUENCE OF IbIfVLTrafficEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides traffic statistics for all virtual lanes which are configured on an InfiniBand interface. There will always be at least one virtual lane on in the range VL0-VL14 configured on an interfaces as well as the control channel VL15. Configuration of what VLs are available on a particular Interface is done by IBA native management." ::= { ibIfObjects 2 } ibIfVLTrafficEntry OBJECT-TYPE SYNTAX IbIfVLTrafficEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular virtual lane (VL)." INDEX { ibIfVlTrafficIfIndex, ibIfVlIndex } ::= { ibIfVLTrafficTable 1 } IbIfVLTrafficEntry ::= SEQUENCE { ibIfVlTrafficIfIndex InterfaceIndex, ibIfVlIndex IbVirtualLane, ibIfVLOutOctets Counter64, ibIfVLOutPkts Counter64, ibIfVLInOctets Counter64, ibIfVLInPkts Counter64 } ibIfVlTrafficIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the InfiniBand interface to which these virtual lane (VL) traffic statistics apply." ::= { ibIfVLTrafficEntry 1 } ibIfVlIndex OBJECT-TYPE SYNTAX IbVirtualLane MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies what Virtual Lane (VL) instance is being addressed." ::= { ibIfVLTrafficEntry 2 } Expires December 2002 [Page 20] Internet Draft IPOVERIB IF MIB June 2002 ibIfVLOutOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted in valid data packets on this interface, including the START and END delimiters and the VCRC." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1." ::= { ibIfVLTrafficEntry 3 } ibIfVLOutPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets successfully sent on this VL." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1." ::= { ibIfVLTrafficEntry 4 } ibIfVLInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in valid data packets received on this interface, including the START and END delimiters and the VCRC." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.4.5; Table 195 PortVLOpPackets." ::= { ibIfVLTrafficEntry 5 } ibIfVLInPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets successfully sent on this VL. Note that this does not include link packets, since link packets are generated by the interface layer, and are not passed from any higher layer protocol." REFERENCE "InfiniBand Architecture Release 1.0.a Vol 1. Section 16.1.4.5; Table 196 PortVLOpData." ::= { ibIfVLTrafficEntry 6 } Expires December 2002 [Page 21] Internet Draft IPOVERIB IF MIB June 2002 --**************************************************************** -- IPoIB Link Layer Address Table -- ibIpoibLinkLayerAddrTable --**************************************************************** ibIpoibLinkLayerAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IbIpoibLinkLayerAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about all IPOIB link layer addresses associated with this InfiniBand interface (port)." ::= { ibIfObjects 3 } ibIpoibLinkLayerAddrEntry OBJECT-TYPE SYNTAX IbIpoibLinkLayerAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about specific IPOIB link layer addresses associated with this InfiniBand interface (port)." INDEX { ibIpoibLinkLayerIfIndex, ibIpoibLinkLayerIndex } ::= { ibIpoibLinkLayerAddrTable 1 } IbIpoibLinkLayerAddrEntry ::= SEQUENCE { ibIpoibLinkLayerIfIndex InterfaceIndex, ibIpoibLinkLayerIndex INTEGER, ibIpoibLinkLayerAddr IbIpoibClientIdentifier } ibIpoibLinkLayerIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the IPOIB InfiniBand interface (port)." ::= { ibIpoibLinkLayerAddrEntry 1 } ibIpoibLinkLayerIndex OBJECT-TYPE SYNTAX INTEGER(1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the IPOIB Link Layer address in the table." ::= { ibIpoibLinkLayerAddrEntry 2 } Expires December 2002 [Page 22] Internet Draft IPOVERIB IF MIB June 2002 ibIpoibLinkLayerAddr OBJECT-TYPE SYNTAX IbIpoibClientIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "A Client Identifier for this interface (port). An implementation may associate multiple IPOIB interfaces on the same port. It is up to the implementation to ensure a unique Client Identifier when multiple IPOIB interfaces are defined over the same port and same GID. A unique, invariant interface-id value must be included in addition to the GID within the Client Identifier definition to achieve this. Note: a port may also be associated with multiple GIDs. Therefore, multiple IPOIB interfaces may exist on the same port while using a different GID from among the GIDs associated with the port. In either case, the IbIpoibLinkLayerAddr MUST be unique." ::= { ibIpoibLinkLayerAddrEntry 3 } ibIfConformance OBJECT IDENTIFIER ::= { ibIfMIB 3 } ibIfCompliances OBJECT IDENTIFIER ::= { ibIfConformance 1 } ibIfMIBGroups OBJECT IDENTIFIER ::= { ibIfConformance 2 } --**************************************************************** -- Compliance Statements --**************************************************************** ibIfBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The basic implementation requirements for managed network entities that have InfiniBand network interfaces." MODULE -- this module -- ibIfStatOptionalPortStatGroup ,ibIfVLTrafficGroup, and -- ibIpoibLinkAddrGroup are not required for basic implementation. MANDATORY-GROUPS { ibIfStatMandatoryPortStatGroup } ::= { ibIfCompliances 1 } ibIfFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The full implementation requirements for managed network entities that have InfiniBand network interfaces." MODULE -- this module MANDATORY-GROUPS { ibIfStatMandatoryPortStatGroup, ibIfStatOptionalPortStatGroup, ibIfVLTrafficGroup, ibIpoibLinkAddrGroup } ::= { ibIfCompliances 2 } Expires December 2002 [Page 23] Internet Draft IPOVERIB IF MIB June 2002 --**************************************************************** -- Units of Conformance --**************************************************************** ibIfStatMandatoryPortStatGroup OBJECT-GROUP OBJECTS { ibIfPortSymbolErrs, ibIfPortLinkErrRecovery, ibIfPortLinkDowned, ibIfPortStatRcvRemPhyErrs, ibIfPortStatRcvConstrErrs, ibIfPortStatLinkIntergrityErrs, ibIfPortStatExcBufOverrunErrs, ibIfPortStatVL15Dropped } STATUS current DESCRIPTION "Detailed error statistics group for mandatory InfiniBand-based Port Statistics counters." ::= { ibIfMIBGroups 1 } ibIfStatOptionalPortStatGroup OBJECT-GROUP OBJECTS { ibIfPortStatLocalPhyErrs, ibIfPortStatMalPktErrs, ibIfPortStatInactDiscards, ibIfPortStatNeighMTUDiscards, ibIfPortStatSwLifetimeDiscards, ibIfPortStatHOQLifetimeDiscards } STATUS current DESCRIPTION "Detailed error statistics group for optional InfiniBand-based Port Statistics counters." ::= { ibIfMIBGroups 2 } ibIfVLTrafficGroup OBJECT-GROUP OBJECTS { ibIfVLOutOctets, ibIfVLOutPkts, ibIfVLInOctets, ibIfVLInPkts } STATUS current DESCRIPTION "Detailed per VL traffic statistics group." ::= { ibIfMIBGroups 3 } Expires December 2002 [Page 24] Internet Draft IPOVERIB IF MIB June 2002 ibIpoibLinkAddrGroup OBJECT-GROUP OBJECTS { ibIpoibLinkLayerAddr } STATUS current DESCRIPTION "Detailed per port IPOIB link layer address group." ::= { ibIfMIBGroups 4 } END 4.0 Revision History This section should be removed when this document is published as an RFC. 4.1 Changes from The InfiniBand Textual Conventions MIB module was removed from this document and became a separate Internet Draft (draft-ietf- ipoib-ibmib-tc-mib-00.txt). That MIB defines the infinibandMIB as object identifier { experimental 117 }. The TC MIB is defined as { infinibandMIB 1 } and the IB Interface MIB will become { infinibandMIB 2 }. The ibIfMIB MODULE-IDENTITY was updated. The infiniband IANA ifType definition of 199 was added. Sean Harnedy from InifiniSwitch as added as an author, and updated Section 8.0 Authors' Addresses. Added Section 4.0 Revision History. Removed former Section 7.1 Known Issues and added REFERENCE clauses to objects and added Basic and Full Compliance modules to differentiate between mandatory and optional InfiniBand counters. Other minor DESCRIPTION edits, etc. as needed. 4.2 Changes from Added the IPOIB Link Layer Address table. Updated IMPORTS section. 4.3 Changes from The SYNTAX of ibIpoibLinkLayerAddrEntry was corrected. Minor edits. 5.0 Security Considerations SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. Expires December 2002 [Page 25] Internet Draft IPOVERIB IF MIB June 2002 It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6.0 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7.0 Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can Expires December 2002 [Page 26] Internet Draft IPOVERIB IF MIB June 2002 be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8.0 Authors' Addresses Name: Bill Anderson EMail: w_d_anderson@yahoo.com Name: Sean Harnedy Company: Infiniswitch Corporation Address: 134 Flanders Road Westborough, MA 01581 Phone: 978-599-6388 EMail: sharnedy@infiniswitch.com 9.0 References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Expires December 2002 [Page 27] Internet Draft IPOVERIB IF MIB June 2002 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. --- end of Framework references [RFC2863] McCloghrie, K., and Kasenholz F., "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2665] Flick J.,and Johnson J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 2665, August 1999. [Infini v1.0a] InfiniBand Architecture Specification, Volume 1.0 Version 1.0a. This Internet draft has an expiration date of December 2002. Expires December 2002 [Page 28]