idnits 2.17.1 draft-ietf-ifmib-mib-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Abstract section. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 356: '...specific MIB MUST completely specify t...' RFC 2119 keyword, line 661: '...and packet counters MUST be used. For...' RFC 2119 keyword, line 663: '...ts/second, 32-bit packet counters MUST...' RFC 2119 keyword, line 664: '...t octet counters MUST be used. For in...' RFC 2119 keyword, line 666: '...ND 64-bit octet counters MUST be used....' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (26 November 1995) is 10379 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '1' is defined on line 2749, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 2755, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 2760, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2766, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2771, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1442 (ref. '1') (Obsoleted by RFC 1902) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '2') ** Obsolete normative reference: RFC 1448 (ref. '3') (Obsoleted by RFC 1905) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '5') ** Obsolete normative reference: RFC 1229 (ref. '7') (Obsoleted by RFC 1573) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft Interfaces Group MIB November 1995 4 The Interfaces Group MIB 6 26 November 1995 8 draft-ietf-ifmib-mib-01.txt 10 Keith McCloghrie 11 Cisco Systems 12 kzm@cisco.com 14 Frank J. Kastenholz 15 FTP Software 16 kasten@ftp.com 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as ``work 29 in progress.'' 31 To learn the current status of any Internet-Draft, please check 32 the ``1id-abstracts.txt'' listing contained in the Internet- 33 Drafts Shadow Directories on ds.internic.net (US East Coast), 34 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 35 munnari.oz.au (Pacific Rim). 37 Draft Interfaces Group MIB November 1995 39 1. Introduction 41 This memo defines an experimental portion of the Management 42 Information Base (MIB) for use with network management protocols 43 in the Internet community. In particular, it describes managed 44 objects used for managing Network Interfaces. 46 This memo discusses the 'interfaces' group of MIB-II, especially 47 the experience gained from the definition of numerous media- 48 specific MIB modules for use in conjunction with the 'interfaces' 49 group for managing various sub-layers beneath the internetwork- 50 layer. It specifies clarifications to, and extensions of, the 51 architectural issues within the previous model used for the 52 'interfaces' group. 54 This memo also includes a MIB module. As well as including new 55 MIB definitions to support the architectural extensions, this MIB 56 module also re-specifies the 'interfaces' group of MIB-II in a 57 manner which is both compliant to the SNMPv2 SMI and 58 semantically-identical to the existing SNMPv1-based definitions. 60 1.1. Change Log 62 This section tracks changes made to the revisions of the Internet 63 Drafts of this document. It will be deleted when the document is 64 published as an RFC. 66 26 November 1995 68 The following changes were made for the version of the document 69 dated 26 November 1995. These changes were made based on the 70 output of the working group's meeting at the Stockholm IETF 71 meeting. 73 (1) Added the ifAlias, ifStackLastChange and ifTableLastChange 74 objects. 76 (2) Defined new group definitions to contain the new objects, and 77 defined a new conformance definition. Deprecated the old 78 group and conformance definitions. 80 (3) Corrected the MAX-ACCESS clause values for 81 ifRcvAddressAddress, ifRcvAddressStatus and ifStackStatus. 83 Draft Interfaces Group MIB November 1995 85 (4) Deprecated the ifTestTable and ifTestGroup. 87 (5) Removed (to be defined elsewhere) the IANAifType-MIB MIB 88 Module. 90 (6) Re-arranged and combined the previous sections 3.1 and 3.2. 92 (7) Minor editorial changes. 94 Draft Interfaces Group MIB November 1995 96 2. The SNMPv2 Network Management Framework 98 The SNMPv2 Network Management Framework consists of four major 99 components. They are: 101 o RFC 1442 which defines the SMI, the mechanisms used for 102 describing and naming objects for the purpose of management. 104 o RFC 1213 defines MIB-II, the core set of managed objects for 105 the Internet suite of protocols. 107 o RFC ???? which defines the administrative and other 108 architectural aspects of the framework. 110 o RFC 1448 which defines the protocol used for network access 111 to managed objects. 113 The Framework permits new objects to be defined for the purpose of 114 experimentation and evaluation. 116 2.1. Object Definitions 118 Managed objects are accessed via a virtual information store, 119 termed the Management Information Base or MIB. Objects in the MIB 120 are defined using the subset of Abstract Syntax Notation One 121 (ASN.1) defined in the SMI. In particular, each object object 122 type is named by an OBJECT IDENTIFIER, an administratively 123 assigned name. The object type together with an object instance 124 serves to uniquely identify a specific instantiation of the 125 object. For human convenience, we often use a textual string, 126 termed the descriptor, to refer to the object type. 128 Draft Interfaces Group MIB November 1995 130 3. Experience with the Interfaces Group 132 One of the strengths of internetwork-layer protocols such as IP 133 [6] is that they are designed to run over any network interface. 134 In achieving this, IP considers any and all protocols it runs over 135 as a single "network interface" layer. A similar view is taken by 136 other internetwork-layer protocols. This concept is represented 137 in MIB-II by the 'interfaces' group which defines a generic set of 138 managed objects such that any network interface can be managed in 139 an interface-independent manner through these managed objects. 140 The 'interfaces' group provides the means for additional managed 141 objects specific to particular types of network interface (e.g., a 142 specific medium such as Ethernet) to be defined as extensions to 143 the 'interfaces' group for media-specific management. Since the 144 standardization of MIB-II, many such media-specific MIB modules 145 have been defined. 147 Experience in defining these media-specific MIB modules has shown 148 that the model defined by MIB-II is too simplistic and/or static 149 for some types of media-specific management. As a result, some of 150 these media-specific MIB modules assume an evolution or loosening 151 of the model. This memo documents and standardizes that evolution 152 of the model and fills in the gaps caused by that evolution. This 153 memo also incorporates the interfaces group extensions documented 154 in RFC 1229 [7]. 156 3.1. Clarifications/Revisions 158 There are several areas for which experience has indicated that 159 clarification, revision, or extension of the model would be 160 helpful. The following sections discuss the changes in the 161 interfaces group adopted by this memo in each of these areas. 163 In some sections, one or more paragraphs contain discussion of 164 rejected alternatives to the model adopted in this memo. Readers 165 not familiar with the MIB-II model and not interested in the 166 rationale behind the new model may want to skip these paragraphs. 168 3.1.1. Interface Sub-Layers 170 Experience in defining media-specific management information has 171 shown the need to distinguish between the multiple sub-layers 172 beneath the internetwork-layer. In addition, there is a need to 173 manage these sub-layers in devices (e.g., MAC-layer bridges) which 174 are unaware of which, if any, internetwork protocols run over 175 Draft Interfaces Group MIB November 1995 177 these sub-layers. As such, a model of having a single conceptual 178 row in the interfaces table (MIB-II's ifTable) represent a whole 179 interface underneath the internetwork-layer, and having a single 180 associated media-specific MIB module (referenced via the ifType 181 object) is too simplistic. A further problem arises with the 182 value of the ifType object which has enumerated values for each 183 type of interface. 185 Consider, for example, an interface with PPP running over an HDLC 186 link which uses a RS232-like connector. Each of these sub-layers 187 has its own media-specific MIB module. If all of this is 188 represented by a single conceptual row in the ifTable, then an 189 enumerated value for ifType is needed for that specific 190 combination which maps to the specific combination of media- 191 specific MIBs. Furthermore, such a model still lacks a method to 192 describe the relationship of all the sub-layers of the MIB stack. 194 An associated problem is that of upward and downward multiplexing 195 of the sub-layers. An example of upward multiplexing is MLP 196 (Multi-Link-Procedure) which provides load-sharing over several 197 serial lines by appearing as a single point-to-point link to the 198 sub-layer(s) above. An example of downward multiplexing would be 199 several instances of PPP, each framed within a separate X.25 200 virtual circuit, all of which run over one fractional T1 channel, 201 concurrently with other uses of the T1 link. The MIB structure 202 must allow these sorts of relationships to be described. 204 Several solutions for representing multiple sub-layers were 205 rejected. One was to retain the concept of one conceptual row for 206 all the sub-layers of an interface and have each media-specific 207 MIB module identify its "superior" and "subordinate" sub-layers 208 through OBJECT IDENTIFIER "pointers". This scheme would have 209 several drawbacks: the superior/subordinate pointers would be 210 contained in the media-specific MIB modules; thus, a manager could 211 not learn the structure of an interface without inspecting 212 multiple pointers in different MIB modules; this would be overly 213 complex and only possible if the manager had knowledge of all the 214 relevant media-specific MIB modules; MIB modules would all need to 215 be retrofitted with these new "pointers"; this scheme would not 216 adequately address the problem of upward and downward 217 multiplexing; and finally, enumerated values of ifType would be 218 needed for each combination of sub-layers. Another rejected 219 solution also retained the concept of one conceptual row for all 220 the sub-layers of an interface but had a new separate MIB table to 221 identify the "superior" and "subordinate" sub-layers and to 222 Draft Interfaces Group MIB November 1995 224 contain OBJECT IDENTIFIER "pointers" to the media-specific MIB 225 module for each sub-layer. Effectively, one conceptual row in the 226 ifTable would represent each combination of sub-layers between the 227 internetwork-layer and the wire. While this scheme has fewer 228 drawbacks, it still would not support downward multiplexing, such 229 as PPP over MLP: observe that MLP makes two (or more) serial lines 230 appear to the layers above as a single physical interface, and 231 thus PPP over MLP should appear to the internetwork-layer as a 232 single interface; in contrast, this scheme would result in two (or 233 more) conceptual rows in the ifTable, both of which the 234 internetwork-layer would run over. This scheme would also require 235 enumerated values of ifType for each combination of sub-layers. 237 The solution adopted by this memo is to have an individual 238 conceptual row in the ifTable to represent each sub-layer, and 239 have a new separate MIB table (the ifStackTable, see section 5 240 below) to identify the "superior" and "subordinate" sub-layers 241 through INTEGER "pointers" to the appropriate conceptual rows in 242 the ifTable. This solution supports both upward and downward 243 multiplexing, allows the IANAifType to Media-Specific MIB mapping 244 to identify the media-specific MIB module for that sub-layer, such 245 that the new table need only be referenced to obtain information 246 about layering, and it only requires enumerated values of ifType 247 for each sub-layer, not for combinations of them. However, it 248 does require that the descriptions of some objects in the ifTable 249 (specifically, ifType, ifPhysAddress, ifInUcastPkts, and 250 ifOutUcastPkts) be generalized so as to apply to any sub-layer 251 (rather than only to a sub-layer immediately beneath the network 252 layer as previously), plus some (specifically, ifSpeed) which need 253 to have appropriate values identified for use when a generalized 254 definition does not apply to a particular sub-layer. 256 In addition, this adopted solution makes no requirement that a 257 device, in which a sub-layer is instrumented by a conceptual row 258 of the ifTable, be aware of whether an internetwork protocol runs 259 on top of (i.e., at some layer above) that sub-layer. In fact, 260 the counters of packets received on an interface are defined as 261 counting the number "delivered to a higher-layer protocol". This 262 meaning of "higher-layer" includes: 264 (1) Delivery to a forwarding module which accepts 265 packets/frames/octets and forwards them on at the same 266 protocol layer. For example, for the purposes of this 267 definition, the forwarding module of a MAC-layer bridge is 268 considered as a "higher-layer" to the MAC-layer of each port 270 Draft Interfaces Group MIB November 1995 272 on the bridge. 274 (2) Delivery to a higher sub-layer within a interface stack. For 275 example, for the purposes of this definition, if a PPP module 276 operated directly over a serial interface, the PPP module 277 would be considered the higher sub-layer to the serial 278 interface. 280 (3) Delivery to a higher protocol layer which does not do packet 281 forwarding for sub-layers that are "at the top of" the 282 interface stack. For example, for the purposes of this 283 definition, the local IP module would be considered the 284 higher layer to a SLIP serial interface. 286 Similarly, for output, the counters of packets transmitted out an 287 interface are defined as counting the number "that higher-level 288 protocols requested to be transmitted". This meaning of "higher- 289 layer" includes: 291 (1) A forwarding module, at the same protocol layer, which 292 transmits packets/frames/octets that were received on an 293 different interface. For example, for the purposes of this 294 definition, the forwarding module of a MAC-layer bridge is 295 considered as a "higher-layer" to the MAC-layer of each port 296 on the bridge. 298 (2) The next higher sub-layer within an interface stack. For 299 example, for the purposes of this definition, if a PPP module 300 operated directly over a serial interface, the PPP module 301 would be a "higher layer" to the serial interface. 303 (3) For sub-layers that are "at the top of" the interface stack, 304 a higher element in the network protocol stack. For example, 305 for the purposes of this definition, the local IP module 306 would be considered the higher layer to an Ethernet 307 interface. 309 3.1.2. Guidance on Defining Sub-layers 311 The designer of a media-specific MIB must decide whether to divide 312 the interface into sub-layers or not, and if so, how to make the 313 divisions. The following guidance is offered to assist the 314 media-specific MIB designer in these decisions. 316 Draft Interfaces Group MIB November 1995 318 In general, the number of entries in the ifTable should be kept to 319 the minimum required for network management. In particular, a 320 group of related interfaces should be treated as a single 321 interface with one entry in the ifTable providing that: 323 (1) None of the group of interfaces performs multiplexing for any 324 other interface in the agent, 326 (2) There is a meaningful and useful way for all of the ifTable's 327 information (e.g., the counters, and the status variables), 328 and all of the ifTable's capabilities (e.g., write access to 329 ifAdminStatus), to apply to the group of interfaces as a 330 whole. 332 Under these circumstances, there should be one entry in the 333 ifTable for such a group of interfaces, and any internal structure 334 which needs to be represented to network management should be 335 captured in a MIB module specific to the particular type of 336 interface. 338 Note that application of bullet 2 above to the ifTable's ifType 339 object requires that there is a meaningful media-specific MIB and 340 a meaningful ifType value which apply to the group of interfaces 341 as a whole. For example, it is not appropriate to treat an HDLC 342 sub-layer and an RS-232 sub-layer as a single ifTable entry when 343 the media-specific MIBs and the ifType values for HDLC and RS-232 344 are separate (rather than combined). 346 Note that the sub-layers of an interface on one device will 347 sometimes be different to the sub-layers of the interconnected 348 interface of another device. A simple example of this is a 349 frame-relay DTE interface which connects to a frameRelayService 350 interface, where the DTE interface has a different ifType value 351 and media-specific MIB to the DCE interface. 353 These guidelines are just that, guidelines. The designer of a 354 media-specific MIB is free to lay out the MIB in whatever SMI 355 conformant manner is desired. However, in doing so, the media- 356 specific MIB MUST completely specify the sub-layering model used 357 for the MIB, and provide the assumptions, reasoning, and rationale 358 used to develop that model. 360 Draft Interfaces Group MIB November 1995 362 3.1.3. Virtual Circuits 364 Several of the sub-layers for which media-specific MIB modules 365 have been defined are connection oriented (e.g., Frame Relay, 366 X.25). Experience has shown that each effort to define such a MIB 367 module revisits the question of whether separate conceptual rows 368 in the ifTable are needed for each virtual circuit. Most, if not 369 all, of these efforts to date have decided to have all virtual 370 circuits reference a single conceptual row in the ifTable. 372 This memo strongly recommends that connection-oriented sub-layers 373 do not have a conceptual row in the ifTable for each virtual 374 circuit. This avoids the proliferation of conceptual rows, 375 especially those which have considerable redundant information. 376 (Note, as a comparison, that connection-less sub-layers do not 377 have conceptual rows for each remote address.) There may, 378 however, be circumstances under which it is appropriate for a 379 virtual circuit of a connection-oriented sub-layer to have its own 380 conceptual row in the ifTable; an example of this might be PPP 381 over an X.25 virtual circuit. The MIB in section 5 of this memo 382 supports such circumstances. 384 If a media-specific MIB wishes to assign an entry in the ifTable 385 to each virtual circuit, the MIB designer must present the 386 rationale for this decision in the media-specific MIB's 387 specification. 389 3.1.4. Bit, Character, and Fixed-Length Interfaces 391 RS-232 is an example of a character-oriented sub-layer over which 392 (e.g., through use of PPP) IP datagrams can be sent. Due to the 393 packet-based nature of many of the objects in the ifTable, 394 experience has shown that it is not appropriate to have a 395 character-oriented sub-layer represented by a whole conceptual row 396 in the ifTable. 398 Experience has also shown that it is sometimes desirable to have 399 some management information for bit-oriented interfaces, which are 400 similarly difficult to represent by a whole conceptual row in the 401 ifTable. For example, to manage the channels of a DS1 circuit, 402 where only some of the channels are carrying packet-based data. 404 A further complication is that some subnetwork technologies 405 transmit data in fixed length transmission units. One example of 406 such a technology is cell relay, and in particular Asynchronous 407 Draft Interfaces Group MIB November 1995 409 Transfer Mode (ATM), which transmits data in fixed-length cells. 410 Representing such a interface as a packet-based interface produces 411 redundant objects if the relationship between the number of 412 packets and the number of octets in either direction is fixed by 413 the size of the transmission unit (e.g., the size of a cell). 415 About half the objects in the ifTable are applicable to every type 416 of interface: packet-oriented, character-oriented, and bit- 417 oriented. Of the other half, two are applicable to both 418 character-oriented and packet-oriented interfaces, and the rest 419 are applicable only to packet-oriented interfaces. Thus, while it 420 is desirable for consistency to be able to represent any/all types 421 of interfaces in the ifTable, it is not possible to implement the 422 full ifTable for bit- and character-oriented sub-layers. 424 A rejected solution to this problem would be to split the ifTable 425 into two (or more) new MIB tables, one of which would contain 426 objects that are relevant only to packet-oriented interfaces 427 (e.g., PPP), and another that may be used by all interfaces. This 428 is highly undesirable since it would require changes in every 429 agent implementing the ifTable (i.e., just about every existing 430 SNMP agent). 432 The solution adopted in this memo builds upon the fact that 433 compliance statements in SNMPv2 (in contrast to SNMPv1) refer to 434 object groups, where object groups are explicitly defined by 435 listing the objects they contain. Thus, in SNMPv2, multiple 436 compliance statements can be specified, one for all interfaces and 437 additional ones for specific types of interfaces. The separate 438 compliance statements can be based on separate object groups, 439 where the object group for all interfaces can contain only those 440 objects from the ifTable which are appropriate for every type of 441 interfaces. Using this solution, every sub-layer can have its own 442 conceptual row in the ifTable. 444 Thus, section 5 of this memo contains definitions of the objects 445 of the existing 'interfaces' group of MIB-II, in a manner which is 446 both SNMPv2-compliant and semantically-equivalent to the existing 447 MIB-II definitions. With equivalent semantics, and with the BER 448 ("on the wire") encodings unchanged, these definitions retain the 449 same OBJECT IDENTIFIER values as assigned by MIB-II. Thus, in 450 general, no rewrite of existing agents which conform to MIB-II and 451 the ifExtensions MIB is required. 453 Draft Interfaces Group MIB November 1995 455 In addition, this memo defines several object groups for the 456 purposes of defining which objects apply to which types of 457 interface: 459 (1) the ifGeneralInformationGroup. This group contains those 460 objects applicable to all types of network interfaces, 461 including bit-oriented interfaces. 463 (2) the ifPacketGroup. This group contains those objects 464 applicable to packet-oriented network interfaces. 466 (3) the ifFixedLengthGroup. This group contains the objects 467 applicable not only to character-oriented interfaces, such as 468 RS-232, but also to those subnetwork technologies, such as 469 cell-relay/ATM, which transmit data in fixed length 470 transmission units. As well as the octet counters, there are 471 also a few other counters (e.g., the error counters) which 472 are useful for this type of interface, but are currently 473 defined as being packet-oriented. To accommodate this, the 474 definitions of these counters are generalized to apply to 475 character-oriented interfaces and fixed-length-transmission 476 interfaces. 478 It should be noted that the octet counters in the ifTable 479 aggregate octet counts for unicast and non-unicast packets into a 480 single octet counter per direction (received/transmitted). Thus, 481 with the above definition of fixed-length-transmission interfaces, 482 where such interfaces which support non-unicast packets, separate 483 counts of unicast and multicast/broadcast transmissions can only 484 be maintained in a media-specific MIB module. 486 3.1.5. Interface Numbering 488 MIB-II defines an object, ifNumber, whose value represents: 490 "The number of network interfaces (regardless of their 491 current state) present on this system." 493 Each interface is identified by a unique value of the ifIndex 494 object, and the description of ifIndex constrains its value as 495 follows: 497 "Its value ranges between 1 and the value of ifNumber. The 498 value for each interface must remain constant at least from 499 one re-initialization of the entity's network management 501 Draft Interfaces Group MIB November 1995 503 system to the next re-initialization." 505 This constancy requirement on the value of ifIndex for a 506 particular interface is vital for efficient management. However, 507 an increasing number of devices allow for the dynamic 508 addition/removal of network interfaces. One example of this is a 509 dynamic ability to configure the use of SLIP/PPP over a 510 character-oriented port. For such dynamic additions/removals, the 511 combination of the constancy requirement and the restriction that 512 the value of ifIndex is less than ifNumber is problematic. 514 Redefining ifNumber to be the largest value of ifIndex was 515 rejected since it would not help. Such a re-definition would 516 require ifNumber to be deprecated and the utility of the redefined 517 object would be questionable. Alternatively, ifNumber could be 518 deprecated and not replaced. However, the deprecation of ifNumber 519 would require a change to that portion of ifIndex's definition 520 which refers to ifNumber. So, since the definition of ifIndex 521 must be changed anyway in order to solve the problem, changes to 522 ifNumber do not benefit the solution. 524 The solution adopted in this memo is just to delete the 525 requirement that the value of ifIndex must be less than the value 526 of ifNumber, and to retain ifNumber with its current definition. 527 This is a minor change in the semantics of ifIndex; however, all 528 existing agent implementations conform to this new definition, and 529 in the interests of not requiring changes to existing agent 530 implementations and to the many existing media-specific MIBs, this 531 memo assumes that this change does not require ifIndex to be 532 deprecated. Experience indicates that this assumption does 533 "break" a few management applications, but this is considered 534 preferable to breaking all agent implementations. 536 This solution also results in the possibility of "holes" in the 537 ifTable, i.e., the ifIndex values of conceptual rows in the 538 ifTable are not necessarily contiguous, but SNMP's GetNext (and 539 SNMPv2's GetBulk) operation easily deals with such holes. The 540 value of ifNumber still represents the number of conceptual rows, 541 which increases/decreases as new interfaces are dynamically 542 added/removed. The vital constancy requirement is met by 543 requiring that after an interface is dynamically removed, its 544 ifIndex value is not re-used (by a different dynamically added 545 interface) until after the following re-initialization of the 546 network management system. This avoids the need for a priori 547 assignment of ifIndex values for all possible interfaces which 548 Draft Interfaces Group MIB November 1995 550 might be added dynamically. 552 The exact meaning of a "different" interface is hard to define, 553 and there will be gray areas. One important criterion is that a 554 management station, not noticing that an interface has gone away 555 and another come into existence, should not be confused when it 556 calculates the difference between the counter values retrieved on 557 successive polls for a particular ifIndex value. However, any 558 firm definition in this document would likely to turn out to be 559 inadequate. Instead, the following guidelines are offered to 560 allow implementors to choose what "different" means in their 561 particular situation. 563 A previously-unused value of ifIndex should be assigned to a 564 dynamically added interface if: 566 (1) an agent has no knowledge of whether the interface is the 567 "same" or "different" to a previously incarnated interface, 568 or 570 (2) an agent knows that the interface is the "same" as a 571 previously incarnated interface, but the assignment of the 572 previously-used ifIndex value to the interface could result 573 in a discontinuity in the values of ifTable counters for that 574 value of ifIndex. 576 Note that discontinuities in the values of ifTable counters 577 can be avoided if an implementation is able to retain the 578 counter values when an interface goes away and restore them 579 on the interface's re-appearance. 581 Note that ifIndex values may change to identify different 582 interfaces upon a re-initialization (e.g., a reboot) of the agent, 583 which can be detected by the value of sysUpTime being reset to 584 zero. Note also that for an agent which supports multiple 585 communities/contexts (e.g., a CNM agent which supports a different 586 subset of interfaces for different customers), there is no 587 required relationship between the ifIndex values which identify 588 interfaces in one community/context and those which identify 589 interfaces in another community/context. It is the agent's choice 590 as to whether the same or different ifIndex values identify the 591 same or different interfaces in different communities/contexts. 593 Because of the restriction of the value of ifIndex to be less than 594 ifNumber, interfaces have been numbered with small integer values. 596 Draft Interfaces Group MIB November 1995 598 This has led to the ability by humans to use the ifIndex values as 599 (somewhat) user-friendly names for network interfaces (e.g., 600 "interface number 3"). With the relaxation of the restriction on 601 the value of ifIndex, there is now the possibility that ifIndex 602 values could be assigned as very large numbers (e.g., memory 603 addresses). Such numbers would be much less user-friendly. 604 Therefore, this memo recommends that ifIndex values still be 605 assigned as (relatively) small integer values starting at 1, even 606 though the values in use at any one time are not necessarily 607 contiguous. (Note that this makes remembering which values have 608 been assigned easy for agents which dynamically add new 609 interfaces) 611 A new problem is introduced by representing each sub-layer as an 612 ifTable entry. Previously, there usually was a simple, direct, 613 mapping of interfaces to the physical ports on systems. This 614 mapping would be based on the ifIndex value. However, by having 615 an ifTable entry for each interface sub-layer, mapping from 616 interfaces to physical ports becomes increasingly problematic. 618 To address this issue, a new object, ifName, is added to the MIB. 619 This object contains the device's local name (e.g., the name used 620 at the device's local console) for the interface of which the 621 relevant entry in the ifTable is a component. For example, 622 consider a router having an interface composed of PPP running over 623 an RS-232 port. If the router uses the name "wan1" for the 624 (combined) interface, then the ifName objects for the 625 corresponding PPP and RS-232 entries in the ifTable would both 626 have the value "wan1". On the other hand, if the router uses the 627 name "wan1.1" for the PPP interface and "wan1.2" for the RS-232 628 port, then the ifName objects for the corresponding PPP and RS-232 629 entries in the ifTable would have the values "wan1.1" and 630 "wan1.2", respectively. 632 3.1.6. Counter Size 634 As the speed of network media increase, the minimum time in which 635 a 32 bit counter will wrap decreases. For example, a 10Mbs stream 636 of back-to-back, full-size packets causes ifInOctets to wrap in 637 just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 638 minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that 639 interfaces be polled frequently enough not to miss a counter wrap 640 is increasingly problematic. 642 Draft Interfaces Group MIB November 1995 644 A rejected solution to this problem was to scale the counters; for 645 example, ifInOctets could be changed to count received octets in, 646 e.g., 1024 byte blocks. While it would provide acceptable 647 functionality at high rates of the counted-events, at low rates it 648 suffers. If there is little traffic on an interface, there might 649 be a significant interval before enough of the counted-events 650 occur to cause the scaled counter to be incremented. Traffic 651 would then appear to be very bursty, leading to incorrect 652 conclusions of the network's performance. 654 Instead, this memo adopts expanded, 64 bit, counters. These 655 counters are provided in new "high capacity" groups. The old, 656 32-bit, counters have not been deprecated. The 64-bit counters 657 are to be used only when the 32-bit counters do not provide enough 658 capacity; that is, when the 32 bit counters could wrap too fast. 660 For interfaces that operate at 20,000,000 (20 million) bits per 661 second or less, 32-bit byte and packet counters MUST be used. For 662 interfaces that operate faster than 20,000,000 bits/second, and 663 slower than 650,000,000 bits/second, 32-bit packet counters MUST 664 be used and 64-bit octet counters MUST be used. For interfaces 665 that operate at 650,000,000 bits/second or faster, 64-bit packet 666 counters AND 64-bit octet counters MUST be used. 668 These speed thresholds were chosen as reasonable compromises based 669 on the following: 671 (1) The cost of maintaining 64-bit counters is relatively high, 672 so minimizing the number of agents which must support them is 673 desirable. Common interfaces (such as 10Mbs Ethernet) should 674 not require them. 676 (2) 64-bit counters are a new feature, introduced in SNMPv2. It 677 is reasonable to expect that support for them will be spotty 678 for the immediate future. Thus, we wish to limit them to as 679 few systems as possible. This, in effect, means that 64-bit 680 counters should be limited to higher speed interfaces. 681 Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are 682 fairly wide-spread so it seems reasonable to not require 64- 683 bit counters for these interfaces. 685 (3) The 32-bit octet counters will wrap in the following times, 686 for the following interfaces (when transmitting maximum-sized 687 packets back-to-back): 689 Draft Interfaces Group MIB November 1995 691 - 10Mbs Ethernet: 57 minutes, 693 - 16Mbs Token Ring: 36 minutes, 695 - a US T3 line (45 megabits): 12 minutes, 697 - FDDI: 5.7 minutes 699 (4) The 32-bit packet counters wrap in about 57 minutes when 64- 700 byte packets are transmitted back-to-back on a 650,000,000 701 bit/second link. 703 As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 704 bit octet counter to wrap in just under 5 years. Conversely, an 705 81,000,000 terabit/second link is required to cause a 64-bit 706 counter to wrap in 30 minutes. We believe that, while technology 707 rapidly marches forward, this link speed will not be achieved for 708 at least several years, leaving sufficient time to evaluate the 709 introduction of 96 bit counters. 711 When 64-bit counters are in use, the 32-bit counters MUST still be 712 available. They will report the low 32-bits of the associated 713 64-bit count (e.g., ifInOctets will report the least significant 714 32 bits of ifHCInOctets). This enhances inter-operability with 715 existing implementations at a very minimal cost to agents. 717 The new "high capacity" groups are: 719 (1) the ifHCFixedLengthGroup for character-oriented/fixed-length 720 interfaces, and the ifHCPacketGroup for packet-based 721 interfaces; both of these groups include 64 bit counters for 722 octets, and 724 (2) the ifVHCPacketGroup for packet-based interfaces; this group 725 includes 64 bit counters for octets and packets. 727 3.1.7. Interface Speed 729 Network speeds are increasing. The range of ifSpeed is limited to 730 reporting a maximum speed of (2**31)-1 bits/second, or 731 approximately 2.2Gbs. SONET defines an OC-48 interface, which is 732 defined at operating at 48 times 51 Mbs, which is a speed in 733 excess of 2.4Gbs. Thus, ifSpeed is insufficient for the future, 734 and this memo defines an additional object: ifHighSpeed. 736 Draft Interfaces Group MIB November 1995 738 The ifHighSpeed object reports the speed of the interface in 739 1,000,000 (1 million) bits/second units. Thus, the true speed of 740 the interface will be the value reported by this object, plus or 741 minus 500,000 bits/second. 743 Other alternatives considered (but rejected) were: 745 (1) Making the interface speed a 64-bit gauge. This was rejected 746 since the current SMI does not allow such a syntax. 748 Furthermore, even if 64-bit gauges were available, their use 749 would require additional complexity in agents due to an 750 increased requirement for 64-bit operations. 752 (2) We also considered making "high-32 bit" and "low-32-bit" 753 objects which, when combined, would be a 64-bit value. This 754 simply seemed overly complex for what we are trying to do. 756 Furthermore, a full 64-bits of precision does not seem 757 necessary. The value of ifHighSpeed will be the only report 758 of interface speed for interfaces that are faster than 759 4,294,967,295 bits per second. At this speed, the 760 granularity of ifHighSpeed will be 1,000,000 bits per second, 761 thus the error will be 1/4294, or about 0.02%. This seems 762 reasonable. 764 (3) Adding a "scale" object, which would define the units which 765 ifSpeed's value is. 767 This would require two additional objects; one for the 768 scaling object, and one to replace the current ifSpeed. This 769 later object is required since the semantics of ifSpeed would 770 be significantly altered, and manager stations which do not 771 understand the new semantics would be confused. 773 3.1.8. Multicast/Broadcast Counters 775 In MIB-II, the ifTable counters for multicast and broadcast 776 packets are combined as counters of non-unicast packets. In 777 contrast, the ifExtensions MIB [7] defined one set of counters for 778 multicast, and a separate set for broadcast packets. With the 779 separate counters, the original combined counters become 780 redundant. To avoid this redundancy, the non-unicast counters are 781 deprecated. 783 Draft Interfaces Group MIB November 1995 785 For the output broadcast and multicast counters defined in RFC 786 1229, their definitions varied slightly from the packet counters 787 in the ifTable, in that they did not count errors/discarded 788 packets. Thus, this memo defines new objects with better aligned 789 definitions. Counters with 64 bits of range are also needed, as 790 explained above. 792 3.1.9. Trap Enable 794 In the multi-layer interface model, each sub-layer for which there 795 is an entry in the ifTable can generate linkUp/Down Traps. Since 796 interface state changes would tend to propagate through the 797 interface (from top to bottom, or bottom to top), it is likely 798 that several traps would be generated for each linkUp/Down 799 occurrence. 801 It is desirable to provide a mechanism for manager stations to 802 control the generation of these traps. To this end, the 803 ifLinkUpDownTrapEnable object has been added. This object allows 804 managers to limit generation of traps to just the sub-layers of 805 interest. 807 The default setting should limit the number of traps generated to 808 one per interface per linkUp/Down event. Furthermore, it seems 809 that the state changes of most interest to network managers occur 810 at the lowest level of an interface stack. Therefore we specify 811 that by default, only the lowest sub-layer of the interface 812 generate traps. 814 3.1.10. Addition of New ifType values 816 Over time, there is the need to add new ifType enumerated values 817 for new interface types. If the syntax of ifType were defined in 818 the MIB in section 5, then a new version of this MIB would have to 819 be re-issued in order to define new values. In the past, re- 820 issuing of a MIB has occurred only after several years. 822 Therefore, the syntax of ifType is changed to be a textual 823 convention, such that the enumerated integer values are now 824 defined in the textual convention, IANAifType, defined in a 825 different document. This allows additional values to be 826 documented without having to re-issue a new version of this 827 document. The Internet Assigned Number Authority (IANA) is 828 responsible for the assignment of all Internet numbers, including 829 various SNMP-related numbers, and specifically, new ifType values. 831 Draft Interfaces Group MIB November 1995 833 3.1.11. InterfaceIndex Textual Convention 835 A new textual convention, InterfaceIndex, has been defined. This 836 textual convention "contains" all of the semantics of the ifIndex 837 object. This allows other mib modules to easily import the 838 semantics of ifIndex. 840 3.1.12. IfAdminStatus and IfOperStatus 842 A new state has been added to ifOperStatus: dormant. This state 843 indicates that the relevant interface is not actually in a 844 condition to pass packets (i.e. up) but is in a "pending" state, 845 waiting for some external event. For "on-demand" interfaces, this 846 new state identifies the situation where the interface is waiting 847 for events to place it in the up state. Examples of such events 848 might be: 850 (1) having packets to transmit before establishing a connection 851 to a remote system; 853 (2) having a remote system establish a connection to the 854 interface (e.g. dialing up to a slip-server). 856 The down state now has two meanings, depending on the value of 857 ifAdminStatus. 859 (1) if ifAdminStatus is not down and ifOperStatus is down then a 860 fault condition is presumed to exist on the interface. 862 (2) if ifAdminStatus is down, then ifOperStatus will normally 863 also be down, i.e., there is not (necessarily) a fault 864 condition on the interface. 866 Note that when ifAdminStatus transitions to down, ifOperStatus 867 will normally also transition to down. In this situation, it is 868 possible that ifOperStatus's transition will not occur 869 immediately, but rather after a small time lag to complete certain 870 operations before going "down"; for example, it might need to 871 finish transmitting a packet. If a manager station finds that 872 ifAdminStatus is down and ifOperStatus is not down for a 873 particular interface, the manager station should wait a short 874 while and check again. If the condition still exists, only then 875 should it raise an error indication. Naturally, it should also 876 ensure that ifLastChange has not changed during this interval. 878 Draft Interfaces Group MIB November 1995 880 Whenever an interface table entry is created (usually as a result 881 of system initialization), the relevant instance of ifAdminStatus 882 is set to down, and presumably ifOperStatus will also be down. 884 An interface may be enabled in two ways: either as a result of 885 explicit management action (i.e. setting ifAdminStatus to up) or 886 as a result of the managed system's initialization process. When 887 ifAdminStatus changes to the up state, the related ifOperStatus 888 should do one of the following: 890 (1) Change to the up state if and only if the interface is able 891 to send and receive packets. 893 (2) Change to the dormant state if and only if the interface is 894 found to be operable, but the interface is waiting for other, 895 external, events to occur before it can transmit or receive 896 packets. Presumably when the expected events occur, the 897 interface will then change to the up state. 899 (3) Remain in the down state if an error or other fault condition 900 is detected on the interface. 902 (4) Change to the unknown state if, for some reason, the state of 903 the interface can not be ascertained. 905 (5) Change to the testing state if some test(s) must be performed 906 on the interface. Presumably after completion of the test, 907 the interface's state will change to up, dormant, or down, as 908 appropriate. 910 3.1.13. Traps 912 The exact definition of when linkUp and linkDown traps are 913 generated has been changed to reflect the changes to ifAdminStatus 914 and ifOperStatus. 916 Operational experience indicates that management stations are most 917 concerned with an interface being in the down state and the fact 918 that this state may indicate a failure. Thus, it is most useful 919 to instrument transitions into/out of either the up state or the 920 down state. 922 Instrumenting transitions into or out of the up state was rejected 923 since it would have the drawback that a demand interface might 924 have many transitions between up and dormant, leading to many 925 Draft Interfaces Group MIB November 1995 927 linkUp traps and no linkDown traps. Furthermore, if a node's only 928 interface is the demand interface, then a transition to dormant 929 would entail generation of a linkDown trap, necessitating bringing 930 the link to the up state (and a linkUp trap)!! 932 On the other hand, instrumenting transitions into or out of the 933 down state has the advantages: 935 (1) A transition into the down state will occur when an error is 936 detected on an interface. Error conditions are presumably of 937 great interest to network managers. 939 (2) Departing the down state generally indicates that the 940 interface is going to either up or dormant, both of which are 941 considered "healthy" states. 943 Furthermore, it is believed that generating traps on transitions 944 into or out of the down state is generally consistent with current 945 usage and interpretation of these traps by manager stations. 947 Therefore, this memo defines that LinkUp and linkDown traps are 948 generated just after ifOperStatus leaves, or just before it 949 enters, the down state, respectively. 951 Note that this definition allows a node with only one interface to 952 transmit a linkDown trap before that interface goes down. (Of 953 course, when the interface is going down because of a failure 954 condition, the linkDown trap probably cannot be successfully 955 transmitted anyway.) 957 3.1.14. ifSpecific 959 The original definition of the OBJECT IDENTIFIER value of 960 ifSpecific was not sufficiently clear. As a result, different 961 implementors have used it differently, and confusion has resulted. 962 Some implementations have the value of ifSpecific be the OBJECT 963 IDENTIFIER that defines the media-specific MIB, i.e., the "foo" 964 of: 965 foo OBJECT IDENTIFIER ::= { transmission xxx } 967 while others have it be OBJECT IDENTIFIER of the specific table or 968 entry in the appropriate media-specific MIB (e.g. fooTable or 969 fooEntry), while still others have it be the OBJECT IDENTIFIER of 970 the index object of the table's row, including instance 971 identifier, (e.g., fooIfIndex.ifIndex). A definition based on the 972 Draft Interfaces Group MIB November 1995 974 latter would not be sufficient unless it also allowed for media- 975 specific MIBs which include several tables, where each table has 976 its own (different) indexing. 978 The only definition that can both be made explicit and can cover 979 all the useful situations is to have ifSpecific be the most 980 general value for the media-specific MIB module (the first example 981 given above). This effectively makes it redundant because it 982 contains no more information than is provided by ifType. Thus, 983 ifSpecific has been deprecated. 985 3.1.15. All Values Must be Known 987 There are a number of situations where an agent does not know the 988 value of one or more objects for a particular interface. In all 989 such circumstances, an agent MUST NOT instanciate an object with 990 an incorrect value; rather, it MUST respond with the appropriate 991 error/exception condition (e.g., noSuchInstance for SNMPv2). 993 One example is where an agent is unable to count the occurrences 994 defined by one (or more) of the ifTable counters. In this 995 circumstance, the agent MUST NOT instanciate the particular 996 counter with a value of, say, zero. To do so would be to provide 997 mis-information to a network management application reading the 998 zero value, and thereby assuming that there have been no 999 occurrences of the event (e.g., no input errors because ifInErrors 1000 is always zero). 1002 Sometimes the lack of knowledge of an object's value is temporary. 1003 For example, when the MTU of an interface is a configured value 1004 and a device dynamically learns the configured value through 1005 (after) exchanging messages over the interface (e.g., ATM LAN- 1006 Emulation [8]). In such a case, the value is not known until 1007 after the ifTable entry has already been created. In such a case, 1008 the ifTable entry should be created without an instance of the 1009 object whose value is unknown; later, when the value becomes 1010 known, the missing object can then be instanciated (e.g., the 1011 instance of ifMtu is only instanciated once the interface's MTU 1012 becomes known). 1014 As a result of this "known values" rule, management applications 1015 MUST be able to cope with the responses to retrieving the object 1016 instances within a conceptual row of the ifTable revealing that 1017 some of the row's columnar objects are missing/not available. 1019 Draft Interfaces Group MIB November 1995 1021 4. Media-Specific MIB Applicability 1023 The exact use and semantics of many objects in this MIB are open 1024 to some interpretation. This is a result of the generic nature of 1025 this MIB. It is not always possible to come up with specific, 1026 unambiguous, text that covers all cases and yet preserves the 1027 generic nature of the MIB. 1029 Therefore, it is incumbent upon a media-specific MIB designer to, 1030 wherever necessary, clarify the use of the objects in this MIB 1031 with respect to the media-specific MIB. 1033 Specific areas of clarification include 1035 Layering Model 1036 The media-specific MIB designer MUST completely and 1037 unambiguously specify the layering model used. Each 1038 individual sub-layer must be identified, as must the 1039 ifStackTable's portrayal of the relationship(s) between the 1040 sub-layers. 1042 Virtual Circuits 1043 The media-specific MIB designer MUST specify whether virtual 1044 circuits are assigned entries in the ifTable or not. If they 1045 are, compelling rationale must be presented. 1047 ifRcvAddressTable 1048 The media-specific MIB designer MUST specify the 1049 applicability of the ifRcvAddressTable. 1051 ifType 1052 For each of the ifType values to which the media-specific MIB 1053 applies, it must specify the mapping of ifType values to 1054 media-specific MIB module(s) and instances of MIB objects 1055 within those modules. 1057 However, wherever this interface MIB is specific in the semantics, 1058 DESCRIPTION, or applicability of objects, the media-specific MIB 1059 designer MUST NOT change said semantics, DESCRIPTION, or 1060 applicability. 1062 Draft Interfaces Group MIB November 1995 1064 5. Overview 1066 This MIB consists of 4 tables: 1068 ifTable 1069 This table is the ifTable from MIB-II. 1071 ifXTable 1072 This table contains objects that have been added to the 1073 Interface MIB as a result of the Interface Evolution effort, 1074 or replacements for objects of the original (MIB-II) ifTable 1075 that were deprecated because the semantics of said objects 1076 have significantly changed. This table also contains objects 1077 that were previously in the ifExtnsTable. 1079 ifStackTable 1080 This table contains objects that define the relationships 1081 among the sub-layers of an interface. 1083 ifRcvAddressTable 1084 This table contains objects that are used to define the 1085 media-level addresses which this interface will receive. 1086 This table is a generic table. The designers of media- 1087 specific MIBs must define exactly how this table applies to 1088 their specific MIB. 1090 Draft Interfaces Group MIB November 1995 1092 6. Interfaces Group Definitions 1094 IF-MIB DEFINITIONS ::= BEGIN 1096 IMPORTS 1097 MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, 1098 Integer32, TimeTicks, 1099 NOTIFICATION-TYPE FROM SNMPv2-SMI 1100 TEXTUAL-CONVENTION, DisplayString, 1101 PhysAddress, TruthValue, RowStatus, 1102 AutonomousType, TestAndIncr FROM SNMPv2-TC 1103 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 1104 snmpTraps FROM SNMPv2-MIB 1105 IANAifType FROM IANAifType-MIB 1106 mib-2, interfaces FROM RFC1213-MIB; 1108 ifMIB MODULE-IDENTITY 1109 LAST-UPDATED "9311082155Z" 1110 ORGANIZATION "IETF Interfaces MIB Working Group" 1111 CONTACT-INFO 1112 " Keith McCloghrie 1113 Cisco Systems, Inc. 1114 170 West Tasman Drive 1115 San Jose, CA 95134-1706 1116 US 1118 408-526-5260 1119 kzm@cisco.com" 1120 DESCRIPTION 1121 "The MIB module to describe generic objects for 1122 network interface sub-layers. This MIB is an updated 1123 version of MIB-II's ifTable, and incorporates the 1124 extensions defined in RFC 1229." 1125 REVISION "9511260000Z" 1126 DESCRIPTION 1127 "Second revision." 1128 REVISION "9311082155Z" 1129 DESCRIPTION 1130 "Initial revision, published as part of RFC 1573." 1131 ::= { mib-2 31 } 1133 ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 } 1134 Draft Interfaces Group MIB November 1995 1136 -- OwnerString has the same semantics as used in RFC 1271 1138 OwnerString ::= TEXTUAL-CONVENTION 1139 DISPLAY-HINT "255a" 1140 STATUS current 1141 DESCRIPTION 1142 "This data type is used to model an administratively 1143 assigned name of the owner of a resource. This 1144 information is taken from the NVT ASCII character set. 1145 It is suggested that this name contain one or more of 1146 the following: ASCII form of the manager station's 1147 transport address, management station name (e.g., 1148 domain name), network management personnel's name, 1149 location, or phone number. In some cases the agent 1150 itself will be the owner of an entry. In these cases, 1151 this string shall be set to a string starting with 1152 'agent'." 1153 SYNTAX OCTET STRING (SIZE(0..255)) 1155 -- InterfaceIndex contains the semantics of ifIndex and 1156 -- should be used for any objects defined on other mib 1157 -- modules that need these semantics. 1159 InterfaceIndex ::= TEXTUAL-CONVENTION 1160 DISPLAY-HINT "d" 1161 STATUS current 1162 DESCRIPTION 1163 "A unique value, greater than zero, for each interface 1164 or interface sub-layer in the managed system. It is 1165 recommended that values are assigned contiguously 1166 starting from 1. The value for each interface sub- 1167 layer must remain constant at least from one re- 1168 initialization of the entity's network management 1169 system to the next re-initialization." 1170 SYNTAX Integer32 1172 Draft Interfaces Group MIB November 1995 1174 ifNumber OBJECT-TYPE 1175 SYNTAX Integer32 1176 MAX-ACCESS read-only 1177 STATUS current 1178 DESCRIPTION 1179 "The number of network interfaces (regardless of their 1180 current state) present on this system." 1181 ::= { interfaces 1 } 1183 ifTableLastChange OBJECT-TYPE 1184 SYNTAX TimeTicks 1185 MAX-ACCESS read-only 1186 STATUS current 1187 DESCRIPTION 1188 "The value of sysUpTime at the time of the last 1189 creation or deletion of an entry in the ifTable. If 1190 the number of entries has been unchanged since the 1191 last re-initialization of the local network management 1192 subsystem, then this object contains a zero value." 1193 ::= { ifMIBObjects 5 } 1195 -- the Interfaces table 1197 -- The Interfaces table contains information on the entity's 1198 -- interfaces. Each sub-layer below the internetwork-layer 1199 -- of a network interface is considered to be an interface. 1201 ifTable OBJECT-TYPE 1202 SYNTAX SEQUENCE OF IfEntry 1203 MAX-ACCESS not-accessible 1204 STATUS current 1205 DESCRIPTION 1206 "A list of interface entries. The number of entries 1207 is given by the value of ifNumber." 1208 ::= { interfaces 2 } 1210 ifEntry OBJECT-TYPE 1211 SYNTAX IfEntry 1212 MAX-ACCESS not-accessible 1213 STATUS current 1214 DESCRIPTION 1215 "An entry containing management information applicable 1216 to a particular interface." 1217 INDEX { ifIndex } 1219 Draft Interfaces Group MIB November 1995 1221 ::= { ifTable 1 } 1223 IfEntry ::= 1224 SEQUENCE { 1225 ifIndex InterfaceIndex, 1226 ifDescr DisplayString, 1227 ifType IANAifType, 1228 ifMtu Integer32, 1229 ifSpeed Gauge32, 1230 ifPhysAddress PhysAddress, 1231 ifAdminStatus INTEGER, 1232 ifOperStatus INTEGER, 1233 ifLastChange TimeTicks, 1234 ifInOctets Counter32, 1235 ifInUcastPkts Counter32, 1236 ifInNUcastPkts Counter32, -- deprecated 1237 ifInDiscards Counter32, 1238 ifInErrors Counter32, 1239 ifInUnknownProtos Counter32, 1240 ifOutOctets Counter32, 1241 ifOutUcastPkts Counter32, 1242 ifOutNUcastPkts Counter32, -- deprecated 1243 ifOutDiscards Counter32, 1244 ifOutErrors Counter32, 1245 ifOutQLen Gauge32, -- deprecated 1246 ifSpecific OBJECT IDENTIFIER -- deprecated 1247 } 1249 ifIndex OBJECT-TYPE 1250 SYNTAX InterfaceIndex 1251 MAX-ACCESS read-only 1252 STATUS current 1253 DESCRIPTION 1254 "A unique value, greater than zero, for each 1255 interface. It is recommended that values are assigned 1256 contiguously starting from 1. The value for each 1257 interface sub-layer must remain constant at least from 1258 one re-initialization of the entity's network 1259 management system to the next re-initialization." 1260 ::= { ifEntry 1 } 1262 ifDescr OBJECT-TYPE 1263 SYNTAX DisplayString (SIZE (0..255)) 1264 MAX-ACCESS read-only 1266 Draft Interfaces Group MIB November 1995 1268 STATUS current 1269 DESCRIPTION 1270 "A textual string containing information about the 1271 interface. This string should include the name of the 1272 manufacturer, the product name and the version of the 1273 interface hardware/software." 1274 ::= { ifEntry 2 } 1276 ifType OBJECT-TYPE 1277 SYNTAX IANAifType 1278 MAX-ACCESS read-only 1279 STATUS current 1280 DESCRIPTION 1281 "The type of interface. Additional values for ifType 1282 are assigned by the Internet Assigned Numbers 1283 Authority (IANA), through updating the syntax of the 1284 IANAifType textual convention." 1285 ::= { ifEntry 3 } 1287 ifMtu OBJECT-TYPE 1288 SYNTAX Integer32 1289 MAX-ACCESS read-only 1290 STATUS current 1291 DESCRIPTION 1292 "The size of the largest packet which can be 1293 sent/received on the interface, specified in octets. 1294 For interfaces that are used for transmitting network 1295 datagrams, this is the size of the largest network 1296 datagram that can be sent on the interface." 1297 ::= { ifEntry 4 } 1299 ifSpeed OBJECT-TYPE 1300 SYNTAX Gauge32 1301 MAX-ACCESS read-only 1302 STATUS current 1303 DESCRIPTION 1304 "An estimate of the interface's current bandwidth in 1305 bits per second. For interfaces which do not vary in 1306 bandwidth or for those where no accurate estimation 1307 can be made, this object should contain the nominal 1308 bandwidth. If the bandwidth of the interface is 1309 greater than the maximum value reportable by this 1310 object then this object should report its maximum 1311 value (4,294,967,295) and ifHighSpeed must be used to 1312 report the interace's speed. For a sub-layer which 1314 Draft Interfaces Group MIB November 1995 1316 has no concept of bandwidth, this object should be 1317 zero." 1318 ::= { ifEntry 5 } 1320 ifPhysAddress OBJECT-TYPE 1321 SYNTAX PhysAddress 1322 MAX-ACCESS read-only 1323 STATUS current 1324 DESCRIPTION 1325 "The interface's address at its protocol sub-layer. 1326 For example, for an 802.x interface, this object 1327 normally contains a MAC address. The interface's 1328 media-specific MIB must define the bit and byte 1329 ordering and the format of the value of this object. 1330 For interfaces which do not have such an address 1331 (e.g., a serial line), this object should contain an 1332 octet string of zero length." 1333 ::= { ifEntry 6 } 1335 ifAdminStatus OBJECT-TYPE 1336 SYNTAX INTEGER { 1337 up(1), -- ready to pass packets 1338 down(2), 1339 testing(3) -- in some test mode 1340 } 1341 MAX-ACCESS read-write 1342 STATUS current 1343 DESCRIPTION 1344 "The desired state of the interface. The testing(3) 1345 state indicates that no operational packets can be 1346 passed. When a managed system initializes, all 1347 interfaces start with ifAdminStatus in the down(2) 1348 state. As a result of either explicit management 1349 action or per configuration information retained by 1350 the managed system, ifAdminStatus is then changed to 1351 either the up(1) or testing(3) states (or remains in 1352 the down(2) state)." 1353 ::= { ifEntry 7 } 1355 ifOperStatus OBJECT-TYPE 1356 SYNTAX INTEGER { 1357 up(1), -- ready to pass packets 1358 down(2), 1359 testing(3), -- in some test mode 1360 unknown(4), -- status can not be determined 1362 Draft Interfaces Group MIB November 1995 1364 -- for some reason. 1365 dormant(5) 1366 } 1367 MAX-ACCESS read-only 1368 STATUS current 1369 DESCRIPTION 1370 "The current operational state of the interface. The 1371 testing(3) state indicates that no operational packets 1372 can be passed. If ifAdminStatus is down(2) then 1373 ifOperStatus should be down(2). If ifAdminStatus is 1374 changed to up(1) then ifOperStatus should change to 1375 up(1) if the interface is ready to transmit and 1376 receive network traffic; it should change to 1377 dormant(5) if the interface is waiting for external 1378 actions (such as a serial line waiting for an incoming 1379 connection); it should remain in the down(2) state if 1380 and only if there is a fault that prevents if from 1381 going to the up(1) state." 1382 ::= { ifEntry 8 } 1384 ifLastChange OBJECT-TYPE 1385 SYNTAX TimeTicks 1386 MAX-ACCESS read-only 1387 STATUS current 1388 DESCRIPTION 1389 "The value of sysUpTime at the time the interface 1390 entered its current operational state. If the current 1391 state was entered prior to the last re-initialization 1392 of the local network management subsystem, then this 1393 object contains a zero value." 1394 ::= { ifEntry 9 } 1396 ifInOctets OBJECT-TYPE 1397 SYNTAX Counter32 1398 MAX-ACCESS read-only 1399 STATUS current 1400 DESCRIPTION 1401 "The total number of octets received on the interface, 1402 including framing characters." 1403 ::= { ifEntry 10 } 1405 ifInUcastPkts OBJECT-TYPE 1406 SYNTAX Counter32 1407 MAX-ACCESS read-only 1408 STATUS current 1410 Draft Interfaces Group MIB November 1995 1412 DESCRIPTION 1413 "The number of packets, delivered by this sub-layer to 1414 a higher (sub-)layer, which were not addressed to a 1415 multicast or broadcast address at this sub-layer." 1416 ::= { ifEntry 11 } 1418 ifInNUcastPkts OBJECT-TYPE 1419 SYNTAX Counter32 1420 MAX-ACCESS read-only 1421 STATUS deprecated 1422 DESCRIPTION 1423 "The number of packets, delivered by this sub-layer to 1424 a higher (sub-)layer, which were addressed to a 1425 multicast or broadcast address at this sub-layer. 1427 This object is deprecated in favour of 1428 ifInMulticastPkts and ifInBroadcastPkts." 1429 ::= { ifEntry 12 } 1431 ifInDiscards OBJECT-TYPE 1432 SYNTAX Counter32 1433 MAX-ACCESS read-only 1434 STATUS current 1435 DESCRIPTION 1436 "The number of inbound packets which were chosen to be 1437 discarded even though no errors had been detected to 1438 prevent their being deliverable to a higher-layer 1439 protocol. One possible reason for discarding such a 1440 packet could be to free up buffer space." 1441 ::= { ifEntry 13 } 1443 ifInErrors OBJECT-TYPE 1444 SYNTAX Counter32 1445 MAX-ACCESS read-only 1446 STATUS current 1447 DESCRIPTION 1448 "For packet-oriented interfaces, the number of inbound 1449 packets that contained errors preventing them from 1450 being deliverable to a higher-layer protocol. For 1451 character-oriented or fixed-length interfaces, the 1452 number of inbound transmission units that contained 1453 errors preventing them from being deliverable to a 1454 higher-layer protocol." 1455 ::= { ifEntry 14 } 1457 Draft Interfaces Group MIB November 1995 1459 ifInUnknownProtos OBJECT-TYPE 1460 SYNTAX Counter32 1461 MAX-ACCESS read-only 1462 STATUS current 1463 DESCRIPTION 1464 "For packet-oriented interfaces, the number of packets 1465 received via the interface which were discarded 1466 because of an unknown or unsupported protocol. For 1467 character-oriented or fixed-length interfaces which 1468 support protocol multiplexing the number of 1469 transmission units received via the interface which 1470 were discarded because of an unknown or unsupported 1471 protocol. For any interface which does not support 1472 protocol multiplexing, this counter will always be 0." 1473 ::= { ifEntry 15 } 1475 ifOutOctets OBJECT-TYPE 1476 SYNTAX Counter32 1477 MAX-ACCESS read-only 1478 STATUS current 1479 DESCRIPTION 1480 "The total number of octets transmitted out of the 1481 interface, including framing characters." 1482 ::= { ifEntry 16 } 1484 ifOutUcastPkts OBJECT-TYPE 1485 SYNTAX Counter32 1486 MAX-ACCESS read-only 1487 STATUS current 1488 DESCRIPTION 1489 "The total number of packets that higher-level 1490 protocols requested be transmitted, and which were not 1491 addressed to a multicast or broadcast address at this 1492 sub-layer, including those that were discarded or not 1493 sent." 1494 ::= { ifEntry 17 } 1496 ifOutNUcastPkts OBJECT-TYPE 1497 SYNTAX Counter32 1498 MAX-ACCESS read-only 1499 STATUS deprecated 1500 DESCRIPTION 1501 "The total number of packets that higher-level 1502 protocols requested be transmitted, and which were 1503 addressed to a multicast or broadcast address at this 1505 Draft Interfaces Group MIB November 1995 1507 sub-layer, including those that were discarded or not 1508 sent. 1510 This object is deprecated in favour of 1511 ifOutMulticastPkts and ifOutBroadcastPkts." 1512 ::= { ifEntry 18 } 1514 ifOutDiscards OBJECT-TYPE 1515 SYNTAX Counter32 1516 MAX-ACCESS read-only 1517 STATUS current 1518 DESCRIPTION 1519 "The number of outbound packets which were chosen to 1520 be discarded even though no errors had been detected 1521 to prevent their being transmitted. One possible 1522 reason for discarding such a packet could be to free 1523 up buffer space." 1524 ::= { ifEntry 19 } 1526 ifOutErrors OBJECT-TYPE 1527 SYNTAX Counter32 1528 MAX-ACCESS read-only 1529 STATUS current 1530 DESCRIPTION 1531 "For packet-oriented interfaces, the number of 1532 outbound packets that could not be transmitted because 1533 of errors. For character-oriented or fixed-length 1534 interfaces, the number of outbound transmission units 1535 that could not be transmitted because of errors." 1536 ::= { ifEntry 20 } 1538 ifOutQLen OBJECT-TYPE 1539 SYNTAX Gauge32 1540 MAX-ACCESS read-only 1541 STATUS deprecated 1542 DESCRIPTION 1543 "The length of the output packet queue (in packets)." 1544 ::= { ifEntry 21 } 1546 ifSpecific OBJECT-TYPE 1547 SYNTAX OBJECT IDENTIFIER 1548 MAX-ACCESS read-only 1549 STATUS deprecated 1550 DESCRIPTION 1551 "A reference to MIB definitions specific to the 1553 Draft Interfaces Group MIB November 1995 1555 particular media being used to realize the interface. 1556 It is recommended that this value point to an instance 1557 of a MIB object in the media-specific MIB, i.e., that 1558 this object have the semantics associated with the 1559 InstancePointer textual convention defined in RFC 1560 1443. In fact, it is recommended that the media- 1561 specific MIB specify what value ifSpecific should/can 1562 take for values of ifType. If no MIB definitions 1563 specific to the particular media are available, the 1564 value should be set to the OBJECT IDENTIFIER { 0 0 }." 1565 ::= { ifEntry 22 } 1567 -- 1568 -- Extension to the interface table 1569 -- 1570 -- This table replaces the ifExtnsTable table. 1571 -- 1573 ifXTable OBJECT-TYPE 1574 SYNTAX SEQUENCE OF IfXEntry 1575 MAX-ACCESS not-accessible 1576 STATUS current 1577 DESCRIPTION 1578 "A list of interface entries. The number of entries 1579 is given by the value of ifNumber. This table 1580 contains additional objects for the interface table." 1581 ::= { ifMIBObjects 1 } 1583 ifXEntry OBJECT-TYPE 1584 SYNTAX IfXEntry 1585 MAX-ACCESS not-accessible 1586 STATUS current 1587 DESCRIPTION 1588 "An entry containing additional management information 1589 applicable to a particular interface." 1590 AUGMENTS { ifEntry } 1591 ::= { ifXTable 1 } 1593 IfXEntry ::= 1594 SEQUENCE { 1595 ifName DisplayString, 1596 ifInMulticastPkts Counter32, 1597 ifInBroadcastPkts Counter32, 1599 Draft Interfaces Group MIB November 1995 1601 ifOutMulticastPkts Counter32, 1602 ifOutBroadcastPkts Counter32, 1603 ifHCInOctets Counter64, 1604 ifHCInUcastPkts Counter64, 1605 ifHCInMulticastPkts Counter64, 1606 ifHCInBroadcastPkts Counter64, 1607 ifHCOutOctets Counter64, 1608 ifHCOutUcastPkts Counter64, 1609 ifHCOutMulticastPkts Counter64, 1610 ifHCOutBroadcastPkts Counter64, 1611 ifLinkUpDownTrapEnable INTEGER, 1612 ifHighSpeed Gauge32, 1613 ifPromiscuousMode TruthValue, 1614 ifConnectorPresent TruthValue, 1615 ifAlias DisplayString 1616 } 1618 ifName OBJECT-TYPE 1619 SYNTAX DisplayString 1620 MAX-ACCESS read-only 1621 STATUS current 1622 DESCRIPTION 1623 "The textual name of the interface. The value of this 1624 object should be the name of the interface as assigned 1625 by the local device and should be suitable for use in 1626 commands entered at the device's `console'. This 1627 might be a text name, such as `le0' or a simple port 1628 number, such as `1', depending on the interface naming 1629 syntax of the device. If several entries in the 1630 ifTable together represent a single interface as named 1631 by the device, then each will have the same value of 1632 ifName. If there is no local name, or this object is 1633 otherwise not applicable, then this object contains a 1634 zero-length string." 1635 ::= { ifXEntry 1 } 1637 ifInMulticastPkts OBJECT-TYPE 1638 SYNTAX Counter32 1639 MAX-ACCESS read-only 1640 STATUS current 1641 DESCRIPTION 1642 "The number of packets, delivered by this sub-layer to 1643 a higher (sub-)layer, which were addressed to a 1644 multicast address at this sub-layer. For a MAC layer 1646 Draft Interfaces Group MIB November 1995 1648 protocol, this includes both Group and Functional 1649 addresses." 1650 ::= { ifXEntry 2 } 1652 ifInBroadcastPkts OBJECT-TYPE 1653 SYNTAX Counter32 1654 MAX-ACCESS read-only 1655 STATUS current 1656 DESCRIPTION 1657 "The number of packets, delivered by this sub-layer to 1658 a higher (sub-)layer, which were addressed to a 1659 broadcast address at this sub-layer." 1660 ::= { ifXEntry 3 } 1662 ifOutMulticastPkts OBJECT-TYPE 1663 SYNTAX Counter32 1664 MAX-ACCESS read-only 1665 STATUS current 1666 DESCRIPTION 1667 "The total number of packets that higher-level 1668 protocols requested be transmitted, and which were 1669 addressed to a multicast address at this sub-layer, 1670 including those that were discarded or not sent. For 1671 a MAC layer protocol, this includes both Group and 1672 Functional addresses." 1673 ::= { ifXEntry 4 } 1675 ifOutBroadcastPkts OBJECT-TYPE 1676 SYNTAX Counter32 1677 MAX-ACCESS read-only 1678 STATUS current 1679 DESCRIPTION 1680 "The total number of packets that higher-level 1681 protocols requested be transmitted, and which were 1682 addressed to a broadcast address at this sub-layer, 1683 including those that were discarded or not sent." 1684 ::= { ifXEntry 5 } 1686 -- 1687 -- High Capacity Counter objects. These objects are all 1688 -- 64 bit versions of the "basic" ifTable counters. These 1689 -- objects all have the same basic semantics as their 32-bit 1690 -- counterparts, however, their syntax has been extended 1691 -- to 64 bits. 1692 -- 1693 Draft Interfaces Group MIB November 1995 1695 ifHCInOctets OBJECT-TYPE 1696 SYNTAX Counter64 1697 MAX-ACCESS read-only 1698 STATUS current 1699 DESCRIPTION 1700 "The total number of octets received on the interface, 1701 including framing characters. This object is a 64-bit 1702 version of ifInOctets." 1703 ::= { ifXEntry 6 } 1705 ifHCInUcastPkts OBJECT-TYPE 1706 SYNTAX Counter64 1707 MAX-ACCESS read-only 1708 STATUS current 1709 DESCRIPTION 1710 "The number of packets, delivered by this sub-layer to 1711 a higher (sub-)layer, which were not addressed to a 1712 multicast or broadcast address at this sub-layer. 1713 This object is a 64-bit version of ifInUcastPkts." 1714 ::= { ifXEntry 7 } 1716 ifHCInMulticastPkts OBJECT-TYPE 1717 SYNTAX Counter64 1718 MAX-ACCESS read-only 1719 STATUS current 1720 DESCRIPTION 1721 "The number of packets, delivered by this sub-layer to 1722 a higher (sub-)layer, which were addressed to a 1723 multicast address at this sub-layer. For a MAC layer 1724 protocol, this includes both Group and Functional 1725 addresses. This object is a 64-bit version of 1726 ifInMulticastPkts." 1727 ::= { ifXEntry 8 } 1729 ifHCInBroadcastPkts OBJECT-TYPE 1730 SYNTAX Counter64 1731 MAX-ACCESS read-only 1732 STATUS current 1733 DESCRIPTION 1734 "The number of packets, delivered by this sub-layer to 1735 a higher (sub-)layer, which were addressed to a 1736 broadcast address at this sub-layer. This object is a 1737 64-bit version of ifInBroadcastPkts." 1738 ::= { ifXEntry 9 } 1740 Draft Interfaces Group MIB November 1995 1742 ifHCOutOctets OBJECT-TYPE 1743 SYNTAX Counter64 1744 MAX-ACCESS read-only 1745 STATUS current 1746 DESCRIPTION 1747 "The total number of octets transmitted out of the 1748 interface, including framing characters. This object 1749 is a 64-bit version of ifOutOctets." 1750 ::= { ifXEntry 10 } 1752 ifHCOutUcastPkts OBJECT-TYPE 1753 SYNTAX Counter64 1754 MAX-ACCESS read-only 1755 STATUS current 1756 DESCRIPTION 1757 "The total number of packets that higher-level 1758 protocols requested be transmitted, and which were not 1759 addressed to a multicast or broadcast address at this 1760 sub-layer, including those that were discarded or not 1761 sent. This object is a 64-bit version of 1762 ifOutUcastPkts." 1763 ::= { ifXEntry 11 } 1765 ifHCOutMulticastPkts OBJECT-TYPE 1766 SYNTAX Counter64 1767 MAX-ACCESS read-only 1768 STATUS current 1769 DESCRIPTION 1770 "The total number of packets that higher-level 1771 protocols requested be transmitted, and which were 1772 addressed to a multicast address at this sub-layer, 1773 including those that were discarded or not sent. For 1774 a MAC layer protocol, this includes both Group and 1775 Functional addresses. This object is a 64-bit version 1776 of ifOutMulticastPkts." 1777 ::= { ifXEntry 12 } 1779 ifHCOutBroadcastPkts OBJECT-TYPE 1780 SYNTAX Counter64 1781 MAX-ACCESS read-only 1782 STATUS current 1783 DESCRIPTION 1784 "The total number of packets that higher-level 1785 protocols requested be transmitted, and which were 1786 addressed to a broadcast address at this sub-layer, 1788 Draft Interfaces Group MIB November 1995 1790 including those that were discarded or not sent. This 1791 object is a 64-bit version of ifOutBroadcastPkts." 1792 ::= { ifXEntry 13 } 1794 ifLinkUpDownTrapEnable OBJECT-TYPE 1795 SYNTAX INTEGER { enabled(1), disabled(2) } 1796 MAX-ACCESS read-write 1797 STATUS current 1798 DESCRIPTION 1799 "Indicates whether linkUp/linkDown traps should be 1800 generated for this interface. 1802 By default, this object should have the value 1803 enabled(1) for interfaces which do not operate on 1804 'top' of any other interface (as defined in the 1805 ifStackTable), and disabled(2) otherwise." 1806 ::= { ifXEntry 14 } 1808 ifHighSpeed OBJECT-TYPE 1809 SYNTAX Gauge32 1810 MAX-ACCESS read-only 1811 STATUS current 1812 DESCRIPTION 1813 "An estimate of the interface's current bandwidth in 1814 units of 1,000,000 bits per second. If this object 1815 reports a value of `n' then the speed of the interface 1816 is somewhere in the range of `n-500,000' to 1817 `n+499,999'. For interfaces which do not vary in 1818 bandwidth or for those where no accurate estimation 1819 can be made, this object should contain the nominal 1820 bandwidth. For a sub-layer which has no concept of 1821 bandwidth, this object should be zero." 1822 ::= { ifXEntry 15 } 1824 ifPromiscuousMode OBJECT-TYPE 1825 SYNTAX TruthValue 1826 MAX-ACCESS read-write 1827 STATUS current 1828 DESCRIPTION 1829 "This object has a value of false(2) if this interface 1830 only accepts packets/frames that are addressed to this 1831 station. This object has a value of true(1) when the 1832 station accepts all packets/frames transmitted on the 1833 media. The value true(1) is only legal on certain 1834 types of media. If legal, setting this object to a 1836 Draft Interfaces Group MIB November 1995 1838 value of true(1) may require the interface to be reset 1839 before becoming effective. 1841 The value of ifPromiscuousMode does not affect the 1842 reception of broadcast and multicast packets/frames by 1843 the interface." 1844 ::= { ifXEntry 16 } 1846 ifConnectorPresent OBJECT-TYPE 1847 SYNTAX TruthValue 1848 MAX-ACCESS read-only 1849 STATUS current 1850 DESCRIPTION 1851 "This object has the value 'true(1)' if the interface 1852 sublayer has a physical connector and the value 1853 'false(2)' otherwise." 1854 ::= { ifXEntry 17 } 1856 ifAlias OBJECT-TYPE 1857 SYNTAX DisplayString (SIZE(0..64)) 1858 MAX-ACCESS read-write 1859 STATUS current 1860 DESCRIPTION 1861 "This object allows the agent to hold shared network 1862 management information for the interface, where this 1863 information is shared between multiple network 1864 management applications and the device's local 1865 management. An example would be the (Telco's) circuit 1866 number/identifier of a WAN interface. 1868 Some agents may support write-access only for 1869 interfaces having particular values of ifType. An 1870 agent which supports write access to this object is 1871 required to keep the value in non-volatile storage, 1872 but it may limit the length of new values depending on 1873 how much storage is already occupied by the current 1874 values for other interfaces." 1875 ::= { ifXEntry 18 } 1877 Draft Interfaces Group MIB November 1995 1879 -- The Interface Stack Group 1880 -- 1881 -- Implementation of this group is mandatory for all systems 1882 -- 1884 ifStackTable OBJECT-TYPE 1885 SYNTAX SEQUENCE OF IfStackEntry 1886 MAX-ACCESS not-accessible 1887 STATUS current 1888 DESCRIPTION 1889 "The table containing information on the relationships 1890 between the multiple sub-layers of network interfaces. 1891 In particular, it contains information on which sub- 1892 layers run 'on top of' which other sub-layers, where 1893 each sub-layer corresponds to a conceptual row in the 1894 ifTable. For example, when the sub-layer with ifIndex 1895 value x runs over the sub-layer with ifIndex value y, 1896 then this table contains: 1898 ifStackStatus.x.y=active 1900 For each ifIndex value, I, which identifies an active 1901 interface, there are always at least two instanciated 1902 rows in this table associated with I. For one of 1903 these rows, I is the value of ifStackHigherLayer; for 1904 the other, I is the value of ifStackLowerLayer. 1906 For example, two rows exist even for an interface 1907 which has no others stacked on top or below it: 1909 ifStackStatus.0.x=active 1910 ifStackStatus.x.0=active " 1911 ::= { ifMIBObjects 2 } 1913 ifStackEntry OBJECT-TYPE 1914 SYNTAX IfStackEntry 1915 MAX-ACCESS not-accessible 1916 STATUS current 1917 DESCRIPTION 1918 "Information on a particular relationship between two 1919 sub-layers, specifying that one sub-layer runs on 1920 'top' of the other sub-layer. Each sub-layer 1921 corresponds to a conceptual row in the ifTable." 1922 INDEX { ifStackHigherLayer, ifStackLowerLayer } 1924 Draft Interfaces Group MIB November 1995 1926 ::= { ifStackTable 1 } 1928 IfStackEntry ::= 1929 SEQUENCE { 1930 ifStackHigherLayer Integer32, 1931 ifStackLowerLayer Integer32, 1932 ifStackStatus RowStatus, 1933 ifStackLastChange TimeTicks 1934 } 1936 ifStackHigherLayer OBJECT-TYPE 1937 SYNTAX Integer32 1938 MAX-ACCESS not-accessible 1939 STATUS current 1940 DESCRIPTION 1941 "The value of ifIndex corresponding to the higher 1942 sub-layer of the relationship, i.e., the sub-layer 1943 which runs on 'top' of the sub-layer identified by the 1944 corresponding instance of ifStackLowerLayer. If there 1945 is no higher sub-layer (below the internetwork layer), 1946 then this object has the value 0." 1947 ::= { ifStackEntry 1 } 1949 ifStackLowerLayer OBJECT-TYPE 1950 SYNTAX Integer32 1951 MAX-ACCESS not-accessible 1952 STATUS current 1953 DESCRIPTION 1954 "The value of ifIndex corresponding to the lower sub- 1955 layer of the relationship, i.e., the sub-layer which 1956 runs 'below' the sub-layer identified by the 1957 corresponding instance of ifStackHigherLayer. If 1958 there is no lower sub-layer, then this object has the 1959 value 0." 1960 ::= { ifStackEntry 2 } 1962 ifStackStatus OBJECT-TYPE 1963 SYNTAX RowStatus 1964 MAX-ACCESS read-create 1965 STATUS current 1966 DESCRIPTION 1968 Draft Interfaces Group MIB November 1995 1970 "The status of the relationship between two sub- 1971 layers. 1973 Changing the value of this object from 'active' to 1974 'notInService' or 'destroy' will likely have 1975 consequences up and down the interface stack. Thus, 1976 write access to this object is likely to be 1977 inappropriate for some types of interfaces, and many 1978 implementations will choose not to support write- 1979 access for any type of interface." 1980 ::= { ifStackEntry 3 } 1982 ifStackLastChange OBJECT-TYPE 1983 SYNTAX TimeTicks 1984 MAX-ACCESS read-only 1985 STATUS current 1986 DESCRIPTION 1987 "The value of sysUpTime at the time of the last change 1988 of the interface stack. A change of the interface 1989 stack is defined to be any creation, deletion, or 1990 change in value of any instance of ifStackStatus. If 1991 the interface stack has been unchanged since the last 1992 re-initialization of the local network management 1993 subsystem, then this object contains a zero value." 1994 ::= { ifStackEntry 4 } 1996 -- Generic Receive Address Table 1997 -- 1998 -- This group of objects is mandatory for all types of 1999 -- interfaces which can receive packets/frames addressed to 2000 -- more than one address. 2001 -- 2002 -- This table replaces the ifExtnsRcvAddr table. The main 2003 -- difference is that this table makes use of the RowStatus 2004 -- textual convention, while ifExtnsRcvAddr did not. 2006 ifRcvAddressTable OBJECT-TYPE 2007 SYNTAX SEQUENCE OF IfRcvAddressEntry 2008 MAX-ACCESS not-accessible 2009 STATUS current 2010 DESCRIPTION 2011 "This table contains an entry for each address 2012 (broadcast, multicast, or uni-cast) for which the 2013 system will receive packets/frames on a particular 2015 Draft Interfaces Group MIB November 1995 2017 interface, except as follows: 2019 - for an interface operating in promiscuous mode, 2020 entries are only required for those addresses for 2021 which the system would receive frames were it not 2022 operating in promiscuous mode. 2024 - for 802.5 functional addresses, only one entry is 2025 required, for the address which has the functional 2026 address bit ANDed with the bit mask of all functional 2027 addresses for which the interface will accept frames. 2029 A system is normally able to use any unicast address 2030 which corresponds to an entry in this table as a 2031 source address." 2032 ::= { ifMIBObjects 4 } 2034 ifRcvAddressEntry OBJECT-TYPE 2035 SYNTAX IfRcvAddressEntry 2036 MAX-ACCESS not-accessible 2037 STATUS current 2038 DESCRIPTION 2039 "A list of objects identifying an address for which 2040 the system will accept packets/frames on the 2041 particular interface identified by the index value 2042 ifIndex." 2043 INDEX { ifIndex, ifRcvAddressAddress } 2044 ::= { ifRcvAddressTable 1 } 2046 IfRcvAddressEntry ::= 2047 SEQUENCE { 2048 ifRcvAddressAddress PhysAddress, 2049 ifRcvAddressStatus RowStatus, 2050 ifRcvAddressType INTEGER 2051 } 2053 ifRcvAddressAddress OBJECT-TYPE 2054 SYNTAX PhysAddress 2055 MAX-ACCESS not-accessible 2056 STATUS current 2057 DESCRIPTION 2058 "An address for which the system will accept 2059 packets/frames on this entry's interface." 2060 ::= { ifRcvAddressEntry 1 } 2062 Draft Interfaces Group MIB November 1995 2064 ifRcvAddressStatus OBJECT-TYPE 2065 SYNTAX RowStatus 2066 MAX-ACCESS read-create 2067 STATUS current 2068 DESCRIPTION 2069 "This object is used to create and delete rows in the 2070 ifRcvAddressTable." 2072 ::= { ifRcvAddressEntry 2 } 2074 ifRcvAddressType OBJECT-TYPE 2075 SYNTAX INTEGER { 2076 other(1), 2077 volatile(2), 2078 nonVolatile(3) 2079 } 2081 MAX-ACCESS read-create 2082 STATUS current 2083 DESCRIPTION 2084 "This object has the value nonVolatile(3) for those 2085 entries in the table which are valid and will not be 2086 deleted by the next restart of the managed system. 2087 Entries having the value volatile(2) are valid and 2088 exist, but have not been saved, so that will not exist 2089 after the next restart of the managed system. Entries 2090 having the value other(1) are valid and exist but are 2091 not classified as to whether they will continue to 2092 exist after the next restart." 2094 DEFVAL { volatile } 2095 ::= { ifRcvAddressEntry 3 } 2097 Draft Interfaces Group MIB November 1995 2099 -- definition of interface-related traps. 2101 linkDown NOTIFICATION-TYPE 2102 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2103 STATUS current 2104 DESCRIPTION 2105 "A linkDown trap signifies that the SNMPv2 entity, 2106 acting in an agent role, has detected that the 2107 ifOperStatus object for one of its communication links 2108 is about to enter the down state." 2109 ::= { snmpTraps 3 } 2111 linkUp NOTIFICATION-TYPE 2112 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2113 STATUS current 2114 DESCRIPTION 2115 "A linkDown trap signifies that the SNMPv2 entity, 2116 acting in an agent role, has detected that the 2117 ifOperStatus object for one of its communication links 2118 has left the down state." 2119 ::= { snmpTraps 4 } 2121 Draft Interfaces Group MIB November 1995 2123 -- conformance information 2125 ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 } 2127 ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 } 2128 ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 } 2130 -- compliance statements 2132 ifCompliance2 MODULE-COMPLIANCE 2133 STATUS current 2134 DESCRIPTION 2135 "The compliance statement for SNMPv2 entities which 2136 have network interfaces." 2138 MODULE -- this module 2139 MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2 } 2141 GROUP ifFixedLengthGroup 2142 DESCRIPTION 2143 "This group is mandatory for all network interfaces 2144 which are character-oriented or transmit data in 2145 fixed-length transmission units." 2147 GROUP ifHCFixedLengthGroup 2148 DESCRIPTION 2149 "This group is mandatory only for those network 2150 interfaces which are character-oriented or transmit 2151 data in fixed-length transmission units, and for which 2152 the value of the corresponding instance of ifSpeed is 2153 greater than 20,000,000 bits/second." 2155 GROUP ifPacketGroup 2156 DESCRIPTION 2157 "This group is mandatory for all network interfaces 2158 which are packet-oriented." 2160 GROUP ifHCPacketGroup 2161 DESCRIPTION 2162 "This group is mandatory only for those network 2163 interfaces which are packet-oriented and for which the 2164 value of the corresponding instance of ifSpeed is 2165 greater than 650,000,000 bits/second." 2167 Draft Interfaces Group MIB November 1995 2169 GROUP ifRcvAddressGroup 2170 DESCRIPTION 2171 "The applicability of this group MUST be defined by 2172 the media-specific MIBs. Media-specific MIBs must 2173 define the exact meaning, use, and semantics of the 2174 addresses in this group." 2176 OBJECT ifLinkUpDownTrapEnable 2177 MIN-ACCESS read-only 2178 DESCRIPTION 2179 "Write access is not required." 2181 OBJECT ifPromiscuousMode 2182 MIN-ACCESS read-only 2183 DESCRIPTION 2184 "Write access is not required." 2186 OBJECT ifStackStatus 2187 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2188 MIN-ACCESS read-only 2189 DESCRIPTION 2190 "Write access is not required, and only one of the six 2191 enumerated values for the RowStatus textual convention 2192 need be supported, specifically: active(1)." 2194 OBJECT ifAdminStatus 2195 SYNTAX INTEGER { up(1), down(2) } 2196 MIN-ACCESS read-only 2197 DESCRIPTION 2198 "Write access is not required, nor is support for the 2199 value testing(3)." 2201 OBJECT ifAlias 2202 MIN-ACCESS read-only 2203 DESCRIPTION 2204 "Write access is not required." 2206 ::= { ifCompliances 2 } 2208 Draft Interfaces Group MIB November 1995 2210 -- units of conformance 2212 ifGeneralInformationGroup OBJECT-GROUP 2213 OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress, 2214 ifAdminStatus, ifOperStatus, ifLastChange, 2215 ifLinkUpDownTrapEnable, ifConnectorPresent, 2216 ifHighSpeed, ifName, ifNumber, ifAlias, 2217 ifTableLastChange } 2218 STATUS current 2219 DESCRIPTION 2220 "A collection of objects providing information 2221 applicable to all network interfaces." 2222 ::= { ifGroups 10 } 2224 -- the following five groups are mutually exclusive; at most 2225 -- one of these groups is implemented for any interface 2227 ifFixedLengthGroup OBJECT-GROUP 2228 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2229 ifInErrors, ifOutErrors } 2230 STATUS current 2231 DESCRIPTION 2232 "A collection of objects providing information 2233 specific to non-high speed (non-high speed interfaces 2234 transmit and receive at speeds less than or equal to 2235 20,000,000 bits/second) character-oriented or fixed- 2236 length-transmission network interfaces." 2237 ::= { ifGroups 2 } 2239 ifHCFixedLengthGroup OBJECT-GROUP 2240 OBJECTS { ifHCInOctets, ifHCOutOctets, 2241 ifInOctets, ifOutOctets, ifInUnknownProtos, 2242 ifInErrors, ifOutErrors } 2243 STATUS current 2244 DESCRIPTION 2245 "A collection of objects providing information 2246 specific to high speed (greater than 20,000,000 2247 bits/second) character-oriented or fixed-length- 2248 transmission network interfaces." 2249 ::= { ifGroups 3 } 2251 ifPacketGroup OBJECT-GROUP 2252 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2253 ifInErrors, ifOutErrors, 2254 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2256 Draft Interfaces Group MIB November 1995 2258 ifInBroadcastPkts, ifInDiscards, 2259 ifOutUcastPkts, ifOutMulticastPkts, 2260 ifOutBroadcastPkts, ifOutDiscards, 2261 ifPromiscuousMode } 2262 STATUS current 2263 DESCRIPTION 2264 "A collection of objects providing information 2265 specific to non-high speed (non-high speed interfaces 2266 transmit and receive at speeds less than or equal to 2267 20,000,000 bits/second) packet-oriented network 2268 interfaces." 2269 ::= { ifGroups 4 } 2271 ifHCPacketGroup OBJECT-GROUP 2272 OBJECTS { ifHCInOctets, ifHCOutOctets, 2273 ifInOctets, ifOutOctets, ifInUnknownProtos, 2274 ifInErrors, ifOutErrors, 2275 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2276 ifInBroadcastPkts, ifInDiscards, 2277 ifOutUcastPkts, ifOutMulticastPkts, 2278 ifOutBroadcastPkts, ifOutDiscards, 2279 ifPromiscuousMode } 2280 STATUS current 2281 DESCRIPTION 2282 "A collection of objects providing information 2283 specific to high speed (greater than 20,000,000 2284 bits/second but less than or equal to 650,000,000 2285 bits/second) packet-oriented network interfaces." 2286 ::= { ifGroups 5 } 2288 ifVHCPacketGroup OBJECT-GROUP 2289 OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, 2290 ifHCInBroadcastPkts, ifHCOutUcastPkts, 2291 ifHCOutMulticastPkts, ifHCOutBroadcastPkts, 2292 ifHCInOctets, ifHCOutOctets, 2293 ifInOctets, ifOutOctets, ifInUnknownProtos, 2294 ifInErrors, ifOutErrors, 2295 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2296 ifInBroadcastPkts, ifInDiscards, 2297 ifOutUcastPkts, ifOutMulticastPkts, 2298 ifOutBroadcastPkts, ifOutDiscards, 2299 ifPromiscuousMode } 2300 STATUS current 2301 DESCRIPTION 2302 "A collection of objects providing information 2304 Draft Interfaces Group MIB November 1995 2306 specific to higher speed (greater than 650,000,000 2307 bits/second) packet-oriented network interfaces." 2308 ::= { ifGroups 6 } 2310 ifRcvAddressGroup OBJECT-GROUP 2311 OBJECTS { ifRcvAddressStatus, ifRcvAddressType } 2312 STATUS current 2313 DESCRIPTION 2314 "A collection of objects providing information on the 2315 multiple addresses which an interface receives." 2316 ::= { ifGroups 7 } 2318 ifStackGroup2 OBJECT-GROUP 2319 OBJECTS { ifStackStatus, ifStackLastChange } 2320 STATUS current 2321 DESCRIPTION 2322 "A collection of objects providing information on the 2323 layering of MIB-II interfaces." 2324 ::= { ifGroups 11 } 2326 Draft Interfaces Group MIB November 1995 2328 -- Deprecated Definitions - Objects 2330 -- 2331 -- The Interface Test Table 2332 -- 2333 -- This group of objects is optional. However, a media-specific 2334 -- MIB may make implementation of this group mandatory. 2335 -- 2336 -- This table replaces the ifExtnsTestTable 2337 -- 2339 ifTestTable OBJECT-TYPE 2340 SYNTAX SEQUENCE OF IfTestEntry 2341 MAX-ACCESS not-accessible 2342 STATUS deprecated 2343 DESCRIPTION 2344 "This table contains one entry per interface. It 2345 defines objects which allow a network manager to 2346 instruct an agent to test an interface for various 2347 faults. Tests for an interface are defined in the 2348 media-specific MIB for that interface. After invoking 2349 a test, the object ifTestResult can be read to 2350 determine the outcome. If an agent can not perform 2351 the test, ifTestResult is set to so indicate. The 2352 object ifTestCode can be used to provide further 2353 test-specific or interface-specific (or even 2354 enterprise-specific) information concerning the 2355 outcome of the test. Only one test can be in progress 2356 on each interface at any one time. If one test is in 2357 progress when another test is invoked, the second test 2358 is rejected. Some agents may reject a test when a 2359 prior test is active on another interface. 2361 Before starting a test, a manager-station must first 2362 obtain 'ownership' of the entry in the ifTestTable for 2363 the interface to be tested. This is accomplished with 2364 the ifTestId and ifTestStatus objects as follows: 2366 try_again: 2367 get (ifTestId, ifTestStatus) 2368 while (ifTestStatus != notInUse) 2369 /* 2370 * Loop while a test is running or some other 2371 * manager is configuring a test. 2373 Draft Interfaces Group MIB November 1995 2375 */ 2376 short delay 2377 get (ifTestId, ifTestStatus) 2378 } 2380 /* 2381 * Is not being used right now -- let's compete 2382 * to see who gets it. 2383 */ 2384 lock_value = ifTestId 2386 if ( set(ifTestId = lock_value, ifTestStatus = inUse, 2387 ifTestOwner = 'my-IP-address') == FAILURE) 2388 /* 2389 * Another manager got the ifTestEntry -- go 2390 * try again 2391 */ 2392 goto try_again; 2394 /* 2395 * I have the lock 2396 */ 2397 set up any test parameters. 2399 /* 2400 * This starts the test 2401 */ 2402 set(ifTestType = test_to_run); 2404 wait for test completion by polling ifTestResult 2406 when test completes, agent sets ifTestResult 2407 agent also sets ifTestStatus = 'notInUse' 2409 retrieve any additional test results, and ifTestId 2411 if (ifTestId == lock_value+1) results are valid 2413 A manager station first retrieves the value of the 2414 appropriate ifTestId and ifTestStatus objects, 2415 periodically repeating the retrieval if necessary, 2416 until the value of ifTestStatus is 'notInUse'. The 2417 manager station then tries to set the same ifTestId 2418 object to the value it just retrieved, the same 2419 ifTestStatus object to 'inUse', and the corresponding 2421 Draft Interfaces Group MIB November 1995 2423 ifTestOwner object to a value indicating itself. If 2424 the set operation succeeds then the manager has 2425 obtained ownership of the ifTestEntry, and the value of 2426 the ifTestId object is incremented by the agent (per 2427 the semantics of TestAndIncr). Failure of the set 2428 operation indicates that some other manager has 2429 obtained ownership of the ifTestEntry. 2431 Once ownership is obtained, any test parameters can be 2432 setup, and then the test is initiated by setting 2433 ifTestType. On completion of the test, the agent sets 2434 ifTestStatus to 'notInUse'. Once this occurs, the 2435 manager can retrieve the results. In the (rare) event 2436 that the invocation of tests by two network managers 2437 were to overlap, then there would be a possibility that 2438 the first test's results might be overwritten by the 2439 second test's results prior to the first results being 2440 read. This unlikely circumstance can be detected by a 2441 network manager retrieving ifTestId at the same time as 2442 retrieving the test results, and ensuring that the 2443 results are for the desired request. 2445 If ifTestType is not set within an abnormally long 2446 period of time after ownership is obtained, the agent 2447 should time-out the manager, and reset the value of the 2448 ifTestStatus object back to 'notInUse'. It is 2449 suggested that this time-out period be 5 minutes. 2451 In general, a management station must not retransmit a 2452 request to invoke a test for which it does not receive 2453 a response; instead, it properly inspects an agent's 2454 MIB to determine if the invocation was successful. 2455 Only if the invocation was unsuccessful, is the 2456 invocation request retransmitted. 2458 Some tests may require the interface to be taken off- 2459 line in order to execute them, or may even require the 2460 agent to reboot after completion of the test. In these 2461 circumstances, communication with the management 2462 station invoking the test may be lost until after 2463 completion of the test. An agent is not required to 2464 support such tests. However, if such tests are 2465 supported, then the agent should make every effort to 2466 transmit a response to the request which invoked the 2467 test prior to losing communication. When the agent is 2469 Draft Interfaces Group MIB November 1995 2471 restored to normal service, the results of the test are 2472 properly made available in the appropriate objects. 2473 Note that this requires that the ifIndex value assigned 2474 to an interface must be unchanged even if the test 2475 causes a reboot. An agent must reject any test for 2476 which it cannot, perhaps due to resource constraints, 2477 make available at least the minimum amount of 2478 information after that test completes." 2479 ::= { ifMIBObjects 3 } 2481 ifTestEntry OBJECT-TYPE 2482 SYNTAX IfTestEntry 2483 MAX-ACCESS not-accessible 2484 STATUS deprecated 2485 DESCRIPTION 2486 "An entry containing objects for invoking tests on an 2487 interface." 2488 AUGMENTS { ifEntry } 2489 ::= { ifTestTable 1 } 2491 IfTestEntry ::= 2492 SEQUENCE { 2493 ifTestId TestAndIncr, 2494 ifTestStatus INTEGER, 2495 ifTestType AutonomousType, 2496 ifTestResult INTEGER, 2497 ifTestCode OBJECT IDENTIFIER, 2498 ifTestOwner OwnerString 2499 } 2501 ifTestId OBJECT-TYPE 2502 SYNTAX TestAndIncr 2503 MAX-ACCESS read-write 2504 STATUS deprecated 2505 DESCRIPTION 2506 "This object identifies the current invocation of the 2507 interface's test." 2508 ::= { ifTestEntry 1 } 2510 ifTestStatus OBJECT-TYPE 2511 SYNTAX INTEGER { notInUse(1), inUse(2) } 2512 MAX-ACCESS read-write 2513 STATUS deprecated 2514 DESCRIPTION 2515 "This object indicates whether or not some manager 2517 Draft Interfaces Group MIB November 1995 2519 currently has the necessary 'ownership' required to 2520 invoke a test on this interface. A write to this 2521 object is only successful when it changes its value 2522 from 'notInUse(1)' to 'inUse(2)'. After completion of 2523 a test, the agent resets the value back to 2524 'notInUse(1)'." 2525 ::= { ifTestEntry 2 } 2527 ifTestType OBJECT-TYPE 2528 SYNTAX AutonomousType 2529 MAX-ACCESS read-write 2530 STATUS deprecated 2531 DESCRIPTION 2532 "A control variable used to start and stop operator- 2533 initiated interface tests. Most OBJECT IDENTIFIER 2534 values assigned to tests are defined elsewhere, in 2535 association with specific types of interface. 2536 However, this document assigns a value for a full- 2537 duplex loopback test, and defines the special meanings 2538 of the subject identifier: 2540 noTest OBJECT IDENTIFIER ::= { 0 0 } 2542 When the value noTest is written to this object, no 2543 action is taken unless a test is in progress, in which 2544 case the test is aborted. Writing any other value to 2545 this object is only valid when no test is currently in 2546 progress, in which case the indicated test is 2547 initiated. 2549 When read, this object always returns the most recent 2550 value that ifTestType was set to. If it has not been 2551 set since the last initialization of the network 2552 management subsystem on the agent, a value of noTest 2553 is returned." 2554 ::= { ifTestEntry 3 } 2556 ifTestResult OBJECT-TYPE 2557 SYNTAX INTEGER { 2558 none(1), -- no test yet requested 2559 success(2), 2560 inProgress(3), 2561 notSupported(4), 2562 unAbleToRun(5), -- due to state of system 2563 aborted(6), 2565 Draft Interfaces Group MIB November 1995 2567 failed(7) 2568 } 2569 MAX-ACCESS read-only 2570 STATUS deprecated 2571 DESCRIPTION 2572 "This object contains the result of the most recently 2573 requested test, or the value none(1) if no tests have 2574 been requested since the last reset. Note that this 2575 facility provides no provision for saving the results 2576 of one test when starting another, as could be 2577 required if used by multiple managers concurrently." 2578 ::= { ifTestEntry 4 } 2580 ifTestCode OBJECT-TYPE 2581 SYNTAX OBJECT IDENTIFIER 2582 MAX-ACCESS read-only 2583 STATUS deprecated 2584 DESCRIPTION 2585 "This object contains a code which contains more 2586 specific information on the test result, for example 2587 an error-code after a failed test. Error codes and 2588 other values this object may take are specific to the 2589 type of interface and/or test. The value may have the 2590 semantics of either the AutonomousType or 2591 InstancePointer textual conventions as defined in RFC 2592 1443. The identifier: 2594 testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } 2596 is defined for use if no additional result code is 2597 available." 2598 ::= { ifTestEntry 5 } 2600 ifTestOwner OBJECT-TYPE 2601 SYNTAX OwnerString 2602 MAX-ACCESS read-write 2603 STATUS deprecated 2604 DESCRIPTION 2605 "The entity which currently has the 'ownership' 2606 required to invoke a test on this interface." 2607 ::= { ifTestEntry 6 } 2609 Draft Interfaces Group MIB November 1995 2611 -- Deprecated Definitions - Groups 2613 ifGeneralGroup OBJECT-GROUP 2614 OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress, 2615 ifAdminStatus, ifOperStatus, ifLastChange, 2616 ifLinkUpDownTrapEnable, ifConnectorPresent, 2617 ifHighSpeed, ifName } 2618 STATUS deprecated 2619 DESCRIPTION 2620 "A collection of objects deprecated in favour of 2621 ifGeneralInformationGroup." 2622 ::= { ifGroups 1 } 2624 ifTestGroup OBJECT-GROUP 2625 OBJECTS { ifTestId, ifTestStatus, ifTestType, 2626 ifTestResult, ifTestCode, ifTestOwner } 2627 STATUS deprecated 2628 DESCRIPTION 2629 "A collection of objects providing the ability to 2630 invoke tests on an interface." 2631 ::= { ifGroups 8 } 2633 ifStackGroup OBJECT-GROUP 2634 OBJECTS { ifStackStatus } 2635 STATUS deprecated 2636 DESCRIPTION 2637 "The previous collection of objects providing 2638 information on the layering of MIB-II interfaces." 2639 ::= { ifGroups 9 } 2641 ifOldObjectsGroup OBJECT-GROUP 2642 OBJECTS { ifInNUcastPkts, ifOutNUcastPkts, 2643 ifOutQLen, ifSpecific } 2644 STATUS deprecated 2645 DESCRIPTION 2646 "The collection of objects deprecated from the 2647 original MIB-II interfaces group." 2648 ::= { ifGroups 12 } 2650 -- Deprecated Definitions - Compliance 2651 Draft Interfaces Group MIB November 1995 2653 ifCompliance MODULE-COMPLIANCE 2654 STATUS deprecated 2655 DESCRIPTION 2656 "The previous compliance statement for SNMPv2 entities 2657 which have network interfaces." 2659 MODULE -- this module 2660 MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup } 2662 GROUP ifFixedLengthGroup 2663 DESCRIPTION 2664 "This group is mandatory for all network interfaces 2665 which are character-oriented or transmit data in 2666 fixed-length transmission units." 2668 GROUP ifHCFixedLengthGroup 2669 DESCRIPTION 2670 "This group is mandatory only for those network 2671 interfaces which are character-oriented or transmit 2672 data in fixed-length transmission units, and for which 2673 the value of the corresponding instance of ifSpeed is 2674 greater than 20,000,000 bits/second." 2676 GROUP ifPacketGroup 2677 DESCRIPTION 2678 "This group is mandatory for all network interfaces 2679 which are packet-oriented." 2681 GROUP ifHCPacketGroup 2682 DESCRIPTION 2683 "This group is mandatory only for those network 2684 interfaces which are packet-oriented and for which the 2685 value of the corresponding instance of ifSpeed is 2686 greater than 650,000,000 bits/second." 2688 GROUP ifTestGroup 2689 DESCRIPTION 2690 "This group is optional. Media-specific MIBs which 2691 require interface tests are strongly encouraged to use 2692 this group for invoking tests and reporting results. 2693 A medium specific MIB which has mandatory tests may 2694 make implementation of this group mandatory." 2696 GROUP ifRcvAddressGroup 2697 DESCRIPTION 2699 Draft Interfaces Group MIB November 1995 2701 "The applicability of this group MUST be defined by 2702 the media-specific MIBs. Media-specific MIBs must 2703 define the exact meaning, use, and semantics of the 2704 addresses in this group." 2706 OBJECT ifLinkUpDownTrapEnable 2707 MIN-ACCESS read-only 2708 DESCRIPTION 2709 "Write access is not required." 2711 OBJECT ifPromiscuousMode 2712 MIN-ACCESS read-only 2713 DESCRIPTION 2714 "Write access is not required." 2716 OBJECT ifStackStatus 2717 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2718 MIN-ACCESS read-only 2719 DESCRIPTION 2720 "Write access is not required, and only one of the six 2721 enumerated values for the RowStatus textual convention 2722 need be supported, specifically: active(1)." 2724 OBJECT ifAdminStatus 2725 SYNTAX INTEGER { up(1), down(2) } 2726 MIN-ACCESS read-only 2727 DESCRIPTION 2728 "Write access is not required, nor is support for the 2729 value testing(3)." 2730 ::= { ifCompliances 1 } 2732 END 2733 Draft Interfaces Group MIB November 1995 2735 7. Acknowledgements 2737 This memo has been produced by the IETF's Interfaces MIB working- 2738 group. 2740 The original proposal evolved from conversations and discussions 2741 with many people, including at least the following: Fred Baker, 2742 Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj 2743 Tesink, and Dean Throop. 2745 Draft Interfaces Group MIB November 1995 2747 8. References 2749 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2750 "Structure of Management Information for version 2 of the 2751 Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP 2752 Research, Inc., Hughes LAN Systems, Dover Beach Consulting, 2753 Inc., Carnegie Mellon University, April 1993. 2755 [2] Galvin, J., and K. McCloghrie, "Administrative Model for 2756 version 2 of the Simple Network Management Protocol 2757 (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN 2758 Systems, April 1993. 2760 [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2761 "Protocol Operations for version 2 of the Simple Network 2762 Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., 2763 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie 2764 Mellon University, April 1993. 2766 [4] McCloghrie, K., and M. Rose, "Management Information Base for 2767 Network Management of TCP/IP-based internets - MIB-II", RFC 2768 1213, Hughes LAN Systems, Performance Systems International, 2769 March 1991. 2771 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 2772 Network Management Protocol", RFC 1157, SNMP Research, 2773 Performance Systems International, Performance Systems 2774 International, MIT Laboratory for Computer Science, May 1990. 2776 [6] J. Postel, "Internet Protocol", RFC 791, Information Sciences 2777 Institute, USC, September 1981. 2779 [7] K. McCloghrie, "Extensions to the Generic-Interface MIB", RFC 2780 1229, Hughes LAN Systems, May 1991. 2782 [8] ATM Forum Technical Committee, "LAN Emulation Client 2783 Management: Version 1.0 Specification", af-lane-0044.000, ATM 2784 Forum, September 1995. 2786 Draft Interfaces Group MIB November 1995 2788 9. Security Considerations 2790 Security issues are not discussed in this memo. 2792 10. Authors' Address 2794 Keith McCloghrie 2795 Cisco Systems, Inc. 2796 170 West Tasman Drive 2797 San Jose, CA 95134-1706 2799 Phone: 408-526-5260 2800 Email: kzm@cisco.com" 2802 Frank Kastenholz 2803 FTP Software 2804 2 High Street 2805 North Andover, Mass. USA 01845 2807 Phone: (508)685-4000 2808 Email: kasten@ftp.com 2810 Draft Interfaces Group MIB November 1995 2812 Table of Contents 2814 1 Introduction .............................................. 2 2815 1.1 Change Log .............................................. 2 2816 2 The SNMPv2 Network Management Framework ................... 4 2817 2.1 Object Definitions ...................................... 4 2818 3 Experience with the Interfaces Group ...................... 5 2819 3.1 Clarifications/Revisions ................................ 5 2820 3.1.1 Interface Sub-Layers .................................. 5 2821 3.1.2 Guidance on Defining Sub-layers ....................... 8 2822 3.1.3 Virtual Circuits ...................................... 10 2823 3.1.4 Bit, Character, and Fixed-Length Interfaces ........... 10 2824 3.1.5 Interface Numbering ................................... 12 2825 3.1.6 Counter Size .......................................... 15 2826 3.1.7 Interface Speed ....................................... 17 2827 3.1.8 Multicast/Broadcast Counters .......................... 18 2828 3.1.9 Trap Enable ........................................... 19 2829 3.1.10 Addition of New ifType values ........................ 19 2830 3.1.11 InterfaceIndex Textual Convention .................... 20 2831 3.1.12 IfAdminStatus and IfOperStatus ....................... 20 2832 3.1.13 Traps ................................................ 21 2833 3.1.14 ifSpecific ........................................... 22 2834 3.1.15 All Values Must be Known ............................. 23 2835 4 Media-Specific MIB Applicability .......................... 24 2836 5 Overview .................................................. 25 2837 6 Interfaces Group Definitions .............................. 26 2838 7 Acknowledgements .......................................... 63 2839 8 References ................................................ 64 2840 9 Security Considerations ................................... 65 2841 10 Authors' Address ......................................... 65