idnits 2.17.1 draft-ietf-ipoib-channel-adapter-mib-01.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 631 has weird spacing: '... before compa...' == Line 878 has weird spacing: '... rights migh...' == Line 879 has weird spacing: '...that it has ...' == Line 881 has weird spacing: '...ack and stan...' == Line 882 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 (May 2002) is 8016 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 965, 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: November 2002 May 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 7. Security Considerations ..................................... 18 60 8. Intellectual Property ....................................... 18 61 9. References .................................................. 19 62 10. Author's Address ........................................... 20 64 1. Introduction 66 This document defines a MIB for InfiniBand Channel Adpaters (CA). 68 The Infiniband Architecture[IBTAArch] (IBA) is defined by the 69 Infiniband Trade Association. Infiniband is designed to provide low 70 latency, high bandwidth interconnect in a computing environment. This 71 document will define the objects related to managing a specific class 72 of InfiniBand nodes called Channel Adapters. 74 A Channel Adapter (CA) is the end-point for IBA packets that are sent 75 and received over the IBA switching fabric. There are two types of 76 CAs: Host Channel Adapters (HCA) and Target Channel Adapters (TCA). 77 Typically, HCAs are used by host processors and TCAs are used by I/O 78 adapters to connect to the IBA switch fabric. The HCA supports the 79 IBA Verbs layer as the transport layer interface, while the TCA often 80 uses its own implementation-specific interface to the transport layer. 82 2. The SNMP Management Framework 84 The SNMP Management Framework presently consists of five major 85 components: 87 o An overall architecture, described in RFC 2571[RFC2571]. 89 o Mechanisms for describing and naming objects and events for 90 the purpose of management. The first version of this 91 Structure of Management Information (SMI) is called SMIv1 92 and described in STD 16, RFC 1155[RFC1155], STD 16, RFC 1212 93 [RFC1212] and RFC 1215 [RFC1215]. The second version, 94 called SMIv2, is described in STD 58, RFC 2578[RFC2578], STD 95 58, RFC 2579[RFC2579], and STD 58, RFC 2580[RFC2580]. 97 o Message protocols for transferring management information. 98 The first version of the SNMP message protocol is called 99 SNMPv1 and described in STD 15, RFC 1157[RFC1157]. A second 100 version of the SNMP message protocol, which is not an 101 Internet standards track protocol, is called SNMPv2c and 102 described in RFC 1901[RFC1901] and RFC 1906[RFC1906]. The 103 third version of the message protocol is called SNMPv3 and 104 described in RFC 1906[RFC1906], RFC 2572[RFC2572] and RFC 105 2574[RFC2574]. 107 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 "200205101200Z" -- May 10, 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 "200205101200Z" 223 DESCRIPTION 224 "Updated IMPORTS section (-01)." 225 REVISION 226 "200203291200Z" 227 DESCRIPTION 228 "Initial IETF Draft Revision (-00)." 229 ::= { infinibandMIB 4 } 231 --**************************************************************** 232 -- Object Indentifiers for the IPOIB CA MIB 233 --**************************************************************** 235 ibCaObjects OBJECT IDENTIFIER ::= { ibCaMIB 1 } 236 ibCaNotifications OBJECT IDENTIFIER ::= { ibCaMIB 2 } 237 ibCaConformance OBJECT IDENTIFIER ::= { ibCaMIB 3 } 239 --**************************************************************** 240 -- General Channel Adapter Info Group 241 --**************************************************************** 243 ibCaGeneralInfo OBJECT IDENTIFIER ::= { ibCaObjects 1 } 245 --**************************************************************** 246 -- General Channel Adapter Info Group 247 -- 248 -- DESCRIPTION: This group contains scalar variables that describe 249 -- general information about the CA. 250 --**************************************************************** 251 ibCaType OBJECT-TYPE 252 SYNTAX INTEGER { 253 unknown(1), 254 hca(2), 255 tca(3) 256 } 257 MAX-ACCESS read-only 258 STATUS current 259 DESCRIPTION 260 "Type of Channel Adapter: either a Host Channel Adpater (HCA), 261 or a Target Channel Adapter (TCA). If the type of CA cannot 262 be determined, the unknown(1) value is returned." 263 REFERENCE 264 "InfiniBand Architecture Release 1.0.a. Vol 1. 265 Section 17.1." 266 ::= { ibCaGeneralInfo 1 } 268 ibCaNodeGuid OBJECT-TYPE 269 SYNTAX OCTET STRING (SIZE(8)) 270 MAX-ACCESS read-only 271 STATUS current 272 DESCRIPTION 273 "The GUID of this CA. All ports on the same node shall 274 report the same CA node GUID value. This provides a 275 means for uniquely identifing a CA node within a 276 subnet and helps to determine the co-location of 277 the ports." 278 REFERENCE 279 "InfiniBand Architecture Release 1.0.a. Vol 1. 280 Section 17.2.5." 281 ::= { ibCaGeneralInfo 2 } 283 ibCaPortGuid OBJECT-TYPE 284 SYNTAX OCTET STRING (SIZE(8)) 285 MAX-ACCESS read-only 286 STATUS current 287 DESCRIPTION 288 "The GUID of this CA port. All ports on the same node shall 289 report the same ibCaPortGuid value. This provides a 290 means for uniquely identifing a node within a 291 subnet and helps to determine the co-location of 292 the ports." 293 REFERENCE 294 "InfiniBand Architecture Release 1.0.a. Vol 1. 295 Section 17.2.5." 296 ::= { ibCaGeneralInfo 3 } 298 ibCaNumPorts OBJECT-TYPE 299 SYNTAX Integer32(1..254) 300 MAX-ACCESS read-only 301 STATUS current 302 DESCRIPTION 303 "Number of physical IB data ports on this Channel Adapter. Ports 304 are numbered starting from 1. If there is more than one port, 305 the ports are numbered sequentially." 306 REFERENCE 307 "InfiniBand Architecture Release 1.0.a. Vol 1. 308 Section 17.2.1.3; Table 254 Port Attributes & Functions." 309 ::= { ibCaGeneralInfo 4 } 311 --**************************************************************** 312 -- Channel Adapter Attributes Info Group 313 --**************************************************************** 315 ibCaAttrInfo OBJECT IDENTIFIER ::= { ibCaObjects 2 } 317 --**************************************************************** 318 -- Channel Adapter Attributes Info Group 319 -- 320 -- DESCRIPTION: This group contains scalar variables that describe 321 -- more specific attributes about the whole CA. 322 --**************************************************************** 324 ibCaHasReliableConnection OBJECT-TYPE 325 SYNTAX TruthValue 326 MAX-ACCESS read-only 327 STATUS current 328 DESCRIPTION 329 "Flag that indicates whether this CA supports 330 Reliable Connection (RC) transport service." 331 REFERENCE 332 "InfiniBand Architecture Release 1.0.a. Vol 1. 333 Section 17.2.2; Table 255 Channel Adapter Attributes." 334 ::= { ibCaAttrInfo 1 } 336 ibCaHasUnreliableConnection OBJECT-TYPE 337 SYNTAX TruthValue 338 MAX-ACCESS read-only 339 STATUS current 340 DESCRIPTION 341 "Flag that indicates whether this CA supports 342 Unreliable Connection (UC) transport service." 343 REFERENCE 344 "InfiniBand Architecture Release 1.0.a. Vol 1. 345 Section 17.2.2; Table 255 Channel Adapter Attributes." 346 ::= { ibCaAttrInfo 2 } 348 ibCaHasReliableDatagram OBJECT-TYPE 349 SYNTAX TruthValue 350 MAX-ACCESS read-only 351 STATUS current 352 DESCRIPTION 353 "Flag that indicates whether this CA supports 354 Reliable Datagram (RD) transport service." 355 REFERENCE 356 "InfiniBand Architecture Release 1.0.a. Vol 1. 357 Section 17.2.2; Table 255 Channel Adapter Attributes." 358 ::= { ibCaAttrInfo 3 } 360 ibCaHasUnreliableDatagram OBJECT-TYPE 361 SYNTAX TruthValue 362 MAX-ACCESS read-only 363 STATUS current 364 DESCRIPTION 365 "Flag that indicates whether this CA supports 366 Unreliable Datagram (UD) transport service." 367 REFERENCE 368 "InfiniBand Architecture Release 1.0.a. Vol 1. 369 Section 17.2.2; Table 255 Channel Adapter Attributes." 370 ::= { ibCaAttrInfo 4 } 372 ibCaSupportsAtomicOperations OBJECT-TYPE 373 SYNTAX TruthValue 374 MAX-ACCESS read-only 375 STATUS current 376 DESCRIPTION 377 "Flag that indicates whether this CA supports 378 atomic operations. An atomic operation is an operation 379 that is guaranteed to finish without having another 380 operation alter the results once the atomic operation 381 has been initiated." 382 REFERENCE 383 "InfiniBand Architecture Release 1.0.a. Vol 1. 384 Section 17.2.2; Table 255 Channel Adapter Attributes." 385 ::= { ibCaAttrInfo 5 } 387 ibCaSupportsOtherOperations OBJECT-TYPE 388 SYNTAX TruthValue 389 MAX-ACCESS read-only 390 STATUS current 391 DESCRIPTION 392 "Flag that indicates whether this CA supports 393 all of the other operations (excluding atomic operations) 394 defined for a particular supported transport service." 395 REFERENCE 396 "InfiniBand Architecture Release 1.0.a. Vol 1. 397 Section 17.2.2; Table 255 Channel Adapter Attributes." 398 ::= { ibCaAttrInfo 6 } 400 ibCaSupportsSolicitedEvents OBJECT-TYPE 401 SYNTAX TruthValue 402 MAX-ACCESS read-only 403 STATUS current 404 DESCRIPTION 405 "Flag that indicates whether this CA supports the 406 generation and reception of solicited events. A solicited 407 event is a feature by which a queue pair consumer on a 408 CA can cause an event to be generated at the destination 409 when its message is received." 410 REFERENCE 411 "InfiniBand Architecture Release 1.0.a. Vol 1. 412 Section 17.2.2; Table 255 Channel Adapter Attributes. 413 and Section 9.2.3 Solicited Event (SE) - 1 bit." 414 ::= { ibCaAttrInfo 7 } 416 ibCaPathMtuSetSupport OBJECT-TYPE 417 SYNTAX INTEGER { 418 mtu256(1), 419 mtu256And512(2), 420 mtu256And512And1024(3), 421 mtu256And512And1024And2048(4), 422 mtu256And512And1024And2048And4096(5) 423 } 424 MAX-ACCESS read-only 425 STATUS current 426 DESCRIPTION 427 "Set of MTU values (in bytes) supported by this CA for all 428 transport service classes. The Maximum Transfer Unit is the 429 largest size allowable for the packet payload." 430 REFERENCE 431 "InfiniBand Architecture Release 1.0.a. Vol 1. 432 Section 17.2.2; Table 255 Channel Adapter Attributes." 433 ::= { ibCaAttrInfo 8 } 435 ibCaGenEndToEndFlowControl OBJECT-TYPE 436 SYNTAX TruthValue 437 MAX-ACCESS read-only 438 STATUS current 439 DESCRIPTION 440 "Flag that indicates whether this CA supports 441 the generation of end-to-end flow control. End-to-end 442 flow control is a mechanism that prevents sending messages 443 when the destination does not have adequate receive buffers 444 to receive the message." 445 REFERENCE 446 "InfiniBand Architecture Release 1.0.a. Vol 1. 447 Section 17.2.2; Table 255 Channel Adapter Attributes." 448 ::= { ibCaAttrInfo 9 } 450 ibCaSupportsMulticast OBJECT-TYPE 451 SYNTAX TruthValue 452 MAX-ACCESS read-only 453 STATUS current 454 DESCRIPTION 455 "Flag that indicates whether this CA supports multicast 456 operations. Multicast is the ability to deliver a single 457 packet to multiple ports." 458 REFERENCE 459 "InfiniBand Architecture Release 1.0.a. Vol 1. 460 Section 17.2.2; Table 255 Channel Adapter Attributes." 461 ::= { ibCaAttrInfo 10 } 463 ibCaSupportsAutoPathMigration OBJECT-TYPE 464 SYNTAX TruthValue 465 MAX-ACCESS read-only 466 STATUS current 467 DESCRIPTION 468 "Flag that indicates whether this CA supports 469 automatic path migration. Automatic path migration 470 is the process by which a CA (on a per QP basis) 471 signals another CA to cause path migration to a 472 preset alternate path." 473 REFERENCE 474 "InfiniBand Architecture Release 1.0.a. Vol 1. 475 Section 17.2.2; Table 255 Channel Adapter Attributes." 476 ::= { ibCaAttrInfo 11 } 478 ibCaSupportsMemoryProtection OBJECT-TYPE 479 SYNTAX TruthValue 480 MAX-ACCESS read-only 481 STATUS current 482 DESCRIPTION 483 "Flag that indicates whether this CA supports InfiniBand 484 memory management protection mechanisms." 485 REFERENCE 486 "InfiniBand Architecture Release 1.0.a. Vol 1. 487 Section 17.2.2; Table 255 Channel Adapter Attributes 488 and Section 10.6 Memory Management." 489 ::= { ibCaAttrInfo 12 } 491 ibCaSupportsLoopback OBJECT-TYPE 492 SYNTAX TruthValue 493 MAX-ACCESS read-only 494 STATUS current 495 DESCRIPTION 496 "Flag that indicates whether this CA supports 497 loopback operations. Loopback support allows for the 498 sending and receiving of self-addressed packets that 499 do not go out on the wire. If this feature is supported, 500 self-addressed packets must work, even if no switch is 501 present." 502 REFERENCE 503 "InfiniBand Architecture Release 1.0.a. Vol 1. 504 Section 17.2.2; Table 255 Channel Adapter Attributes." 505 ::= { ibCaAttrInfo 13 } 507 ibCaHasSubnetManager OBJECT-TYPE 508 SYNTAX TruthValue 509 MAX-ACCESS read-only 510 STATUS current 511 DESCRIPTION 512 "Flag that indicates whether this CA supports 513 a Subnet Manager (SM) instance." 514 REFERENCE 515 "InfiniBand Architecture Release 1.0.a. Vol 1. 516 Section 17.2.5." 517 ::= { ibCaAttrInfo 14 } 519 --**************************************************************** 520 -- Channel Adapter Port Attributes and Functions Info Group 521 --**************************************************************** 523 ibCaPortAttrInfo OBJECT IDENTIFIER ::= { ibCaObjects 3 } 525 --**************************************************************** 526 -- Channel Adapter Port Attributes and Functions Info Group 527 -- 528 -- DESCRIPTION: This group contains information about the CA ports. 529 -- This includes the type of physical interfaces supported, other 530 -- port attributes, and a table containing the port GIDs. 531 --**************************************************************** 532 ibCaHasCablePhyInterface OBJECT-TYPE 533 SYNTAX TruthValue 534 MAX-ACCESS read-only 535 STATUS current 536 DESCRIPTION 537 "Flag that indicates whether this CA supports 538 a cable connector physical interface. This 539 physical attach point is defined for use with 540 copper cables." 541 REFERENCE 542 "InfiniBand Architecture Release 1.0.a. Vol 1. 543 Section 17.2.1.3 Port Attributes and Functions; 544 Vol 2. 3.1 Introduction (Physical Layer Overview)." 545 ::= { ibCaPortAttrInfo 1 } 547 ibCaHasFiberPhyInterface OBJECT-TYPE 548 SYNTAX TruthValue 549 MAX-ACCESS read-only 550 STATUS current 551 DESCRIPTION 552 "Flag that indicates whether this CA supports 553 a fiber connector physical interface. This 554 physical attach point is defined for use with 555 optical cables." 556 REFERENCE 557 "InfiniBand Architecture Release 1.0.a. Vol 1. 558 Section 17.2.1.3 Port Attributes and Functions; 559 Vol 2. 3.1 Introduction (Physical Layer Overview)." 560 ::= { ibCaPortAttrInfo 2 } 562 ibCaHasBackplanePhyInterface OBJECT-TYPE 563 SYNTAX TruthValue 564 MAX-ACCESS read-only 565 STATUS current 566 DESCRIPTION 567 "Flag that indicates whether this CA supports 568 a backplane connector physical interface. This 569 physical attach point is defined for accepting 570 a specified form factor that houses the 571 channel adapter." 572 REFERENCE 573 "InfiniBand Architecture Release 1.0.a. Vol 1. 574 Section 17.2.1.3 Port Attributes and Functions; 575 Vol 2. 3.1 Introduction (Physical Layer Overview)." 576 ::= { ibCaPortAttrInfo 3 } 578 ibCaSupportsStaticRateControl OBJECT-TYPE 579 SYNTAX TruthValue 580 MAX-ACCESS read-only 581 STATUS current 582 DESCRIPTION 583 "Flag that indicates whether this CA supports static 584 rate control. Static rate controls are required for 585 all IB ports that support a data rate over 2.5 Gbps." 586 REFERENCE 587 "InfiniBand Architecture Release 1.0.a. Vol 1. 588 Section 17.2.6 Static Rate Control." 589 ::= { ibCaPortAttrInfo 4 } 591 ibCaInterpacketDelayValue OBJECT-TYPE 592 SYNTAX INTEGER { 593 unknown(1), 594 zero(2), -- 100% 595 three(3), -- 25% 596 two(4), -- 33% 597 eleven(5) -- 8% 598 } 599 MAX-ACCESS read-only 600 STATUS current 601 DESCRIPTION 602 "Interpacket Delay Value (IPD) supported for CAs that have 603 static rate control (i.e., the ibCaSupportsStaticRateControl 604 object must have a value of true(1) for this object to 605 contain a valid value; Otherwise, unknown(1) is returned). 606 The IPD allows for the slowing of the packet rate for all 607 of the standard link rates. 609 An ibCaInterpacketDelayValue of zero(2) is required for all CAs 610 that support static rate control. An ibCaInterpacketDelayValue 611 of three(3) is required by CAs that support 1 GBs or higher 612 link rate. An ibCaInterpacketDelayValue of two(4) is required by 613 CAs that support 3 Gbps or higher link rates and, an 614 ibCaInterpacketDelayValue of eleven(5) is required by CAs that 615 also support 3 Gbps or higher link rates." 616 REFERENCE 617 "InfiniBand Architecture Release 1.0.a. Vol 1. 618 Section 17.2.6 Static Rate Control, and Table 256 619 Static Rate Control IPD Values." 620 ::= { ibCaPortAttrInfo 5 } 622 ibCaSupportsMultipathing OBJECT-TYPE 623 SYNTAX TruthValue 624 MAX-ACCESS read-only 625 STATUS current 626 DESCRIPTION 627 "Flag that indicates whether this CA supports multipathing. 628 The CA link layer port checks the unicast DLID in the 629 received packet for validity by masking the number of low 630 order bits indicated by the LID Mask Control field (LMC) 631 before comparing the DLID to its assigned LID if this 632 object is true(1)." 633 REFERENCE 634 "InfiniBand Architecture Release 1.0.a. Vol 1. 635 Section 7.2.1.3. and Table 254; Also, Section 7.11.1 636 Multipathing Requirements on End Node." 637 ::= { ibCaPortAttrInfo 6 } 639 ibCaSupportsPKeyCheck OBJECT-TYPE 640 SYNTAX TruthValue 641 MAX-ACCESS read-only 642 STATUS current 643 DESCRIPTION 644 "Flag that indicates whether this CA supports partition 645 key (P_Key) checking. If true(1), the CA port validates the 646 incoming packet's P_Key with the P_Key bound to the 647 destination QP." 648 REFERENCE 649 "InfiniBand Architecture Release 1.0.a. Vol 1. 650 Section 7.2.1.3. and Table 254." 651 ::= { ibCaPortAttrInfo 7 } 653 ibCaValidatesInPktDlid OBJECT-TYPE 654 SYNTAX TruthValue 655 MAX-ACCESS read-only 656 STATUS current 657 DESCRIPTION 658 "Flag that indicates whether this CA supports the validation 659 of incoming packet DLIDs, and if the GRH is present, the 660 DGID." 661 REFERENCE 662 "InfiniBand Architecture Release 1.0.a. Vol 1. 663 Section 7.2.1.3. and Table 254." 664 ::= { ibCaPortAttrInfo 8 } 666 ibCaMaxGidsPerPort OBJECT-TYPE 667 SYNTAX Integer32 668 MAX-ACCESS read-only 669 STATUS current 670 DESCRIPTION 671 "Maximum number of GIDs per port. The maximum number of 672 unicast GIDs supported per CA port is implementation 673 specific." 674 REFERENCE 675 "InfiniBand Architecture Release 1.0.a. Vol 1." 676 ::= { ibCaPortAttrInfo 9 } 678 ibCaPortGidTable OBJECT-TYPE 679 SYNTAX SEQUENCE OF IbCaPortGidEntry 680 MAX-ACCESS not-accessible 681 STATUS current 682 DESCRIPTION 683 "A table containing the CA port GIDs. The Global Identifier 684 (GID) is a 128-bit (16-byte) unicast or multicast identifier 685 used to identify a channel adapter port. A GID is a valid 686 128-bit IPv6 address (as defined in RFC 2373) with additional 687 IBA modifications that facilitate node discovery, routing, 688 and communications." 689 ::= { ibCaPortAttrInfo 10 } 691 ibCaPortGidEntry OBJECT-TYPE 692 SYNTAX IbCaPortGidEntry 693 MAX-ACCESS not-accessible 694 STATUS current 695 DESCRIPTION 696 "A conceptual row of the ibCaPortGidTable containing 697 information about a particular GID on a CA IB port." 698 INDEX { ibCaPortIndex, ibCaPortGidIndex } 699 ::= { ibCaPortGidTable 1 } 701 IbCaPortGidEntry ::= SEQUENCE { 702 ibCaPortIndex Integer32, 703 ibCaPortGidIndex Integer32, 704 ibCaPortGidValue OCTET STRING 705 } 707 ibCaPortIndex OBJECT-TYPE 708 SYNTAX Integer32(1..254) 709 MAX-ACCESS not-accessible 710 STATUS current 711 DESCRIPTION 712 "Index that identifies the InfiniBand data port. The IBA 713 defines a range of valid data ports from 1 to N, where 714 N can have a maximum value of 254 for an IBA switch." 715 ::= { ibCaPortGidEntry 1 } 717 ibCaPortGidIndex OBJECT-TYPE 718 SYNTAX Integer32(1..65535) 719 MAX-ACCESS not-accessible 720 STATUS current 721 DESCRIPTION 722 "Index that identifies the GID entry for this IB data port. 723 Each port on a CA is assigned at least 1 unicast GID. 724 Note, the value of ibCaPortGidIndex will never be greater 725 than the value of ibCaMaxGidsPerPort that defines the 726 upper value for this index." 727 ::= { ibCaPortGidEntry 2 } 729 ibCaPortGidValue OBJECT-TYPE 730 SYNTAX OCTET STRING (SIZE(16)) 731 MAX-ACCESS read-only 732 STATUS current 733 DESCRIPTION 734 "The Global Identifier (GID) is a 128-bit (16-byte) unicast 735 or multicast identifier used to identify a channel adapter 736 port. A GID is a valid 128-bit IPv6 address (as defined in 737 RFC 2373) with additional IBA modifications that facilitate 738 node discovery, routing, and communications." 739 REFERENCE 740 "InfiniBand Architecture Release 1.0.a. Vol 1. 741 Section 4.1.1 GID Usage and Properties." 742 ::= { ibCaPortGidEntry 3 } 744 --**************************************************************** 745 -- Module Conformance Statement 746 -- 747 -- DESCRIPTION: The module conformance statement includes the 748 -- compliance statements and the units of conformance 749 -- section. 750 --**************************************************************** 752 ibCaCompliances OBJECT IDENTIFIER ::= { ibCaConformance 1 } 754 ibCaGroups OBJECT IDENTIFIER ::= { ibCaConformance 2 } 756 --**************************************************************** 757 -- Compliance Statements 758 --**************************************************************** 760 ibCaBasicCompliance MODULE-COMPLIANCE 761 STATUS current 762 DESCRIPTION 763 "The basic CA implementation requirements for agents that 764 support the IPOIB CA MIB." 765 MODULE -- this module 766 MANDATORY-GROUPS { 767 ibCaGeneralGroup 768 } 769 ::= { ibCaCompliances 1 } 771 ibCaFullCompliance MODULE-COMPLIANCE 772 STATUS current 773 DESCRIPTION 774 "The complete node implementation requirements for agents that 775 support the full IPOIB CA MIB." 776 MODULE -- this module 777 MANDATORY-GROUPS { 778 ibCaGeneralGroup, 779 ibCaAttrGroup, 780 ibCaPortAttrGroup 781 } 782 ::= { ibCaCompliances 2 } 784 --**************************************************************** 785 -- Units Of Conformance 786 --**************************************************************** 788 ibCaGeneralGroup OBJECT-GROUP 789 OBJECTS { 790 ibCaType, 791 ibCaNodeGuid, 792 ibCaPortGuid, 793 ibCaNumPorts 794 } 795 STATUS current 796 DESCRIPTION 797 "The ibCaGeneralGroup defines the MIB objects that describe 798 the general characteritics of this Channel Adapter." 799 ::= { ibCaGroups 2 } 801 ibCaAttrGroup OBJECT-GROUP 802 OBJECTS { 803 ibCaHasReliableConnection, 804 ibCaHasUnreliableConnection, 805 ibCaHasReliableDatagram, 806 ibCaHasUnreliableDatagram, 807 ibCaSupportsAtomicOperations, 808 ibCaSupportsOtherOperations, 809 ibCaSupportsSolicitedEvents, 810 ibCaPathMtuSetSupport, 811 ibCaGenEndToEndFlowControl, 812 ibCaSupportsMulticast, 813 ibCaSupportsAutoPathMigration, 814 ibCaSupportsMemoryProtection, 815 ibCaSupportsLoopback, 816 ibCaHasSubnetManager 817 } 818 STATUS current 819 DESCRIPTION 820 "The ibCaAttrGroup defines the MIB objects that describe 821 more specific attributes about the Channel Adpater." 822 ::= { ibCaGroups 3 } 824 ibCaPortAttrGroup OBJECT-GROUP 825 OBJECTS { 826 ibCaHasCablePhyInterface, 827 ibCaHasFiberPhyInterface, 828 ibCaHasBackplanePhyInterface, 829 ibCaSupportsStaticRateControl, 830 ibCaInterpacketDelayValue, 831 ibCaSupportsMultipathing, 832 ibCaSupportsPKeyCheck, 833 ibCaValidatesInPktDlid, 834 ibCaMaxGidsPerPort, 835 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 4 } 843 END 845 6.0 Revision History 847 This section should be removed when this document is published as an 848 RFC. 850 6.1 Changes from 852 Fixed object definitions as needed. 854 7. Security Considerations 856 SNMPv1 by itself is not a secure environment. Even if the network 857 itself is secure (for example by using IPSec), even then, there is no 858 control as to who on the secure network is allowed to access and 859 GET/SET (read/change/create/delete) the objects in this MIB. 861 It is recommended that the implementers consider the security 862 features as provided by the SNMPv3 framework. Specifically, the use 863 of the User-based Security Model RFC 2574 [RFC2574] and the View- 864 based Access Control Model RFC 2575 [RFC2575] is recommended. 866 It is then a customer/user responsibility to ensure that the SNMP 867 entity giving access to an instance of this MIB, is properly 868 configured to give access to the objects only to those principals 869 (users) that have legitimate rights to indeed GET or SET 870 (change/create/delete) them. 872 8. Intellectual Property 874 The IETF takes no position regarding the validity or scope of any 875 intellectual property or other rights that might be claimed to 876 pertain to the implementation or use of the technology described 877 in this document or the extent to which any license under such 878 rights might or might not be available; neither does it 879 represent that it has made any effort to identify any such 880 rights. Information on the IETF's procedures with respect to 881 rights in standards-track and standards-related documentation 882 can be found in BCP-11. Copies of claims of rights made 883 available for publication and any assurances of licenses to be 884 made available, or the result of an attempt made to obtain a 885 general license or permission for the use of such proprietary 886 rights by implementors or users of this specification can be 887 obtained from the IETF Secretariat. 889 The IETF invites any interested party to bring to its attention 890 any copyrights, patents or patent applications, or other 891 proprietary rights which may cover technology that may be required 892 to practice this standard. Please address the information to the 893 IETF Executive Director. 895 9. References 897 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An 898 Architecture for Describing SNMP Management Frameworks", 899 RFC 2571, April 1999. 901 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 902 of Management Information for TCP/IP-based Internets", STD 903 16, RFC 1155, May 1990. 905 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 906 16, RFC 1212, March 1991. 908 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 909 the SNMP", RFC 1215, March 1991. 911 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 912 Rose, M. and S. Waldbusser, "Structure of Management 913 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 914 1999. 916 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 917 Rose, M. and S. Waldbusser, "Textual Conventions for 918 SMIv2", STD 58, RFC 2579, April 1999. 920 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 921 Rose, M. and S. Waldbusser, "Conformance Statements for 922 SMIv2", STD 58, RFC 2580, April 1999. 924 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple 925 Network Management Protocol", STD 15, RFC 1157, May 1990. 927 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 928 "Introduction to Community-based SNMPv2", RFC 1901, 929 January 1996. 931 [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 932 "Transport Mappings for Version 2 of the Simple Network 933 Management Protocol (SNMPv2)", RFC 1906, January 1996. 935 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, 936 "Message Processing and Dispatching for the Simple Network 937 Management Protocol (SNMP)", RFC 2572, April 1999. 939 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 940 (USM) for version 3 of the Simple Network Management 941 Protocol (SNMPv3)", RFC 2574, April 1999. 943 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 944 "Protocol Operations for Version 2 of the Simple Network 945 Management Protocol (SNMPv2)", RFC 1905, January 1996. 947 [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", 948 RFC 2573, April 1999. 950 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 951 Access Control Model (VACM) for the Simple Network 952 Management Protocol (SNMP)", RFC 2575, April 1999. 954 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 955 "Introduction to Version 3 of the Internet-standard 956 Network Management Framework", RFC 2570, April 1999. 958 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 959 Requirement Levels", BCP 14, RFC 2119, March 1997. 961 [IBTAArch] Infiniband Trade Association, Infiniband(TM) 962 Architecture Specification Vol 1&2 Release 1.0a, 1999, 963 2000. 965 [IBTC] Harnedy, S., "Definitions of Textual Conventions and OBJECT- 966 IDENTITIES for IP Over InfiniBand (IPOVERIB) Management" 967 . May 2002. 969 10. Author's Address 971 Sean Harnedy 972 InfiniSwitch Corporation 973 134 Flanders Road Phone: 1-508-599-6388 974 Westborough, MA 01581 Email: sharnedy@infiniswitch.com 975 USA