idnits 2.17.1 draft-ietf-ifmib-mib-03.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-25) 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 400: '...specific MIB MUST completely specify t...' RFC 2119 keyword, line 723: '...and packet counters MUST be used. For...' RFC 2119 keyword, line 725: '...ts/second, 32-bit packet counters MUST...' RFC 2119 keyword, line 726: '...t octet counters MUST be used. For in...' RFC 2119 keyword, line 728: '...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 (22 February 1996) is 10290 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 2963, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 2973, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2978, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2983, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '2') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1905 (ref. '3') (Obsoleted by RFC 3416) ** 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 (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft Interfaces Group MIB February 1996 4 The Interfaces Group MIB 6 22 February 1996 8 draft-ietf-ifmib-mib-03.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 February 1996 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 22 February 1996 68 The following changes were made for the version of the document 69 dated 19 February 1996. These changes were made based on Working 70 Group email discussions. 72 (1) Added InterfaceIndexOrZero textual convention. 74 (2) Added notPresent state for ifOperStatus. 76 11 February 1996 78 The following changes were made for the version of the document 79 dated 11 February 1996. These changes were made based on comments 80 received via email. 82 Draft Interfaces Group MIB February 1996 84 (1) Clarified value of ifOperStatus in linkUp and linkDown traps. 86 (2) Included ifIndex in the ifGeneralInformationGroup object 87 group. 89 (3) Supplemented the explanatory text for ifName. 91 28 January 1996 93 The following changes were made for the version of the document 94 dated 28 January 1996. These changes were made based on the output 95 of the working group's meeting at the Dallas IETF meeting. 97 (1) Changed ifStackLastChange to be a scalar object. 99 (2) Updated the definition of ifAlias. 101 (3) Added text contrasting the use of ifDescr, ifName and 102 ifAlias. 104 (4) Added section on the creation/deletion of interfaces. 106 (5) Added section on how an interface's ifOperStatus depends on 107 the states of the interfaces below it in the interface stack. 109 (6) Added clarification that a defective interface which 110 periodically tests itself does not transition to the 111 ifOperStatus=testing state while that testing is in progress. 113 26 November 1995 115 The following changes were made for the version of the document 116 dated 26 November 1995. These changes were made based on the 117 output of the working group's meeting at the Stockholm IETF 118 meeting. 120 (1) Added the ifAlias, ifStackLastChange and ifTableLastChange 121 objects. 123 (2) Defined new group definitions to contain the new objects, and 124 defined a new conformance definition. Deprecated the old 125 group and conformance definitions. 127 (3) Corrected the MAX-ACCESS clause values for 128 ifRcvAddressAddress, ifRcvAddressStatus and ifStackStatus. 130 Draft Interfaces Group MIB February 1996 132 (4) Deprecated the ifTestTable and ifTestGroup. 134 (5) Removed (to be defined elsewhere) the IANAifType-MIB MIB 135 Module. 137 (6) Re-arranged and combined the previous sections 3.1 and 3.2. 139 (7) Minor editorial changes. 141 Draft Interfaces Group MIB February 1996 143 2. The SNMP Network Management Framework 145 The SNMP Network Management Framework presently consists of three 146 major components. They are: 148 o RFC 1902 which defines the SMI, the mechanisms used for 149 describing and naming objects for the purpose of management. 151 o RFC 1213 defines MIB-II, the core set of managed objects for 152 the Internet suite of protocols. 154 o RFC 1157 and RFC 1905 which define two versions of the 155 protocol used for network access to managed objects. 157 The Framework permits new objects to be defined for the purpose of 158 experimentation and evaluation. 160 2.1. Object Definitions 162 Managed objects are accessed via a virtual information store, 163 termed the Management Information Base or MIB. Objects in the MIB 164 are defined using the subset of Abstract Syntax Notation One 165 (ASN.1) defined in the SMI. In particular, each object object 166 type is named by an OBJECT IDENTIFIER, an administratively 167 assigned name. The object type together with an object instance 168 serves to uniquely identify a specific instantiation of the 169 object. For human convenience, we often use a textual string, 170 termed the descriptor, to refer to the object type. 172 Draft Interfaces Group MIB February 1996 174 3. Experience with the Interfaces Group 176 One of the strengths of internetwork-layer protocols such as IP 177 [6] is that they are designed to run over any network interface. 178 In achieving this, IP considers any and all protocols it runs over 179 as a single "network interface" layer. A similar view is taken by 180 other internetwork-layer protocols. This concept is represented 181 in MIB-II by the 'interfaces' group which defines a generic set of 182 managed objects such that any network interface can be managed in 183 an interface-independent manner through these managed objects. 184 The 'interfaces' group provides the means for additional managed 185 objects specific to particular types of network interface (e.g., a 186 specific medium such as Ethernet) to be defined as extensions to 187 the 'interfaces' group for media-specific management. Since the 188 standardization of MIB-II, many such media-specific MIB modules 189 have been defined. 191 Experience in defining these media-specific MIB modules has shown 192 that the model defined by MIB-II is too simplistic and/or static 193 for some types of media-specific management. As a result, some of 194 these media-specific MIB modules assume an evolution or loosening 195 of the model. This memo documents and standardizes that evolution 196 of the model and fills in the gaps caused by that evolution. This 197 memo also incorporates the interfaces group extensions documented 198 in RFC 1229 [7]. 200 3.1. Clarifications/Revisions 202 There are several areas for which experience has indicated that 203 clarification, revision, or extension of the model would be 204 helpful. The following sections discuss the changes in the 205 interfaces group adopted by this memo in each of these areas. 207 In some sections, one or more paragraphs contain discussion of 208 rejected alternatives to the model adopted in this memo. Readers 209 not familiar with the MIB-II model and not interested in the 210 rationale behind the new model may want to skip these paragraphs. 212 3.1.1. Interface Sub-Layers 214 Experience in defining media-specific management information has 215 shown the need to distinguish between the multiple sub-layers 216 beneath the internetwork-layer. In addition, there is a need to 217 manage these sub-layers in devices (e.g., MAC-layer bridges) which 218 are unaware of which, if any, internetwork protocols run over 219 Draft Interfaces Group MIB February 1996 221 these sub-layers. As such, a model of having a single conceptual 222 row in the interfaces table (MIB-II's ifTable) represent a whole 223 interface underneath the internetwork-layer, and having a single 224 associated media-specific MIB module (referenced via the ifType 225 object) is too simplistic. A further problem arises with the 226 value of the ifType object which has enumerated values for each 227 type of interface. 229 Consider, for example, an interface with PPP running over an HDLC 230 link which uses a RS232-like connector. Each of these sub-layers 231 has its own media-specific MIB module. If all of this is 232 represented by a single conceptual row in the ifTable, then an 233 enumerated value for ifType is needed for that specific 234 combination which maps to the specific combination of media- 235 specific MIBs. Furthermore, such a model still lacks a method to 236 describe the relationship of all the sub-layers of the MIB stack. 238 An associated problem is that of upward and downward multiplexing 239 of the sub-layers. An example of upward multiplexing is MLP 240 (Multi-Link-Procedure) which provides load-sharing over several 241 serial lines by appearing as a single point-to-point link to the 242 sub-layer(s) above. An example of downward multiplexing would be 243 several instances of PPP, each framed within a separate X.25 244 virtual circuit, all of which run over one fractional T1 channel, 245 concurrently with other uses of the T1 link. The MIB structure 246 must allow these sorts of relationships to be described. 248 Several solutions for representing multiple sub-layers were 249 rejected. One was to retain the concept of one conceptual row for 250 all the sub-layers of an interface and have each media-specific 251 MIB module identify its "superior" and "subordinate" sub-layers 252 through OBJECT IDENTIFIER "pointers". This scheme would have 253 several drawbacks: the superior/subordinate pointers would be 254 contained in the media-specific MIB modules; thus, a manager could 255 not learn the structure of an interface without inspecting 256 multiple pointers in different MIB modules; this would be overly 257 complex and only possible if the manager had knowledge of all the 258 relevant media-specific MIB modules; MIB modules would all need to 259 be retrofitted with these new "pointers"; this scheme would not 260 adequately address the problem of upward and downward 261 multiplexing; and finally, enumerated values of ifType would be 262 needed for each combination of sub-layers. Another rejected 263 solution also retained the concept of one conceptual row for all 264 the sub-layers of an interface but had a new separate MIB table to 265 identify the "superior" and "subordinate" sub-layers and to 266 Draft Interfaces Group MIB February 1996 268 contain OBJECT IDENTIFIER "pointers" to the media-specific MIB 269 module for each sub-layer. Effectively, one conceptual row in the 270 ifTable would represent each combination of sub-layers between the 271 internetwork-layer and the wire. While this scheme has fewer 272 drawbacks, it still would not support downward multiplexing, such 273 as PPP over MLP: observe that MLP makes two (or more) serial lines 274 appear to the layers above as a single physical interface, and 275 thus PPP over MLP should appear to the internetwork-layer as a 276 single interface; in contrast, this scheme would result in two (or 277 more) conceptual rows in the ifTable, both of which the 278 internetwork-layer would run over. This scheme would also require 279 enumerated values of ifType for each combination of sub-layers. 281 The solution adopted by this memo is to have an individual 282 conceptual row in the ifTable to represent each sub-layer, and 283 have a new separate MIB table (the ifStackTable, see section 5 284 below) to identify the "superior" and "subordinate" sub-layers 285 through INTEGER "pointers" to the appropriate conceptual rows in 286 the ifTable. This solution supports both upward and downward 287 multiplexing, allows the IANAifType to Media-Specific MIB mapping 288 to identify the media-specific MIB module for that sub-layer, such 289 that the new table need only be referenced to obtain information 290 about layering, and it only requires enumerated values of ifType 291 for each sub-layer, not for combinations of them. However, it 292 does require that the descriptions of some objects in the ifTable 293 (specifically, ifType, ifPhysAddress, ifInUcastPkts, and 294 ifOutUcastPkts) be generalized so as to apply to any sub-layer 295 (rather than only to a sub-layer immediately beneath the network 296 layer as previously), plus some (specifically, ifSpeed) which need 297 to have appropriate values identified for use when a generalized 298 definition does not apply to a particular sub-layer. 300 In addition, this adopted solution makes no requirement that a 301 device, in which a sub-layer is instrumented by a conceptual row 302 of the ifTable, be aware of whether an internetwork protocol runs 303 on top of (i.e., at some layer above) that sub-layer. In fact, 304 the counters of packets received on an interface are defined as 305 counting the number "delivered to a higher-layer protocol". This 306 meaning of "higher-layer" includes: 308 (1) Delivery to a forwarding module which accepts 309 packets/frames/octets and forwards them on at the same 310 protocol layer. For example, for the purposes of this 311 definition, the forwarding module of a MAC-layer bridge is 312 considered as a "higher-layer" to the MAC-layer of each port 314 Draft Interfaces Group MIB February 1996 316 on the bridge. 318 (2) Delivery to a higher sub-layer within a interface stack. For 319 example, for the purposes of this definition, if a PPP module 320 operated directly over a serial interface, the PPP module 321 would be considered the higher sub-layer to the serial 322 interface. 324 (3) Delivery to a higher protocol layer which does not do packet 325 forwarding for sub-layers that are "at the top of" the 326 interface stack. For example, for the purposes of this 327 definition, the local IP module would be considered the 328 higher layer to a SLIP serial interface. 330 Similarly, for output, the counters of packets transmitted out an 331 interface are defined as counting the number "that higher-level 332 protocols requested to be transmitted". This meaning of "higher- 333 layer" includes: 335 (1) A forwarding module, at the same protocol layer, which 336 transmits packets/frames/octets that were received on an 337 different interface. For example, for the purposes of this 338 definition, the forwarding module of a MAC-layer bridge is 339 considered as a "higher-layer" to the MAC-layer of each port 340 on the bridge. 342 (2) The next higher sub-layer within an interface stack. For 343 example, for the purposes of this definition, if a PPP module 344 operated directly over a serial interface, the PPP module 345 would be a "higher layer" to the serial interface. 347 (3) For sub-layers that are "at the top of" the interface stack, 348 a higher element in the network protocol stack. For example, 349 for the purposes of this definition, the local IP module 350 would be considered the higher layer to an Ethernet 351 interface. 353 3.1.2. Guidance on Defining Sub-layers 355 The designer of a media-specific MIB must decide whether to divide 356 the interface into sub-layers or not, and if so, how to make the 357 divisions. The following guidance is offered to assist the 358 media-specific MIB designer in these decisions. 360 Draft Interfaces Group MIB February 1996 362 In general, the number of entries in the ifTable should be kept to 363 the minimum required for network management. In particular, a 364 group of related interfaces should be treated as a single 365 interface with one entry in the ifTable providing that: 367 (1) None of the group of interfaces performs multiplexing for any 368 other interface in the agent, 370 (2) There is a meaningful and useful way for all of the ifTable's 371 information (e.g., the counters, and the status variables), 372 and all of the ifTable's capabilities (e.g., write access to 373 ifAdminStatus), to apply to the group of interfaces as a 374 whole. 376 Under these circumstances, there should be one entry in the 377 ifTable for such a group of interfaces, and any internal structure 378 which needs to be represented to network management should be 379 captured in a MIB module specific to the particular type of 380 interface. 382 Note that application of bullet 2 above to the ifTable's ifType 383 object requires that there is a meaningful media-specific MIB and 384 a meaningful ifType value which apply to the group of interfaces 385 as a whole. For example, it is not appropriate to treat an HDLC 386 sub-layer and an RS-232 sub-layer as a single ifTable entry when 387 the media-specific MIBs and the ifType values for HDLC and RS-232 388 are separate (rather than combined). 390 Note that the sub-layers of an interface on one device will 391 sometimes be different to the sub-layers of the interconnected 392 interface of another device. A simple example of this is a 393 frame-relay DTE interface which connects to a frameRelayService 394 interface, where the DTE interface has a different ifType value 395 and media-specific MIB to the DCE interface. 397 These guidelines are just that, guidelines. The designer of a 398 media-specific MIB is free to lay out the MIB in whatever SMI 399 conformant manner is desired. However, in doing so, the media- 400 specific MIB MUST completely specify the sub-layering model used 401 for the MIB, and provide the assumptions, reasoning, and rationale 402 used to develop that model. 404 Draft Interfaces Group MIB February 1996 406 3.1.3. Virtual Circuits 408 Several of the sub-layers for which media-specific MIB modules 409 have been defined are connection oriented (e.g., Frame Relay, 410 X.25). Experience has shown that each effort to define such a MIB 411 module revisits the question of whether separate conceptual rows 412 in the ifTable are needed for each virtual circuit. Most, if not 413 all, of these efforts to date have decided to have all virtual 414 circuits reference a single conceptual row in the ifTable. 416 This memo strongly recommends that connection-oriented sub-layers 417 do not have a conceptual row in the ifTable for each virtual 418 circuit. This avoids the proliferation of conceptual rows, 419 especially those which have considerable redundant information. 420 (Note, as a comparison, that connection-less sub-layers do not 421 have conceptual rows for each remote address.) There may, 422 however, be circumstances under which it is appropriate for a 423 virtual circuit of a connection-oriented sub-layer to have its own 424 conceptual row in the ifTable; an example of this might be PPP 425 over an X.25 virtual circuit. The MIB in section 5 of this memo 426 supports such circumstances. 428 If a media-specific MIB wishes to assign an entry in the ifTable 429 to each virtual circuit, the MIB designer must present the 430 rationale for this decision in the media-specific MIB's 431 specification. 433 3.1.4. Bit, Character, and Fixed-Length Interfaces 435 RS-232 is an example of a character-oriented sub-layer over which 436 (e.g., through use of PPP) IP datagrams can be sent. Due to the 437 packet-based nature of many of the objects in the ifTable, 438 experience has shown that it is not appropriate to have a 439 character-oriented sub-layer represented by a whole conceptual row 440 in the ifTable. 442 Experience has also shown that it is sometimes desirable to have 443 some management information for bit-oriented interfaces, which are 444 similarly difficult to represent by a whole conceptual row in the 445 ifTable. For example, to manage the channels of a DS1 circuit, 446 where only some of the channels are carrying packet-based data. 448 A further complication is that some subnetwork technologies 449 transmit data in fixed length transmission units. One example of 450 such a technology is cell relay, and in particular Asynchronous 451 Draft Interfaces Group MIB February 1996 453 Transfer Mode (ATM), which transmits data in fixed-length cells. 454 Representing such a interface as a packet-based interface produces 455 redundant objects if the relationship between the number of 456 packets and the number of octets in either direction is fixed by 457 the size of the transmission unit (e.g., the size of a cell). 459 About half the objects in the ifTable are applicable to every type 460 of interface: packet-oriented, character-oriented, and bit- 461 oriented. Of the other half, two are applicable to both 462 character-oriented and packet-oriented interfaces, and the rest 463 are applicable only to packet-oriented interfaces. Thus, while it 464 is desirable for consistency to be able to represent any/all types 465 of interfaces in the ifTable, it is not possible to implement the 466 full ifTable for bit- and character-oriented sub-layers. 468 A rejected solution to this problem would be to split the ifTable 469 into two (or more) new MIB tables, one of which would contain 470 objects that are relevant only to packet-oriented interfaces 471 (e.g., PPP), and another that may be used by all interfaces. This 472 is highly undesirable since it would require changes in every 473 agent implementing the ifTable (i.e., just about every existing 474 SNMP agent). 476 The solution adopted in this memo builds upon the fact that 477 compliance statements in SNMPv2 (in contrast to SNMPv1) refer to 478 object groups, where object groups are explicitly defined by 479 listing the objects they contain. Thus, in SNMPv2, multiple 480 compliance statements can be specified, one for all interfaces and 481 additional ones for specific types of interfaces. The separate 482 compliance statements can be based on separate object groups, 483 where the object group for all interfaces can contain only those 484 objects from the ifTable which are appropriate for every type of 485 interfaces. Using this solution, every sub-layer can have its own 486 conceptual row in the ifTable. 488 Thus, section 5 of this memo contains definitions of the objects 489 of the existing 'interfaces' group of MIB-II, in a manner which is 490 both SNMPv2-compliant and semantically-equivalent to the existing 491 MIB-II definitions. With equivalent semantics, and with the BER 492 ("on the wire") encodings unchanged, these definitions retain the 493 same OBJECT IDENTIFIER values as assigned by MIB-II. Thus, in 494 general, no rewrite of existing agents which conform to MIB-II and 495 the ifExtensions MIB is required. 497 Draft Interfaces Group MIB February 1996 499 In addition, this memo defines several object groups for the 500 purposes of defining which objects apply to which types of 501 interface: 503 (1) the ifGeneralInformationGroup. This group contains those 504 objects applicable to all types of network interfaces, 505 including bit-oriented interfaces. 507 (2) the ifPacketGroup. This group contains those objects 508 applicable to packet-oriented network interfaces. 510 (3) the ifFixedLengthGroup. This group contains the objects 511 applicable not only to character-oriented interfaces, such as 512 RS-232, but also to those subnetwork technologies, such as 513 cell-relay/ATM, which transmit data in fixed length 514 transmission units. As well as the octet counters, there are 515 also a few other counters (e.g., the error counters) which 516 are useful for this type of interface, but are currently 517 defined as being packet-oriented. To accommodate this, the 518 definitions of these counters are generalized to apply to 519 character-oriented interfaces and fixed-length-transmission 520 interfaces. 522 It should be noted that the octet counters in the ifTable 523 aggregate octet counts for unicast and non-unicast packets into a 524 single octet counter per direction (received/transmitted). Thus, 525 with the above definition of fixed-length-transmission interfaces, 526 where such interfaces which support non-unicast packets, separate 527 counts of unicast and multicast/broadcast transmissions can only 528 be maintained in a media-specific MIB module. 530 3.1.5. Interface Numbering 532 MIB-II defines an object, ifNumber, whose value represents: 534 "The number of network interfaces (regardless of their 535 current state) present on this system." 537 Each interface is identified by a unique value of the ifIndex 538 object, and the description of ifIndex constrains its value as 539 follows: 541 "Its value ranges between 1 and the value of ifNumber. The 542 value for each interface must remain constant at least from 543 one re-initialization of the entity's network management 545 Draft Interfaces Group MIB February 1996 547 system to the next re-initialization." 549 This constancy requirement on the value of ifIndex for a 550 particular interface is vital for efficient management. However, 551 an increasing number of devices allow for the dynamic 552 addition/removal of network interfaces. One example of this is a 553 dynamic ability to configure the use of SLIP/PPP over a 554 character-oriented port. For such dynamic additions/removals, the 555 combination of the constancy requirement and the restriction that 556 the value of ifIndex is less than ifNumber is problematic. 558 Redefining ifNumber to be the largest value of ifIndex was 559 rejected since it would not help. Such a re-definition would 560 require ifNumber to be deprecated and the utility of the redefined 561 object would be questionable. Alternatively, ifNumber could be 562 deprecated and not replaced. However, the deprecation of ifNumber 563 would require a change to that portion of ifIndex's definition 564 which refers to ifNumber. So, since the definition of ifIndex 565 must be changed anyway in order to solve the problem, changes to 566 ifNumber do not benefit the solution. 568 The solution adopted in this memo is just to delete the 569 requirement that the value of ifIndex must be less than the value 570 of ifNumber, and to retain ifNumber with its current definition. 571 This is a minor change in the semantics of ifIndex; however, all 572 existing agent implementations conform to this new definition, and 573 in the interests of not requiring changes to existing agent 574 implementations and to the many existing media-specific MIBs, this 575 memo assumes that this change does not require ifIndex to be 576 deprecated. Experience indicates that this assumption does 577 "break" a few management applications, but this is considered 578 preferable to breaking all agent implementations. 580 This solution also results in the possibility of "holes" in the 581 ifTable, i.e., the ifIndex values of conceptual rows in the 582 ifTable are not necessarily contiguous, but SNMP's GetNext (and 583 SNMPv2's GetBulk) operation easily deals with such holes. The 584 value of ifNumber still represents the number of conceptual rows, 585 which increases/decreases as new interfaces are dynamically 586 added/removed. The vital constancy requirement is met by 587 requiring that after an interface is dynamically removed, its 588 ifIndex value is not re-used (by a different dynamically added 589 interface) until after the following re-initialization of the 590 network management system. This avoids the need for a priori 591 assignment of ifIndex values for all possible interfaces which 592 Draft Interfaces Group MIB February 1996 594 might be added dynamically. 596 The exact meaning of a "different" interface is hard to define, 597 and there will be gray areas. One important criterion is that a 598 management station, not noticing that an interface has gone away 599 and another come into existence, should not be confused when it 600 calculates the difference between the counter values retrieved on 601 successive polls for a particular ifIndex value. However, any 602 firm definition in this document would likely to turn out to be 603 inadequate. Instead, the following guidelines are offered to 604 allow implementors to choose what "different" means in their 605 particular situation. 607 A previously-unused value of ifIndex should be assigned to a 608 dynamically added interface if: 610 (1) an agent has no knowledge of whether the interface is the 611 "same" or "different" to a previously incarnated interface, 612 or 614 (2) an agent knows that the interface is the "same" as a 615 previously incarnated interface, but the assignment of the 616 previously-used ifIndex value to the interface could result 617 in a discontinuity in the values of ifTable counters for that 618 value of ifIndex. 620 Note that discontinuities in the values of ifTable counters 621 can be avoided if an implementation is able to retain the 622 counter values when an interface goes away and restore them 623 on the interface's re-appearance. 625 Note that ifIndex values may change to identify different 626 interfaces upon a re-initialization (e.g., a reboot) of the agent, 627 which can be detected by the value of sysUpTime being reset to 628 zero. Note also that some agents support multiple "naming 629 scopes", i.e., for an SNMPv1 agent, multiple values of the SNMPv1 630 community string. For such an agent (e.g., a CNM agent which 631 supports a different subset of interfaces for different 632 customers), there is no required relationship between the ifIndex 633 values which identify interfaces in one naming scope and those 634 which identify interfaces in another naming scope. It is the 635 agent's choice as to whether the same or different ifIndex values 636 identify the same or different interfaces in different naming 637 scopes. 639 Draft Interfaces Group MIB February 1996 641 Because of the restriction of the value of ifIndex to be less than 642 ifNumber, interfaces have been numbered with small integer values. 643 This has led to the ability by humans to use the ifIndex values as 644 (somewhat) user-friendly names for network interfaces (e.g., 645 "interface number 3"). With the relaxation of the restriction on 646 the value of ifIndex, there is now the possibility that ifIndex 647 values could be assigned as very large numbers (e.g., memory 648 addresses). Such numbers would be much less user-friendly. 649 Therefore, this memo recommends that ifIndex values still be 650 assigned as (relatively) small integer values starting at 1, even 651 though the values in use at any one time are not necessarily 652 contiguous. (Note that this makes remembering which values have 653 been assigned easy for agents which dynamically add new 654 interfaces) 656 A new problem is introduced by representing each sub-layer as an 657 ifTable entry. Previously, there usually was a simple, direct, 658 mapping of interfaces to the physical ports on systems. This 659 mapping would be based on the ifIndex value. However, by having 660 an ifTable entry for each interface sub-layer, mapping from 661 interfaces to physical ports becomes increasingly problematic. 663 To address this issue, a new object, ifName, is added to the MIB. 664 This object contains the device's local name (e.g., the name used 665 at the device's local console) for the interface of which the 666 relevant entry in the ifTable is a component. For example, 667 consider a router having an interface composed of PPP running over 668 an RS-232 port. If the router uses the name "wan1" for the 669 (combined) interface, then the ifName objects for the 670 corresponding PPP and RS-232 entries in the ifTable would both 671 have the value "wan1". On the other hand, if the router uses the 672 name "wan1.1" for the PPP interface and "wan1.2" for the RS-232 673 port, then the ifName objects for the corresponding PPP and RS-232 674 entries in the ifTable would have the values "wan1.1" and 675 "wan1.2", respectively. As an another example, consider an agent 676 which responds to SNMP queries concerning an interface on some 677 other (proxied) device: if such a proxied device associates a 678 particular identifier with an interface, then it is appropriate to 679 use this identifier as the value of the interface's ifName, since 680 the local console in this case is that of the proxied device. 682 In contrast, the existing ifDescr object is intended to contain a 683 description of an interface, whereas another new object, ifAlias, 684 provides a location in which a network management application can 685 store a non-volatile interface-naming value of its own choice. 687 Draft Interfaces Group MIB February 1996 689 The ifAlias object allows a network manager to give one or more 690 interfaces their own unique names, irrespective of any interface- 691 stack relationship. Further, the ifAlias name is non-volatile, 692 and thus an interface must retain its assigned ifAlias value 693 across reboots, even if an agent chooses a new ifIndex value for 694 the interface. 696 3.1.6. Counter Size 698 As the speed of network media increase, the minimum time in which 699 a 32 bit counter will wrap decreases. For example, a 10Mbs stream 700 of back-to-back, full-size packets causes ifInOctets to wrap in 701 just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 702 minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that 703 interfaces be polled frequently enough not to miss a counter wrap 704 is increasingly problematic. 706 A rejected solution to this problem was to scale the counters; for 707 example, ifInOctets could be changed to count received octets in, 708 e.g., 1024 byte blocks. While it would provide acceptable 709 functionality at high rates of the counted-events, at low rates it 710 suffers. If there is little traffic on an interface, there might 711 be a significant interval before enough of the counted-events 712 occur to cause the scaled counter to be incremented. Traffic 713 would then appear to be very bursty, leading to incorrect 714 conclusions of the network's performance. 716 Instead, this memo adopts expanded, 64 bit, counters. These 717 counters are provided in new "high capacity" groups. The old, 718 32-bit, counters have not been deprecated. The 64-bit counters 719 are to be used only when the 32-bit counters do not provide enough 720 capacity; that is, when the 32 bit counters could wrap too fast. 722 For interfaces that operate at 20,000,000 (20 million) bits per 723 second or less, 32-bit byte and packet counters MUST be used. For 724 interfaces that operate faster than 20,000,000 bits/second, and 725 slower than 650,000,000 bits/second, 32-bit packet counters MUST 726 be used and 64-bit octet counters MUST be used. For interfaces 727 that operate at 650,000,000 bits/second or faster, 64-bit packet 728 counters AND 64-bit octet counters MUST be used. 730 These speed thresholds were chosen as reasonable compromises based 731 on the following: 733 Draft Interfaces Group MIB February 1996 735 (1) The cost of maintaining 64-bit counters is relatively high, 736 so minimizing the number of agents which must support them is 737 desirable. Common interfaces (such as 10Mbs Ethernet) should 738 not require them. 740 (2) 64-bit counters are a new feature, introduced in SNMPv2. It 741 is reasonable to expect that support for them will be spotty 742 for the immediate future. Thus, we wish to limit them to as 743 few systems as possible. This, in effect, means that 64-bit 744 counters should be limited to higher speed interfaces. 745 Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are 746 fairly wide-spread so it seems reasonable to not require 64- 747 bit counters for these interfaces. 749 (3) The 32-bit octet counters will wrap in the following times, 750 for the following interfaces (when transmitting maximum-sized 751 packets back-to-back): 753 - 10Mbs Ethernet: 57 minutes, 755 - 16Mbs Token Ring: 36 minutes, 757 - a US T3 line (45 megabits): 12 minutes, 759 - FDDI: 5.7 minutes 761 (4) The 32-bit packet counters wrap in about 57 minutes when 64- 762 byte packets are transmitted back-to-back on a 650,000,000 763 bit/second link. 765 As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 766 bit octet counter to wrap in just under 5 years. Conversely, an 767 81,000,000 terabit/second link is required to cause a 64-bit 768 counter to wrap in 30 minutes. We believe that, while technology 769 rapidly marches forward, this link speed will not be achieved for 770 at least several years, leaving sufficient time to evaluate the 771 introduction of 96 bit counters. 773 When 64-bit counters are in use, the 32-bit counters MUST still be 774 available. They will report the low 32-bits of the associated 775 64-bit count (e.g., ifInOctets will report the least significant 776 32 bits of ifHCInOctets). This enhances inter-operability with 777 existing implementations at a very minimal cost to agents. 779 Draft Interfaces Group MIB February 1996 781 The new "high capacity" groups are: 783 (1) the ifHCFixedLengthGroup for character-oriented/fixed-length 784 interfaces, and the ifHCPacketGroup for packet-based 785 interfaces; both of these groups include 64 bit counters for 786 octets, and 788 (2) the ifVHCPacketGroup for packet-based interfaces; this group 789 includes 64 bit counters for octets and packets. 791 3.1.7. Interface Speed 793 Network speeds are increasing. The range of ifSpeed is limited to 794 reporting a maximum speed of (2**31)-1 bits/second, or 795 approximately 2.2Gbs. SONET defines an OC-48 interface, which is 796 defined at operating at 48 times 51 Mbs, which is a speed in 797 excess of 2.4Gbs. Thus, ifSpeed is insufficient for the future, 798 and this memo defines an additional object: ifHighSpeed. 800 The ifHighSpeed object reports the speed of the interface in 801 1,000,000 (1 million) bits/second units. Thus, the true speed of 802 the interface will be the value reported by this object, plus or 803 minus 500,000 bits/second. 805 Other alternatives considered (but rejected) were: 807 (1) Making the interface speed a 64-bit gauge. This was rejected 808 since the current SMI does not allow such a syntax. 810 Furthermore, even if 64-bit gauges were available, their use 811 would require additional complexity in agents due to an 812 increased requirement for 64-bit operations. 814 (2) We also considered making "high-32 bit" and "low-32-bit" 815 objects which, when combined, would be a 64-bit value. This 816 simply seemed overly complex for what we are trying to do. 818 Furthermore, a full 64-bits of precision does not seem 819 necessary. The value of ifHighSpeed will be the only report 820 of interface speed for interfaces that are faster than 821 4,294,967,295 bits per second. At this speed, the 822 granularity of ifHighSpeed will be 1,000,000 bits per second, 823 thus the error will be 1/4294, or about 0.02%. This seems 824 reasonable. 826 Draft Interfaces Group MIB February 1996 828 (3) Adding a "scale" object, which would define the units which 829 ifSpeed's value is. 831 This would require two additional objects; one for the 832 scaling object, and one to replace the current ifSpeed. This 833 later object is required since the semantics of ifSpeed would 834 be significantly altered, and manager stations which do not 835 understand the new semantics would be confused. 837 3.1.8. Multicast/Broadcast Counters 839 In MIB-II, the ifTable counters for multicast and broadcast 840 packets are combined as counters of non-unicast packets. In 841 contrast, the ifExtensions MIB [7] defined one set of counters for 842 multicast, and a separate set for broadcast packets. With the 843 separate counters, the original combined counters become 844 redundant. To avoid this redundancy, the non-unicast counters are 845 deprecated. 847 For the output broadcast and multicast counters defined in RFC 848 1229, their definitions varied slightly from the packet counters 849 in the ifTable, in that they did not count errors/discarded 850 packets. Thus, this memo defines new objects with better aligned 851 definitions. Counters with 64 bits of range are also needed, as 852 explained above. 854 3.1.9. Trap Enable 856 In the multi-layer interface model, each sub-layer for which there 857 is an entry in the ifTable can generate linkUp/Down Traps. Since 858 interface state changes would tend to propagate through the 859 interface (from top to bottom, or bottom to top), it is likely 860 that several traps would be generated for each linkUp/Down 861 occurrence. 863 It is desirable to provide a mechanism for manager stations to 864 control the generation of these traps. To this end, the 865 ifLinkUpDownTrapEnable object has been added. This object allows 866 managers to limit generation of traps to just the sub-layers of 867 interest. 869 The default setting should limit the number of traps generated to 870 one per interface per linkUp/Down event. Furthermore, it seems 871 that the state changes of most interest to network managers occur 872 at the lowest level of an interface stack. Therefore we specify 873 Draft Interfaces Group MIB February 1996 875 that by default, only the lowest sub-layer of the interface 876 generate traps. 878 3.1.10. Addition of New ifType values 880 Over time, there is the need to add new ifType enumerated values 881 for new interface types. If the syntax of ifType were defined in 882 the MIB in section 5, then a new version of this MIB would have to 883 be re-issued in order to define new values. In the past, re- 884 issuing of a MIB has occurred only after several years. 886 Therefore, the syntax of ifType is changed to be a textual 887 convention, such that the enumerated integer values are now 888 defined in the textual convention, IANAifType, defined in a 889 different document. This allows additional values to be 890 documented without having to re-issue a new version of this 891 document. The Internet Assigned Number Authority (IANA) is 892 responsible for the assignment of all Internet numbers, including 893 various SNMP-related numbers, and specifically, new ifType values. 895 3.1.11. InterfaceIndex Textual Convention 897 A new textual convention, InterfaceIndex, has been defined. This 898 textual convention "contains" all of the semantics of the ifIndex 899 object. This allows other mib modules to easily import the 900 semantics of ifIndex. 902 3.1.12. New states for IfOperStatus 904 Two new states have been added to ifOperStatus: 'dormant' and 905 'notPresent'. 907 The dormant state indicates that the relevant interface is not 908 actually in a condition to pass packets (i.e. up) but is in a 909 "pending" state, waiting for some external event. For "on-demand" 910 interfaces, this new state identifies the situation where the 911 interface is waiting for events to place it in the up state. 912 Examples of such events might be: 914 (1) having packets to transmit before establishing a connection 915 to a remote system; 917 (2) having a remote system establish a connection to the 918 interface (e.g. dialing up to a slip-server). 920 Draft Interfaces Group MIB February 1996 922 The notPresent state is a refinement on the down state which 923 indicates that the relevant interface is down specifically because 924 some component (typically, a hardware component) is not present in 925 the managed system. Examples of use of the notPresent state are: 927 (1) to allow an interface's conceptual row including its counter 928 values to be retained across a "hot swap" of a card/module, 929 and/or 931 (2) to allow an interface's conceptual row to be created, and 932 thereby enable interfaces to be pre-configured prior to 933 installation of the hardware needed to make the interface 934 operational. 936 Agents are not required to support interfaces in the notPresent 937 state. However, from a conceptual viewpoint, when a row in the 938 ifTable is created, it first enters the notPresent state and then 939 subsequently transistions into the down state; similarly, when a 940 row in the ifTable is deleted, it first enters the notPresent 941 state and then subsequently the object instances are deleted. For 942 an agent with no support for notPresent, both of these transitions 943 (from the notPresent state to the down state, and from the 944 notPresent state to the instances being removed) are immediate, 945 i.e., the transition does not last long enough to be recorded by 946 ifOperStatus. Even for those agents which do support interfaces 947 in the notPresent state, the length of time and conditions under 948 which an interface stays in the notPresent state is 949 implementation-specific. 951 3.1.13. IfAdminStatus and IfOperStatus 953 The down state of ifOperStatus now has two meanings, depending on 954 the value of ifAdminStatus. 956 (1) if ifAdminStatus is not down and ifOperStatus is down then a 957 fault condition is presumed to exist on the interface. 959 (2) if ifAdminStatus is down, then ifOperStatus will normally 960 also be down (or notPresent) i.e., there is not (necessarily) 961 a fault condition on the interface. 963 Note that when ifAdminStatus transitions to down, ifOperStatus 964 will normally also transition to down. In this situation, it is 965 possible that ifOperStatus's transition will not occur 966 immediately, but rather after a small time lag to complete certain 967 Draft Interfaces Group MIB February 1996 969 operations before going "down"; for example, it might need to 970 finish transmitting a packet. If a manager station finds that 971 ifAdminStatus is down and ifOperStatus is not down for a 972 particular interface, the manager station should wait a short 973 while and check again. If the condition still exists, only then 974 should it raise an error indication. Naturally, it should also 975 ensure that ifLastChange has not changed during this interval. 977 Whenever an interface table entry is created (usually as a result 978 of system initialization), the relevant instance of ifAdminStatus 979 is set to down, and presumably ifOperStatus will be down or 980 notPresent. 982 An interface may be enabled in two ways: either as a result of 983 explicit management action (i.e. setting ifAdminStatus to up) or 984 as a result of the managed system's initialization process. When 985 ifAdminStatus changes to the up state, the related ifOperStatus 986 should do one of the following: 988 (1) Change to the up state if and only if the interface is able 989 to send and receive packets. 991 (2) Change to the dormant state if and only if the interface is 992 found to be operable, but the interface is waiting for other, 993 external, events to occur before it can transmit or receive 994 packets. Presumably when the expected events occur, the 995 interface will then change to the up state. 997 (3) Remain in the down state if an error or other fault condition 998 is detected on the interface. 1000 (4) Change to the unknown state if, for some reason, the state of 1001 the interface can not be ascertained. 1003 (5) Change to the testing state if some test(s) must be performed 1004 on the interface. Presumably after completion of the test, 1005 the interface's state will change to up, dormant, or down, as 1006 appropriate. 1008 (6) Remain in the notPresent state if interface components are 1009 missing. 1011 Draft Interfaces Group MIB February 1996 1013 3.1.14. IfOperStatus in an Interface Stack 1015 When an interface is a part of an interface-stack, but is not the 1016 lowest interface in the stack, then: 1018 (1) ifOperStatus has the value 'down' while all interfaces below 1019 it in the stack are either 'down', 'notPresent', 'unknown' or 1020 'testing'. 1022 (2) ifOperStatus has the value 'dormant' if one or more 1023 interfaces below it in the stack are 'dormant', and all 1024 others below it are either 'down', 'notPresent', 'unknown' or 1025 'testing'. 1027 (3) ifOperStatus has the value 'up' if it is able to pass packets 1028 due to one or more interfaces below it in the stack being 1029 'up', irrespective of whether other interfaces below it are 1030 'down', 'dormant', 'notPresent', 'unknown' or 'testing'. 1032 3.1.15. Traps 1034 The exact definition of when linkUp and linkDown traps are 1035 generated has been changed to reflect the changes to ifAdminStatus 1036 and ifOperStatus. 1038 Operational experience indicates that management stations are most 1039 concerned with an interface being in the down state and the fact 1040 that this state may indicate a failure. Thus, it is most useful 1041 to instrument transitions into/out of either the up state or the 1042 down state. 1044 Instrumenting transitions into or out of the up state was rejected 1045 since it would have the drawback that a demand interface might 1046 have many transitions between up and dormant, leading to many 1047 linkUp traps and no linkDown traps. Furthermore, if a node's only 1048 interface is the demand interface, then a transition to dormant 1049 would entail generation of a linkDown trap, necessitating bringing 1050 the link to the up state (and a linkUp trap)!! 1052 On the other hand, instrumenting transitions into or out of the 1053 down state (to/from all other states except notPresent) has the 1054 advantages: 1056 (1) A transition into the down state (from a state other than 1057 notPresent) will occur when an error is detected on an 1059 Draft Interfaces Group MIB February 1996 1061 interface. Error conditions are presumably of great interest 1062 to network managers. 1064 (2) Departing the down state (to a state other than the 1065 notPresent state) generally indicates that the interface is 1066 going to either up or dormant, both of which are considered 1067 "healthy" states. 1069 Furthermore, it is believed that generating traps on transitions 1070 into or out of the down state (except to/from the notPresent 1071 state) is generally consistent with current usage and 1072 interpretation of these traps by manager stations. 1074 Transistions to/from the notPresent are concerned with the 1075 insertion and removal of hardware, and are outside the scope of 1076 these traps. 1078 Therefore, this memo defines that LinkUp and linkDown traps are 1079 generated on just after ifOperStatus leaves, or just before it 1080 enters, the down state, respectively; except that LinkUp and 1081 linkDown traps never generated on transitions to/from the 1082 notPresent state. 1084 Note that this definition allows a node with only one interface to 1085 transmit a linkDown trap before that interface goes down. (Of 1086 course, when the interface is going down because of a failure 1087 condition, the linkDown trap probably cannot be successfully 1088 transmitted anyway.) 1090 Some interfaces perform a link "training" function when trying to 1091 bring the interface up. In the event that such an interface were 1092 defective, then the training function would fail and the interface 1093 would remain down, and the training function might be repeated at 1094 appropriate intervals. If the interface, while performing this 1095 training function, were considered to the in the testing state, 1096 then linkUp and linkDown traps would be generated for each start 1097 and end of the training function. This is not the intent of the 1098 linkUp and linkDown traps, and therefore, while performing such a 1099 training function, the interface's state should be represented as 1100 down. 1102 3.1.16. ifSpecific 1104 The original definition of the OBJECT IDENTIFIER value of 1105 ifSpecific was not sufficiently clear. As a result, different 1106 Draft Interfaces Group MIB February 1996 1108 implementors have used it differently, and confusion has resulted. 1109 Some implementations have the value of ifSpecific be the OBJECT 1110 IDENTIFIER that defines the media-specific MIB, i.e., the "foo" 1111 of: 1112 foo OBJECT IDENTIFIER ::= { transmission xxx } 1114 while others have it be OBJECT IDENTIFIER of the specific table or 1115 entry in the appropriate media-specific MIB (e.g. fooTable or 1116 fooEntry), while still others have it be the OBJECT IDENTIFIER of 1117 the index object of the table's row, including instance 1118 identifier, (e.g., fooIfIndex.ifIndex). A definition based on the 1119 latter would not be sufficient unless it also allowed for media- 1120 specific MIBs which include several tables, where each table has 1121 its own (different) indexing. 1123 The only definition that can both be made explicit and can cover 1124 all the useful situations is to have ifSpecific be the most 1125 general value for the media-specific MIB module (the first example 1126 given above). This effectively makes it redundant because it 1127 contains no more information than is provided by ifType. Thus, 1128 ifSpecific has been deprecated. 1130 3.1.17. Creation/Deletion of Interfaces 1132 While some interfaces, for example, most physical interfaces, 1133 cannot be created via network management, other interfaces such as 1134 logical interfaces sometimes can be. The ifTable contains only 1135 generic information about an interface. Almost all 'create-able' 1136 interfaces have other, media-specific, information through which 1137 configuration parameters may be supplied prior to creating such an 1138 interface. Thus, the ifTable does not itself support the creation 1139 or deletion of an interface (i.e., it has no RowStatus [2] 1140 column). Rather, if a particular interface type supports the 1141 dynamic creation and/or deletion of an interface of that type, 1142 then that media-specific MIB should include an appropriate 1143 RowStatus object (see the ATM LAN-Emulation Client MIB [8] for an 1144 example of a MIB which does this). Typically, when such a 1145 RowStatus object is created/deleted, then the conceptual row in 1146 the ifTable appears/disappears as a by-product, and an ifIndex 1147 value (chosen by the agent) is stored in an appropriate object in 1148 the media-specific MIB. 1150 Draft Interfaces Group MIB February 1996 1152 3.1.18. All Values Must be Known 1154 There are a number of situations where an agent does not know the 1155 value of one or more objects for a particular interface. In all 1156 such circumstances, an agent MUST NOT instantiate an object with 1157 an incorrect value; rather, it MUST respond with the appropriate 1158 error/exception condition (e.g., noSuchInstance for SNMPv2). 1160 One example is where an agent is unable to count the occurrences 1161 defined by one (or more) of the ifTable counters. In this 1162 circumstance, the agent MUST NOT instantiate the particular 1163 counter with a value of, say, zero. To do so would be to provide 1164 mis-information to a network management application reading the 1165 zero value, and thereby assuming that there have been no 1166 occurrences of the event (e.g., no input errors because ifInErrors 1167 is always zero). 1169 Sometimes the lack of knowledge of an object's value is temporary. 1170 For example, when the MTU of an interface is a configured value 1171 and a device dynamically learns the configured value through 1172 (after) exchanging messages over the interface (e.g., ATM LAN- 1173 Emulation [8]). In such a case, the value is not known until 1174 after the ifTable entry has already been created. In such a case, 1175 the ifTable entry should be created without an instance of the 1176 object whose value is unknown; later, when the value becomes 1177 known, the missing object can then be instantiated (e.g., the 1178 instance of ifMtu is only instantiated once the interface's MTU 1179 becomes known). 1181 As a result of this "known values" rule, management applications 1182 MUST be able to cope with the responses to retrieving the object 1183 instances within a conceptual row of the ifTable revealing that 1184 some of the row's columnar objects are missing/not available. 1186 Draft Interfaces Group MIB February 1996 1188 4. Media-Specific MIB Applicability 1190 The exact use and semantics of many objects in this MIB are open 1191 to some interpretation. This is a result of the generic nature of 1192 this MIB. It is not always possible to come up with specific, 1193 unambiguous, text that covers all cases and yet preserves the 1194 generic nature of the MIB. 1196 Therefore, it is incumbent upon a media-specific MIB designer to, 1197 wherever necessary, clarify the use of the objects in this MIB 1198 with respect to the media-specific MIB. 1200 Specific areas of clarification include 1202 Layering Model 1203 The media-specific MIB designer MUST completely and 1204 unambiguously specify the layering model used. Each 1205 individual sub-layer must be identified, as must the 1206 ifStackTable's portrayal of the relationship(s) between the 1207 sub-layers. 1209 Virtual Circuits 1210 The media-specific MIB designer MUST specify whether virtual 1211 circuits are assigned entries in the ifTable or not. If they 1212 are, compelling rationale must be presented. 1214 ifRcvAddressTable 1215 The media-specific MIB designer MUST specify the 1216 applicability of the ifRcvAddressTable. 1218 ifType 1219 For each of the ifType values to which the media-specific MIB 1220 applies, it must specify the mapping of ifType values to 1221 media-specific MIB module(s) and instances of MIB objects 1222 within those modules. 1224 However, wherever this interface MIB is specific in the semantics, 1225 DESCRIPTION, or applicability of objects, the media-specific MIB 1226 designer MUST NOT change said semantics, DESCRIPTION, or 1227 applicability. 1229 Draft Interfaces Group MIB February 1996 1231 5. Overview 1233 This MIB consists of 4 tables: 1235 ifTable 1236 This table is the ifTable from MIB-II. 1238 ifXTable 1239 This table contains objects that have been added to the 1240 Interface MIB as a result of the Interface Evolution effort, 1241 or replacements for objects of the original (MIB-II) ifTable 1242 that were deprecated because the semantics of said objects 1243 have significantly changed. This table also contains objects 1244 that were previously in the ifExtnsTable. 1246 ifStackTable 1247 This table contains objects that define the relationships 1248 among the sub-layers of an interface. 1250 ifRcvAddressTable 1251 This table contains objects that are used to define the 1252 media-level addresses which this interface will receive. 1253 This table is a generic table. The designers of media- 1254 specific MIBs must define exactly how this table applies to 1255 their specific MIB. 1257 Draft Interfaces Group MIB February 1996 1259 6. Interfaces Group Definitions 1261 IF-MIB DEFINITIONS ::= BEGIN 1263 IMPORTS 1264 MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, 1265 Integer32, TimeTicks, 1266 NOTIFICATION-TYPE FROM SNMPv2-SMI 1267 TEXTUAL-CONVENTION, DisplayString, 1268 PhysAddress, TruthValue, RowStatus, 1269 AutonomousType, TestAndIncr FROM SNMPv2-TC 1270 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 1271 snmpTraps FROM SNMPv2-MIB 1272 IANAifType FROM IANAifType-MIB 1273 mib-2, interfaces FROM RFC1213-MIB; 1275 ifMIB MODULE-IDENTITY 1276 LAST-UPDATED "9602221355Z" 1277 ORGANIZATION "IETF Interfaces MIB Working Group" 1278 CONTACT-INFO 1279 " Keith McCloghrie 1280 Cisco Systems, Inc. 1281 170 West Tasman Drive 1282 San Jose, CA 95134-1706 1283 US 1285 408-526-5260 1286 kzm@cisco.com" 1287 DESCRIPTION 1288 "The MIB module to describe generic objects for 1289 network interface sub-layers. This MIB is an updated 1290 version of MIB-II's ifTable, and incorporates the 1291 extensions defined in RFC 1229." 1292 REVISION "9602282155Z" 1293 DESCRIPTION 1294 "Revisions made by the Interfaces MIB WG." 1295 REVISION "9311082155Z" 1296 DESCRIPTION 1297 "Initial revision, published as part of RFC 1573." 1298 ::= { mib-2 31 } 1300 ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 } 1301 Draft Interfaces Group MIB February 1996 1303 -- OwnerString has the same semantics as used in RFC 1271 1305 OwnerString ::= TEXTUAL-CONVENTION 1306 DISPLAY-HINT "255a" 1307 STATUS current 1308 DESCRIPTION 1309 "This data type is used to model an administratively 1310 assigned name of the owner of a resource. This 1311 information is taken from the NVT ASCII character set. 1312 It is suggested that this name contain one or more of 1313 the following: ASCII form of the manager station's 1314 transport address, management station name (e.g., 1315 domain name), network management personnel's name, 1316 location, or phone number. In some cases the agent 1317 itself will be the owner of an entry. In these cases, 1318 this string shall be set to a string starting with 1319 'agent'." 1320 SYNTAX OCTET STRING (SIZE(0..255)) 1322 -- InterfaceIndex contains the semantics of ifIndex and 1323 -- should be used for any objects defined on other mib 1324 -- modules that need these semantics. 1326 InterfaceIndex ::= TEXTUAL-CONVENTION 1327 DISPLAY-HINT "d" 1328 STATUS current 1329 DESCRIPTION 1330 "A unique value, greater than zero, for each interface 1331 or interface sub-layer in the managed system. It is 1332 recommended that values are assigned contiguously 1333 starting from 1. The value for each interface sub- 1334 layer must remain constant at least from one re- 1335 initialization of the entity's network management 1336 system to the next re-initialization." 1337 SYNTAX Integer32 (1..2147483647) 1339 Draft Interfaces Group MIB February 1996 1341 InterfaceIndexOrZero ::= TEXTUAL-CONVENTION 1342 DISPLAY-HINT "d" 1343 STATUS current 1344 DESCRIPTION 1345 "This textual convention is an extension of the 1346 InterfaceIndex convention. The latter defines a 1347 greater than zero to identify an interface or 1348 interface sub-layer in the managed system. This 1349 extension permits the additional value of zero. the 1350 value zero is object-specific and must therefore be 1351 defined as part of the description of any object which 1352 uses this syntax. Examples of the usage of zero might 1353 include situations where interface was unknown, or 1354 when none or all interfaces need to be referenced." 1355 SYNTAX Integer32 (0..2147483647) 1357 Draft Interfaces Group MIB February 1996 1359 ifNumber OBJECT-TYPE 1360 SYNTAX Integer32 1361 MAX-ACCESS read-only 1362 STATUS current 1363 DESCRIPTION 1364 "The number of network interfaces (regardless of their 1365 current state) present on this system." 1366 ::= { interfaces 1 } 1368 ifTableLastChange OBJECT-TYPE 1369 SYNTAX TimeTicks 1370 MAX-ACCESS read-only 1371 STATUS current 1372 DESCRIPTION 1373 "The value of sysUpTime at the time of the last 1374 creation or deletion of an entry in the ifTable. If 1375 the number of entries has been unchanged since the 1376 last re-initialization of the local network management 1377 subsystem, then this object contains a zero value." 1378 ::= { ifMIBObjects 5 } 1380 -- the Interfaces table 1382 -- The Interfaces table contains information on the entity's 1383 -- interfaces. Each sub-layer below the internetwork-layer 1384 -- of a network interface is considered to be an interface. 1386 ifTable OBJECT-TYPE 1387 SYNTAX SEQUENCE OF IfEntry 1388 MAX-ACCESS not-accessible 1389 STATUS current 1390 DESCRIPTION 1391 "A list of interface entries. The number of entries 1392 is given by the value of ifNumber." 1393 ::= { interfaces 2 } 1395 ifEntry OBJECT-TYPE 1396 SYNTAX IfEntry 1397 MAX-ACCESS not-accessible 1398 STATUS current 1399 DESCRIPTION 1400 "An entry containing management information applicable 1401 to a particular interface." 1402 INDEX { ifIndex } 1404 Draft Interfaces Group MIB February 1996 1406 ::= { ifTable 1 } 1408 IfEntry ::= 1409 SEQUENCE { 1410 ifIndex InterfaceIndex, 1411 ifDescr DisplayString, 1412 ifType IANAifType, 1413 ifMtu Integer32, 1414 ifSpeed Gauge32, 1415 ifPhysAddress PhysAddress, 1416 ifAdminStatus INTEGER, 1417 ifOperStatus INTEGER, 1418 ifLastChange TimeTicks, 1419 ifInOctets Counter32, 1420 ifInUcastPkts Counter32, 1421 ifInNUcastPkts Counter32, -- deprecated 1422 ifInDiscards Counter32, 1423 ifInErrors Counter32, 1424 ifInUnknownProtos Counter32, 1425 ifOutOctets Counter32, 1426 ifOutUcastPkts Counter32, 1427 ifOutNUcastPkts Counter32, -- deprecated 1428 ifOutDiscards Counter32, 1429 ifOutErrors Counter32, 1430 ifOutQLen Gauge32, -- deprecated 1431 ifSpecific OBJECT IDENTIFIER -- deprecated 1432 } 1434 ifIndex OBJECT-TYPE 1435 SYNTAX InterfaceIndex 1436 MAX-ACCESS read-only 1437 STATUS current 1438 DESCRIPTION 1439 "A unique value, greater than zero, for each 1440 interface. It is recommended that values are assigned 1441 contiguously starting from 1. The value for each 1442 interface sub-layer must remain constant at least from 1443 one re-initialization of the entity's network 1444 management system to the next re-initialization." 1445 ::= { ifEntry 1 } 1447 ifDescr OBJECT-TYPE 1448 SYNTAX DisplayString (SIZE (0..255)) 1449 MAX-ACCESS read-only 1451 Draft Interfaces Group MIB February 1996 1453 STATUS current 1454 DESCRIPTION 1455 "A textual string containing information about the 1456 interface. This string should include the name of the 1457 manufacturer, the product name and the version of the 1458 interface hardware/software." 1459 ::= { ifEntry 2 } 1461 ifType OBJECT-TYPE 1462 SYNTAX IANAifType 1463 MAX-ACCESS read-only 1464 STATUS current 1465 DESCRIPTION 1466 "The type of interface. Additional values for ifType 1467 are assigned by the Internet Assigned Numbers 1468 Authority (IANA), through updating the syntax of the 1469 IANAifType textual convention." 1470 ::= { ifEntry 3 } 1472 ifMtu OBJECT-TYPE 1473 SYNTAX Integer32 1474 MAX-ACCESS read-only 1475 STATUS current 1476 DESCRIPTION 1477 "The size of the largest packet which can be 1478 sent/received on the interface, specified in octets. 1479 For interfaces that are used for transmitting network 1480 datagrams, this is the size of the largest network 1481 datagram that can be sent on the interface." 1482 ::= { ifEntry 4 } 1484 ifSpeed OBJECT-TYPE 1485 SYNTAX Gauge32 1486 MAX-ACCESS read-only 1487 STATUS current 1488 DESCRIPTION 1489 "An estimate of the interface's current bandwidth in 1490 bits per second. For interfaces which do not vary in 1491 bandwidth or for those where no accurate estimation 1492 can be made, this object should contain the nominal 1493 bandwidth. If the bandwidth of the interface is 1494 greater than the maximum value reportable by this 1495 object then this object should report its maximum 1496 value (4,294,967,295) and ifHighSpeed must be used to 1497 report the interace's speed. For a sub-layer which 1499 Draft Interfaces Group MIB February 1996 1501 has no concept of bandwidth, this object should be 1502 zero." 1503 ::= { ifEntry 5 } 1505 ifPhysAddress OBJECT-TYPE 1506 SYNTAX PhysAddress 1507 MAX-ACCESS read-only 1508 STATUS current 1509 DESCRIPTION 1510 "The interface's address at its protocol sub-layer. 1511 For example, for an 802.x interface, this object 1512 normally contains a MAC address. The interface's 1513 media-specific MIB must define the bit and byte 1514 ordering and the format of the value of this object. 1515 For interfaces which do not have such an address 1516 (e.g., a serial line), this object should contain an 1517 octet string of zero length." 1518 ::= { ifEntry 6 } 1520 ifAdminStatus OBJECT-TYPE 1521 SYNTAX INTEGER { 1522 up(1), -- ready to pass packets 1523 down(2), 1524 testing(3) -- in some test mode 1525 } 1526 MAX-ACCESS read-write 1527 STATUS current 1528 DESCRIPTION 1529 "The desired state of the interface. The testing(3) 1530 state indicates that no operational packets can be 1531 passed. When a managed system initializes, all 1532 interfaces start with ifAdminStatus in the down(2) 1533 state. As a result of either explicit management 1534 action or per configuration information retained by 1535 the managed system, ifAdminStatus is then changed to 1536 either the up(1) or testing(3) states (or remains in 1537 the down(2) state)." 1538 ::= { ifEntry 7 } 1540 ifOperStatus OBJECT-TYPE 1541 SYNTAX INTEGER { 1542 up(1), -- ready to pass packets 1543 down(2), 1544 testing(3), -- in some test mode 1545 unknown(4), -- status can not be determined 1547 Draft Interfaces Group MIB February 1996 1549 -- for some reason. 1550 dormant(5), 1551 notPresent(6) -- some component is missing 1552 } 1553 MAX-ACCESS read-only 1554 STATUS current 1555 DESCRIPTION 1556 "The current operational state of the interface. The 1557 testing(3) state indicates that no operational packets 1558 can be passed. If ifAdminStatus is down(2) then 1559 ifOperStatus should be down(2). If ifAdminStatus is 1560 changed to up(1) then ifOperStatus should change to 1561 up(1) if the interface is ready to transmit and 1562 receive network traffic; it should change to 1563 dormant(5) if the interface is waiting for external 1564 actions (such as a serial line waiting for an incoming 1565 connection); it should remain in the down(2) state if 1566 and only if there is a fault that prevents if from 1567 going to the up(1) state; it should remain in the 1568 notPresent(6) state if the interface has missing 1569 (typically, hardware) components." 1570 ::= { ifEntry 8 } 1572 ifLastChange OBJECT-TYPE 1573 SYNTAX TimeTicks 1574 MAX-ACCESS read-only 1575 STATUS current 1576 DESCRIPTION 1577 "The value of sysUpTime at the time the interface 1578 entered its current operational state. If the current 1579 state was entered prior to the last re-initialization 1580 of the local network management subsystem, then this 1581 object contains a zero value." 1582 ::= { ifEntry 9 } 1584 ifInOctets OBJECT-TYPE 1585 SYNTAX Counter32 1586 MAX-ACCESS read-only 1587 STATUS current 1588 DESCRIPTION 1589 "The total number of octets received on the interface, 1590 including framing characters." 1591 ::= { ifEntry 10 } 1593 ifInUcastPkts OBJECT-TYPE 1594 Draft Interfaces Group MIB February 1996 1596 SYNTAX Counter32 1597 MAX-ACCESS read-only 1598 STATUS current 1599 DESCRIPTION 1600 "The number of packets, delivered by this sub-layer to 1601 a higher (sub-)layer, which were not addressed to a 1602 multicast or broadcast address at this sub-layer." 1603 ::= { ifEntry 11 } 1605 ifInNUcastPkts OBJECT-TYPE 1606 SYNTAX Counter32 1607 MAX-ACCESS read-only 1608 STATUS deprecated 1609 DESCRIPTION 1610 "The number of packets, delivered by this sub-layer to 1611 a higher (sub-)layer, which were addressed to a 1612 multicast or broadcast address at this sub-layer. 1614 This object is deprecated in favour of 1615 ifInMulticastPkts and ifInBroadcastPkts." 1616 ::= { ifEntry 12 } 1618 ifInDiscards OBJECT-TYPE 1619 SYNTAX Counter32 1620 MAX-ACCESS read-only 1621 STATUS current 1622 DESCRIPTION 1623 "The number of inbound packets which were chosen to be 1624 discarded even though no errors had been detected to 1625 prevent their being deliverable to a higher-layer 1626 protocol. One possible reason for discarding such a 1627 packet could be to free up buffer space." 1628 ::= { ifEntry 13 } 1630 ifInErrors OBJECT-TYPE 1631 SYNTAX Counter32 1632 MAX-ACCESS read-only 1633 STATUS current 1634 DESCRIPTION 1635 "For packet-oriented interfaces, the number of inbound 1636 packets that contained errors preventing them from 1637 being deliverable to a higher-layer protocol. For 1638 character-oriented or fixed-length interfaces, the 1639 number of inbound transmission units that contained 1640 errors preventing them from being deliverable to a 1642 Draft Interfaces Group MIB February 1996 1644 higher-layer protocol." 1645 ::= { ifEntry 14 } 1647 ifInUnknownProtos OBJECT-TYPE 1648 SYNTAX Counter32 1649 MAX-ACCESS read-only 1650 STATUS current 1651 DESCRIPTION 1652 "For packet-oriented interfaces, the number of packets 1653 received via the interface which were discarded 1654 because of an unknown or unsupported protocol. For 1655 character-oriented or fixed-length interfaces which 1656 support protocol multiplexing the number of 1657 transmission units received via the interface which 1658 were discarded because of an unknown or unsupported 1659 protocol. For any interface which does not support 1660 protocol multiplexing, this counter will always be 0." 1661 ::= { ifEntry 15 } 1663 ifOutOctets OBJECT-TYPE 1664 SYNTAX Counter32 1665 MAX-ACCESS read-only 1666 STATUS current 1667 DESCRIPTION 1668 "The total number of octets transmitted out of the 1669 interface, including framing characters." 1670 ::= { ifEntry 16 } 1672 ifOutUcastPkts OBJECT-TYPE 1673 SYNTAX Counter32 1674 MAX-ACCESS read-only 1675 STATUS current 1676 DESCRIPTION 1677 "The total number of packets that higher-level 1678 protocols requested be transmitted, and which were not 1679 addressed to a multicast or broadcast address at this 1680 sub-layer, including those that were discarded or not 1681 sent." 1682 ::= { ifEntry 17 } 1684 ifOutNUcastPkts OBJECT-TYPE 1685 SYNTAX Counter32 1686 MAX-ACCESS read-only 1687 STATUS deprecated 1688 DESCRIPTION 1690 Draft Interfaces Group MIB February 1996 1692 "The total number of packets that higher-level 1693 protocols requested be transmitted, and which were 1694 addressed to a multicast or broadcast address at this 1695 sub-layer, including those that were discarded or not 1696 sent. 1698 This object is deprecated in favour of 1699 ifOutMulticastPkts and ifOutBroadcastPkts." 1700 ::= { ifEntry 18 } 1702 ifOutDiscards OBJECT-TYPE 1703 SYNTAX Counter32 1704 MAX-ACCESS read-only 1705 STATUS current 1706 DESCRIPTION 1707 "The number of outbound packets which were chosen to 1708 be discarded even though no errors had been detected 1709 to prevent their being transmitted. One possible 1710 reason for discarding such a packet could be to free 1711 up buffer space." 1712 ::= { ifEntry 19 } 1714 ifOutErrors OBJECT-TYPE 1715 SYNTAX Counter32 1716 MAX-ACCESS read-only 1717 STATUS current 1718 DESCRIPTION 1719 "For packet-oriented interfaces, the number of 1720 outbound packets that could not be transmitted because 1721 of errors. For character-oriented or fixed-length 1722 interfaces, the number of outbound transmission units 1723 that could not be transmitted because of errors." 1724 ::= { ifEntry 20 } 1726 ifOutQLen OBJECT-TYPE 1727 SYNTAX Gauge32 1728 MAX-ACCESS read-only 1729 STATUS deprecated 1730 DESCRIPTION 1731 "The length of the output packet queue (in packets)." 1732 ::= { ifEntry 21 } 1734 ifSpecific OBJECT-TYPE 1735 SYNTAX OBJECT IDENTIFIER 1736 MAX-ACCESS read-only 1738 Draft Interfaces Group MIB February 1996 1740 STATUS deprecated 1741 DESCRIPTION 1742 "A reference to MIB definitions specific to the 1743 particular media being used to realize the interface. 1744 It is recommended that this value point to an instance 1745 of a MIB object in the media-specific MIB, i.e., that 1746 this object have the semantics associated with the 1747 InstancePointer textual convention defined in RFC 1748 1903. In fact, it is recommended that the media- 1749 specific MIB specify what value ifSpecific should/can 1750 take for values of ifType. If no MIB definitions 1751 specific to the particular media are available, the 1752 value should be set to the OBJECT IDENTIFIER { 0 0 }." 1753 ::= { ifEntry 22 } 1755 -- 1756 -- Extension to the interface table 1757 -- 1758 -- This table replaces the ifExtnsTable table. 1759 -- 1761 ifXTable OBJECT-TYPE 1762 SYNTAX SEQUENCE OF IfXEntry 1763 MAX-ACCESS not-accessible 1764 STATUS current 1765 DESCRIPTION 1766 "A list of interface entries. The number of entries 1767 is given by the value of ifNumber. This table 1768 contains additional objects for the interface table." 1769 ::= { ifMIBObjects 1 } 1771 ifXEntry OBJECT-TYPE 1772 SYNTAX IfXEntry 1773 MAX-ACCESS not-accessible 1774 STATUS current 1775 DESCRIPTION 1776 "An entry containing additional management information 1777 applicable to a particular interface." 1778 AUGMENTS { ifEntry } 1779 ::= { ifXTable 1 } 1781 IfXEntry ::= 1782 SEQUENCE { 1784 Draft Interfaces Group MIB February 1996 1786 ifName DisplayString, 1787 ifInMulticastPkts Counter32, 1788 ifInBroadcastPkts Counter32, 1789 ifOutMulticastPkts Counter32, 1790 ifOutBroadcastPkts Counter32, 1791 ifHCInOctets Counter64, 1792 ifHCInUcastPkts Counter64, 1793 ifHCInMulticastPkts Counter64, 1794 ifHCInBroadcastPkts Counter64, 1795 ifHCOutOctets Counter64, 1796 ifHCOutUcastPkts Counter64, 1797 ifHCOutMulticastPkts Counter64, 1798 ifHCOutBroadcastPkts Counter64, 1799 ifLinkUpDownTrapEnable INTEGER, 1800 ifHighSpeed Gauge32, 1801 ifPromiscuousMode TruthValue, 1802 ifConnectorPresent TruthValue, 1803 ifAlias DisplayString 1804 } 1806 ifName OBJECT-TYPE 1807 SYNTAX DisplayString 1808 MAX-ACCESS read-only 1809 STATUS current 1810 DESCRIPTION 1811 "The textual name of the interface. The value of this 1812 object should be the name of the interface as assigned 1813 by the local device and should be suitable for use in 1814 commands entered at the device's `console'. This 1815 might be a text name, such as `le0' or a simple port 1816 number, such as `1', depending on the interface naming 1817 syntax of the device. If several entries in the 1818 ifTable together represent a single interface as named 1819 by the device, then each will have the same value of 1820 ifName. Note that for an agent which responds to SNMP 1821 queries concerning an interface on some other 1822 (proxied) device, then the value of ifName for such an 1823 interface is the proxied device's local name for it. 1825 If there is no local name, or this object is otherwise 1826 not applicable, then this object contains a zero- 1827 length string." 1828 ::= { ifXEntry 1 } 1830 Draft Interfaces Group MIB February 1996 1832 ifInMulticastPkts OBJECT-TYPE 1833 SYNTAX Counter32 1834 MAX-ACCESS read-only 1835 STATUS current 1836 DESCRIPTION 1837 "The number of packets, delivered by this sub-layer to 1838 a higher (sub-)layer, which were addressed to a 1839 multicast address at this sub-layer. For a MAC layer 1840 protocol, this includes both Group and Functional 1841 addresses." 1842 ::= { ifXEntry 2 } 1844 ifInBroadcastPkts OBJECT-TYPE 1845 SYNTAX Counter32 1846 MAX-ACCESS read-only 1847 STATUS current 1848 DESCRIPTION 1849 "The number of packets, delivered by this sub-layer to 1850 a higher (sub-)layer, which were addressed to a 1851 broadcast address at this sub-layer." 1852 ::= { ifXEntry 3 } 1854 ifOutMulticastPkts OBJECT-TYPE 1855 SYNTAX Counter32 1856 MAX-ACCESS read-only 1857 STATUS current 1858 DESCRIPTION 1859 "The total number of packets that higher-level 1860 protocols requested be transmitted, and which were 1861 addressed to a multicast address at this sub-layer, 1862 including those that were discarded or not sent. For 1863 a MAC layer protocol, this includes both Group and 1864 Functional addresses." 1865 ::= { ifXEntry 4 } 1867 ifOutBroadcastPkts OBJECT-TYPE 1868 SYNTAX Counter32 1869 MAX-ACCESS read-only 1870 STATUS current 1871 DESCRIPTION 1872 "The total number of packets that higher-level 1873 protocols requested be transmitted, and which were 1874 addressed to a broadcast address at this sub-layer, 1875 including those that were discarded or not sent." 1876 ::= { ifXEntry 5 } 1878 Draft Interfaces Group MIB February 1996 1880 -- 1881 -- High Capacity Counter objects. These objects are all 1882 -- 64 bit versions of the "basic" ifTable counters. These 1883 -- objects all have the same basic semantics as their 32-bit 1884 -- counterparts, however, their syntax has been extended 1885 -- to 64 bits. 1886 -- 1888 ifHCInOctets OBJECT-TYPE 1889 SYNTAX Counter64 1890 MAX-ACCESS read-only 1891 STATUS current 1892 DESCRIPTION 1893 "The total number of octets received on the interface, 1894 including framing characters. This object is a 64-bit 1895 version of ifInOctets." 1896 ::= { ifXEntry 6 } 1898 ifHCInUcastPkts OBJECT-TYPE 1899 SYNTAX Counter64 1900 MAX-ACCESS read-only 1901 STATUS current 1902 DESCRIPTION 1903 "The number of packets, delivered by this sub-layer to 1904 a higher (sub-)layer, which were not addressed to a 1905 multicast or broadcast address at this sub-layer. 1906 This object is a 64-bit version of ifInUcastPkts." 1907 ::= { ifXEntry 7 } 1909 ifHCInMulticastPkts OBJECT-TYPE 1910 SYNTAX Counter64 1911 MAX-ACCESS read-only 1912 STATUS current 1913 DESCRIPTION 1914 "The number of packets, delivered by this sub-layer to 1915 a higher (sub-)layer, which were addressed to a 1916 multicast address at this sub-layer. For a MAC layer 1917 protocol, this includes both Group and Functional 1918 addresses. This object is a 64-bit version of 1919 ifInMulticastPkts." 1920 ::= { ifXEntry 8 } 1922 ifHCInBroadcastPkts OBJECT-TYPE 1923 SYNTAX Counter64 1924 MAX-ACCESS read-only 1926 Draft Interfaces Group MIB February 1996 1928 STATUS current 1929 DESCRIPTION 1930 "The number of packets, delivered by this sub-layer to 1931 a higher (sub-)layer, which were addressed to a 1932 broadcast address at this sub-layer. This object is a 1933 64-bit version of ifInBroadcastPkts." 1934 ::= { ifXEntry 9 } 1936 ifHCOutOctets OBJECT-TYPE 1937 SYNTAX Counter64 1938 MAX-ACCESS read-only 1939 STATUS current 1940 DESCRIPTION 1941 "The total number of octets transmitted out of the 1942 interface, including framing characters. This object 1943 is a 64-bit version of ifOutOctets." 1944 ::= { ifXEntry 10 } 1946 ifHCOutUcastPkts OBJECT-TYPE 1947 SYNTAX Counter64 1948 MAX-ACCESS read-only 1949 STATUS current 1950 DESCRIPTION 1951 "The total number of packets that higher-level 1952 protocols requested be transmitted, and which were not 1953 addressed to a multicast or broadcast address at this 1954 sub-layer, including those that were discarded or not 1955 sent. This object is a 64-bit version of 1956 ifOutUcastPkts." 1957 ::= { ifXEntry 11 } 1959 ifHCOutMulticastPkts OBJECT-TYPE 1960 SYNTAX Counter64 1961 MAX-ACCESS read-only 1962 STATUS current 1963 DESCRIPTION 1964 "The total number of packets that higher-level 1965 protocols requested be transmitted, and which were 1966 addressed to a multicast address at this sub-layer, 1967 including those that were discarded or not sent. For 1968 a MAC layer protocol, this includes both Group and 1969 Functional addresses. This object is a 64-bit version 1970 of ifOutMulticastPkts." 1971 ::= { ifXEntry 12 } 1973 Draft Interfaces Group MIB February 1996 1975 ifHCOutBroadcastPkts OBJECT-TYPE 1976 SYNTAX Counter64 1977 MAX-ACCESS read-only 1978 STATUS current 1979 DESCRIPTION 1980 "The total number of packets that higher-level 1981 protocols requested be transmitted, and which were 1982 addressed to a broadcast address at this sub-layer, 1983 including those that were discarded or not sent. This 1984 object is a 64-bit version of ifOutBroadcastPkts." 1985 ::= { ifXEntry 13 } 1987 ifLinkUpDownTrapEnable OBJECT-TYPE 1988 SYNTAX INTEGER { enabled(1), disabled(2) } 1989 MAX-ACCESS read-write 1990 STATUS current 1991 DESCRIPTION 1992 "Indicates whether linkUp/linkDown traps should be 1993 generated for this interface. 1995 By default, this object should have the value 1996 enabled(1) for interfaces which do not operate on 1997 'top' of any other interface (as defined in the 1998 ifStackTable), and disabled(2) otherwise." 1999 ::= { ifXEntry 14 } 2001 ifHighSpeed OBJECT-TYPE 2002 SYNTAX Gauge32 2003 MAX-ACCESS read-only 2004 STATUS current 2005 DESCRIPTION 2006 "An estimate of the interface's current bandwidth in 2007 units of 1,000,000 bits per second. If this object 2008 reports a value of `n' then the speed of the interface 2009 is somewhere in the range of `n-500,000' to 2010 `n+499,999'. For interfaces which do not vary in 2011 bandwidth or for those where no accurate estimation 2012 can be made, this object should contain the nominal 2013 bandwidth. For a sub-layer which has no concept of 2014 bandwidth, this object should be zero." 2015 ::= { ifXEntry 15 } 2017 ifPromiscuousMode OBJECT-TYPE 2018 SYNTAX TruthValue 2019 MAX-ACCESS read-write 2021 Draft Interfaces Group MIB February 1996 2023 STATUS current 2024 DESCRIPTION 2025 "This object has a value of false(2) if this interface 2026 only accepts packets/frames that are addressed to this 2027 station. This object has a value of true(1) when the 2028 station accepts all packets/frames transmitted on the 2029 media. The value true(1) is only legal on certain 2030 types of media. If legal, setting this object to a 2031 value of true(1) may require the interface to be reset 2032 before becoming effective. 2034 The value of ifPromiscuousMode does not affect the 2035 reception of broadcast and multicast packets/frames by 2036 the interface." 2037 ::= { ifXEntry 16 } 2039 ifConnectorPresent OBJECT-TYPE 2040 SYNTAX TruthValue 2041 MAX-ACCESS read-only 2042 STATUS current 2043 DESCRIPTION 2044 "This object has the value 'true(1)' if the interface 2045 sublayer has a physical connector and the value 2046 'false(2)' otherwise." 2047 ::= { ifXEntry 17 } 2049 ifAlias OBJECT-TYPE 2050 SYNTAX DisplayString (SIZE(0..64)) 2051 MAX-ACCESS read-write 2052 STATUS current 2053 DESCRIPTION 2054 "This object is an 'alias' name for the interface as 2055 specified by a network manager, and provides a non- 2056 volatile 'handle' for the interface. 2058 On the first instantiation of an interface, the value 2059 of ifAlias associated with that interface is the 2060 zero-length string. As and when a value is written 2061 into an instance of ifAlias through a network 2062 management set operation, then the agent must retain 2063 the supplied value in the ifAlias instance associated 2064 with the same interface for as long as that interface 2065 remains instantiated, including across all re- 2066 initializations/reboots of the network management 2067 system, including those which result in a change of 2069 Draft Interfaces Group MIB February 1996 2071 the interface's ifIndex value. 2073 An example of the value which a network manager might 2074 store in this object for a WAN interface is the 2075 (Telco's) circuit number/identifier of the interface. 2077 Some agents may support write-access only for 2078 interfaces having particular values of ifType. An 2079 agent which supports write access to this object is 2080 required to keep the value in non-volatile storage, 2081 but it may limit the length of new values depending on 2082 how much storage is already occupied by the current 2083 values for other interfaces." 2084 ::= { ifXEntry 18 } 2086 Draft Interfaces Group MIB February 1996 2088 -- The Interface Stack Group 2089 -- 2090 -- Implementation of this group is mandatory for all systems 2091 -- 2093 ifStackTable OBJECT-TYPE 2094 SYNTAX SEQUENCE OF IfStackEntry 2095 MAX-ACCESS not-accessible 2096 STATUS current 2097 DESCRIPTION 2098 "The table containing information on the relationships 2099 between the multiple sub-layers of network interfaces. 2100 In particular, it contains information on which sub- 2101 layers run 'on top of' which other sub-layers, where 2102 each sub-layer corresponds to a conceptual row in the 2103 ifTable. For example, when the sub-layer with ifIndex 2104 value x runs over the sub-layer with ifIndex value y, 2105 then this table contains: 2107 ifStackStatus.x.y=active 2109 For each ifIndex value, I, which identifies an active 2110 interface, there are always at least two instantiated 2111 rows in this table associated with I. For one of 2112 these rows, I is the value of ifStackHigherLayer; for 2113 the other, I is the value of ifStackLowerLayer. 2115 For example, two rows exist even for an interface 2116 which has no others stacked on top or below it: 2118 ifStackStatus.0.x=active 2119 ifStackStatus.x.0=active " 2120 ::= { ifMIBObjects 2 } 2122 ifStackEntry OBJECT-TYPE 2123 SYNTAX IfStackEntry 2124 MAX-ACCESS not-accessible 2125 STATUS current 2126 DESCRIPTION 2127 "Information on a particular relationship between two 2128 sub-layers, specifying that one sub-layer runs on 2129 'top' of the other sub-layer. Each sub-layer 2130 corresponds to a conceptual row in the ifTable." 2131 INDEX { ifStackHigherLayer, ifStackLowerLayer } 2133 Draft Interfaces Group MIB February 1996 2135 ::= { ifStackTable 1 } 2137 IfStackEntry ::= 2138 SEQUENCE { 2139 ifStackHigherLayer Integer32, 2140 ifStackLowerLayer Integer32, 2141 ifStackStatus RowStatus 2142 } 2144 ifStackHigherLayer OBJECT-TYPE 2145 SYNTAX Integer32 2146 MAX-ACCESS not-accessible 2147 STATUS current 2148 DESCRIPTION 2149 "The value of ifIndex corresponding to the higher 2150 sub-layer of the relationship, i.e., the sub-layer 2151 which runs on 'top' of the sub-layer identified by the 2152 corresponding instance of ifStackLowerLayer. If there 2153 is no higher sub-layer (below the internetwork layer), 2154 then this object has the value 0." 2155 ::= { ifStackEntry 1 } 2157 ifStackLowerLayer OBJECT-TYPE 2158 SYNTAX Integer32 2159 MAX-ACCESS not-accessible 2160 STATUS current 2161 DESCRIPTION 2162 "The value of ifIndex corresponding to the lower sub- 2163 layer of the relationship, i.e., the sub-layer which 2164 runs 'below' the sub-layer identified by the 2165 corresponding instance of ifStackHigherLayer. If 2166 there is no lower sub-layer, then this object has the 2167 value 0." 2168 ::= { ifStackEntry 2 } 2170 ifStackStatus OBJECT-TYPE 2171 SYNTAX RowStatus 2172 MAX-ACCESS read-create 2173 STATUS current 2174 DESCRIPTION 2175 "The status of the relationship between two sub- 2177 Draft Interfaces Group MIB February 1996 2179 layers. 2181 Changing the value of this object from 'active' to 2182 'notInService' or 'destroy' will likely have 2183 consequences up and down the interface stack. Thus, 2184 write access to this object is likely to be 2185 inappropriate for some types of interfaces, and many 2186 implementations will choose not to support write- 2187 access for any type of interface." 2188 ::= { ifStackEntry 3 } 2190 ifStackLastChange OBJECT-TYPE 2191 SYNTAX TimeTicks 2192 MAX-ACCESS read-only 2193 STATUS current 2194 DESCRIPTION 2195 "The value of sysUpTime at the time of the last change 2196 of the (whole) interface stack. A change of the 2197 interface stack is defined to be any creation, 2198 deletion, or change in value of any instance of 2199 ifStackStatus. If the interface stack has been 2200 unchanged since the last re-initialization of the 2201 local network management subsystem, then this object 2202 contains a zero value." 2203 ::= { ifMIBObjects 6 } 2205 -- Generic Receive Address Table 2206 -- 2207 -- This group of objects is mandatory for all types of 2208 -- interfaces which can receive packets/frames addressed to 2209 -- more than one address. 2210 -- 2211 -- This table replaces the ifExtnsRcvAddr table. The main 2212 -- difference is that this table makes use of the RowStatus 2213 -- textual convention, while ifExtnsRcvAddr did not. 2215 ifRcvAddressTable OBJECT-TYPE 2216 SYNTAX SEQUENCE OF IfRcvAddressEntry 2217 MAX-ACCESS not-accessible 2218 STATUS current 2219 DESCRIPTION 2220 "This table contains an entry for each address 2221 (broadcast, multicast, or uni-cast) for which the 2222 system will receive packets/frames on a particular 2224 Draft Interfaces Group MIB February 1996 2226 interface, except as follows: 2228 - for an interface operating in promiscuous mode, 2229 entries are only required for those addresses for 2230 which the system would receive frames were it not 2231 operating in promiscuous mode. 2233 - for 802.5 functional addresses, only one entry is 2234 required, for the address which has the functional 2235 address bit ANDed with the bit mask of all functional 2236 addresses for which the interface will accept frames. 2238 A system is normally able to use any unicast address 2239 which corresponds to an entry in this table as a 2240 source address." 2241 ::= { ifMIBObjects 4 } 2243 ifRcvAddressEntry OBJECT-TYPE 2244 SYNTAX IfRcvAddressEntry 2245 MAX-ACCESS not-accessible 2246 STATUS current 2247 DESCRIPTION 2248 "A list of objects identifying an address for which 2249 the system will accept packets/frames on the 2250 particular interface identified by the index value 2251 ifIndex." 2252 INDEX { ifIndex, ifRcvAddressAddress } 2253 ::= { ifRcvAddressTable 1 } 2255 IfRcvAddressEntry ::= 2256 SEQUENCE { 2257 ifRcvAddressAddress PhysAddress, 2258 ifRcvAddressStatus RowStatus, 2259 ifRcvAddressType INTEGER 2260 } 2262 ifRcvAddressAddress OBJECT-TYPE 2263 SYNTAX PhysAddress 2264 MAX-ACCESS not-accessible 2265 STATUS current 2266 DESCRIPTION 2267 "An address for which the system will accept 2268 packets/frames on this entry's interface." 2269 ::= { ifRcvAddressEntry 1 } 2271 Draft Interfaces Group MIB February 1996 2273 ifRcvAddressStatus OBJECT-TYPE 2274 SYNTAX RowStatus 2275 MAX-ACCESS read-create 2276 STATUS current 2277 DESCRIPTION 2278 "This object is used to create and delete rows in the 2279 ifRcvAddressTable." 2281 ::= { ifRcvAddressEntry 2 } 2283 ifRcvAddressType OBJECT-TYPE 2284 SYNTAX INTEGER { 2285 other(1), 2286 volatile(2), 2287 nonVolatile(3) 2288 } 2290 MAX-ACCESS read-create 2291 STATUS current 2292 DESCRIPTION 2293 "This object has the value nonVolatile(3) for those 2294 entries in the table which are valid and will not be 2295 deleted by the next restart of the managed system. 2296 Entries having the value volatile(2) are valid and 2297 exist, but have not been saved, so that will not exist 2298 after the next restart of the managed system. Entries 2299 having the value other(1) are valid and exist but are 2300 not classified as to whether they will continue to 2301 exist after the next restart." 2303 DEFVAL { volatile } 2304 ::= { ifRcvAddressEntry 3 } 2306 Draft Interfaces Group MIB February 1996 2308 -- definition of interface-related traps. 2310 linkDown NOTIFICATION-TYPE 2311 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2312 STATUS current 2313 DESCRIPTION 2314 "A linkDown trap signifies that the SNMPv2 entity, 2315 acting in an agent role, has detected that the 2316 ifOperStatus object for one of its communication links 2317 is about to enter the down state from some other state 2318 (but not from the notPresent state). This other state 2319 is indicated by the included value of ifOperStatus." 2320 ::= { snmpTraps 3 } 2322 linkUp NOTIFICATION-TYPE 2323 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2324 STATUS current 2325 DESCRIPTION 2326 "A linkDown trap signifies that the SNMPv2 entity, 2327 acting in an agent role, has detected that the 2328 ifOperStatus object for one of its communication links 2329 left the down state and transitioned into some other 2330 state (but not into the notPresent state). This other 2331 state is indicated by the included value of 2332 ifOperStatus." 2333 ::= { snmpTraps 4 } 2335 Draft Interfaces Group MIB February 1996 2337 -- conformance information 2339 ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 } 2341 ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 } 2342 ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 } 2344 -- compliance statements 2346 ifCompliance2 MODULE-COMPLIANCE 2347 STATUS current 2348 DESCRIPTION 2349 "The compliance statement for SNMPv2 entities which 2350 have network interfaces." 2352 MODULE -- this module 2353 MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2 } 2355 GROUP ifFixedLengthGroup 2356 DESCRIPTION 2357 "This group is mandatory for all network interfaces 2358 which are character-oriented or transmit data in 2359 fixed-length transmission units." 2361 GROUP ifHCFixedLengthGroup 2362 DESCRIPTION 2363 "This group is mandatory only for those network 2364 interfaces which are character-oriented or transmit 2365 data in fixed-length transmission units, and for which 2366 the value of the corresponding instance of ifSpeed is 2367 greater than 20,000,000 bits/second." 2369 GROUP ifPacketGroup 2370 DESCRIPTION 2371 "This group is mandatory for all network interfaces 2372 which are packet-oriented." 2374 GROUP ifHCPacketGroup 2375 DESCRIPTION 2376 "This group is mandatory only for those network 2377 interfaces which are packet-oriented and for which the 2378 value of the corresponding instance of ifSpeed is 2379 greater than 650,000,000 bits/second." 2381 Draft Interfaces Group MIB February 1996 2383 GROUP ifRcvAddressGroup 2384 DESCRIPTION 2385 "The applicability of this group MUST be defined by 2386 the media-specific MIBs. Media-specific MIBs must 2387 define the exact meaning, use, and semantics of the 2388 addresses in this group." 2390 OBJECT ifLinkUpDownTrapEnable 2391 MIN-ACCESS read-only 2392 DESCRIPTION 2393 "Write access is not required." 2395 OBJECT ifPromiscuousMode 2396 MIN-ACCESS read-only 2397 DESCRIPTION 2398 "Write access is not required." 2400 OBJECT ifStackStatus 2401 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2402 MIN-ACCESS read-only 2403 DESCRIPTION 2404 "Write access is not required, and only one of the six 2405 enumerated values for the RowStatus textual convention 2406 need be supported, specifically: active(1)." 2408 OBJECT ifAdminStatus 2409 SYNTAX INTEGER { up(1), down(2) } 2410 MIN-ACCESS read-only 2411 DESCRIPTION 2412 "Write access is not required, nor is support for the 2413 value testing(3)." 2415 OBJECT ifAlias 2416 MIN-ACCESS read-only 2417 DESCRIPTION 2418 "Write access is not required." 2420 ::= { ifCompliances 2 } 2422 Draft Interfaces Group MIB February 1996 2424 -- units of conformance 2426 ifGeneralInformationGroup OBJECT-GROUP 2427 OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress, 2428 ifAdminStatus, ifOperStatus, ifLastChange, 2429 ifLinkUpDownTrapEnable, ifConnectorPresent, 2430 ifHighSpeed, ifName, ifNumber, ifAlias, 2431 ifTableLastChange } 2432 STATUS current 2433 DESCRIPTION 2434 "A collection of objects providing information 2435 applicable to all network interfaces." 2436 ::= { ifGroups 10 } 2438 -- the following five groups are mutually exclusive; at most 2439 -- one of these groups is implemented for any interface 2441 ifFixedLengthGroup OBJECT-GROUP 2442 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2443 ifInErrors, ifOutErrors } 2444 STATUS current 2445 DESCRIPTION 2446 "A collection of objects providing information 2447 specific to non-high speed (non-high speed interfaces 2448 transmit and receive at speeds less than or equal to 2449 20,000,000 bits/second) character-oriented or fixed- 2450 length-transmission network interfaces." 2451 ::= { ifGroups 2 } 2453 ifHCFixedLengthGroup OBJECT-GROUP 2454 OBJECTS { ifHCInOctets, ifHCOutOctets, 2455 ifInOctets, ifOutOctets, ifInUnknownProtos, 2456 ifInErrors, ifOutErrors } 2457 STATUS current 2458 DESCRIPTION 2459 "A collection of objects providing information 2460 specific to high speed (greater than 20,000,000 2461 bits/second) character-oriented or fixed-length- 2462 transmission network interfaces." 2463 ::= { ifGroups 3 } 2465 ifPacketGroup OBJECT-GROUP 2466 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2467 ifInErrors, ifOutErrors, 2468 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2470 Draft Interfaces Group MIB February 1996 2472 ifInBroadcastPkts, ifInDiscards, 2473 ifOutUcastPkts, ifOutMulticastPkts, 2474 ifOutBroadcastPkts, ifOutDiscards, 2475 ifPromiscuousMode } 2476 STATUS current 2477 DESCRIPTION 2478 "A collection of objects providing information 2479 specific to non-high speed (non-high speed interfaces 2480 transmit and receive at speeds less than or equal to 2481 20,000,000 bits/second) packet-oriented network 2482 interfaces." 2483 ::= { ifGroups 4 } 2485 ifHCPacketGroup OBJECT-GROUP 2486 OBJECTS { ifHCInOctets, ifHCOutOctets, 2487 ifInOctets, ifOutOctets, ifInUnknownProtos, 2488 ifInErrors, ifOutErrors, 2489 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2490 ifInBroadcastPkts, ifInDiscards, 2491 ifOutUcastPkts, ifOutMulticastPkts, 2492 ifOutBroadcastPkts, ifOutDiscards, 2493 ifPromiscuousMode } 2494 STATUS current 2495 DESCRIPTION 2496 "A collection of objects providing information 2497 specific to high speed (greater than 20,000,000 2498 bits/second but less than or equal to 650,000,000 2499 bits/second) packet-oriented network interfaces." 2500 ::= { ifGroups 5 } 2502 ifVHCPacketGroup OBJECT-GROUP 2503 OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, 2504 ifHCInBroadcastPkts, ifHCOutUcastPkts, 2505 ifHCOutMulticastPkts, ifHCOutBroadcastPkts, 2506 ifHCInOctets, ifHCOutOctets, 2507 ifInOctets, ifOutOctets, ifInUnknownProtos, 2508 ifInErrors, ifOutErrors, 2509 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2510 ifInBroadcastPkts, ifInDiscards, 2511 ifOutUcastPkts, ifOutMulticastPkts, 2512 ifOutBroadcastPkts, ifOutDiscards, 2513 ifPromiscuousMode } 2514 STATUS current 2515 DESCRIPTION 2516 "A collection of objects providing information 2518 Draft Interfaces Group MIB February 1996 2520 specific to higher speed (greater than 650,000,000 2521 bits/second) packet-oriented network interfaces." 2522 ::= { ifGroups 6 } 2524 ifRcvAddressGroup OBJECT-GROUP 2525 OBJECTS { ifRcvAddressStatus, ifRcvAddressType } 2526 STATUS current 2527 DESCRIPTION 2528 "A collection of objects providing information on the 2529 multiple addresses which an interface receives." 2530 ::= { ifGroups 7 } 2532 ifStackGroup2 OBJECT-GROUP 2533 OBJECTS { ifStackStatus, ifStackLastChange } 2534 STATUS current 2535 DESCRIPTION 2536 "A collection of objects providing information on the 2537 layering of MIB-II interfaces." 2538 ::= { ifGroups 11 } 2540 Draft Interfaces Group MIB February 1996 2542 -- Deprecated Definitions - Objects 2544 -- 2545 -- The Interface Test Table 2546 -- 2547 -- This group of objects is optional. However, a media-specific 2548 -- MIB may make implementation of this group mandatory. 2549 -- 2550 -- This table replaces the ifExtnsTestTable 2551 -- 2553 ifTestTable OBJECT-TYPE 2554 SYNTAX SEQUENCE OF IfTestEntry 2555 MAX-ACCESS not-accessible 2556 STATUS deprecated 2557 DESCRIPTION 2558 "This table contains one entry per interface. It 2559 defines objects which allow a network manager to 2560 instruct an agent to test an interface for various 2561 faults. Tests for an interface are defined in the 2562 media-specific MIB for that interface. After invoking 2563 a test, the object ifTestResult can be read to 2564 determine the outcome. If an agent can not perform 2565 the test, ifTestResult is set to so indicate. The 2566 object ifTestCode can be used to provide further 2567 test-specific or interface-specific (or even 2568 enterprise-specific) information concerning the 2569 outcome of the test. Only one test can be in progress 2570 on each interface at any one time. If one test is in 2571 progress when another test is invoked, the second test 2572 is rejected. Some agents may reject a test when a 2573 prior test is active on another interface. 2575 Before starting a test, a manager-station must first 2576 obtain 'ownership' of the entry in the ifTestTable for 2577 the interface to be tested. This is accomplished with 2578 the ifTestId and ifTestStatus objects as follows: 2580 try_again: 2581 get (ifTestId, ifTestStatus) 2582 while (ifTestStatus != notInUse) 2583 /* 2584 * Loop while a test is running or some other 2585 * manager is configuring a test. 2587 Draft Interfaces Group MIB February 1996 2589 */ 2590 short delay 2591 get (ifTestId, ifTestStatus) 2592 } 2594 /* 2595 * Is not being used right now -- let's compete 2596 * to see who gets it. 2597 */ 2598 lock_value = ifTestId 2600 if ( set(ifTestId = lock_value, ifTestStatus = inUse, 2601 ifTestOwner = 'my-IP-address') == FAILURE) 2602 /* 2603 * Another manager got the ifTestEntry -- go 2604 * try again 2605 */ 2606 goto try_again; 2608 /* 2609 * I have the lock 2610 */ 2611 set up any test parameters. 2613 /* 2614 * This starts the test 2615 */ 2616 set(ifTestType = test_to_run); 2618 wait for test completion by polling ifTestResult 2620 when test completes, agent sets ifTestResult 2621 agent also sets ifTestStatus = 'notInUse' 2623 retrieve any additional test results, and ifTestId 2625 if (ifTestId == lock_value+1) results are valid 2627 A manager station first retrieves the value of the 2628 appropriate ifTestId and ifTestStatus objects, 2629 periodically repeating the retrieval if necessary, 2630 until the value of ifTestStatus is 'notInUse'. The 2631 manager station then tries to set the same ifTestId 2632 object to the value it just retrieved, the same 2633 ifTestStatus object to 'inUse', and the corresponding 2635 Draft Interfaces Group MIB February 1996 2637 ifTestOwner object to a value indicating itself. If 2638 the set operation succeeds then the manager has 2639 obtained ownership of the ifTestEntry, and the value of 2640 the ifTestId object is incremented by the agent (per 2641 the semantics of TestAndIncr). Failure of the set 2642 operation indicates that some other manager has 2643 obtained ownership of the ifTestEntry. 2645 Once ownership is obtained, any test parameters can be 2646 setup, and then the test is initiated by setting 2647 ifTestType. On completion of the test, the agent sets 2648 ifTestStatus to 'notInUse'. Once this occurs, the 2649 manager can retrieve the results. In the (rare) event 2650 that the invocation of tests by two network managers 2651 were to overlap, then there would be a possibility that 2652 the first test's results might be overwritten by the 2653 second test's results prior to the first results being 2654 read. This unlikely circumstance can be detected by a 2655 network manager retrieving ifTestId at the same time as 2656 retrieving the test results, and ensuring that the 2657 results are for the desired request. 2659 If ifTestType is not set within an abnormally long 2660 period of time after ownership is obtained, the agent 2661 should time-out the manager, and reset the value of the 2662 ifTestStatus object back to 'notInUse'. It is 2663 suggested that this time-out period be 5 minutes. 2665 In general, a management station must not retransmit a 2666 request to invoke a test for which it does not receive 2667 a response; instead, it properly inspects an agent's 2668 MIB to determine if the invocation was successful. 2669 Only if the invocation was unsuccessful, is the 2670 invocation request retransmitted. 2672 Some tests may require the interface to be taken off- 2673 line in order to execute them, or may even require the 2674 agent to reboot after completion of the test. In these 2675 circumstances, communication with the management 2676 station invoking the test may be lost until after 2677 completion of the test. An agent is not required to 2678 support such tests. However, if such tests are 2679 supported, then the agent should make every effort to 2680 transmit a response to the request which invoked the 2681 test prior to losing communication. When the agent is 2683 Draft Interfaces Group MIB February 1996 2685 restored to normal service, the results of the test are 2686 properly made available in the appropriate objects. 2687 Note that this requires that the ifIndex value assigned 2688 to an interface must be unchanged even if the test 2689 causes a reboot. An agent must reject any test for 2690 which it cannot, perhaps due to resource constraints, 2691 make available at least the minimum amount of 2692 information after that test completes." 2693 ::= { ifMIBObjects 3 } 2695 ifTestEntry OBJECT-TYPE 2696 SYNTAX IfTestEntry 2697 MAX-ACCESS not-accessible 2698 STATUS deprecated 2699 DESCRIPTION 2700 "An entry containing objects for invoking tests on an 2701 interface." 2702 AUGMENTS { ifEntry } 2703 ::= { ifTestTable 1 } 2705 IfTestEntry ::= 2706 SEQUENCE { 2707 ifTestId TestAndIncr, 2708 ifTestStatus INTEGER, 2709 ifTestType AutonomousType, 2710 ifTestResult INTEGER, 2711 ifTestCode OBJECT IDENTIFIER, 2712 ifTestOwner OwnerString 2713 } 2715 ifTestId OBJECT-TYPE 2716 SYNTAX TestAndIncr 2717 MAX-ACCESS read-write 2718 STATUS deprecated 2719 DESCRIPTION 2720 "This object identifies the current invocation of the 2721 interface's test." 2722 ::= { ifTestEntry 1 } 2724 ifTestStatus OBJECT-TYPE 2725 SYNTAX INTEGER { notInUse(1), inUse(2) } 2726 MAX-ACCESS read-write 2727 STATUS deprecated 2728 DESCRIPTION 2729 "This object indicates whether or not some manager 2731 Draft Interfaces Group MIB February 1996 2733 currently has the necessary 'ownership' required to 2734 invoke a test on this interface. A write to this 2735 object is only successful when it changes its value 2736 from 'notInUse(1)' to 'inUse(2)'. After completion of 2737 a test, the agent resets the value back to 2738 'notInUse(1)'." 2739 ::= { ifTestEntry 2 } 2741 ifTestType OBJECT-TYPE 2742 SYNTAX AutonomousType 2743 MAX-ACCESS read-write 2744 STATUS deprecated 2745 DESCRIPTION 2746 "A control variable used to start and stop operator- 2747 initiated interface tests. Most OBJECT IDENTIFIER 2748 values assigned to tests are defined elsewhere, in 2749 association with specific types of interface. 2750 However, this document assigns a value for a full- 2751 duplex loopback test, and defines the special meanings 2752 of the subject identifier: 2754 noTest OBJECT IDENTIFIER ::= { 0 0 } 2756 When the value noTest is written to this object, no 2757 action is taken unless a test is in progress, in which 2758 case the test is aborted. Writing any other value to 2759 this object is only valid when no test is currently in 2760 progress, in which case the indicated test is 2761 initiated. 2763 When read, this object always returns the most recent 2764 value that ifTestType was set to. If it has not been 2765 set since the last initialization of the network 2766 management subsystem on the agent, a value of noTest 2767 is returned." 2768 ::= { ifTestEntry 3 } 2770 ifTestResult OBJECT-TYPE 2771 SYNTAX INTEGER { 2772 none(1), -- no test yet requested 2773 success(2), 2774 inProgress(3), 2775 notSupported(4), 2776 unAbleToRun(5), -- due to state of system 2777 aborted(6), 2779 Draft Interfaces Group MIB February 1996 2781 failed(7) 2782 } 2783 MAX-ACCESS read-only 2784 STATUS deprecated 2785 DESCRIPTION 2786 "This object contains the result of the most recently 2787 requested test, or the value none(1) if no tests have 2788 been requested since the last reset. Note that this 2789 facility provides no provision for saving the results 2790 of one test when starting another, as could be 2791 required if used by multiple managers concurrently." 2792 ::= { ifTestEntry 4 } 2794 ifTestCode OBJECT-TYPE 2795 SYNTAX OBJECT IDENTIFIER 2796 MAX-ACCESS read-only 2797 STATUS deprecated 2798 DESCRIPTION 2799 "This object contains a code which contains more 2800 specific information on the test result, for example 2801 an error-code after a failed test. Error codes and 2802 other values this object may take are specific to the 2803 type of interface and/or test. The value may have the 2804 semantics of either the AutonomousType or 2805 InstancePointer textual conventions as defined in RFC 2806 1903. The identifier: 2808 testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } 2810 is defined for use if no additional result code is 2811 available." 2812 ::= { ifTestEntry 5 } 2814 ifTestOwner OBJECT-TYPE 2815 SYNTAX OwnerString 2816 MAX-ACCESS read-write 2817 STATUS deprecated 2818 DESCRIPTION 2819 "The entity which currently has the 'ownership' 2820 required to invoke a test on this interface." 2821 ::= { ifTestEntry 6 } 2823 Draft Interfaces Group MIB February 1996 2825 -- Deprecated Definitions - Groups 2827 ifGeneralGroup OBJECT-GROUP 2828 OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress, 2829 ifAdminStatus, ifOperStatus, ifLastChange, 2830 ifLinkUpDownTrapEnable, ifConnectorPresent, 2831 ifHighSpeed, ifName } 2832 STATUS deprecated 2833 DESCRIPTION 2834 "A collection of objects deprecated in favour of 2835 ifGeneralInformationGroup." 2836 ::= { ifGroups 1 } 2838 ifTestGroup OBJECT-GROUP 2839 OBJECTS { ifTestId, ifTestStatus, ifTestType, 2840 ifTestResult, ifTestCode, ifTestOwner } 2841 STATUS deprecated 2842 DESCRIPTION 2843 "A collection of objects providing the ability to 2844 invoke tests on an interface." 2845 ::= { ifGroups 8 } 2847 ifStackGroup OBJECT-GROUP 2848 OBJECTS { ifStackStatus } 2849 STATUS deprecated 2850 DESCRIPTION 2851 "The previous collection of objects providing 2852 information on the layering of MIB-II interfaces." 2853 ::= { ifGroups 9 } 2855 ifOldObjectsGroup OBJECT-GROUP 2856 OBJECTS { ifInNUcastPkts, ifOutNUcastPkts, 2857 ifOutQLen, ifSpecific } 2858 STATUS deprecated 2859 DESCRIPTION 2860 "The collection of objects deprecated from the 2861 original MIB-II interfaces group." 2862 ::= { ifGroups 12 } 2864 -- Deprecated Definitions - Compliance 2865 Draft Interfaces Group MIB February 1996 2867 ifCompliance MODULE-COMPLIANCE 2868 STATUS deprecated 2869 DESCRIPTION 2870 "The previous compliance statement for SNMPv2 entities 2871 which have network interfaces." 2873 MODULE -- this module 2874 MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup } 2876 GROUP ifFixedLengthGroup 2877 DESCRIPTION 2878 "This group is mandatory for all network interfaces 2879 which are character-oriented or transmit data in 2880 fixed-length transmission units." 2882 GROUP ifHCFixedLengthGroup 2883 DESCRIPTION 2884 "This group is mandatory only for those network 2885 interfaces which are character-oriented or transmit 2886 data in fixed-length transmission units, and for which 2887 the value of the corresponding instance of ifSpeed is 2888 greater than 20,000,000 bits/second." 2890 GROUP ifPacketGroup 2891 DESCRIPTION 2892 "This group is mandatory for all network interfaces 2893 which are packet-oriented." 2895 GROUP ifHCPacketGroup 2896 DESCRIPTION 2897 "This group is mandatory only for those network 2898 interfaces which are packet-oriented and for which the 2899 value of the corresponding instance of ifSpeed is 2900 greater than 650,000,000 bits/second." 2902 GROUP ifTestGroup 2903 DESCRIPTION 2904 "This group is optional. Media-specific MIBs which 2905 require interface tests are strongly encouraged to use 2906 this group for invoking tests and reporting results. 2907 A medium specific MIB which has mandatory tests may 2908 make implementation of this group mandatory." 2910 GROUP ifRcvAddressGroup 2911 DESCRIPTION 2913 Draft Interfaces Group MIB February 1996 2915 "The applicability of this group MUST be defined by 2916 the media-specific MIBs. Media-specific MIBs must 2917 define the exact meaning, use, and semantics of the 2918 addresses in this group." 2920 OBJECT ifLinkUpDownTrapEnable 2921 MIN-ACCESS read-only 2922 DESCRIPTION 2923 "Write access is not required." 2925 OBJECT ifPromiscuousMode 2926 MIN-ACCESS read-only 2927 DESCRIPTION 2928 "Write access is not required." 2930 OBJECT ifStackStatus 2931 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2932 MIN-ACCESS read-only 2933 DESCRIPTION 2934 "Write access is not required, and only one of the six 2935 enumerated values for the RowStatus textual convention 2936 need be supported, specifically: active(1)." 2938 OBJECT ifAdminStatus 2939 SYNTAX INTEGER { up(1), down(2) } 2940 MIN-ACCESS read-only 2941 DESCRIPTION 2942 "Write access is not required, nor is support for the 2943 value testing(3)." 2944 ::= { ifCompliances 1 } 2946 END 2947 Draft Interfaces Group MIB February 1996 2949 7. Acknowledgements 2951 This memo has been produced by the IETF's Interfaces MIB working- 2952 group. 2954 The original proposal evolved from conversations and discussions 2955 with many people, including at least the following: Fred Baker, 2956 Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj 2957 Tesink, and Dean Throop. 2959 Draft Interfaces Group MIB February 1996 2961 8. References 2963 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 2964 S. Waldbusser, "Structure of Management Information for 2965 version 2 of the Simple Network Management Protocol 2966 (SNMPv2)", RFC 1902, January 1996. 2968 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 2969 S. Waldbusser, "Textual Conventions for version 2 of the 2970 Simple Network Management Protocol (SNMPv2)", RFC 1903, 2971 January 1996. 2973 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 2974 S. Waldbusser, "Protocol Operations for version 2 of the 2975 Simple Network Management Protocol (SNMPv2)", RFC 1905, 2976 January 1996. 2978 [4] McCloghrie, K., and M. Rose, "Management Information Base for 2979 Network Management of TCP/IP-based internets - MIB-II", RFC 2980 1213, Hughes LAN Systems, Performance Systems International, 2981 March 1991. 2983 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 2984 Network Management Protocol", RFC 1157, SNMP Research, 2985 Performance Systems International, Performance Systems 2986 International, MIT Laboratory for Computer Science, May 1990. 2988 [6] J. Postel, "Internet Protocol", RFC 791, Information Sciences 2989 Institute, USC, September 1981. 2991 [7] K. McCloghrie, "Extensions to the Generic-Interface MIB", RFC 2992 1229, Hughes LAN Systems, May 1991. 2994 [8] ATM Forum Technical Committee, "LAN Emulation Client 2995 Management: Version 1.0 Specification", af-lane-0044.000, ATM 2996 Forum, September 1995. 2998 Draft Interfaces Group MIB February 1996 3000 9. Security Considerations 3002 Security issues are not discussed in this memo. 3004 10. Authors' Address 3006 Keith McCloghrie 3007 Cisco Systems, Inc. 3008 170 West Tasman Drive 3009 San Jose, CA 95134-1706 3011 Phone: 408-526-5260 3012 Email: kzm@cisco.com" 3014 Frank Kastenholz 3015 FTP Software 3016 2 High Street 3017 North Andover, Mass. USA 01845 3019 Phone: (508)685-4000 3020 Email: kasten@ftp.com 3022 Draft Interfaces Group MIB February 1996 3024 Table of Contents 3026 1 Introduction .............................................. 2 3027 1.1 Change Log .............................................. 2 3028 2 The SNMP Network Management Framework ..................... 5 3029 2.1 Object Definitions ...................................... 5 3030 3 Experience with the Interfaces Group ...................... 6 3031 3.1 Clarifications/Revisions ................................ 6 3032 3.1.1 Interface Sub-Layers .................................. 6 3033 3.1.2 Guidance on Defining Sub-layers ....................... 9 3034 3.1.3 Virtual Circuits ...................................... 11 3035 3.1.4 Bit, Character, and Fixed-Length Interfaces ........... 11 3036 3.1.5 Interface Numbering ................................... 13 3037 3.1.6 Counter Size .......................................... 17 3038 3.1.7 Interface Speed ....................................... 19 3039 3.1.8 Multicast/Broadcast Counters .......................... 20 3040 3.1.9 Trap Enable ........................................... 20 3041 3.1.10 Addition of New ifType values ........................ 21 3042 3.1.11 InterfaceIndex Textual Convention .................... 21 3043 3.1.12 New states for IfOperStatus .......................... 21 3044 3.1.13 IfAdminStatus and IfOperStatus ....................... 22 3045 3.1.14 IfOperStatus in an Interface Stack ................... 24 3046 3.1.15 Traps ................................................ 24 3047 3.1.16 ifSpecific ........................................... 25 3048 3.1.17 Creation/Deletion of Interfaces ...................... 26 3049 3.1.18 All Values Must be Known ............................. 27 3050 4 Media-Specific MIB Applicability .......................... 28 3051 5 Overview .................................................. 29 3052 6 Interfaces Group Definitions .............................. 30 3053 7 Acknowledgements .......................................... 69 3054 8 References ................................................ 70 3055 9 Security Considerations ................................... 71 3056 10 Authors' Address ......................................... 71