Internet-Draft Sean Harnedy
InfiniSwitch Corp.
Expiration Date: July 2003 Bill Anderson
January 2003
Definitions of Managed Objects
for InfiniBand Interface Types
<draft-ietf-ipoib-ibif-mib-04.txt>
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. Please send comments
to the IP Over IB (ipoib) Working Group, ipoverib@ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2002). 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 July 2003 [Page 1]
Internet-Draft IPOVERIB IF MIB January 2003
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 ................................ 4
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 <draft-ietf-ipoib-ibif-mib-00.txt> ........... 25
4.2 Changes from <draft-ietf-ipoib-ibif-mib-01.txt> ........... 25
4.3 Changes from <draft-ietf-ipoib-ibif-mib-02.txt> ........... 25
4.4 Changes from <draft-ietf-ipoib-ibif-mib-03.txt> ........... 26
5.0 Security Considerations ................................... 26
6.0 Full Copyright Statement .................................. 26
7.0 Intellectual Property ..................................... 27
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
Expires July 2003 [Page 2]
Internet-Draft IPOVERIB IF MIB January 2003
[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 (e.g., 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 [RFC2119].
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.
Expires July 2003 [Page 3]
Internet-Draft IPOVERIB IF MIB January 2003
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.1] 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 that 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
conflict 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.1].
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, InfiniBand media are identified by the following values
Expires July 2003 [Page 4]
Internet-Draft IPOVERIB IF MIB January 2003
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) 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 Interfaces MIB [RFC2863] requires that any MIB which is an
adjunct of the Interface MIB clarify specific areas within the
Interfaces MIB. These areas were intentionally left vague in the
Interfaces MIB to avoid over constraining the MIB, thereby precluding
management of certain media-types.
Section 4.0 of [RFC2863] enumerates several areas that 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
There are no media tests which are instrumented with this MIB.
Expires July 2003 [Page 5]
Internet-Draft IPOVERIB IF MIB January 2003
2.2.4. ifRcvAddressTable
For IBA Routers and Channel Adapters (CAs):
Routers and CAs which have been programmed by the IBA Subnet Manager
to have more than one address, use this table to display the set of
additional addresses 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 (ifPhysAddress).
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 the 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.
Expires July 2003 [Page 6]
Internet-Draft IPOVERIB IF MIB January 2003
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 values are greater than the
maximum reportable by this object,
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 through the SMA.
ifOperStatus The operational state of the interface.
Support for "testing" is not required.
ifLastChange Refer to [RFC2863].
Expires July 2003 [Page 7]
Internet-Draft IPOVERIB IF MIB January 2003
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 are
implemented.
Expires July 2003 [Page 8]
Internet-Draft IPOVERIB IF MIB January 2003
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 0. Refer to [RFC2863].
ifOutBroadcastPkts Always 0.
ifHCInBroadcastPkts Always 0.
ifHCOutBroadcastPkts Always 0.
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 July 2003 [Page 9]
Internet-Draft IPOVERIB IF MIB January 2003
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 flow control Packet = 8 = 1 START + 1 END +
6 flow control octets;
MHB = Max Header Bytes = 126 octets; includes all packet fields
except framing characters. See [Infini v1.1] sec 7.7.8.
Expires July 2003 [Page 10]
Internet-Draft IPOVERIB IF MIB January 2003
_____________________________________________________________________
IBA Attribute and Field Corresponding SNMP Object
_____________________________________________________________________
------------
PortCounters see [Infini v1.1] Table:191
------------
(.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.1] Table:194
-----------------
.PortLocalPhysicalErrors = ibIfPortStatLocalPhyErrs
.PortMalformedPacketErrors = ibIfPortStatMalPktErrs
Expires July 2003 [Page 11]
Internet-Draft IPOVERIB IF MIB January 2003
----------------------
PortXmitDiscardDetails see [Infini v1.1] table:195
----------------------
.PortInactiveDiscards = ibIfPortStatInactDiscards
.PortNeighborMTUDiscards = ibIfPortStatNeighMTUDiscards
.PortSwLifetimeLimitDiscards = ibIfPortStatSwLifetimeDiscards
.PortSwHOQLimitDiscards = ibIfPortStatHOQLifetimeDiscards
--------
PortInfo see [Infini v1.1] Table:132
--------
.NeighborMTU = IF-MIB:ifMtu
.linkWidthActive = IF-MIB:ifSpeed
_____________________________________________________________________
IBA Port Sample Counter Corresponding SNMP Object
_____________________________________________________________________
--------------------
Sample Select Values see [Infini v1.1] table:189
--------------------
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 July 2003 [Page 12]
Internet-Draft IPOVERIB IF MIB January 2003
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 July 2003 [Page 13]
Internet-Draft IPOVERIB IF MIB January 2003
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 "200301011200Z" -- 1 January 2003 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
"200301011200Z" -- 1 January 2003 12:00:00 EST
DESCRIPTION
"Updated REFERENCE clauses to IBTA Spec Version 1.1."
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."
Expires July 2003 [Page 14]
Internet-Draft IPOVERIB IF MIB January 2003
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 }
--****************************************************************
-- IPoIB Detailed per interface/port statistics
-- ibIfPortStat Table
--****************************************************************
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 July 2003 [Page 15]
Internet-Draft IPOVERIB IF MIB January 2003
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 minor link errors detected on one or more
physical lanes."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section
16.1.3.5; Table 191 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.1 Vol 1. Section
16.1.3.5; Table 191 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.1 Vol 1. Section
16.1.3.5; Table 191 PortCounters::LinkDownedCounter."
::= { ibIfPortStatEntry 4 }
Expires July 2003 [Page 16]
Internet-Draft IPOVERIB IF MIB January 2003
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.1 Vol 1. Section
16.1.3.5; Table 191 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.1 Vol 1. Section
16.1.3.5; Table 191 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.1 Vol 1. Section
16.1.3.5; Table 191 PortCounters::PortRcvRemotePhysicalErrors."
::= { ibIfPortStatEntry 7 }
Expires July 2003 [Page 17]
Internet-Draft IPOVERIB IF MIB January 2003
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 or IP version check."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section 16.1.3.5;
Table 191 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 not in the active state."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section 16.1.4.2;
Table 195 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.1 Vol 1. Section 16.1.4.2;
Table 195 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.1 Vol 1. Section 16.1.4.2;
Table 195 PortXmitDiscardDetails::PortSwLifetimeLimitDiscards."
::= { ibIfPortStatEntry 11 }
Expires July 2003 [Page 18]
Internet-Draft IPOVERIB IF MIB January 2003
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.1 Vol 1. Section 16.1.4.2;
Table 195 PortXmitDiscardDetails::PortSwHOQLimitDiscards."
::= { ibIfPortStatEntry 12 }
ibIfPortStatLinkIntergrityErrs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that the count of local physical errors
exceeded the LocalPhyErrors threshold."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section 16.1.3.5;
Table 191 PortCounters::LocalLinkIntegrityErrors.; Also see
Table 132 PortInfo."
::= { ibIfPortStatEntry 13 }
ibIfPortStatExcBufOverrunErrs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that OverrunErrors consecutive
flow control update periods occurred with at least one
overrun error in each period."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section 16.1.3.5;
Table 191 PortCounters::ExcessiveBufferOverrunErrors.; Also
see Table 132 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 the selected port (e.g., lack of buffers)."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section 16.1.3.5;
Table 191 PortCounters::VL15Dropped."
::= { ibIfPortStatEntry 15 }
Expires July 2003 [Page 19]
Internet-Draft IPOVERIB IF MIB January 2003
--****************************************************************
-- IPoIB per port VL Traffic Objects
-- ibIfVLTraffic Table
--****************************************************************
ibIfVLTrafficTable OBJECT-TYPE
SYNTAX SEQUENCE OF IbIfVLTrafficEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides traffic statistics for all
virtual lanes that are configured on an InfiniBand
interface. There will always be at least one data virtual
lane in the range VL0-VL14 configured on an interface,
as well as 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 July 2003 [Page 20]
Internet-Draft IPOVERIB IF MIB January 2003
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 for this VL."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section 16.1.3.3;
Table 189 CounterSelect::PortXmitDataVL."
::= { 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.1 Vol 1. Section 16.1.3.3;
Table 189 CounterSelect::PortXmitPktVL."
::= { 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
for this VL."
REFERENCE
"InfiniBand Architecture Release 1.1 Vol 1. Section 16.1.3.3;
Table 189 CounterSelect::PortRcvDataVL."
::= { ibIfVLTrafficEntry 5 }
ibIfVLInPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets successfully received on this VL. Note,
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.1 Vol 1. Section 16.1.3.3;
Table 189 CounterSelect::PortRcvPktVL."
::= { ibIfVLTrafficEntry 6 }
Expires July 2003 [Page 21]
Internet-Draft IPOVERIB IF MIB January 2003
--****************************************************************
-- IPoIB Link Layer Address Table
-- ibIpoibLinkLayerAddr Table
--****************************************************************
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 July 2003 [Page 22]
Internet-Draft IPOVERIB IF MIB January 2003
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 July 2003 [Page 23]
Internet-Draft IPOVERIB IF MIB January 2003
--****************************************************************
-- 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 July 2003 [Page 24]
Internet-Draft IPOVERIB IF MIB January 2003
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 <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 InfiniSwitch 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 <draft-ietf-ipoib-ibif-mib-01.txt>
Added the IPOIB Link Layer Address table. Updated IMPORTS section.
4.3 Changes from <draft-ietf-ipoib-ibif-mib-02.txt>
The SYNTAX of ibIpoibLinkLayerAddrEntry was corrected. Minor edits.
Expires July 2003 [Page 25]
Internet-Draft IPOVERIB IF MIB January 2003
4.4 Changes from <draft-ietf-ipoib-ibif-mib-03.txt>
Updated REFERENCE notation to new IBTA Spec version 1.1; Minor edits.
Updated DESCRIPTIONs to match new spec.
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 (2002). 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.
Expires July 2003 [Page 26]
Internet-Draft IPOVERIB IF MIB January 2003
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: 508-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.
Expires July 2003 [Page 27]
Internet-Draft IPOVERIB IF MIB January 2003
[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.
[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.
Expires July 2003 [Page 28]
Internet-Draft IPOVERIB IF MIB January 2003
[RFC2665] Flick J.,and Johnson J.,
"Definitions of Managed Objects for the Ethernet-like
Interface Types", RFC 2665, August 1999.
[Infini v1.1] InfiniBand Architecture Specification, Volume 1,
Version 1.1. November 6, 2002.
This Internet draft has an expiration date of July 2003.
Expires July 2003 [Page 29]
