idnits 2.17.1 draft-ietf-ipoib-channel-adapter-mib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 630 has weird spacing: '... before compa...' == Line 869 has weird spacing: '... rights migh...' == Line 870 has weird spacing: '...that it has ...' == Line 872 has weird spacing: '...ack and stan...' == Line 873 has weird spacing: '...pies of clai...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2002) is 8070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IBTC' is defined on line 956, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) -- Possible downref: Non-RFC (?) normative reference: ref. 'IBTAArch' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBTC' Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft S. Harnedy 3 InfiniSwitch Corp. 4 Expiration Date: September 2002 March 2002 6 Definitions of Managed Objects for 7 Infiniband Channel Adapters (CA) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 This memo defines a portion of the Management Information Base (MIB) 38 for use with network management protocols in the Internet community. 39 In particular, it defines objects for managing InfiniBand Channel 40 Adapters (CA). 42 Table of Contents 44 1. Introduction ................................................ 2 45 2. The SNMP Management Framework ............................... 2 46 3. Conventions used in this document ........................... 3 47 4. Structure of the MIB ........................................ 3 48 4.1. Overview .................................................. 3 49 4.2. Discussion of MIB Groups .................................. 3 50 4.3. The CA MIB Objects ........................................ 3 51 4.3.1. The General Channel Adapter Info Group .................. 4 52 4.3.2. The Channel Adapter Attributes Info Group ............... 4 53 4.3.3. The Channel Adapter Port Attributes and Functions Info Group 4 54 4.4. The CA Notifications Group ................................ 4 55 4.5. The CA Conformance Group .................................. 4 56 4.5.1. CA Compliance Groups .................................... 4 57 5. IPOIB CA MIB Definitions .................................... 4 58 6. Security Considerations ..................................... 16 59 7. Intellectual Property ....................................... 17 60 8. References .................................................. 18 61 9. Author's Address ............................................ 19 63 1. Introduction 65 This document defines a MIB for InfiniBand Channel Adpaters (CA). 67 The Infiniband Architecture[IBTAArch] (IBA) is defined by the 68 Infiniband Trade Association. Infiniband is designed to provide low 69 latency, high bandwidth interconnect in a computing environment. This 70 document will define the objects related to managing a specific class 71 of InfiniBand nodes called Channel Adapters. 73 A Channel Adapter (CA) is the end-point for IBA packets that are sent 74 and received over the IBA switching fabric. There are two types of 75 CAs: Host Channel Adapters (HCA) and Target Channel Adapters (TCA). 76 Typically, HCAs are used by host processors and TCAs are used by I/O 77 adapters to connect to the IBA switch fabric. The HCA supports the 78 IBA Verbs layer as the transport layer interface, while the TCA often 79 uses its own implementation-specific interface to the transport layer. 81 2. The SNMP Management Framework 83 The SNMP Management Framework presently consists of five major 84 components: 86 o An overall architecture, described in RFC 2571[RFC2571]. 88 o Mechanisms for describing and naming objects and events for 89 the purpose of management. The first version of this 90 Structure of Management Information (SMI) is called SMIv1 91 and described in STD 16, RFC 1155[RFC1155], STD 16, RFC 1212 92 [RFC1212] and RFC 1215 [RFC1215]. The second version, 93 called SMIv2, is described in STD 58, RFC 2578[RFC2578], STD 94 58, RFC 2579[RFC2579], and STD 58, RFC 2580[RFC2580]. 96 o Message protocols for transferring management information. 97 The first version of the SNMP message protocol is called 98 SNMPv1 and described in STD 15, RFC 1157[RFC1157]. A second 99 version of the SNMP message protocol, which is not an 100 Internet standards track protocol, is called SNMPv2c and 101 described in RFC 1901[RFC1901] and RFC 1906[RFC1906]. The 102 third version of the message protocol is called SNMPv3 and 103 described in RFC 1906[RFC1906], RFC 2572[RFC2572] and RFC 104 2574[RFC2574]. 106 o Protocol operations for accessing management information. 108 The first set of protocol operations and associated PDU 109 formats is described in STD 15, RFC 1157[RFC1157]. A second 110 set of protocol operations and associated PDU formats is 111 described in RFC 1905[RFC1905]. 113 o A set of fundamental applications described in RFC 114 2573[RFC2573] and the view-based access control mechanism 115 described in RFC 2575[RFC2575]. 117 A more detailed introduction to the current SNMP Management 118 Framework can be found in RFC 2570[RFC2570]. 120 Managed objects are accessed via a virtual information store, 121 termed the Management Information Base or MIB. Objects in the MIB 122 are defined using the mechanisms defined in the SMI. 124 This memo specifies a MIB module that is compliant to the SMIv2. 125 A MIB conforming to the SMIv1 can be produced through the 126 appropriate translations. The resulting translated MIB must be 127 semantically equivalent, except where objects or events are 128 omitted because no translation is possible (use of Counter64). 129 Some machine readable information in SMIv2 will be converted into 130 textual descriptions in SMIv1 during the translation process. 131 However, this loss of machine readable information is not 132 considered to change the semantics of the MIB. 134 3. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 137 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 RFC 2119 [RFC2119]. 141 4. Structure of the MIB 143 This section describes the structure of the IPOIB CA MIB. 145 4.1. Overview 147 The SNMP management of the CA involves the monitoring of key channel 148 adapter attributes. 150 4.2. Discussion of MIB Groups 152 The CA MIB is divided into two basic groups: MIB objects and the 153 conformance section. 155 4.3. The CA MIB Objects 157 The CA MIB objects correlate to the set of Channel Adapter attributes. 158 These attributes are organized into three major CA MIB groups. 159 These are: The General Channel Adpater Info Group, The Channel Adapter 160 Attributes Info Group, and the Channel Adpater Port Attributes and 161 Functions Info Group. 163 4.3.1. The General Channel Adapter Info Group 165 This group provides general information common to any InfiniBand 166 CA. This includes distinguishing between the HCA and the TCA, 167 displaying the node and port GUID, and showing the number of ports on 168 the CA. 170 4.3.2. The Channel Adapter Attributes Info Group 172 This group provides more specific information about the CA. This 173 includes various attribute flags, transport service support, and 174 other CA characteristics. 176 4.3.3. The Channel Adapter Port Attributes and Functions Info Group 178 This group provides information about the CA ports. This includes 179 the type of physical interfaces supported, other port attributes, 180 and a table containing the port GIDs. 182 4.4. The CA Notifications Group 184 The CA MIB currently does not define a Notifications Group. 186 4.5. The CA Conformance Group 188 The CA Conformance Group lists the possible compliances for various 189 types of InfiniBand nodes that contain channel adapters. Currently, 190 two types of compliance are defined: basic and full. The units of 191 conformance which define the constituent object groups are also 192 listed. 194 4.5.1. CA Compliance Groups 196 The Compliance Groups list acceptable MIB implementation requirements. 198 5. IPOIB CA MIB Definitions 200 IB-CA-MIB DEFINITIONS ::= BEGIN 202 IMPORTS 203 MODULE-IDENTITY, OBJECT-TYPE, 204 Counter32, NOTIFICATION-TYPE, Integer32 FROM SNMPv2-SMI 205 TruthValue, DisplayString FROM SNMPv2-TC 206 MODULE-COMPLIANCE, OBJECT-GROUP, 207 NOTIFICATION-GROUP FROM SNMPv2-CONF 208 IbPort, infinibandMIB FROM IB-TC-MIB; 210 ibCaMIB MODULE-IDENTITY 211 LAST-UPDATED "200203291200Z" -- March 29, 2002 212 ORGANIZATION "IETF IP Over IB Working Group 213 Email: ipoib@ietf.org" 214 CONTACT-INFO 215 "Sean Harnedy (sharnedy@infiniswitch.com) 216 InfiniSwitch Corporation" 217 DESCRIPTION 218 "This module contains managed object definitions for 219 the instrumentation for an InfiniBand Channel Adpater (CA)." 220 REVISION 221 "200203291200Z" 222 DESCRIPTION 223 "Initial IETF Draft Revision (-00)." 224 ::= { infinibandMIB 4 } 226 --**************************************************************** 227 -- Object Indentifiers for the IPOIB CA MIB 228 --**************************************************************** 230 ibCaObjects OBJECT IDENTIFIER ::= { ibCaMIB 1 } 231 ibCaNotifications OBJECT IDENTIFIER ::= { ibCaMIB 2 } 232 ibCaConformance OBJECT IDENTIFIER ::= { ibCaMIB 3 } 234 --**************************************************************** 235 -- General Channel Adapter Info Group 236 --**************************************************************** 238 ibCaGeneralInfo OBJECT IDENTIFIER ::= { ibCaObjects 1 } 240 --**************************************************************** 241 -- General Channel Adapter Info Group 242 -- 243 -- DESCRIPTION: This group contains scalar variables that describe 244 -- general information about the CA. 245 --**************************************************************** 247 ibCaType OBJECT-TYPE 248 SYNTAX INTEGER { 249 unknown(1), 250 hca(2), 251 tca(3) 252 } 253 MAX-ACCESS read-only 254 STATUS current 255 DESCRIPTION 256 "Type of Channel Adapter: either a Host Channel Adpater (HCA), 257 or a Target Channel Adapter (TCA). If the type of CA cannot 258 be determined, the unknown(1) value is returned." 259 REFERENCE 260 "InfiniBand Architecture Release 1.0.a. Vol 1. 261 Section 17.1." 262 ::= { ibCaGeneralInfo 1 } 264 ibCaNodeGuid OBJECT-TYPE 265 SYNTAX OCTET STRING (SIZE(8)) 266 MAX-ACCESS read-only 267 STATUS current 268 DESCRIPTION 269 "The GUID of this CA. All ports on the same node shall 270 report the same CA node GUID value. This provides a 271 means for uniquely identifing a CA node within a 272 subnet and helps to determine the co-location of 273 the ports." 274 REFERENCE 275 "InfiniBand Architecture Release 1.0.a. Vol 1. 276 Section 17.2.5." 277 ::= { ibCaGeneralInfo 2 } 279 ibCaPortGuid OBJECT-TYPE 280 SYNTAX OCTET STRING (SIZE(8)) 281 MAX-ACCESS read-only 282 STATUS current 283 DESCRIPTION 284 "The GUID of this CA port. All ports on the same node shall 285 report the same ibCaPortGuid value. This provides a 286 means for uniquely identifing a node within a 287 subnet and helps to determine the co-location of 288 the ports." 289 REFERENCE 290 "InfiniBand Architecture Release 1.0.a. Vol 1. 291 Section 17.2.5." 292 ::= { ibCaGeneralInfo 3 } 294 ibCaNumPorts OBJECT-TYPE 295 SYNTAX Integer32(1..254) 296 MAX-ACCESS read-only 297 STATUS current 298 DESCRIPTION 299 "Number of physical IB data ports on this Channel Adapter. Ports 300 are numbered starting from 1. If there is more than one port, 301 the ports are numbered sequentially." 302 REFERENCE 303 "InfiniBand Architecture Release 1.0.a. Vol 1. 304 Section 17.2.1.3; Table 254 Port Attributes & Functions." 305 ::= { ibCaGeneralInfo 4 } 307 --**************************************************************** 308 -- Channel Adapter Attributes Info Group 309 --**************************************************************** 311 ibCaAttrInfo OBJECT IDENTIFIER ::= { ibCaObjects 2 } 313 --**************************************************************** 314 -- Channel Adapter Attributes Info Group 315 -- 316 -- DESCRIPTION: This group contains scalar variables that describe 317 -- more specific attributes about the whole CA. 318 --**************************************************************** 320 ibCaHasReliableConnection OBJECT-TYPE 321 SYNTAX TruthValue 322 MAX-ACCESS read-only 323 STATUS current 324 DESCRIPTION 325 "Flag that indicates whether this CA supports 326 Reliable Connection (RC) transport service." 327 REFERENCE 328 "InfiniBand Architecture Release 1.0.a. Vol 1. 329 Section 17.2.2; Table 255 Channel Adapter Attributes." 330 ::= { ibCaAttrInfo 1 } 332 ibCaHasUnreliableConnection OBJECT-TYPE 333 SYNTAX TruthValue 334 MAX-ACCESS read-only 335 STATUS current 336 DESCRIPTION 337 "Flag that indicates whether this CA supports 338 Unreliable Connection (UC) transport service." 339 REFERENCE 340 "InfiniBand Architecture Release 1.0.a. Vol 1. 341 Section 17.2.2; Table 255 Channel Adapter Attributes." 342 ::= { ibCaAttrInfo 2 } 344 ibCaHasReliableDatagram OBJECT-TYPE 345 SYNTAX TruthValue 346 MAX-ACCESS read-only 347 STATUS current 348 DESCRIPTION 349 "Flag that indicates whether this CA supports 350 Reliable Datagram (RD) transport service." 351 REFERENCE 352 "InfiniBand Architecture Release 1.0.a. Vol 1. 353 Section 17.2.2; Table 255 Channel Adapter Attributes." 354 ::= { ibCaAttrInfo 3 } 356 ibCaHasUnreliableDatagram OBJECT-TYPE 357 SYNTAX TruthValue 358 MAX-ACCESS read-only 359 STATUS current 360 DESCRIPTION 361 "Flag that indicates whether this CA supports 362 Unreliable Datagram (UD) transport service." 363 REFERENCE 364 "InfiniBand Architecture Release 1.0.a. Vol 1. 365 Section 17.2.2; Table 255 Channel Adapter Attributes." 366 ::= { ibCaAttrInfo 4 } 368 ibCaSupportsAtomicOperations OBJECT-TYPE 369 SYNTAX TruthValue 370 MAX-ACCESS read-only 371 STATUS current 372 DESCRIPTION 373 "Flag that indicates whether this CA supports 374 atomic operations. An atomic operation is an operation 375 that is guaranteed to finish without having another 376 operation alter the results once the atomic operation 377 has been initiated." 378 REFERENCE 379 "InfiniBand Architecture Release 1.0.a. Vol 1. 380 Section 17.2.2; Table 255 Channel Adapter Attributes." 381 ::= { ibCaAttrInfo 5 } 383 ibCaSupportsOtherOperations OBJECT-TYPE 384 SYNTAX TruthValue 385 MAX-ACCESS read-only 386 STATUS current 387 DESCRIPTION 388 "Flag that indicates whether this CA supports 389 all of the other operations (excluding atomic operations) 390 defined for a particular supported transport service." 391 REFERENCE 392 "InfiniBand Architecture Release 1.0.a. Vol 1. 393 Section 17.2.2; Table 255 Channel Adapter Attributes." 394 ::= { ibCaAttrInfo 6 } 396 ibCaSupportsSolicitedEvents OBJECT-TYPE 397 SYNTAX TruthValue 398 MAX-ACCESS read-only 399 STATUS current 400 DESCRIPTION 401 "Flag that indicates whether this CA supports the 402 generation and reception of solicited events. A solicited 403 event is a feature by which a queue pair consumer on a 404 CA can cause an event to be generated at the destination 405 when its message is received." 406 REFERENCE 407 "InfiniBand Architecture Release 1.0.a. Vol 1. 408 Section 17.2.2; Table 255 Channel Adapter Attributes. 409 and Section 9.2.3 Solicited Event (SE) - 1 bit." 410 ::= { ibCaAttrInfo 7 } 412 ibCaPathMtuSetSupport OBJECT-TYPE 413 SYNTAX INTEGER { 414 mtu256(1), 415 mtu256And512(2), 416 mtu256And512And1024(3), 417 mtu256And512And1024And2048(4), 418 mtu256And512And1024And2048And4096(5) 419 } 421 MAX-ACCESS read-only 422 STATUS current 423 DESCRIPTION 424 "Set of MTU values (in bytes) supported by this CA for all 425 transport service classes. The Maximum Transfer Unit is the 426 largest size allowable for the packet payload." 427 REFERENCE 428 "InfiniBand Architecture Release 1.0.a. Vol 1. 429 Section 17.2.2; Table 255 Channel Adapter Attributes." 430 ::= { ibCaAttrInfo 8 } 432 ibCaGenEndToEndFlowControl OBJECT-TYPE 433 SYNTAX TruthValue 434 MAX-ACCESS read-only 435 STATUS current 436 DESCRIPTION 437 "Flag that indicates whether this CA supports 438 the generation of end-to-end flow control. End-to-end 439 flow control is a mechanism that prevents sending messages 440 when the destination does not have adequate receive buffers 441 to receive the message." 442 REFERENCE 443 "InfiniBand Architecture Release 1.0.a. Vol 1. 444 Section 17.2.2; Table 255 Channel Adapter Attributes." 445 ::= { ibCaAttrInfo 9 } 447 ibCaSupportsMulticast OBJECT-TYPE 448 SYNTAX TruthValue 449 MAX-ACCESS read-only 450 STATUS current 451 DESCRIPTION 452 "Flag that indicates whether this CA supports multicast 453 operations. Multicast is the ability to deliver a single 454 packet to multiple ports." 455 REFERENCE 456 "InfiniBand Architecture Release 1.0.a. Vol 1. 457 Section 17.2.2; Table 255 Channel Adapter Attributes." 458 ::= { ibCaAttrInfo 10 } 460 ibCaSupportsAutoPathMigration OBJECT-TYPE 461 SYNTAX TruthValue 462 MAX-ACCESS read-only 463 STATUS current 464 DESCRIPTION 465 "Flag that indicates whether this CA supports 466 automatic path migration. Automatic path migration 467 is the process by which a CA (on a per QP basis) 468 signals another CA to cause path migration to a 469 preset alternate path." 470 REFERENCE 471 "InfiniBand Architecture Release 1.0.a. Vol 1. 472 Section 17.2.2; Table 255 Channel Adapter Attributes." 474 ::= { ibCaAttrInfo 11 } 476 ibCaSupportsMemoryProtection OBJECT-TYPE 477 SYNTAX TruthValue 478 MAX-ACCESS read-only 479 STATUS current 480 DESCRIPTION 481 "Flag that indicates whether this CA supports InfiniBand 482 memory management protection mechanisms." 483 REFERENCE 484 "InfiniBand Architecture Release 1.0.a. Vol 1. 485 Section 17.2.2; Table 255 Channel Adapter Attributes 486 and Section 10.6 Memory Management." 487 ::= { ibCaAttrInfo 12 } 489 ibCaSupportsLoopback OBJECT-TYPE 490 SYNTAX TruthValue 491 MAX-ACCESS read-only 492 STATUS current 493 DESCRIPTION 494 "Flag that indicates whether this CA supports 495 loopback operations. Loopback support allows for the 496 sending and receiving of self-addressed packets that 497 do not go out on the wire. If this feature is supported, 498 self-addressed packets must work, even if no switch is 499 present." 500 REFERENCE 501 "InfiniBand Architecture Release 1.0.a. Vol 1. 502 Section 17.2.2; Table 255 Channel Adapter Attributes." 503 ::= { ibCaAttrInfo 13 } 505 ibCaHasSubnetManager OBJECT-TYPE 506 SYNTAX TruthValue 507 MAX-ACCESS read-only 508 STATUS current 509 DESCRIPTION 510 "Flag that indicates whether this CA supports 511 a Subnet Manager (SM) instance." 512 REFERENCE 513 "InfiniBand Architecture Release 1.0.a. Vol 1. 514 Section 17.2.5." 515 ::= { ibCaAttrInfo 14 } 517 --**************************************************************** 518 -- Channel Adapter Port Attributes and Functions Info Group 519 --**************************************************************** 521 ibCaPortAttrInfo OBJECT IDENTIFIER ::= { ibCaObjects 3 } 523 --**************************************************************** 524 -- Channel Adapter Port Attributes and Functions Info Group 525 -- 526 -- DESCRIPTION: This group contains information about the CA ports. 527 -- This includes the type of physical interfaces supported, other 528 -- port attributes, and a table containing the port GIDs. 529 --**************************************************************** 531 ibCaHasCablePhyInterface OBJECT-TYPE 532 SYNTAX TruthValue 533 MAX-ACCESS read-only 534 STATUS current 535 DESCRIPTION 536 "Flag that indicates whether this CA supports 537 a cable connector physical interface. This 538 physical attach point is defined for use with 539 copper cables." 540 REFERENCE 541 "InfiniBand Architecture Release 1.0.a. Vol 1. 542 Section 17.2.1.3 Port Attributes and Functions; 543 Vol 2. 3.1 Introduction (Physical Layer Overview)." 544 ::= { ibCaPortAttrInfo 1 } 546 ibCaHasFiberPhyInterface OBJECT-TYPE 547 SYNTAX TruthValue 548 MAX-ACCESS read-only 549 STATUS current 550 DESCRIPTION 551 "Flag that indicates whether this CA supports 552 a fiber connector physical interface. This 553 physical attach point is defined for use with 554 optical cables." 555 REFERENCE 556 "InfiniBand Architecture Release 1.0.a. Vol 1. 557 Section 17.2.1.3 Port Attributes and Functions; 558 Vol 2. 3.1 Introduction (Physical Layer Overview)." 559 ::= { ibCaPortAttrInfo 2 } 561 ibCaHasBackplanePhyInterface OBJECT-TYPE 562 SYNTAX TruthValue 563 MAX-ACCESS read-only 564 STATUS current 565 DESCRIPTION 566 "Flag that indicates whether this CA supports 567 a backplane connector physical interface. This 568 physical attach point is defined for accepting 569 a specified form factor that houses the 570 channel adapter." 571 REFERENCE 572 "InfiniBand Architecture Release 1.0.a. Vol 1. 573 Section 17.2.1.3 Port Attributes and Functions; 574 Vol 2. 3.1 Introduction (Physical Layer Overview)." 575 ::= { ibCaPortAttrInfo 3 } 577 ibCaSupportsStaticRateControl OBJECT-TYPE 578 SYNTAX TruthValue 579 MAX-ACCESS read-only 580 STATUS current 581 DESCRIPTION 582 "Flag that indicates whether this CA supports static 583 rate control. Static rate controls are required for 584 all IB ports that support a data rate over 2.5 Gbps." 585 REFERENCE 586 "InfiniBand Architecture Release 1.0.a. Vol 1. 587 Section 17.2.6 Static Rate Control." 588 ::= { ibCaPortAttrInfo 4 } 590 ibCaInterpacketDelayValue OBJECT-TYPE 591 SYNTAX INTEGER { 592 unknown(1), 593 zero(2), -- 100% 594 three(3), -- 25% 595 two(4), -- 33% 596 eleven(5) -- 8% 597 } 598 MAX-ACCESS read-only 599 STATUS current 600 DESCRIPTION 601 "Interpacket Delay Value (IPD) supported for CAs that have 602 static rate control (i.e., the ibCaSupportsStaticRateControl 603 object must have a value of true(1) for this object to 604 contain a valid value; Otherwise, unknown(1) is returned). 605 The IPD allows for the slowing of the packet rate for all 606 of the standard link rates. 608 An ibCaInterpacketDelayValue of zero(2) is required for all CAs 609 that support static rate control. An ibCaInterpacketDelayValue 610 of three(3) is required by CAs that support 1 GBs or higher 611 link rate. An ibCaInterpacketDelayValue of two(4) is required by 612 CAs that support 3 Gbps or higher link rates and, an 613 ibCaInterpacketDelayValue of eleven(5) is required by CAs that 614 also support 3 Gbps or higher link rates." 615 REFERENCE 616 "InfiniBand Architecture Release 1.0.a. Vol 1. 617 Section 17.2.6 Static Rate Control, and Table 256 618 Static Rate Control IPD Values." 619 ::= { ibCaPortAttrInfo 5 } 621 ibCaSupportsMultipathing OBJECT-TYPE 622 SYNTAX TruthValue 623 MAX-ACCESS read-only 624 STATUS current 625 DESCRIPTION 626 "Flag that indicates whether this CA supports multipathing. 627 The CA link layer port checks the unicast DLID in the 628 received packet for validity by masking the number of low 629 order bits indicated by the LID Mask Control field (LMC) 630 before comparing the DLID to its assigned LID if this 631 object is true(1)." 632 REFERENCE 633 "InfiniBand Architecture Release 1.0.a. Vol 1. 634 Section 7.2.1.3. and Table 254; Also, Section 7.11.1 635 Multipathing Requirements on End Node." 636 ::= { ibCaPortAttrInfo 6 } 638 ibCaSupportsPKeyCheck OBJECT-TYPE 639 SYNTAX TruthValue 640 MAX-ACCESS read-only 641 STATUS current 642 DESCRIPTION 643 "Flag that indicates whether this CA supports partition 644 key (P_Key) checking. If true(1), the CA port validates the 645 incoming packet's P_Key with the P_Key bound to the 646 destination QP." 647 REFERENCE 648 "InfiniBand Architecture Release 1.0.a. Vol 1. 649 Section 7.2.1.3. and Table 254." 650 ::= { ibCaPortAttrInfo 7 } 652 ibCaValidatesInPktDlid OBJECT-TYPE 653 SYNTAX TruthValue 654 MAX-ACCESS read-only 655 STATUS current 656 DESCRIPTION 657 "Flag that indicates whether this CA supports the validation 658 of incoming packet DLIDs, and if the GRH is present, the 659 DGID." 660 REFERENCE 661 "InfiniBand Architecture Release 1.0.a. Vol 1. 662 Section 7.2.1.3. and Table 254." 663 ::= { ibCaPortAttrInfo 8 } 665 ibCaMaxGidsPerPort OBJECT-TYPE 666 SYNTAX Integer32 667 MAX-ACCESS read-only 668 STATUS current 669 DESCRIPTION 670 "Maximum number of GIDs per port. The maximum number of 671 unicast GIDs supported per CA port is implementation 672 specific." 673 REFERENCE 674 "InfiniBand Architecture Release 1.0.a. Vol 1." 675 ::= { ibCaPortAttrInfo 9 } 677 ibCaPortGidTable OBJECT-TYPE 678 SYNTAX SEQUENCE OF IbCaPortGidEntry 679 MAX-ACCESS not-accessible 680 STATUS current 681 DESCRIPTION 682 "A table containing the CA port GIDs. The Global Identifier 683 (GID) is a 128-bit (16-byte) unicast or multicast identifier 684 used to identify a channel adapter port. A GID is a valid 685 128-bit IPv6 address (as defined in RFC 2373) with additional 686 IBA modifications that facilitate node discovery, routing, 687 and communications." 688 ::= { ibCaPortAttrInfo 10 } 690 ibCaPortGidEntry OBJECT-TYPE 691 SYNTAX IbCaPortGidEntry 692 MAX-ACCESS not-accessible 693 STATUS current 694 DESCRIPTION 695 "A conceptual row of the ibCaPortGidTable containing 696 information about a particular GID on a CA IB port." 697 INDEX { ibCaPortIndex, ibCaPortGidIndex } 698 ::= { ibCaPortGidTable 1 } 700 IbCaPortGidEntry ::= SEQUENCE { 701 ibCaPortIndex Integer32, 702 ibCaPortGidIndex Integer32, 703 ibCaPortGidValue OCTET STRING 704 } 706 ibCaPortIndex OBJECT-TYPE 707 SYNTAX Integer32(1..254) 708 MAX-ACCESS not-accessible 709 STATUS current 710 DESCRIPTION 711 "Index that identifies the InfiniBand data port. The IBA 712 defines a range of valid data ports from 1 to N, where 713 N can have a maximum value of 254 for an IBA switch." 714 ::= { ibCaPortGidEntry 1 } 716 ibCaPortGidIndex OBJECT-TYPE 717 SYNTAX Integer32 718 MAX-ACCESS not-accessible 719 STATUS current 720 DESCRIPTION 721 "Index that identifies the GID entry for this IB data port. 722 Each port on a CA is assigned at least 1 unicast GID. 723 Note, the value of ibCaPortGidIndex will never be greater 724 than the value of ibCaMaxGidsPerPort that defines the 725 upper value for this index." 726 ::= { ibCaPortGidEntry 2 } 728 ibCaPortGidValue OBJECT-TYPE 729 SYNTAX OCTET STRING (SIZE(16)) 730 MAX-ACCESS read-only 731 STATUS current 732 DESCRIPTION 733 "The Global Identifier (GID) is a 128-bit (16-byte) unicast 734 or multicast identifier used to identify a channel adapter 735 port. A GID is a valid 128-bit IPv6 address (as defined in 736 RFC 2373) with additional IBA modifications that facilitate 737 node discovery, routing, and communications." 738 REFERENCE 739 "InfiniBand Architecture Release 1.0.a. Vol 1. 740 Section 4.1.1 GID Usage and Properties." 741 ::= { ibCaPortGidEntry 3 } 743 --**************************************************************** 744 -- Module Conformance Statement 745 -- 746 -- DESCRIPTION: The module conformance statement includes the 747 -- compliance statements and the units of conformance 748 -- section. 749 --**************************************************************** 751 ibCaCompliances OBJECT IDENTIFIER ::= { ibCaConformance 1 } 753 ibCaGroups OBJECT IDENTIFIER ::= { ibCaConformance 2 } 755 --**************************************************************** 756 -- Compliance Statements 757 --**************************************************************** 759 ibCaBasicCompliance MODULE-COMPLIANCE 760 STATUS current 761 DESCRIPTION 762 "The basic CA implementation requirements for agents that 763 support the IPOIB CA MIB." 764 MODULE -- this module 765 MANDATORY-GROUPS { 766 ibCaGeneralGroup 767 } 768 ::= { ibCaCompliances 1 } 770 ibCaFullCompliance MODULE-COMPLIANCE 771 STATUS current 772 DESCRIPTION 773 "The complete node implementation requirements for agents that 774 support the full IPOIB CA MIB." 775 MODULE -- this module 776 MANDATORY-GROUPS { 777 ibCaGeneralGroup, 778 ibCaAttrGroup, 779 ibCaPortAttrGroup 780 } 781 ::= { ibCaCompliances 2 } 783 --**************************************************************** 784 -- Units Of Conformance 785 --**************************************************************** 787 ibCaGeneralGroup OBJECT-GROUP 788 OBJECTS { 789 ibCaType, 790 ibCaNodeGuid, 791 ibCaPortGuid, 792 ibCaNumPorts 793 } 794 STATUS current 795 DESCRIPTION 796 "The ibCaGeneralGroup defines the MIB objects that describe 797 the general characteritics of this Channel Adapter." 798 ::= { ibCaGroups 1 } 800 ibCaAttrGroup OBJECT-GROUP 801 OBJECTS { 802 ibCaHasReliableConnection, 803 ibCaHasUnreliableConnection, 804 ibCaHasReliableDatagram, 805 ibCaHasUnreliableDatagram, 806 ibCaSupportsAtomicOperations, 807 ibCaSupportsOtherOperations, 808 ibCaSupportsSolicitedEvents, 809 ibCaPathMtuSetSupport, 810 ibCaGenEndToEndFlowControl, 811 ibCaSupportsMulticast, 812 ibCaSupportsAutoPathMigration, 813 ibCaSupportsMemoryProtection, 814 ibCaSupportsLoopback, 815 ibCaHasSubnetManager 816 } 817 STATUS current 818 DESCRIPTION 819 "The ibCaAttrGroup defines the MIB objects that describe 820 more specific attributes about the Channel Adpater." 821 ::= { ibCaGroups 2 } 823 ibCaPortAttrGroup OBJECT-GROUP 824 OBJECTS { 825 ibCaHasCablePhyInterface, 826 ibCaHasFiberPhyInterface, 827 ibCaHasBackplanePhyInterface, 828 ibCaSupportsStaticRateControl, 829 ibCaInterpacketDelayValue, 830 ibCaSupportsMultipathing, 831 ibCaSupportsPKeyCheck, 832 ibCaValidatesInPktDlid, 833 ibCaMaxGidsPerPort, 834 ibCaPortGidValue 836 } 837 STATUS current 838 DESCRIPTION 839 "The ibCaPortAttrGroup defines the MIB objects that describe 840 attributes about the Channel Adpater ports." 841 ::= { ibCaGroups 3 } 843 END 845 6. Security Considerations 847 SNMPv1 by itself is not a secure environment. Even if the network 848 itself is secure (for example by using IPSec), even then, there is no 849 control as to who on the secure network is allowed to access and 850 GET/SET (read/change/create/delete) the objects in this MIB. 852 It is recommended that the implementers consider the security 853 features as provided by the SNMPv3 framework. Specifically, the use 854 of the User-based Security Model RFC 2574 [RFC2574] and the View- 855 based Access Control Model RFC 2575 [RFC2575] is recommended. 857 It is then a customer/user responsibility to ensure that the SNMP 858 entity giving access to an instance of this MIB, is properly 859 configured to give access to the objects only to those principals 860 (users) that have legitimate rights to indeed GET or SET 861 (change/create/delete) them. 863 7. Intellectual Property 865 The IETF takes no position regarding the validity or scope of any 866 intellectual property or other rights that might be claimed to 867 pertain to the implementation or use of the technology described 868 in this document or the extent to which any license under such 869 rights might or might not be available; neither does it 870 represent that it has made any effort to identify any such 871 rights. Information on the IETF's procedures with respect to 872 rights in standards-track and standards-related documentation 873 can be found in BCP-11. Copies of claims of rights made 874 available for publication and any assurances of licenses to be 875 made available, or the result of an attempt made to obtain a 876 general license or permission for the use of such proprietary 877 rights by implementors or users of this specification can be 878 obtained from the IETF Secretariat. 880 The IETF invites any interested party to bring to its attention 881 any copyrights, patents or patent applications, or other 882 proprietary rights which may cover technology that may be required 883 to practice this standard. Please address the information to the 884 IETF Executive Director. 886 8. References 888 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An 889 Architecture for Describing SNMP Management Frameworks", 890 RFC 2571, April 1999. 892 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 893 of Management Information for TCP/IP-based Internets", STD 894 16, RFC 1155, May 1990. 896 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 897 16, RFC 1212, March 1991. 899 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 900 the SNMP", RFC 1215, March 1991. 902 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 903 Rose, M. and S. Waldbusser, "Structure of Management 904 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 905 1999. 907 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 908 Rose, M. and S. Waldbusser, "Textual Conventions for 909 SMIv2", STD 58, RFC 2579, April 1999. 911 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 912 Rose, M. and S. Waldbusser, "Conformance Statements for 913 SMIv2", STD 58, RFC 2580, April 1999. 915 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple 916 Network Management Protocol", STD 15, RFC 1157, May 1990. 918 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 919 "Introduction to Community-based SNMPv2", RFC 1901, 920 January 1996. 922 [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 923 "Transport Mappings for Version 2 of the Simple Network 924 Management Protocol (SNMPv2)", RFC 1906, January 1996. 926 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, 927 "Message Processing and Dispatching for the Simple Network 928 Management Protocol (SNMP)", RFC 2572, April 1999. 930 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 931 (USM) for version 3 of the Simple Network Management 932 Protocol (SNMPv3)", RFC 2574, April 1999. 934 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 935 "Protocol Operations for Version 2 of the Simple Network 936 Management Protocol (SNMPv2)", RFC 1905, January 1996. 938 [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", 939 RFC 2573, April 1999. 941 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 942 Access Control Model (VACM) for the Simple Network 943 Management Protocol (SNMP)", RFC 2575, April 1999. 945 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 946 "Introduction to Version 3 of the Internet-standard 947 Network Management Framework", RFC 2570, April 1999. 949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 950 Requirement Levels", BCP 14, RFC 2119, March 1997. 952 [IBTAArch] Infiniband Trade Association, Infiniband(TM) 953 Architecture Specification Vol 1&2 Release 1.0a, 1999, 954 2000. 956 [IBTC] Harnedy, S., "Definitions of Textual Conventions and OBJECT- 957 IDENTITIES for IP Over InfiniBand (IPOVERIB) Management" 958 . November 2001. 960 9. Author's Addresses 962 Sean Harnedy 963 InfiniSwitch Corporation 964 134 Flanders Road Phone: 1-508-599-6388 965 Westborough, MA 01581 Email: sharnedy@infiniswitch.com 966 USA