idnits 2.17.1 draft-ietf-ipoib-channel-adapter-mib-02.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 7 instances of too long lines in the document, the longest one being 4 characters 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 635 has weird spacing: '... before compa...' == Line 870 has weird spacing: '... rights migh...' == Line 871 has weird spacing: '...that it has ...' == Line 873 has weird spacing: '...ack and stan...' == Line 874 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 (June 2002) is 7986 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. -------------------------------------------------------------------------------- 1 Internet Draft Sean Harnedy 2 InfiniSwitch Corp. 3 Expiration Date: December 2002 June 2002 5 Definitions of Managed Objects for 6 Infiniband Channel Adapters (CA) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This memo defines a portion of the Management Information Base (MIB) 37 for use with network management protocols in the Internet community. 38 In particular, it defines objects for managing InfiniBand Channel 39 Adapters (CA). 41 Table of Contents 43 1. Introduction ................................................ 2 44 2. The SNMP Management Framework ............................... 2 45 3. Conventions used in this document ........................... 3 46 4. Structure of the MIB ........................................ 3 47 4.1. Overview .................................................. 3 48 4.2. Discussion of MIB Groups .................................. 3 49 4.3. The CA MIB Objects ........................................ 3 50 4.3.1. The General Channel Adapter Info Group .................. 4 51 4.3.2. The Channel Adapter Attributes Info Group ............... 4 52 4.3.3. The Channel Adapter Port Attributes and Functions Info Group 4 53 4.4. The CA Notifications Group ................................ 4 54 4.5. The CA Conformance Group .................................. 4 55 4.5.1. CA Compliance Groups .................................... 4 56 5. IPOIB CA MIB Definitions .................................... 4 57 6. Revision History ............................................ 18 58 6.1 Changes from . 18 59 6.2 Changes from . 18 60 7. Security Considerations ..................................... 18 61 8. Intellectual Property ....................................... 19 62 9. References .................................................. 19 63 10. Author's Address ........................................... 20 65 1. Introduction 67 This document defines a MIB for InfiniBand Channel Adpaters (CA). 69 The Infiniband Architecture[IBTAArch] (IBA) is defined by the 70 Infiniband Trade Association. Infiniband is designed to provide low 71 latency, high bandwidth interconnect in a computing environment. This 72 document will define the objects related to managing a specific class 73 of InfiniBand nodes called Channel Adapters. 75 A Channel Adapter (CA) is the end-point for IBA packets that are sent 76 and received over the IBA switching fabric. There are two types of 77 CAs: Host Channel Adapters (HCA) and Target Channel Adapters (TCA). 78 Typically, HCAs are used by host processors and TCAs are used by I/O 79 adapters to connect to the IBA switch fabric. The HCA supports the 80 IBA Verbs layer as the transport layer interface, while the TCA often 81 uses its own implementation-specific interface to the transport layer. 83 2. The SNMP Management Framework 85 The SNMP Management Framework presently consists of five major 86 components: 88 o An overall architecture, described in RFC 2571[RFC2571]. 90 o Mechanisms for describing and naming objects and events for 91 the purpose of management. The first version of this 92 Structure of Management Information (SMI) is called SMIv1 93 and described in STD 16, RFC 1155[RFC1155], STD 16, RFC 1212 94 [RFC1212] and RFC 1215 [RFC1215]. The second version, 95 called SMIv2, is described in STD 58, RFC 2578[RFC2578], STD 96 58, RFC 2579[RFC2579], and STD 58, RFC 2580[RFC2580]. 98 o Message protocols for transferring management information. 99 The first version of the SNMP message protocol is called 100 SNMPv1 and described in STD 15, RFC 1157[RFC1157]. A second 101 version of the SNMP message protocol, which is not an 102 Internet standards track protocol, is called SNMPv2c and 103 described in RFC 1901[RFC1901] and RFC 1906[RFC1906]. The 104 third version of the message protocol is called SNMPv3 and 105 described in RFC 1906[RFC1906], RFC 2572[RFC2572] and RFC 106 2574[RFC2574]. 108 o Protocol operations for accessing management information. 109 The first set of protocol operations and associated PDU 110 formats is described in STD 15, RFC 1157[RFC1157]. A second 111 set of protocol operations and associated PDU formats is 112 described in RFC 1905[RFC1905]. 114 o A set of fundamental applications described in RFC 115 2573[RFC2573] and the view-based access control mechanism 116 described in RFC 2575[RFC2575]. 118 A more detailed introduction to the current SNMP Management 119 Framework can be found in RFC 2570[RFC2570]. 121 Managed objects are accessed via a virtual information store, 122 termed the Management Information Base or MIB. Objects in the MIB 123 are defined using the mechanisms defined in the SMI. 125 This memo specifies a MIB module that is compliant to the SMIv2. 126 A MIB conforming to the SMIv1 can be produced through the 127 appropriate translations. The resulting translated MIB must be 128 semantically equivalent, except where objects or events are 129 omitted because no translation is possible (use of Counter64). 130 Some machine readable information in SMIv2 will be converted into 131 textual descriptions in SMIv1 during the translation process. 132 However, this loss of machine readable information is not 133 considered to change the semantics of the MIB. 135 3. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 138 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 RFC 2119 [RFC2119]. 142 4. Structure of the MIB 144 This section describes the structure of the IPOIB CA MIB. 146 4.1. Overview 148 The SNMP management of the CA involves the monitoring of key channel 149 adapter attributes. 151 4.2. Discussion of MIB Groups 153 The CA MIB is divided into two basic groups: MIB objects and the 154 conformance section. 156 4.3. The CA MIB Objects 158 The CA MIB objects correlate to the set of Channel Adapter attributes. 159 These attributes are organized into three major CA MIB groups. 160 These are: The General Channel Adpater Info Group, The Channel Adapter 161 Attributes Info Group, and the Channel Adpater Port Attributes and 162 Functions Info Group. 164 4.3.1. The General Channel Adapter Info Group 166 This group provides general information common to any InfiniBand 167 CA. This includes distinguishing between the HCA and the TCA, 168 displaying the node and port GUID, and showing the number of ports on 169 the CA. 171 4.3.2. The Channel Adapter Attributes Info Group 173 This group provides more specific information about the CA. This 174 includes various attribute flags, transport service support, and 175 other CA characteristics. 177 4.3.3. The Channel Adapter Port Attributes and Functions Info Group 179 This group provides information about the CA ports. This includes 180 the type of physical interfaces supported, other port attributes, 181 and a table containing the port GIDs. 183 4.4. The CA Notifications Group 185 The CA MIB currently does not define a Notifications Group. 187 4.5. The CA Conformance Group 189 The CA Conformance Group lists the possible compliances for various 190 types of InfiniBand nodes that contain channel adapters. Currently, 191 two types of compliance are defined: basic and full. The units of 192 conformance which define the constituent object groups are also 193 listed. 195 4.5.1. CA Compliance Groups 197 The Compliance Groups list acceptable MIB implementation requirements. 199 5. IPOIB CA MIB Definitions 201 IB-CA-MIB DEFINITIONS ::= BEGIN 203 IMPORTS 204 MODULE-IDENTITY, OBJECT-TYPE, 205 Counter32, NOTIFICATION-TYPE, Integer32 FROM SNMPv2-SMI 206 TruthValue, DisplayString FROM SNMPv2-TC 207 MODULE-COMPLIANCE, OBJECT-GROUP, 208 NOTIFICATION-GROUP FROM SNMPv2-CONF 209 infinibandMIB FROM IB-TC-MIB; 211 ibCaMIB MODULE-IDENTITY 212 LAST-UPDATED "200206231200Z" -- Jnue 23, 2002 213 ORGANIZATION "IETF IP Over IB Working Group 214 Email: ipoib@ietf.org" 215 CONTACT-INFO 216 "Sean Harnedy (sharnedy@infiniswitch.com) 217 InfiniSwitch Corporation" 218 DESCRIPTION 219 "This module contains managed object definitions for 220 the instrumentation for an InfiniBand Channel Adpater (CA)." 221 REVISION 222 "200206231200Z" 223 DESCRIPTION 224 "Removed ibCaSupportsPKeyCheck object; corrected ibCaPortGuid 225 DESCRIPTION (-02)." 226 REVISION 227 "200205101200Z" 228 DESCRIPTION 229 "Updated IMPORTS section (-01)." 230 REVISION 231 "200203291200Z" 232 DESCRIPTION 233 "Initial IETF Draft Revision (-00)." 234 ::= { infinibandMIB 4 } 236 --**************************************************************** 237 -- Object Indentifiers for the IPOIB CA MIB 238 --**************************************************************** 240 ibCaObjects OBJECT IDENTIFIER ::= { ibCaMIB 1 } 241 ibCaNotifications OBJECT IDENTIFIER ::= { ibCaMIB 2 } 242 ibCaConformance OBJECT IDENTIFIER ::= { ibCaMIB 3 } 244 --**************************************************************** 245 -- General Channel Adapter Info Group 246 --**************************************************************** 248 ibCaGeneralInfo OBJECT IDENTIFIER ::= { ibCaObjects 1 } 250 --**************************************************************** 251 -- General Channel Adapter Info Group 252 -- 253 -- DESCRIPTION: This group contains scalar variables that describe 254 -- general information about the CA. 255 --**************************************************************** 256 ibCaType OBJECT-TYPE 257 SYNTAX INTEGER { 258 unknown(1), 259 hca(2), 260 tca(3) 261 } 262 MAX-ACCESS read-only 263 STATUS current 264 DESCRIPTION 265 "Type of Channel Adapter: either a Host Channel Adpater (HCA), 266 or a Target Channel Adapter (TCA). If the type of CA cannot 267 be determined, the unknown(1) value is returned." 268 REFERENCE 269 "InfiniBand Architecture Release 1.0.a. Vol 1. 270 Section 17.1." 271 ::= { ibCaGeneralInfo 1 } 273 ibCaNodeGuid OBJECT-TYPE 274 SYNTAX OCTET STRING (SIZE(8)) 275 MAX-ACCESS read-only 276 STATUS current 277 DESCRIPTION 278 "The GUID of this CA. All ports on the same node shall 279 report the same CA node GUID value. This provides a 280 means for uniquely identifing a CA node within a 281 subnet and helps to determine the co-location of 282 the ports." 283 REFERENCE 284 "InfiniBand Architecture Release 1.0.a. Vol 1. 285 Section 17.2.5." 286 ::= { ibCaGeneralInfo 2 } 288 ibCaPortGuid OBJECT-TYPE 289 SYNTAX OCTET STRING (SIZE(8)) 290 MAX-ACCESS read-only 291 STATUS current 292 DESCRIPTION 293 "The GUID of this CA port. All ports on the same node shall 294 report a unique ibCaPortGuid value. This provides a means 295 for uniquely identifing a node within a subnet and helps 296 to determine the co-location of the ports." 297 REFERENCE 298 "InfiniBand Architecture Release 1.0.a. Vol 1. 299 Section 17.2.5." 300 ::= { ibCaGeneralInfo 3 } 302 ibCaNumPorts OBJECT-TYPE 303 SYNTAX Integer32(1..254) 304 MAX-ACCESS read-only 305 STATUS current 306 DESCRIPTION 307 "Number of physical IB data ports on this Channel Adapter. Ports 308 are numbered starting from 1. If there is more than one port, 309 the ports are numbered sequentially." 310 REFERENCE 311 "InfiniBand Architecture Release 1.0.a. Vol 1. 312 Section 17.2.1.3; Table 254 Port Attributes & Functions." 313 ::= { ibCaGeneralInfo 4 } 315 --**************************************************************** 316 -- Channel Adapter Attributes Info Group 317 --**************************************************************** 319 ibCaAttrInfo OBJECT IDENTIFIER ::= { ibCaObjects 2 } 321 --**************************************************************** 322 -- Channel Adapter Attributes Info Group 323 -- 324 -- DESCRIPTION: This group contains scalar variables that describe 325 -- more specific attributes about the whole CA. 326 --**************************************************************** 328 ibCaHasReliableConnection OBJECT-TYPE 329 SYNTAX TruthValue 330 MAX-ACCESS read-only 331 STATUS current 332 DESCRIPTION 333 "Flag that indicates whether this CA supports 334 Reliable Connection (RC) transport service." 335 REFERENCE 336 "InfiniBand Architecture Release 1.0.a. Vol 1. 337 Section 17.2.2; Table 255 Channel Adapter Attributes." 338 ::= { ibCaAttrInfo 1 } 340 ibCaHasUnreliableConnection OBJECT-TYPE 341 SYNTAX TruthValue 342 MAX-ACCESS read-only 343 STATUS current 344 DESCRIPTION 345 "Flag that indicates whether this CA supports 346 Unreliable Connection (UC) transport service." 347 REFERENCE 348 "InfiniBand Architecture Release 1.0.a. Vol 1. 349 Section 17.2.2; Table 255 Channel Adapter Attributes." 350 ::= { ibCaAttrInfo 2 } 352 ibCaHasReliableDatagram OBJECT-TYPE 353 SYNTAX TruthValue 354 MAX-ACCESS read-only 355 STATUS current 356 DESCRIPTION 357 "Flag that indicates whether this CA supports 358 Reliable Datagram (RD) transport service." 359 REFERENCE 360 "InfiniBand Architecture Release 1.0.a. Vol 1. 361 Section 17.2.2; Table 255 Channel Adapter Attributes." 362 ::= { ibCaAttrInfo 3 } 364 ibCaHasUnreliableDatagram OBJECT-TYPE 365 SYNTAX TruthValue 366 MAX-ACCESS read-only 367 STATUS current 368 DESCRIPTION 369 "Flag that indicates whether this CA supports 370 Unreliable Datagram (UD) transport service." 371 REFERENCE 372 "InfiniBand Architecture Release 1.0.a. Vol 1. 373 Section 17.2.2; Table 255 Channel Adapter Attributes." 374 ::= { ibCaAttrInfo 4 } 376 ibCaSupportsAtomicOperations OBJECT-TYPE 377 SYNTAX TruthValue 378 MAX-ACCESS read-only 379 STATUS current 380 DESCRIPTION 381 "Flag that indicates whether this CA supports 382 atomic operations. An atomic operation is an operation 383 that is guaranteed to finish without having another 384 operation alter the results once the atomic operation 385 has been initiated." 386 REFERENCE 387 "InfiniBand Architecture Release 1.0.a. Vol 1. 388 Section 17.2.2; Table 255 Channel Adapter Attributes." 389 ::= { ibCaAttrInfo 5 } 391 ibCaSupportsOtherOperations OBJECT-TYPE 392 SYNTAX TruthValue 393 MAX-ACCESS read-only 394 STATUS current 395 DESCRIPTION 396 "Flag that indicates whether this CA supports 397 all of the other operations (excluding atomic operations) 398 defined for a particular supported transport service." 399 REFERENCE 400 "InfiniBand Architecture Release 1.0.a. Vol 1. 401 Section 17.2.2; Table 255 Channel Adapter Attributes." 402 ::= { ibCaAttrInfo 6 } 404 ibCaSupportsSolicitedEvents OBJECT-TYPE 405 SYNTAX TruthValue 406 MAX-ACCESS read-only 407 STATUS current 408 DESCRIPTION 409 "Flag that indicates whether this CA supports the 410 generation and reception of solicited events. A solicited 411 event is a feature by which a queue pair consumer on a 412 CA can cause an event to be generated at the destination 413 when its message is received." 414 REFERENCE 415 "InfiniBand Architecture Release 1.0.a. Vol 1. 416 Section 17.2.2; Table 255 Channel Adapter Attributes. 417 and Section 9.2.3 Solicited Event (SE) - 1 bit." 418 ::= { ibCaAttrInfo 7 } 420 ibCaPathMtuSetSupport OBJECT-TYPE 421 SYNTAX INTEGER { 422 mtu256(1), 423 mtu256And512(2), 424 mtu256And512And1024(3), 425 mtu256And512And1024And2048(4), 426 mtu256And512And1024And2048And4096(5) 427 } 428 MAX-ACCESS read-only 429 STATUS current 430 DESCRIPTION 431 "Set of MTU values (in bytes) supported by this CA for all 432 transport service classes. The Maximum Transfer Unit is the 433 largest size allowable for the packet payload." 434 REFERENCE 435 "InfiniBand Architecture Release 1.0.a. Vol 1. 436 Section 17.2.2; Table 255 Channel Adapter Attributes." 437 ::= { ibCaAttrInfo 8 } 439 ibCaGenEndToEndFlowControl OBJECT-TYPE 440 SYNTAX TruthValue 441 MAX-ACCESS read-only 442 STATUS current 443 DESCRIPTION 444 "Flag that indicates whether this CA supports 445 the generation of end-to-end flow control. End-to-end 446 flow control is a mechanism that prevents sending messages 447 when the destination does not have adequate receive buffers 448 to receive the message." 449 REFERENCE 450 "InfiniBand Architecture Release 1.0.a. Vol 1. 451 Section 17.2.2; Table 255 Channel Adapter Attributes." 452 ::= { ibCaAttrInfo 9 } 454 ibCaSupportsMulticast OBJECT-TYPE 455 SYNTAX TruthValue 456 MAX-ACCESS read-only 457 STATUS current 458 DESCRIPTION 459 "Flag that indicates whether this CA supports multicast 460 operations. Multicast is the ability to deliver a single 461 packet to multiple ports." 462 REFERENCE 463 "InfiniBand Architecture Release 1.0.a. Vol 1. 464 Section 17.2.2; Table 255 Channel Adapter Attributes." 465 ::= { ibCaAttrInfo 10 } 467 ibCaSupportsAutoPathMigration OBJECT-TYPE 468 SYNTAX TruthValue 469 MAX-ACCESS read-only 470 STATUS current 471 DESCRIPTION 472 "Flag that indicates whether this CA supports 473 automatic path migration. Automatic path migration 474 is the process by which a CA (on a per QP basis) 475 signals another CA to cause path migration to a 476 preset alternate path." 477 REFERENCE 478 "InfiniBand Architecture Release 1.0.a. Vol 1. 479 Section 17.2.2; Table 255 Channel Adapter Attributes." 480 ::= { ibCaAttrInfo 11 } 482 ibCaSupportsMemoryProtection OBJECT-TYPE 483 SYNTAX TruthValue 484 MAX-ACCESS read-only 485 STATUS current 486 DESCRIPTION 487 "Flag that indicates whether this CA supports InfiniBand 488 memory management protection mechanisms." 489 REFERENCE 490 "InfiniBand Architecture Release 1.0.a. Vol 1. 491 Section 17.2.2; Table 255 Channel Adapter Attributes 492 and Section 10.6 Memory Management." 493 ::= { ibCaAttrInfo 12 } 495 ibCaSupportsLoopback OBJECT-TYPE 496 SYNTAX TruthValue 497 MAX-ACCESS read-only 498 STATUS current 499 DESCRIPTION 500 "Flag that indicates whether this CA supports 501 loopback operations. Loopback support allows for the 502 sending and receiving of self-addressed packets that 503 do not go out on the wire. If this feature is supported, 504 self-addressed packets must work, even if no switch is 505 present." 506 REFERENCE 507 "InfiniBand Architecture Release 1.0.a. Vol 1. 508 Section 17.2.2; Table 255 Channel Adapter Attributes." 509 ::= { ibCaAttrInfo 13 } 511 ibCaHasSubnetManager OBJECT-TYPE 512 SYNTAX TruthValue 513 MAX-ACCESS read-only 514 STATUS current 515 DESCRIPTION 516 "Flag that indicates whether this CA supports 517 a Subnet Manager (SM) instance." 518 REFERENCE 519 "InfiniBand Architecture Release 1.0.a. Vol 1. 520 Section 17.2.5." 521 ::= { ibCaAttrInfo 14 } 523 --**************************************************************** 524 -- Channel Adapter Port Attributes and Functions Info Group 525 --**************************************************************** 527 ibCaPortAttrInfo OBJECT IDENTIFIER ::= { ibCaObjects 3 } 529 --**************************************************************** 530 -- Channel Adapter Port Attributes and Functions Info Group 531 -- 532 -- DESCRIPTION: This group contains information about the CA ports. 533 -- This includes the type of physical interfaces supported, other 534 -- port attributes, and a table containing the port GIDs. 535 --**************************************************************** 536 ibCaHasCablePhyInterface OBJECT-TYPE 537 SYNTAX TruthValue 538 MAX-ACCESS read-only 539 STATUS current 540 DESCRIPTION 541 "Flag that indicates whether this CA supports 542 a cable connector physical interface. This 543 physical attach point is defined for use with 544 copper cables." 545 REFERENCE 546 "InfiniBand Architecture Release 1.0.a. Vol 1. 547 Section 17.2.1.3 Port Attributes and Functions; 548 Vol 2. 3.1 Introduction (Physical Layer Overview)." 549 ::= { ibCaPortAttrInfo 1 } 551 ibCaHasFiberPhyInterface OBJECT-TYPE 552 SYNTAX TruthValue 553 MAX-ACCESS read-only 554 STATUS current 555 DESCRIPTION 556 "Flag that indicates whether this CA supports 557 a fiber connector physical interface. This 558 physical attach point is defined for use with 559 optical cables." 560 REFERENCE 561 "InfiniBand Architecture Release 1.0.a. Vol 1. 562 Section 17.2.1.3 Port Attributes and Functions; 563 Vol 2. 3.1 Introduction (Physical Layer Overview)." 564 ::= { ibCaPortAttrInfo 2 } 566 ibCaHasBackplanePhyInterface OBJECT-TYPE 567 SYNTAX TruthValue 568 MAX-ACCESS read-only 569 STATUS current 570 DESCRIPTION 571 "Flag that indicates whether this CA supports 572 a backplane connector physical interface. This 573 physical attach point is defined for accepting 574 a specified form factor that houses the 575 channel adapter." 576 REFERENCE 577 "InfiniBand Architecture Release 1.0.a. Vol 1. 578 Section 17.2.1.3 Port Attributes and Functions; 579 Vol 2. 3.1 Introduction (Physical Layer Overview)." 580 ::= { ibCaPortAttrInfo 3 } 582 ibCaSupportsStaticRateControl OBJECT-TYPE 583 SYNTAX TruthValue 584 MAX-ACCESS read-only 585 STATUS current 586 DESCRIPTION 587 "Flag that indicates whether this CA supports static 588 rate control. Static rate controls are required for 589 all IB ports that support a data rate over 2.5 Gbps." 590 REFERENCE 591 "InfiniBand Architecture Release 1.0.a. Vol 1. 592 Section 17.2.6 Static Rate Control." 593 ::= { ibCaPortAttrInfo 4 } 595 ibCaInterpacketDelayValue OBJECT-TYPE 596 SYNTAX INTEGER { 597 unknown(1), 598 zero(2), -- 100% 599 three(3), -- 25% 600 two(4), -- 33% 601 eleven(5) -- 8% 602 } 603 MAX-ACCESS read-only 604 STATUS current 605 DESCRIPTION 606 "Interpacket Delay Value (IPD) supported for CAs that have 607 static rate control (i.e., the ibCaSupportsStaticRateControl 608 object must have a value of true(1) for this object to 609 contain a valid value; Otherwise, unknown(1) is returned). 610 The IPD allows for the slowing of the packet rate for all 611 of the standard link rates. 613 An ibCaInterpacketDelayValue of zero(2) is required for all CAs 614 that support static rate control. An ibCaInterpacketDelayValue 615 of three(3) is required by CAs that support 1 GBs or higher 616 link rate. An ibCaInterpacketDelayValue of two(4) is required by 617 CAs that support 3 Gbps or higher link rates and, an 618 ibCaInterpacketDelayValue of eleven(5) is required by CAs that 619 also support 3 Gbps or higher link rates." 620 REFERENCE 621 "InfiniBand Architecture Release 1.0.a. Vol 1. 622 Section 17.2.6 Static Rate Control, and Table 256 623 Static Rate Control IPD Values." 624 ::= { ibCaPortAttrInfo 5 } 626 ibCaSupportsMultipathing OBJECT-TYPE 627 SYNTAX TruthValue 628 MAX-ACCESS read-only 629 STATUS current 630 DESCRIPTION 631 "Flag that indicates whether this CA supports multipathing. 632 The CA link layer port checks the unicast DLID in the 633 received packet for validity by masking the number of low 634 order bits indicated by the LID Mask Control field (LMC) 635 before comparing the DLID to its assigned LID if this 636 object is true(1)." 637 REFERENCE 638 "InfiniBand Architecture Release 1.0.a. Vol 1. 639 Section 7.2.1.3. and Table 254; Also, Section 7.11.1 640 Multipathing Requirements on End Node." 641 ::= { ibCaPortAttrInfo 6 } 643 ibCaValidatesInPktDlid OBJECT-TYPE 644 SYNTAX TruthValue 645 MAX-ACCESS read-only 646 STATUS current 647 DESCRIPTION 648 "Flag that indicates whether this CA supports the validation 649 of incoming packet DLIDs, and if the GRH is present, the 650 DGID." 651 REFERENCE 652 "InfiniBand Architecture Release 1.0.a. Vol 1. 653 Section 7.2.1.3. and Table 254." 654 ::= { ibCaPortAttrInfo 7 } 656 ibCaMaxGidsPerPort OBJECT-TYPE 657 SYNTAX Integer32 658 MAX-ACCESS read-only 659 STATUS current 660 DESCRIPTION 661 "Maximum number of GIDs per port. The maximum number of 662 unicast GIDs supported per CA port is implementation specific." 663 REFERENCE 664 "InfiniBand Architecture Release 1.0.a. Vol 1." 665 ::= { ibCaPortAttrInfo 8 } 667 ibCaPortGidTable OBJECT-TYPE 668 SYNTAX SEQUENCE OF IbCaPortGidEntry 669 MAX-ACCESS not-accessible 670 STATUS current 671 DESCRIPTION 672 "A table containing the CA port GIDs. The Global Identifier 673 (GID) is a 128-bit (16-byte) unicast or multicast identifier 674 used to identify a channel adapter port. A GID is a valid 675 128-bit IPv6 address (as defined in RFC 2373) with additional 676 IBA modifications that facilitate node discovery, routing, 677 and communications." 678 ::= { ibCaPortAttrInfo 9 } 680 ibCaPortGidEntry OBJECT-TYPE 681 SYNTAX IbCaPortGidEntry 682 MAX-ACCESS not-accessible 683 STATUS current 684 DESCRIPTION 685 "A conceptual row of the ibCaPortGidTable containing 686 information about a particular GID on a CA IB port." 687 INDEX { ibCaPortIndex, ibCaPortGidIndex } 688 ::= { ibCaPortGidTable 1 } 690 IbCaPortGidEntry ::= SEQUENCE { 691 ibCaPortIndex Integer32, 692 ibCaPortGidIndex Integer32, 693 ibCaPortGidValue OCTET STRING 694 } 696 ibCaPortIndex OBJECT-TYPE 697 SYNTAX Integer32(1..254) 698 MAX-ACCESS not-accessible 699 STATUS current 700 DESCRIPTION 701 "Index that identifies the InfiniBand data port. The IBA 702 defines a range of valid data ports from 1 to N, where 703 N can have a maximum value of 254 for an IBA switch." 704 ::= { ibCaPortGidEntry 1 } 706 ibCaPortGidIndex OBJECT-TYPE 707 SYNTAX Integer32(1..65535) 708 MAX-ACCESS not-accessible 709 STATUS current 710 DESCRIPTION 711 "Index that identifies the GID entry for this IB data port. 712 Each port on a CA is assigned at least 1 unicast GID. 713 Note, the value of ibCaPortGidIndex will never be greater 714 than the value of ibCaMaxGidsPerPort that defines the 715 upper value for this index." 716 ::= { ibCaPortGidEntry 2 } 718 ibCaPortGidValue OBJECT-TYPE 719 SYNTAX OCTET STRING (SIZE(16)) 720 MAX-ACCESS read-only 721 STATUS current 722 DESCRIPTION 723 "The Global Identifier (GID) is a 128-bit (16-byte) unicast 724 or multicast identifier used to identify a channel adapter 725 port. A GID is a valid 128-bit IPv6 address (as defined in 726 RFC 2373) with additional IBA modifications that facilitate 727 node discovery, routing, and communications." 728 REFERENCE 729 "InfiniBand Architecture Release 1.0.a. Vol 1. 730 Section 4.1.1 GID Usage and Properties." 731 ::= { ibCaPortGidEntry 3 } 733 --**************************************************************** 734 -- Module Conformance Statement 735 -- 736 -- DESCRIPTION: The module conformance statement includes the 737 -- compliance statements and the units of conformance 738 -- section. 739 --**************************************************************** 741 ibCaCompliances OBJECT IDENTIFIER ::= { ibCaConformance 1 } 743 ibCaGroups OBJECT IDENTIFIER ::= { ibCaConformance 2 } 745 --**************************************************************** 746 -- Compliance Statements 747 --**************************************************************** 749 ibCaBasicCompliance MODULE-COMPLIANCE 750 STATUS current 751 DESCRIPTION 752 "The basic CA implementation requirements for agents that 753 support the IPOIB CA MIB." 754 MODULE -- this module 755 MANDATORY-GROUPS { 756 ibCaGeneralGroup 757 } 758 ::= { ibCaCompliances 1 } 760 ibCaFullCompliance MODULE-COMPLIANCE 761 STATUS current 762 DESCRIPTION 763 "The complete node implementation requirements for agents that 764 support the full IPOIB CA MIB." 765 MODULE -- this module 766 MANDATORY-GROUPS { 767 ibCaGeneralGroup, 768 ibCaAttrGroup, 769 ibCaPortAttrGroup 770 } 771 ::= { ibCaCompliances 2 } 773 --**************************************************************** 774 -- Units Of Conformance 775 --**************************************************************** 776 ibCaGeneralGroup OBJECT-GROUP 777 OBJECTS { 778 ibCaType, 779 ibCaNodeGuid, 780 ibCaPortGuid, 781 ibCaNumPorts 782 } 783 STATUS current 784 DESCRIPTION 785 "The ibCaGeneralGroup defines the MIB objects that describe 786 the general characteritics of this Channel Adapter." 787 ::= { ibCaGroups 2 } 789 ibCaAttrGroup OBJECT-GROUP 790 OBJECTS { 791 ibCaHasReliableConnection, 792 ibCaHasUnreliableConnection, 793 ibCaHasReliableDatagram, 794 ibCaHasUnreliableDatagram, 795 ibCaSupportsAtomicOperations, 796 ibCaSupportsOtherOperations, 797 ibCaSupportsSolicitedEvents, 798 ibCaPathMtuSetSupport, 799 ibCaGenEndToEndFlowControl, 800 ibCaSupportsMulticast, 801 ibCaSupportsAutoPathMigration, 802 ibCaSupportsMemoryProtection, 803 ibCaSupportsLoopback, 804 ibCaHasSubnetManager 805 } 806 STATUS current 807 DESCRIPTION 808 "The ibCaAttrGroup defines the MIB objects that describe 809 more specific attributes about the Channel Adpater." 810 ::= { ibCaGroups 3 } 812 ibCaPortAttrGroup OBJECT-GROUP 813 OBJECTS { 814 ibCaHasCablePhyInterface, 815 ibCaHasFiberPhyInterface, 816 ibCaHasBackplanePhyInterface, 817 ibCaSupportsStaticRateControl, 818 ibCaInterpacketDelayValue, 819 ibCaSupportsMultipathing, 820 ibCaValidatesInPktDlid, 821 ibCaMaxGidsPerPort, 822 ibCaPortGidValue 823 } 824 STATUS current 825 DESCRIPTION 826 "The ibCaPortAttrGroup defines the MIB objects that describe 827 attributes about the Channel Adpater ports." 828 ::= { ibCaGroups 4 } 830 END 832 6.0 Revision History 834 This section should be removed when this document is published as an 835 RFC. 837 6.1 Changes from 839 Fixed object definitions as needed. 841 6.2 Changes from 843 Deleted ibCaSupportsPKeyCheck object (CAs are required to enforce P_Key 844 per the InfiniBand spec). Fixed DESCRIPTION of ibCaPortGuid object. 846 7. Security Considerations 848 SNMPv1 by itself is not a secure environment. Even if the network 849 itself is secure (for example by using IPSec), even then, there is no 850 control as to who on the secure network is allowed to access and 851 GET/SET (read/change/create/delete) the objects in this MIB. 853 It is recommended that the implementers consider the security 854 features as provided by the SNMPv3 framework. Specifically, the use 855 of the User-based Security Model RFC 2574 [RFC2574] and the View- 856 based Access Control Model RFC 2575 [RFC2575] is recommended. 858 It is then a customer/user responsibility to ensure that the SNMP 859 entity giving access to an instance of this MIB, is properly 860 configured to give access to the objects only to those principals 861 (users) that have legitimate rights to indeed GET or SET 862 (change/create/delete) them. 864 8. Intellectual Property 866 The IETF takes no position regarding the validity or scope of any 867 intellectual property or other rights that might be claimed to 868 pertain to the implementation or use of the technology described 869 in this document or the extent to which any license under such 870 rights might or might not be available; neither does it 871 represent that it has made any effort to identify any such 872 rights. Information on the IETF's procedures with respect to 873 rights in standards-track and standards-related documentation 874 can be found in BCP-11. Copies of claims of rights made 875 available for publication and any assurances of licenses to be 876 made available, or the result of an attempt made to obtain a 877 general license or permission for the use of such proprietary 878 rights by implementors or users of this specification can be 879 obtained from the IETF Secretariat. 881 The IETF invites any interested party to bring to its attention 882 any copyrights, patents or patent applications, or other proprietary 883 rights which may cover technology that may be required to practice this 884 standard. Please address the information to the IETF Executive Director. 886 9. 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 . May 2002. 960 10. Author's Address 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