INTERNET DRAFT B. Anderson
Expiration Date: May 13, 2002 S. Harnedy
InfiniSwitch
November 13, 2001
Definitions of Managed Objects
for InfiniBand Interface Types
<draft-ietf-ipoib-ibif-mib-01.txt>
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.
Anderson [Page 1]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
Table of Contents
1.0 The SNMP Management Framework ............................. 3
1.1 Conventions used in this document ......................... 4
1.2 IANA Considerations ....................................... 4
2.0 Introduction to InfiniBand ................................ 4
2.1 Relation to MIB-2 ......................................... 5
2.2 Relation to the Interfaces MIB ............................ 5
2.2.1 Layering Model .......................................... 6
2.2.2 Virtual Circuits ........................................ 6
2.2.3 ifTestTable ............................................. 6
2.2.4 ifRcvAddressTable ....................................... 6
2.2.5 ifPhysAddress ........................................... 6
2.2.6 ifType .................................................. 7
2.2.7 Specific Interface MIB Objects .......................... 7
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 ...................... 15
4.0 Revision History .......................................... 24
4.1 Changes from <draft-ietf-ipoib-ibif-mib-00.txt> ........... 24
5.0 Security Considerations ................................... 25
6.0 Full Copyright Statement .................................. 25
7.0 Intellectual Property ..................................... 26
8.0 Authors' Addresses ........................................ 26
9.0 References ................................................ 26
Anderson [Page 2]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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].
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.
Anderson [Page 3]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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.
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.
Anderson [Page 4]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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
2.1 Relation to MIB-2
This section applies only when this MIB is used in conjunction with
the "old" (RFC 1213) [24] 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
Anderson [Page 5]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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.
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.
Anderson [Page 6]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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.
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.
Anderson [Page 7]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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].
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].
Anderson [Page 8]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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.
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'.
Anderson [Page 9]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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.
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 two 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.
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
Anderson [Page 10]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
_____________________________________________________________________
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
Anderson [Page 11]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
----------------------
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.
Anderson [Page 12]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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
Anderson [Page 13]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
PC.PortXmitDiscards = PortInactiveDiscards +
PortNeighborMTUDiscards +
PortSwLifeTimeLimitDiscard +
PortSwHOQLifetimeLimitDiscards
PC.PortRcvErrors = PRED.PortLocalPhysicalErrors +
PRED.PortMalformedPacketErrors +
PRED.PortBufferOverrunErrors
PC.PortRcvSwitchRelayErrors = PRED.PortDLIDMapErrs +
PRED.PortVLMapErrs +
PRED.PortLoopingErr
Anderson [Page 14]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 FROM IB-TC-MIB
;
ibIfMIB MODULE-IDENTITY
LAST-UPDATED "200111131200Z" -- 13 November 2001 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 history.
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 }
--
-- Object Identifier Assignments
--
ibIfObjects OBJECT IDENTIFIER ::= { ibIfMIB 1}
ibIfNotifications OBJECT IDENTIFIER ::= { ibIfMIB 2}
Anderson [Page 15]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
--****************************************************************
-- 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
}
Anderson [Page 16]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 virtual
more 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 }
Anderson [Page 17]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 }
Anderson [Page 18]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 }
Anderson [Page 19]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 }
Anderson [Page 20]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
--****************************************************************
-- 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 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."
::= { ibIfPortStatEntry 1 }
ibIfVlIndex OBJECT-TYPE
SYNTAX IbVirtualLane
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Identifies what Virtual Lane instance is being addressed."
::= { ibIfVLTrafficEntry 2 }
Anderson [Page 21]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 }
Anderson [Page 22]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 and ibIfVLTrafficGroup are
-- not required for the 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 }
::= { ibIfCompliances 2 }
--****************************************************************
-- 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 }
Anderson [Page 23]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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 }
END
4.0 Revision History
This section should be removed when this document is published as an
RFC.
4.1 Changes from <draft-ietf-ipoib-ibif-mib-00.txt>
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.
Anderson [Page 24]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
Added Basic and Full Compliance modules to differentiate between
mandatory and optional InfiniBand counters.
Other minor DESCRIPTION edits, etc. as needed.
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.
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.
Anderson [Page 25]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
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
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
Anderson [Page 26]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
[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.
[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 2863, August 1999
Anderson [Page 27]
Internet Draft draft-ietf-ipoib-ibif-mib-01.txt November 13, 2001
[Infini v1.0a] InfiniBand Architecture Specification,
Volume 1.0 Version 1.0a
This Internet draft has an expiration date of May 13, 2002.
Anderson [Page 28]
