idnits 2.17.1 draft-ietf-ifmib-mib-05.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-27) 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 430: '...specific MIB MUST completely specify t...' RFC 2119 keyword, line 794: '...and packet counters MUST be used. For...' RFC 2119 keyword, line 796: '...ts/second, 32-bit packet counters MUST...' RFC 2119 keyword, line 797: '...t octet counters MUST be used. For in...' RFC 2119 keyword, line 799: '...ND 64-bit octet counters MUST be used....' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 November 1996) is 10014 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 3209, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 3219, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 3224, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 3229, 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. -------------------------------------------------------------------------------- 1 Draft Interfaces Group MIB November 1996 3 The Interfaces Group MIB 5 26 November 1996 7 draft-ietf-ifmib-mib-05.txt 9 Keith McCloghrie 10 Cisco Systems 11 kzm@cisco.com 13 Frank J. Kastenholz 14 FTP Software 15 kasten@ftp.com 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as ``work 28 in progress.'' 30 To learn the current status of any Internet-Draft, please check 31 the ``1id-abstracts.txt'' listing contained in the Internet- 32 Drafts Shadow Directories on ds.internic.net (US East Coast), 33 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 34 munnari.oz.au (Pacific Rim). 36 Draft Interfaces Group MIB November 1996 38 1. Introduction 40 This memo defines a portion of the Management Information Base 41 (MIB) for use with network management protocols in the Internet 42 community. In particular, it describes managed objects used for 43 managing Network Interfaces. 45 This memo discusses the 'interfaces' group of MIB-II, especially 46 the experience gained from the definition of numerous media- 47 specific MIB modules for use in conjunction with the 'interfaces' 48 group for managing various sub-layers beneath the internetwork- 49 layer. It specifies clarifications to, and extensions of, the 50 architectural issues within the previous model used for the 51 'interfaces' group. 53 This memo also includes a MIB module. As well as including new 54 MIB definitions to support the architectural extensions, this MIB 55 module also re-specifies the 'interfaces' group of MIB-II in a 56 manner that is both compliant to the SNMPv2 SMI and semantically- 57 identical to the existing SNMPv1-based definitions. 59 1.1. Change Log 61 This section tracks changes made to the revisions of the Internet 62 Drafts of this document. It will be deleted when the document is 63 published as an RFC. 65 26 November 1996 67 The following changes were made for the version of the document 68 dated 26 November 1996. These changes were made based on Working 69 Group email discussions following the Montreal IETF meeting. 71 (1) Added additional clarifying text for when assigning an 72 ifIndex value is appropriate. 74 (2) Added lowerLayerDown state for ifOperStatus. 76 (3) Added ifCounterDiscontinuityTime. 78 (4) Updated the description clause of each counter object covered 79 by ifCounterDiscontinuityTime (as required by RFC 1902, 80 section 7.1.6). 82 Draft Interfaces Group MIB November 1996 84 (5) Added text on rate-limiting linkUp/linkDown text. 86 (6) Minor editorial changes. 88 22 February 1996 90 The following changes were made for the version of the document 91 dated 19 February 1996. These changes were made based on Working 92 Group email discussions. 94 (1) Added InterfaceIndexOrZero textual convention. 96 (2) Added notPresent state for ifOperStatus. 98 11 February 1996 100 The following changes were made for the version of the document 101 dated 11 February 1996. These changes were made based on comments 102 received via email. 104 (1) Clarified value of ifOperStatus in linkUp and linkDown traps. 106 (2) Included ifIndex in the ifGeneralInformationGroup object 107 group. 109 (3) Supplemented the explanatory text for ifName. 111 28 January 1996 113 The following changes were made for the version of the document 114 dated 28 January 1996. These changes were made based on the output 115 of the working group's meeting at the Dallas IETF meeting. 117 (1) Changed ifStackLastChange to be a scalar object. 119 (2) Updated the definition of ifAlias. 121 (3) Added text contrasting the use of ifDescr, ifName and 122 ifAlias. 124 (4) Added section on the creation/deletion of interfaces. 126 (5) Added section on how an interface's ifOperStatus depends on 127 the states of the interfaces below it in the interface stack. 129 Draft Interfaces Group MIB November 1996 131 (6) Added clarification that a defective interface which 132 periodically tests itself does not transition to the 133 ifOperStatus=testing state while that testing is in progress. 135 26 November 1995 137 The following changes were made for the version of the document 138 dated 26 November 1995. These changes were made based on the 139 output of the working group's meeting at the Stockholm IETF 140 meeting. 142 (1) Added the ifAlias, ifStackLastChange and ifTableLastChange 143 objects. 145 (2) Defined new group definitions to contain the new objects, and 146 defined a new conformance definition. Deprecated the old 147 group and conformance definitions. 149 (3) Corrected the MAX-ACCESS clause values for 150 ifRcvAddressAddress, ifRcvAddressStatus and ifStackStatus. 152 (4) Deprecated the ifTestTable and ifTestGroup. 154 (5) Removed (to be defined elsewhere) the IANAifType-MIB MIB 155 Module. 157 (6) Re-arranged and combined the previous sections 3.1 and 3.2. 159 (7) Minor editorial changes. 161 Draft Interfaces Group MIB November 1996 163 2. The SNMP Network Management Framework 165 The SNMP Network Management Framework presently consists of three 166 major components. They are: 168 o RFC 1902 which defines the SMI, the mechanisms used for 169 describing and naming objects for the purpose of management. 171 o RFC 1213 defines MIB-II, the core set of managed objects for 172 the Internet suite of protocols. 174 o RFC 1157 and RFC 1905 which define two versions of the 175 protocol used for network access to managed objects. 177 The Framework permits new objects to be defined for the purpose of 178 experimentation and evaluation. 180 2.1. Object Definitions 182 Managed objects are accessed via a virtual information store, 183 termed the Management Information Base or MIB. Objects in the MIB 184 are defined using the subset of Abstract Syntax Notation One 185 (ASN.1) defined in the SMI. In particular, each object object 186 type is named by an OBJECT IDENTIFIER, an administratively 187 assigned name. The object type together with an object instance 188 serves to uniquely identify a specific instantiation of the 189 object. For human convenience, we often use a textual string, 190 termed the descriptor, to refer to the object type. 192 Draft Interfaces Group MIB November 1996 194 3. Experience with the Interfaces Group 196 One of the strengths of internetwork-layer protocols such as IP 197 [6] is that they are designed to run over any network interface. 198 In achieving this, IP considers any and all protocols it runs over 199 as a single "network interface" layer. A similar view is taken by 200 other internetwork-layer protocols. This concept is represented 201 in MIB-II by the 'interfaces' group which defines a generic set of 202 managed objects such that any network interface can be managed in 203 an interface-independent manner through these managed objects. 204 The 'interfaces' group provides the means for additional managed 205 objects specific to particular types of network interface (e.g., a 206 specific medium such as Ethernet) to be defined as extensions to 207 the 'interfaces' group for media-specific management. Since the 208 standardization of MIB-II, many such media-specific MIB modules 209 have been defined. 211 Experience in defining these media-specific MIB modules has shown 212 that the model defined by MIB-II is too simplistic and/or static 213 for some types of media-specific management. As a result, some of 214 these media-specific MIB modules assume an evolution or loosening 215 of the model. This memo documents and standardizes that evolution 216 of the model and fills in the gaps caused by that evolution. This 217 memo also incorporates the interfaces group extensions documented 218 in RFC 1229 [7]. 220 3.1. Clarifications/Revisions 222 There are several areas for which experience has indicated that 223 clarification, revision, or extension of the model would be 224 helpful. The following sections discuss the changes in the 225 interfaces group adopted by this memo in each of these areas. 227 In some sections, one or more paragraphs contain discussion of 228 rejected alternatives to the model adopted in this memo. Readers 229 not familiar with the MIB-II model and not interested in the 230 rationale behind the new model may want to skip these paragraphs. 232 3.1.1. Interface Sub-Layers 234 Experience in defining media-specific management information has 235 shown the need to distinguish between the multiple sub-layers 236 beneath the internetwork-layer. In addition, there is a need to 237 manage these sub-layers in devices (e.g., MAC-layer bridges) which 238 are unaware of which, if any, internetwork protocols run over 239 Draft Interfaces Group MIB November 1996 241 these sub-layers. As such, a model of having a single conceptual 242 row in the interfaces table (MIB-II's ifTable) represent a whole 243 interface underneath the internetwork-layer, and having a single 244 associated media-specific MIB module (referenced via the ifType 245 object) is too simplistic. A further problem arises with the 246 value of the ifType object which has enumerated values for each 247 type of interface. 249 Consider, for example, an interface with PPP running over an HDLC 250 link which uses a RS232-like connector. Each of these sub-layers 251 has its own media-specific MIB module. If all of this is 252 represented by a single conceptual row in the ifTable, then an 253 enumerated value for ifType is needed for that specific 254 combination which maps to the specific combination of media- 255 specific MIBs. Furthermore, such a model still lacks a method to 256 describe the relationship of all the sub-layers of the MIB stack. 258 An associated problem is that of upward and downward multiplexing 259 of the sub-layers. An example of upward multiplexing is MLP 260 (Multi-Link-Procedure) which provides load-sharing over several 261 serial lines by appearing as a single point-to-point link to the 262 sub-layer(s) above. An example of downward multiplexing would be 263 several instances of PPP, each framed within a separate X.25 264 virtual circuit, all of which run over one fractional T1 channel, 265 concurrently with other uses of the T1 link. The MIB structure 266 must allow these sorts of relationships to be described. 268 Several solutions for representing multiple sub-layers were 269 rejected. One was to retain the concept of one conceptual row for 270 all the sub-layers of an interface and have each media-specific 271 MIB module identify its "superior" and "subordinate" sub-layers 272 through OBJECT IDENTIFIER "pointers". This scheme would have 273 several drawbacks: the superior/subordinate pointers would be 274 contained in the media-specific MIB modules; thus, a manager could 275 not learn the structure of an interface without inspecting 276 multiple pointers in different MIB modules; this would be overly 277 complex and only possible if the manager had knowledge of all the 278 relevant media-specific MIB modules; MIB modules would all need to 279 be retrofitted with these new "pointers"; this scheme would not 280 adequately address the problem of upward and downward 281 multiplexing; and finally, enumerated values of ifType would be 282 needed for each combination of sub-layers. Another rejected 283 solution also retained the concept of one conceptual row for all 284 the sub-layers of an interface but had a new separate MIB table to 285 identify the "superior" and "subordinate" sub-layers and to 286 Draft Interfaces Group MIB November 1996 288 contain OBJECT IDENTIFIER "pointers" to the media-specific MIB 289 module for each sub-layer. Effectively, one conceptual row in the 290 ifTable would represent each combination of sub-layers between the 291 internetwork-layer and the wire. While this scheme has fewer 292 drawbacks, it still would not support downward multiplexing, such 293 as PPP over MLP: observe that MLP makes two (or more) serial lines 294 appear to the layers above as a single physical interface, and 295 thus PPP over MLP should appear to the internetwork-layer as a 296 single interface; in contrast, this scheme would result in two (or 297 more) conceptual rows in the ifTable, both of which the 298 internetwork-layer would run over. This scheme would also require 299 enumerated values of ifType for each combination of sub-layers. 301 The solution adopted by this memo is to have an individual 302 conceptual row in the ifTable to represent each sub-layer, and 303 have a new separate MIB table (the ifStackTable, see section 6 304 below) to identify the "superior" and "subordinate" sub-layers 305 through INTEGER "pointers" to the appropriate conceptual rows in 306 the ifTable. This solution supports both upward and downward 307 multiplexing, allows the IANAifType to Media-Specific MIB mapping 308 to identify the media-specific MIB module for that sub-layer, such 309 that the new table need only be referenced to obtain information 310 about layering, and it only requires enumerated values of ifType 311 for each sub-layer, not for combinations of them. However, it 312 does require that the descriptions of some objects in the ifTable 313 (specifically, ifType, ifPhysAddress, ifInUcastPkts, and 314 ifOutUcastPkts) be generalized so as to apply to any sub-layer 315 (rather than only to a sub-layer immediately beneath the network 316 layer as previously), plus some (specifically, ifSpeed) which need 317 to have appropriate values identified for use when a generalized 318 definition does not apply to a particular sub-layer. 320 In addition, this adopted solution makes no requirement that a 321 device, in which a sub-layer is instrumented by a conceptual row 322 of the ifTable, be aware of whether an internetwork protocol runs 323 on top of (i.e., at some layer above) that sub-layer. In fact, 324 the counters of packets received on an interface are defined as 325 counting the number "delivered to a higher-layer protocol". This 326 meaning of "higher-layer" includes: 328 (1) Delivery to a forwarding module which accepts 329 packets/frames/octets and forwards them on at the same 330 protocol layer. For example, for the purposes of this 331 definition, the forwarding module of a MAC-layer bridge is 332 considered as a "higher-layer" to the MAC-layer of each port 334 Draft Interfaces Group MIB November 1996 336 on the bridge. 338 (2) Delivery to a higher sub-layer within a interface stack. For 339 example, for the purposes of this definition, if a PPP module 340 operated directly over a serial interface, the PPP module 341 would be considered the higher sub-layer to the serial 342 interface. 344 (3) Delivery to a higher protocol layer which does not do packet 345 forwarding for sub-layers that are "at the top of" the 346 interface stack. For example, for the purposes of this 347 definition, the local IP module would be considered the 348 higher layer to a SLIP serial interface. 350 Similarly, for output, the counters of packets transmitted out an 351 interface are defined as counting the number "that higher-level 352 protocols requested to be transmitted". This meaning of "higher- 353 layer" includes: 355 (1) A forwarding module, at the same protocol layer, which 356 transmits packets/frames/octets that were received on an 357 different interface. For example, for the purposes of this 358 definition, the forwarding module of a MAC-layer bridge is 359 considered as a "higher-layer" to the MAC-layer of each port 360 on the bridge. 362 (2) The next higher sub-layer within an interface stack. For 363 example, for the purposes of this definition, if a PPP module 364 operated directly over a serial interface, the PPP module 365 would be a "higher layer" to the serial interface. 367 (3) For sub-layers that are "at the top of" the interface stack, 368 a higher element in the network protocol stack. For example, 369 for the purposes of this definition, the local IP module 370 would be considered the higher layer to an Ethernet 371 interface. 373 3.1.2. Guidance on Defining Sub-layers 375 The designer of a media-specific MIB must decide whether to divide 376 the interface into sub-layers or not, and if so, how to make the 377 divisions. The following guidance is offered to assist the 378 media-specific MIB designer in these decisions. 380 Draft Interfaces Group MIB November 1996 382 In general, the number of entries in the ifTable should be kept to 383 the minimum required for network management. In particular, a 384 group of related interfaces should be treated as a single 385 interface with one entry in the ifTable providing that: 387 (1) None of the group of interfaces performs multiplexing for any 388 other interface in the agent, 390 (2) There is a meaningful and useful way for all of the ifTable's 391 information (e.g., the counters, and the status variables), 392 and all of the ifTable's capabilities (e.g., write access to 393 ifAdminStatus), to apply to the group of interfaces as a 394 whole. 396 Under these circumstances, there should be one entry in the 397 ifTable for such a group of interfaces, and any internal structure 398 which needs to be represented to network management should be 399 captured in a MIB module specific to the particular type of 400 interface. 402 Note that application of bullet 2 above to the ifTable's ifType 403 object requires that there is a meaningful media-specific MIB and 404 a meaningful ifType value which apply to the group of interfaces 405 as a whole. For example, it is not appropriate to treat an HDLC 406 sub-layer and an RS-232 sub-layer as a single ifTable entry when 407 the media-specific MIBs and the ifType values for HDLC and RS-232 408 are separate (rather than combined). 410 Subject to the above, it is appropriate to assign an ifIndex value 411 to any interface that can occur in an interface stack (in the 412 ifStackTable) where the bottom of the stack is a physical 413 interface (ifConnectorPresent has the value 'true') and there is a 414 layer-3 or other application that "points down" to the top of this 415 stack. An example of an application that points down to the top 416 of the stack is the Character MIB [9]. 418 Note that the sub-layers of an interface on one device will 419 sometimes be different from the sub-layers of the interconnected 420 interface of another device; for example, for a frame-relay DTE 421 interface connected a frameRelayService interface, the inter- 422 connected DTE and DCE interfaces have different ifType values and 423 media-specific MIBs. 425 These guidelines are just that, guidelines. The designer of a 426 media-specific MIB is free to lay out the MIB in whatever SMI 427 Draft Interfaces Group MIB November 1996 429 conformant manner is desired. However, in doing so, the media- 430 specific MIB MUST completely specify the sub-layering model used 431 for the MIB, and provide the assumptions, reasoning, and rationale 432 used to develop that model. 434 3.1.3. Virtual Circuits 436 Several of the sub-layers for which media-specific MIB modules 437 have been defined are connection oriented (e.g., Frame Relay, 438 X.25). Experience has shown that each effort to define such a MIB 439 module revisits the question of whether separate conceptual rows 440 in the ifTable are needed for each virtual circuit. Most, if not 441 all, of these efforts to date have decided to have all virtual 442 circuits reference a single conceptual row in the ifTable. 444 This memo strongly recommends that connection-oriented sub-layers 445 do not have a conceptual row in the ifTable for each virtual 446 circuit. This avoids the proliferation of conceptual rows, 447 especially those which have considerable redundant information. 448 (Note, as a comparison, that connection-less sub-layers do not 449 have conceptual rows for each remote address.) There may, 450 however, be circumstances under which it is appropriate for a 451 virtual circuit of a connection-oriented sub-layer to have its own 452 conceptual row in the ifTable; an example of this might be PPP 453 over an X.25 virtual circuit. The MIB in section 6 of this memo 454 supports such circumstances. 456 If a media-specific MIB wishes to assign an entry in the ifTable 457 to each virtual circuit, the MIB designer must present the 458 rationale for this decision in the media-specific MIB's 459 specification. 461 3.1.4. Bit, Character, and Fixed-Length Interfaces 463 RS-232 is an example of a character-oriented sub-layer over which 464 (e.g., through use of PPP) IP datagrams can be sent. Due to the 465 packet-based nature of many of the objects in the ifTable, 466 experience has shown that it is not appropriate to have a 467 character-oriented sub-layer represented by a whole conceptual row 468 in the ifTable. 470 Experience has also shown that it is sometimes desirable to have 471 some management information for bit-oriented interfaces, which are 472 similarly difficult to represent by a whole conceptual row in the 473 ifTable. For example, to manage the channels of a DS1 circuit, 474 Draft Interfaces Group MIB November 1996 476 where only some of the channels are carrying packet-based data. 478 A further complication is that some subnetwork technologies 479 transmit data in fixed length transmission units. One example of 480 such a technology is cell relay, and in particular Asynchronous 481 Transfer Mode (ATM), which transmits data in fixed-length cells. 482 Representing such a interface as a packet-based interface produces 483 redundant objects if the relationship between the number of 484 packets and the number of octets in either direction is fixed by 485 the size of the transmission unit (e.g., the size of a cell). 487 About half the objects in the ifTable are applicable to every type 488 of interface: packet-oriented, character-oriented, and bit- 489 oriented. Of the other half, two are applicable to both 490 character-oriented and packet-oriented interfaces, and the rest 491 are applicable only to packet-oriented interfaces. Thus, while it 492 is desirable for consistency to be able to represent any/all types 493 of interfaces in the ifTable, it is not possible to implement the 494 full ifTable for bit- and character-oriented sub-layers. 496 A rejected solution to this problem would be to split the ifTable 497 into two (or more) new MIB tables, one of which would contain 498 objects that are relevant only to packet-oriented interfaces 499 (e.g., PPP), and another that may be used by all interfaces. This 500 is highly undesirable since it would require changes in every 501 agent implementing the ifTable (i.e., just about every existing 502 SNMP agent). 504 The solution adopted in this memo builds upon the fact that 505 compliance statements in SNMPv2 (in contrast to SNMPv1) refer to 506 object groups, where object groups are explicitly defined by 507 listing the objects they contain. Thus, in SNMPv2, multiple 508 compliance statements can be specified, one for all interfaces and 509 additional ones for specific types of interfaces. The separate 510 compliance statements can be based on separate object groups, 511 where the object group for all interfaces can contain only those 512 objects from the ifTable which are appropriate for every type of 513 interfaces. Using this solution, every sub-layer can have its own 514 conceptual row in the ifTable. 516 Thus, section 6 of this memo contains definitions of the objects 517 of the existing 'interfaces' group of MIB-II, in a manner which is 518 both SNMPv2-compliant and semantically-equivalent to the existing 519 MIB-II definitions. With equivalent semantics, and with the BER 520 ("on the wire") encodings unchanged, these definitions retain the 521 Draft Interfaces Group MIB November 1996 523 same OBJECT IDENTIFIER values as assigned by MIB-II. Thus, in 524 general, no rewrite of existing agents which conform to MIB-II and 525 the ifExtensions MIB is required. 527 In addition, this memo defines several object groups for the 528 purposes of defining which objects apply to which types of 529 interface: 531 (1) the ifGeneralInformationGroup. This group contains those 532 objects applicable to all types of network interfaces, 533 including bit-oriented interfaces. 535 (2) the ifPacketGroup. This group contains those objects 536 applicable to packet-oriented network interfaces. 538 (3) the ifFixedLengthGroup. This group contains the objects 539 applicable not only to character-oriented interfaces, such as 540 RS-232, but also to those subnetwork technologies, such as 541 cell-relay/ATM, which transmit data in fixed length 542 transmission units. As well as the octet counters, there are 543 also a few other counters (e.g., the error counters) which 544 are useful for this type of interface, but are currently 545 defined as being packet-oriented. To accommodate this, the 546 definitions of these counters are generalized to apply to 547 character-oriented interfaces and fixed-length-transmission 548 interfaces. 550 It should be noted that the octet counters in the ifTable 551 aggregate octet counts for unicast and non-unicast packets into a 552 single octet counter per direction (received/transmitted). Thus, 553 with the above definition of fixed-length-transmission interfaces, 554 where such interfaces which support non-unicast packets, separate 555 counts of unicast and multicast/broadcast transmissions can only 556 be maintained in a media-specific MIB module. 558 3.1.5. Interface Numbering 560 MIB-II defines an object, ifNumber, whose value represents: 562 "The number of network interfaces (regardless of their 563 current state) present on this system." 565 Each interface is identified by a unique value of the ifIndex 566 object, and the description of ifIndex constrains its value as 567 follows: 569 Draft Interfaces Group MIB November 1996 571 "Its value ranges between 1 and the value of ifNumber. The 572 value for each interface must remain constant at least from 573 one re-initialization of the entity's network management 574 system to the next re-initialization." 576 This constancy requirement on the value of ifIndex for a 577 particular interface is vital for efficient management. However, 578 an increasing number of devices allow for the dynamic 579 addition/removal of network interfaces. One example of this is a 580 dynamic ability to configure the use of SLIP/PPP over a 581 character-oriented port. For such dynamic additions/removals, the 582 combination of the constancy requirement and the restriction that 583 the value of ifIndex is less than ifNumber is problematic. 585 Redefining ifNumber to be the largest value of ifIndex was 586 rejected since it would not help. Such a re-definition would 587 require ifNumber to be deprecated and the utility of the redefined 588 object would be questionable. Alternatively, ifNumber could be 589 deprecated and not replaced. However, the deprecation of ifNumber 590 would require a change to that portion of ifIndex's definition 591 which refers to ifNumber. So, since the definition of ifIndex 592 must be changed anyway in order to solve the problem, changes to 593 ifNumber do not benefit the solution. 595 The solution adopted in this memo is just to delete the 596 requirement that the value of ifIndex must be less than the value 597 of ifNumber, and to retain ifNumber with its current definition. 598 This is a minor change in the semantics of ifIndex; however, all 599 existing agent implementations conform to this new definition, and 600 in the interests of not requiring changes to existing agent 601 implementations and to the many existing media-specific MIBs, this 602 memo assumes that this change does not require ifIndex to be 603 deprecated. Experience indicates that this assumption does 604 "break" a few management applications, but this is considered 605 preferable to breaking all agent implementations. 607 This solution also results in the possibility of "holes" in the 608 ifTable, i.e., the ifIndex values of conceptual rows in the 609 ifTable are not necessarily contiguous, but SNMP's GetNext (and 610 SNMPv2's GetBulk) operation easily deals with such holes. The 611 value of ifNumber still represents the number of conceptual rows, 612 which increases/decreases as new interfaces are dynamically 613 added/removed. 615 Draft Interfaces Group MIB November 1996 617 The requirement for constancy (between re-initializations) of an 618 interface's ifIndex value is met by requiring that after an 619 interface is dynamically removed, its ifIndex value is not re-used 620 by a *different* dynamically added interface until after the 621 following re-initialization of the network management system. 622 This avoids the need for assignment (in advance) of ifIndex values 623 for all possible interfaces that might be added dynamically. The 624 exact meaning of a "different" interface is hard to define, and 625 there will be gray areas. Any firm definition in this document 626 would likely to turn out to be inadequate. Instead, implementors 627 must choose what it means in their particular situation, subject 628 to the following rules: 630 (1) a previously-unused value of ifIndex must be assigned to a 631 dynamically added interface if an agent has no knowledge of 632 whether the interface is the "same" or "different" to a 633 previously incarnated interface. 635 (2) a management station, not noticing that an interface has gone 636 away and another has come into existence, must not be 637 confused when calculating the difference between the counter 638 values retrieved on successive polls for a particular ifIndex 639 value. 641 When the new interface is the same as an old interface, but a 642 discontinuity in the value of the interface's counters cannot be 643 avoided, the ifTable has (until now) required that a new ifIndex 644 value be assigned to the returning interface. That is, either all 645 counter values have had to be retained during the absence of an 646 interface in order to use the same ifIndex value on that 647 interface's return, or else a new ifIndex value has had to be 648 assigned to the returning interface. Both alternatives have 649 proved to be burdensome to some implementations: 651 (1) maintaining the counter values may not be possible (e.g., if 652 they are maintained on removable hardware), 654 (2) using a new ifIndex value presents extra work for management 655 applications. While the potential need for such extra work 656 is unavoidable on agent re-initializations, it is desirable 657 to avoid it between re-initializations. 659 To address this, a new object, ifCounterDiscontinuityTime, has 660 been defined to record the time of the last discontinuity in an 661 interface's counters. By monitoring the value of this new object, 662 Draft Interfaces Group MIB November 1996 664 a management application can now detect counter discontinuities 665 without the ifIndex value of the interface being changed. Thus, 666 an agent which implements this new object should, when a new 667 interface is the same as an old interface, retain that interface's 668 ifIndex value and update if necessary the interface's value of 669 ifCounterDiscontinuityTime. With this new object, a management 670 application must, when calculating differences between counter 671 values retrieved on successive polls, discard any calculated 672 difference for which the value of ifCounterDiscontinuityTime is 673 different for the two polls. (Note that this test must be 674 performed in addition to the normal checking of sysUpTime to 675 detect an agent re-initialization.) Since such discards are a 676 waste of network management processing and bandwidth, an agent 677 should not update the value of ifCounterDiscontinuityTime unless 678 absolutely necessary. 680 While defining this new object is a change in the semantics of the 681 ifTable counter objects, it is impractical to deprecate and 682 redefine all these counters because of their wide deployment and 683 importance. Also, a survey of implementations indicates that many 684 agents and management applications do not correctly implement this 685 aspect of the current semantics (because of the burdensome issues 686 mentioned above), such that the practical implications of such a 687 change is small. Thus, this breach of the SMI's rules is 688 considered to be acceptable. 690 Note, however, that the addition of ifCounterDiscontinuityTime 691 does not change the fact that: 693 it is necessary at certain times for the 694 assignment of ifIndex values to change on a re- 695 initialization of the agent (such as a reboot). 697 The possibility of ifIndex value re-assignment must be 698 accommodated by a management application whenever the value of 699 sysUpTime is reset to zero. 701 Note also that some agents support multiple "naming scopes", e.g., 702 for an SNMPv1 agent, multiple values of the SNMPv1 community 703 string. For such an agent (e.g., a CNM agent which supports a 704 different subset of interfaces for different customers), there is 705 no required relationship between the ifIndex values which identify 706 interfaces in one naming scope and those which identify interfaces 707 in another naming scope. It is the agent's choice as to whether 708 the same or different ifIndex values identify the same or 709 Draft Interfaces Group MIB November 1996 711 different interfaces in different naming scopes. 713 Because of the restriction of the value of ifIndex to be less than 714 ifNumber, interfaces have been numbered with small integer values. 715 This has led to the ability by humans to use the ifIndex values as 716 (somewhat) user-friendly names for network interfaces (e.g., 717 "interface number 3"). With the relaxation of the restriction on 718 the value of ifIndex, there is now the possibility that ifIndex 719 values could be assigned as very large numbers (e.g., memory 720 addresses). Such numbers would be much less user-friendly. 721 Therefore, this memo recommends that ifIndex values still be 722 assigned as (relatively) small integer values starting at 1, even 723 though the values in use at any one time are not necessarily 724 contiguous. (Note that this makes remembering which values have 725 been assigned easy for agents which dynamically add new 726 interfaces) 728 A new problem is introduced by representing each sub-layer as an 729 ifTable entry. Previously, there usually was a simple, direct, 730 mapping of interfaces to the physical ports on systems. This 731 mapping would be based on the ifIndex value. However, by having 732 an ifTable entry for each interface sub-layer, mapping from 733 interfaces to physical ports becomes increasingly problematic. 735 To address this issue, a new object, ifName, is added to the MIB. 736 This object contains the device's local name (e.g., the name used 737 at the device's local console) for the interface of which the 738 relevant entry in the ifTable is a component. For example, 739 consider a router having an interface composed of PPP running over 740 an RS-232 port. If the router uses the name "wan1" for the 741 (combined) interface, then the ifName objects for the 742 corresponding PPP and RS-232 entries in the ifTable would both 743 have the value "wan1". On the other hand, if the router uses the 744 name "wan1.1" for the PPP interface and "wan1.2" for the RS-232 745 port, then the ifName objects for the corresponding PPP and RS-232 746 entries in the ifTable would have the values "wan1.1" and 747 "wan1.2", respectively. As an another example, consider an agent 748 which responds to SNMP queries concerning an interface on some 749 other (proxied) device: if such a proxied device associates a 750 particular identifier with an interface, then it is appropriate to 751 use this identifier as the value of the interface's ifName, since 752 the local console in this case is that of the proxied device. 754 In contrast, the existing ifDescr object is intended to contain a 755 description of an interface, whereas another new object, ifAlias, 756 Draft Interfaces Group MIB November 1996 758 provides a location in which a network management application can 759 store a non-volatile interface-naming value of its own choice. 760 The ifAlias object allows a network manager to give one or more 761 interfaces their own unique names, irrespective of any interface- 762 stack relationship. Further, the ifAlias name is non-volatile, 763 and thus an interface must retain its assigned ifAlias value 764 across reboots, even if an agent chooses a new ifIndex value for 765 the interface. 767 3.1.6. Counter Size 769 As the speed of network media increase, the minimum time in which 770 a 32 bit counter will wrap decreases. For example, a 10Mbs stream 771 of back-to-back, full-size packets causes ifInOctets to wrap in 772 just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 773 minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that 774 interfaces be polled frequently enough not to miss a counter wrap 775 is increasingly problematic. 777 A rejected solution to this problem was to scale the counters; for 778 example, ifInOctets could be changed to count received octets in, 779 say, 1024 byte blocks. While it would provide acceptable 780 functionality at high rates of the counted-events, at low rates it 781 suffers. If there is little traffic on an interface, there might 782 be a significant interval before enough of the counted-events 783 occur to cause the scaled counter to be incremented. Traffic 784 would then appear to be very bursty, leading to incorrect 785 conclusions of the network's performance. 787 Instead, this memo adopts expanded, 64 bit, counters. These 788 counters are provided in new "high capacity" groups. The old, 789 32-bit, counters have not been deprecated. The 64-bit counters 790 are to be used only when the 32-bit counters do not provide enough 791 capacity; that is, when the 32 bit counters could wrap too fast. 793 For interfaces that operate at 20,000,000 (20 million) bits per 794 second or less, 32-bit byte and packet counters MUST be used. For 795 interfaces that operate faster than 20,000,000 bits/second, and 796 slower than 650,000,000 bits/second, 32-bit packet counters MUST 797 be used and 64-bit octet counters MUST be used. For interfaces 798 that operate at 650,000,000 bits/second or faster, 64-bit packet 799 counters AND 64-bit octet counters MUST be used. 801 These speed thresholds were chosen as reasonable compromises based 802 on the following: 804 Draft Interfaces Group MIB November 1996 806 (1) The cost of maintaining 64-bit counters is relatively high, 807 so minimizing the number of agents which must support them is 808 desirable. Common interfaces (such as 10Mbs Ethernet) should 809 not require them. 811 (2) 64-bit counters are a new feature, introduced in SNMPv2. It 812 is reasonable to expect that support for them will be spotty 813 for the immediate future. Thus, we wish to limit them to as 814 few systems as possible. This, in effect, means that 64-bit 815 counters should be limited to higher speed interfaces. 816 Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are 817 fairly wide-spread so it seems reasonable to not require 64- 818 bit counters for these interfaces. 820 (3) The 32-bit octet counters will wrap in the following times, 821 for the following interfaces (when transmitting maximum-sized 822 packets back-to-back): 824 - 10Mbs Ethernet: 57 minutes, 826 - 16Mbs Token Ring: 36 minutes, 828 - a US T3 line (45 megabits): 12 minutes, 830 - FDDI: 5.7 minutes 832 (4) The 32-bit packet counters wrap in about 57 minutes when 64- 833 byte packets are transmitted back-to-back on a 650,000,000 834 bit/second link. 836 As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 837 bit octet counter to wrap in just under 5 years. Conversely, an 838 81,000,000 terabit/second link is required to cause a 64-bit 839 counter to wrap in 30 minutes. We believe that, while technology 840 rapidly marches forward, this link speed will not be achieved for 841 at least several years, leaving sufficient time to evaluate the 842 introduction of 96 bit counters. 844 When 64-bit counters are in use, the 32-bit counters MUST still be 845 available. They will report the low 32-bits of the associated 846 64-bit count (e.g., ifInOctets will report the least significant 847 32 bits of ifHCInOctets). This enhances inter-operability with 848 existing implementations at a very minimal cost to agents. 850 Draft Interfaces Group MIB November 1996 852 The new "high capacity" groups are: 854 (1) the ifHCFixedLengthGroup for character-oriented/fixed-length 855 interfaces, and the ifHCPacketGroup for packet-based 856 interfaces; both of these groups include 64 bit counters for 857 octets, and 859 (2) the ifVHCPacketGroup for packet-based interfaces; this group 860 includes 64 bit counters for octets and packets. 862 3.1.7. Interface Speed 864 Network speeds are increasing. The range of ifSpeed is limited to 865 reporting a maximum speed of (2**31)-1 bits/second, or 866 approximately 2.2Gbs. SONET defines an OC-48 interface, which is 867 defined at operating at 48 times 51 Mbs, which is a speed in 868 excess of 2.4Gbs. Thus, ifSpeed is insufficient for the future, 869 and this memo defines an additional object: ifHighSpeed. 871 The ifHighSpeed object reports the speed of the interface in 872 1,000,000 (1 million) bits/second units. Thus, the true speed of 873 the interface will be the value reported by this object, plus or 874 minus 500,000 bits/second. 876 Other alternatives considered (but rejected) were: 878 (1) Making the interface speed a 64-bit gauge. This was rejected 879 since the current SMI does not allow such a syntax. 881 Furthermore, even if 64-bit gauges were available, their use 882 would require additional complexity in agents due to an 883 increased requirement for 64-bit operations. 885 (2) We also considered making "high-32 bit" and "low-32-bit" 886 objects which, when combined, would be a 64-bit value. This 887 simply seemed overly complex for what we are trying to do. 889 Furthermore, a full 64-bits of precision does not seem 890 necessary. The value of ifHighSpeed will be the only report 891 of interface speed for interfaces that are faster than 892 4,294,967,295 bits per second. At this speed, the 893 granularity of ifHighSpeed will be 1,000,000 bits per second, 894 thus the error will be 1/4294, or about 0.02%. This seems 895 reasonable. 897 Draft Interfaces Group MIB November 1996 899 (3) Adding a "scale" object, which would define the units which 900 ifSpeed's value is. 902 This would require two additional objects; one for the 903 scaling object, and one to replace the current ifSpeed. This 904 later object is required since the semantics of ifSpeed would 905 be significantly altered, and manager stations which do not 906 understand the new semantics would be confused. 908 3.1.8. Multicast/Broadcast Counters 910 In MIB-II, the ifTable counters for multicast and broadcast 911 packets are combined as counters of non-unicast packets. In 912 contrast, the ifExtensions MIB [7] defined one set of counters for 913 multicast, and a separate set for broadcast packets. With the 914 separate counters, the original combined counters become 915 redundant. To avoid this redundancy, the non-unicast counters are 916 deprecated. 918 For the output broadcast and multicast counters defined in RFC 919 1229, their definitions varied slightly from the packet counters 920 in the ifTable, in that they did not count errors/discarded 921 packets. Thus, this memo defines new objects with better aligned 922 definitions. Counters with 64 bits of range are also needed, as 923 explained above. 925 3.1.9. Trap Enable 927 In the multi-layer interface model, each sub-layer for which there 928 is an entry in the ifTable can generate linkUp/Down Traps. Since 929 interface state changes would tend to propagate through the 930 interface (from top to bottom, or bottom to top), it is likely 931 that several traps would be generated for each linkUp/Down 932 occurrence. 934 It is desirable to provide a mechanism for manager stations to 935 control the generation of these traps. To this end, the 936 ifLinkUpDownTrapEnable object has been added. This object allows 937 managers to limit generation of traps to just the sub-layers of 938 interest. 940 The default setting should limit the number of traps generated to 941 one per interface per linkUp/Down event. Furthermore, it seems 942 that the state changes of most interest to network managers occur 943 at the lowest level of an interface stack. Therefore we specify 944 Draft Interfaces Group MIB November 1996 946 that by default, only the lowest sub-layer of the interface 947 generate traps. 949 3.1.10. Addition of New ifType values 951 Over time, there is the need to add new ifType enumerated values 952 for new interface types. If the syntax of ifType were defined in 953 the MIB in section 6, then a new version of this MIB would have to 954 be re-issued in order to define new values. In the past, re- 955 issuing of a MIB has occurred only after several years. 957 Therefore, the syntax of ifType is changed to be a textual 958 convention, such that the enumerated integer values are now 959 defined in the textual convention, IANAifType, defined in a 960 different document. This allows additional values to be 961 documented without having to re-issue a new version of this 962 document. The Internet Assigned Number Authority (IANA) is 963 responsible for the assignment of all Internet numbers, including 964 various SNMP-related numbers, and specifically, new ifType values. 966 3.1.11. InterfaceIndex Textual Convention 968 A new textual convention, InterfaceIndex, has been defined. This 969 textual convention "contains" all of the semantics of the ifIndex 970 object. This allows other mib modules to easily import the 971 semantics of ifIndex. 973 3.1.12. New states for IfOperStatus 975 Three new states have been added to ifOperStatus: 'dormant', 976 'notPresent', and 'lowerLayerDown'. 978 The dormant state indicates that the relevant interface is not 979 actually in a condition to pass packets (i.e., it is not 'up') but 980 is in a "pending" state, waiting for some external event. For 981 "on-demand" interfaces, this new state identifies the situation 982 where the interface is waiting for events to place it in the up 983 state. Examples of such events might be: 985 (1) having packets to transmit before establishing a connection 986 to a remote system; 988 (2) having a remote system establish a connection to the 989 interface (e.g. dialing up to a slip-server). 991 Draft Interfaces Group MIB November 1996 993 The notPresent state is a refinement on the down state which 994 indicates that the relevant interface is down specifically because 995 some component (typically, a hardware component) is not present in 996 the managed system. Examples of use of the notPresent state are: 998 (1) to allow an interface's conceptual row including its counter 999 values to be retained across a "hot swap" of a card/module, 1000 and/or 1002 (2) to allow an interface's conceptual row to be created, and 1003 thereby enable interfaces to be pre-configured prior to 1004 installation of the hardware needed to make the interface 1005 operational. 1007 Agents are not required to support interfaces in the notPresent 1008 state. However, from a conceptual viewpoint, when a row in the 1009 ifTable is created, it first enters the notPresent state and then 1010 subsequently transitions into the down state; similarly, when a 1011 row in the ifTable is deleted, it first enters the notPresent 1012 state and then subsequently the object instances are deleted. For 1013 an agent with no support for notPresent, both of these transitions 1014 (from the notPresent state to the down state, and from the 1015 notPresent state to the instances being removed) are immediate, 1016 i.e., the transition does not last long enough to be recorded by 1017 ifOperStatus. Even for those agents which do support interfaces 1018 in the notPresent state, the length of time and conditions under 1019 which an interface stays in the notPresent state is 1020 implementation-specific. 1022 The lowerLayerDown state is also a refinement on the down state. 1023 This new state indicates that this interface runs "on top of" one 1024 or more other interfaces (see ifStackTable) and that this 1025 interface is down specifically because one or more of these 1026 lower-layer interfaces are down. 1028 3.1.13. IfAdminStatus and IfOperStatus 1030 The down state of ifOperStatus now has two meanings, depending on 1031 the value of ifAdminStatus. 1033 (1) if ifAdminStatus is not down and ifOperStatus is down then a 1034 fault condition is presumed to exist on the interface. 1036 (2) if ifAdminStatus is down, then ifOperStatus will normally 1037 also be down (or notPresent) i.e., there is not (necessarily) 1039 Draft Interfaces Group MIB November 1996 1041 a fault condition on the interface. 1043 Note that when ifAdminStatus transitions to down, ifOperStatus 1044 will normally also transition to down. In this situation, it is 1045 possible that ifOperStatus's transition will not occur 1046 immediately, but rather after a small time lag to complete certain 1047 operations before going "down"; for example, it might need to 1048 finish transmitting a packet. If a manager station finds that 1049 ifAdminStatus is down and ifOperStatus is not down for a 1050 particular interface, the manager station should wait a short 1051 while and check again. If the condition still exists, only then 1052 should it raise an error indication. Naturally, it should also 1053 ensure that ifLastChange has not changed during this interval. 1055 Whenever an interface table entry is created (usually as a result 1056 of system initialization), the relevant instance of ifAdminStatus 1057 is set to down, and presumably ifOperStatus will be down or 1058 notPresent. 1060 An interface may be enabled in two ways: either as a result of 1061 explicit management action (e.g. setting ifAdminStatus to up) or 1062 as a result of the managed system's initialization process. When 1063 ifAdminStatus changes to the up state, the related ifOperStatus 1064 should do one of the following: 1066 (1) Change to the up state if and only if the interface is able 1067 to send and receive packets. 1069 (2) Change to the lowerLayerDown state if and only if the 1070 interface is prevented from entering the up state because of 1071 the state of one or more of the interfaces beneath it in the 1072 interface stack. 1074 (3) Change to the dormant state if and only if the interface is 1075 found to be operable, but the interface is waiting for other, 1076 external, events to occur before it can transmit or receive 1077 packets. Presumably when the expected events occur, the 1078 interface will then change to the up state. 1080 (4) Remain in the down state if an error or other fault condition 1081 is detected on the interface. 1083 (5) Change to the unknown state if, for some reason, the state of 1084 the interface can not be ascertained. 1086 Draft Interfaces Group MIB November 1996 1088 (6) Change to the testing state if some test(s) must be performed 1089 on the interface. Presumably after completion of the test, 1090 the interface's state will change to up, dormant, or down, as 1091 appropriate. 1093 (7) Remain in the notPresent state if interface components are 1094 missing. 1096 3.1.14. IfOperStatus in an Interface Stack 1098 When an interface is a part of an interface-stack, but is not the 1099 lowest interface in the stack, then: 1101 (1) ifOperStatus has the value 'up' if it is able to pass packets 1102 due to one or more interfaces below it in the stack being 1103 'up', irrespective of whether other interfaces below it are 1104 'down', 'dormant', 'notPresent', 'lowerLayerDown', 'unknown' 1105 or 'testing'. 1107 (2) ifOperStatus may have the value 'up' or 'dormant' if one or 1108 more interfaces below it in the stack are 'dormant', and all 1109 others below it are either 'down', 'dormant', 'notPresent', 1110 'lowerLayerDown', 'unknown' or 'testing'. 1112 (3) ifOperStatus has the value 'lowerLayerDown' while all 1113 interfaces below it in the stack are either 'down', 1114 'notPresent', 'lowerLayerDown', or 'testing'. 1116 3.1.15. Traps 1118 The exact definition of when linkUp and linkDown traps are 1119 generated has been changed to reflect the changes to ifAdminStatus 1120 and ifOperStatus. 1122 Operational experience indicates that management stations are most 1123 concerned with an interface being in the down state and the fact 1124 that this state may indicate a failure. Thus, it is most useful 1125 to instrument transitions into/out of either the up state or the 1126 down state. 1128 Instrumenting transitions into or out of the up state was rejected 1129 since it would have the drawback that a demand interface might 1130 have many transitions between up and dormant, leading to many 1131 linkUp traps and no linkDown traps. Furthermore, if a node's only 1132 interface is the demand interface, then a transition to dormant 1133 Draft Interfaces Group MIB November 1996 1135 would entail generation of a linkDown trap, necessitating bringing 1136 the link to the up state (and a linkUp trap)!! 1138 On the other hand, instrumenting transitions into or out of the 1139 down state (to/from all other states except notPresent) has the 1140 advantages: 1142 (1) A transition into the down state (from a state other than 1143 notPresent) will occur when an error is detected on an 1144 interface. Error conditions are presumably of great interest 1145 to network managers. 1147 (2) Departing the down state (to a state other than the 1148 notPresent state) generally indicates that the interface is 1149 going to either up or dormant, both of which are considered 1150 "healthy" states. 1152 Furthermore, it is believed that generating traps on transitions 1153 into or out of the down state (except to/from the notPresent 1154 state) is generally consistent with current usage and 1155 interpretation of these traps by manager stations. 1157 Transitions to/from the notPresent state are concerned with the 1158 insertion and removal of hardware, and are outside the scope of 1159 these traps. 1161 Therefore, this memo defines that LinkUp and linkDown traps are 1162 generated on just after ifOperStatus leaves, or just before it 1163 enters, the down state, respectively; except that LinkUp and 1164 linkDown traps never generated on transitions to/from the 1165 notPresent state. 1167 Note that this definition allows a node with only one interface to 1168 transmit a linkDown trap before that interface goes down. (Of 1169 course, when the interface is going down because of a failure 1170 condition, the linkDown trap probably cannot be successfully 1171 transmitted anyway.) 1173 Some interfaces perform a link "training" function when trying to 1174 bring the interface up. In the event that such an interface were 1175 defective, then the training function would fail and the interface 1176 would remain down, and the training function might be repeated at 1177 appropriate intervals. If the interface, while performing this 1178 training function, were considered to the in the testing state, 1179 then linkUp and linkDown traps would be generated for each start 1180 Draft Interfaces Group MIB November 1996 1182 and end of the training function. This is not the intent of the 1183 linkUp and linkDown traps, and therefore, while performing such a 1184 training function, the interface's state should be represented as 1185 down. 1187 An exception to the above generation of linkUp/linkDown traps on 1188 changes in ifOperStatus, occurs when an interface is "flapping", 1189 i.e., when it is rapidly oscillating between the up and down 1190 states. If traps were generated for each such oscillation, the 1191 network and the network management system would be flooded with 1192 unnecessary traps. In such a situation, the agent should rate- 1193 limit its generation of traps. 1195 3.1.16. ifSpecific 1197 The original definition of the OBJECT IDENTIFIER value of 1198 ifSpecific was not sufficiently clear. As a result, different 1199 implementors used it differently, and confusion resulted. Some 1200 implementations set the value of ifSpecific to the OBJECT 1201 IDENTIFIER that defines the media-specific MIB, i.e., the "foo" 1202 of: 1203 foo OBJECT IDENTIFIER ::= { transmission xxx } 1205 while others set it to be OBJECT IDENTIFIER of the specific table 1206 or entry in the appropriate media-specific MIB (i.e., fooTable or 1207 fooEntry), while still others set it be the OBJECT IDENTIFIER of 1208 the index object of the table's row, including instance 1209 identifier, (i.e., fooIfIndex.ifIndex). A definition based on the 1210 latter would not be sufficient unless it also allowed for media- 1211 specific MIBs which include several tables, where each table has 1212 its own (different) indexing. 1214 The only definition that can both be made explicit and can cover 1215 all the useful situations is to have ifSpecific be the most 1216 general value for the media-specific MIB module (the first example 1217 given above). This effectively makes it redundant because it 1218 contains no more information than is provided by ifType. Thus, 1219 ifSpecific has been deprecated. 1221 3.1.17. Creation/Deletion of Interfaces 1223 While some interfaces, for example, most physical interfaces, 1224 cannot be created via network management, other interfaces such as 1225 logical interfaces sometimes can be. The ifTable contains only 1226 generic information about an interface. Almost all 'create-able' 1227 Draft Interfaces Group MIB November 1996 1229 interfaces have other, media-specific, information through which 1230 configuration parameters may be supplied prior to creating such an 1231 interface. Thus, the ifTable does not itself support the creation 1232 or deletion of an interface (specifically, it has no RowStatus [2] 1233 column). Rather, if a particular interface type supports the 1234 dynamic creation and/or deletion of an interface of that type, 1235 then that media-specific MIB should include an appropriate 1236 RowStatus object (see the ATM LAN-Emulation Client MIB [8] for an 1237 example of a MIB which does this). Typically, when such a 1238 RowStatus object is created/deleted, then the conceptual row in 1239 the ifTable appears/disappears as a by-product, and an ifIndex 1240 value (chosen by the agent) is stored in an appropriate object in 1241 the media-specific MIB. 1243 3.1.18. All Values Must be Known 1245 There are a number of situations where an agent does not know the 1246 value of one or more objects for a particular interface. In all 1247 such circumstances, an agent MUST NOT instantiate an object with 1248 an incorrect value; rather, it MUST respond with the appropriate 1249 error/exception condition (e.g., noSuchInstance for SNMPv2). 1251 One example is where an agent is unable to count the occurrences 1252 defined by one (or more) of the ifTable counters. In this 1253 circumstance, the agent MUST NOT instantiate the particular 1254 counter with a value of, say, zero. To do so would be to provide 1255 mis-information to a network management application reading the 1256 zero value, and thereby assuming that there have been no 1257 occurrences of the event (e.g., no input errors because ifInErrors 1258 is always zero). 1260 Sometimes the lack of knowledge of an object's value is temporary. 1261 For example, when the MTU of an interface is a configured value 1262 and a device dynamically learns the configured value through 1263 (after) exchanging messages over the interface (e.g., ATM LAN- 1264 Emulation [8]). In such a case, the value is not known until 1265 after the ifTable entry has already been created. In such a case, 1266 the ifTable entry should be created without an instance of the 1267 object whose value is unknown; later, when the value becomes 1268 known, the missing object can then be instantiated (e.g., the 1269 instance of ifMtu is only instantiated once the interface's MTU 1270 becomes known). 1272 As a result of this "known values" rule, management applications 1273 MUST be able to cope with the responses to retrieving the object 1274 Draft Interfaces Group MIB November 1996 1276 instances within a conceptual row of the ifTable revealing that 1277 some of the row's columnar objects are missing/not available. 1279 Draft Interfaces Group MIB November 1996 1281 4. Media-Specific MIB Applicability 1283 The exact use and semantics of many objects in this MIB are open 1284 to some interpretation. This is a result of the generic nature of 1285 this MIB. It is not always possible to come up with specific, 1286 unambiguous, text that covers all cases and yet preserves the 1287 generic nature of the MIB. 1289 Therefore, it is incumbent upon a media-specific MIB designer to, 1290 wherever necessary, clarify the use of the objects in this MIB 1291 with respect to the media-specific MIB. 1293 Specific areas of clarification include 1295 Layering Model 1296 The media-specific MIB designer MUST completely and 1297 unambiguously specify the layering model used. Each 1298 individual sub-layer must be identified, as must the 1299 ifStackTable's portrayal of the relationship(s) between the 1300 sub-layers. 1302 Virtual Circuits 1303 The media-specific MIB designer MUST specify whether virtual 1304 circuits are assigned entries in the ifTable or not. If they 1305 are, compelling rationale must be presented. 1307 ifRcvAddressTable 1308 The media-specific MIB designer MUST specify the 1309 applicability of the ifRcvAddressTable. 1311 ifType 1312 For each of the ifType values to which the media-specific MIB 1313 applies, it must specify the mapping of ifType values to 1314 media-specific MIB module(s) and instances of MIB objects 1315 within those modules. 1317 However, wherever this interface MIB is specific in the semantics, 1318 DESCRIPTION, or applicability of objects, the media-specific MIB 1319 designer MUST NOT change said semantics, DESCRIPTION, or 1320 applicability. 1322 Draft Interfaces Group MIB November 1996 1324 5. Overview 1326 This MIB consists of 4 tables: 1328 ifTable 1329 This table is the ifTable from MIB-II. 1331 ifXTable 1332 This table contains objects that have been added to the 1333 Interface MIB as a result of the Interface Evolution effort, 1334 or replacements for objects of the original (MIB-II) ifTable 1335 that were deprecated because the semantics of said objects 1336 have significantly changed. This table also contains objects 1337 that were previously in the ifExtnsTable. 1339 ifStackTable 1340 This table contains objects that define the relationships 1341 among the sub-layers of an interface. 1343 ifRcvAddressTable 1344 This table contains objects that are used to define the 1345 media-level addresses which this interface will receive. 1346 This table is a generic table. The designers of media- 1347 specific MIBs must define exactly how this table applies to 1348 their specific MIB. 1350 Draft Interfaces Group MIB November 1996 1352 6. Interfaces Group Definitions 1354 IF-MIB DEFINITIONS ::= BEGIN 1356 IMPORTS 1357 MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, 1358 Integer32, TimeTicks, mib-2, 1359 NOTIFICATION-TYPE FROM SNMPv2-SMI 1360 TEXTUAL-CONVENTION, DisplayString, 1361 PhysAddress, TruthValue, RowStatus, 1362 TimeStamp, AutonomousType, TestAndIncr FROM SNMPv2-TC 1363 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 1364 snmpTraps FROM SNMPv2-MIB 1365 IANAifType FROM IANAifType-MIB; 1367 ifMIB MODULE-IDENTITY 1368 LAST-UPDATED "9611031355Z" 1369 ORGANIZATION "IETF Interfaces MIB Working Group" 1370 CONTACT-INFO 1371 " Keith McCloghrie 1372 Cisco Systems, Inc. 1373 170 West Tasman Drive 1374 San Jose, CA 95134-1706 1375 US 1377 408-526-5260 1378 kzm@cisco.com" 1379 DESCRIPTION 1380 "The MIB module to describe generic objects for 1381 network interface sub-layers. This MIB is an updated 1382 version of MIB-II's ifTable, and incorporates the 1383 extensions defined in RFC 1229." 1384 REVISION "9602282155Z" 1385 DESCRIPTION 1386 "Revisions made by the Interfaces MIB WG." 1387 REVISION "9311082155Z" 1388 DESCRIPTION 1389 "Initial revision, published as part of RFC 1573." 1390 ::= { mib-2 31 } 1392 ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 } 1394 interfaces OBJECT IDENTIFIER ::= { mib-2 2 } 1395 Draft Interfaces Group MIB November 1996 1397 -- OwnerString has the same semantics as used in RFC 1271 1399 OwnerString ::= TEXTUAL-CONVENTION 1400 DISPLAY-HINT "255a" 1401 STATUS current 1402 DESCRIPTION 1403 "This data type is used to model an administratively 1404 assigned name of the owner of a resource. This 1405 information is taken from the NVT ASCII character set. 1406 It is suggested that this name contain one or more of 1407 the following: ASCII form of the manager station's 1408 transport address, management station name (e.g., 1409 domain name), network management personnel's name, 1410 location, or phone number. In some cases the agent 1411 itself will be the owner of an entry. In these cases, 1412 this string shall be set to a string starting with 1413 'agent'." 1414 SYNTAX OCTET STRING (SIZE(0..255)) 1416 -- InterfaceIndex contains the semantics of ifIndex and 1417 -- should be used for any objects defined on other mib 1418 -- modules that need these semantics. 1420 InterfaceIndex ::= TEXTUAL-CONVENTION 1421 DISPLAY-HINT "d" 1422 STATUS current 1423 DESCRIPTION 1424 "A unique value, greater than zero, for each interface 1425 or interface sub-layer in the managed system. It is 1426 recommended that values are assigned contiguously 1427 starting from 1. The value for each interface sub- 1428 layer must remain constant at least from one re- 1429 initialization of the entity's network management 1430 system to the next re-initialization." 1431 SYNTAX Integer32 (1..2147483647) 1433 Draft Interfaces Group MIB November 1996 1435 InterfaceIndexOrZero ::= TEXTUAL-CONVENTION 1436 DISPLAY-HINT "d" 1437 STATUS current 1438 DESCRIPTION 1439 "This textual convention is an extension of the 1440 InterfaceIndex convention. The latter defines a 1441 greater than zero value used to identify an interface 1442 or interface sub-layer in the managed system. This 1443 extension permits the additional value of zero. the 1444 value zero is object-specific and must therefore be 1445 defined as part of the description of any object which 1446 uses this syntax. Examples of the usage of zero might 1447 include situations where interface was unknown, or 1448 when none or all interfaces need to be referenced." 1449 SYNTAX Integer32 (0..2147483647) 1451 Draft Interfaces Group MIB November 1996 1453 ifNumber OBJECT-TYPE 1454 SYNTAX Integer32 1455 MAX-ACCESS read-only 1456 STATUS current 1457 DESCRIPTION 1458 "The number of network interfaces (regardless of their 1459 current state) present on this system." 1460 ::= { interfaces 1 } 1462 ifTableLastChange OBJECT-TYPE 1463 SYNTAX TimeTicks 1464 MAX-ACCESS read-only 1465 STATUS current 1466 DESCRIPTION 1467 "The value of sysUpTime at the time of the last 1468 creation or deletion of an entry in the ifTable. If 1469 the number of entries has been unchanged since the 1470 last re-initialization of the local network management 1471 subsystem, then this object contains a zero value." 1472 ::= { ifMIBObjects 5 } 1474 -- the Interfaces table 1476 -- The Interfaces table contains information on the entity's 1477 -- interfaces. Each sub-layer below the internetwork-layer 1478 -- of a network interface is considered to be an interface. 1480 ifTable OBJECT-TYPE 1481 SYNTAX SEQUENCE OF IfEntry 1482 MAX-ACCESS not-accessible 1483 STATUS current 1484 DESCRIPTION 1485 "A list of interface entries. The number of entries 1486 is given by the value of ifNumber." 1487 ::= { interfaces 2 } 1489 ifEntry OBJECT-TYPE 1490 SYNTAX IfEntry 1491 MAX-ACCESS not-accessible 1492 STATUS current 1493 DESCRIPTION 1494 "An entry containing management information applicable 1495 to a particular interface." 1496 INDEX { ifIndex } 1498 Draft Interfaces Group MIB November 1996 1500 ::= { ifTable 1 } 1502 IfEntry ::= 1503 SEQUENCE { 1504 ifIndex InterfaceIndex, 1505 ifDescr DisplayString, 1506 ifType IANAifType, 1507 ifMtu Integer32, 1508 ifSpeed Gauge32, 1509 ifPhysAddress PhysAddress, 1510 ifAdminStatus INTEGER, 1511 ifOperStatus INTEGER, 1512 ifLastChange TimeTicks, 1513 ifInOctets Counter32, 1514 ifInUcastPkts Counter32, 1515 ifInNUcastPkts Counter32, -- deprecated 1516 ifInDiscards Counter32, 1517 ifInErrors Counter32, 1518 ifInUnknownProtos Counter32, 1519 ifOutOctets Counter32, 1520 ifOutUcastPkts Counter32, 1521 ifOutNUcastPkts Counter32, -- deprecated 1522 ifOutDiscards Counter32, 1523 ifOutErrors Counter32, 1524 ifOutQLen Gauge32, -- deprecated 1525 ifSpecific OBJECT IDENTIFIER -- deprecated 1526 } 1528 ifIndex OBJECT-TYPE 1529 SYNTAX InterfaceIndex 1530 MAX-ACCESS read-only 1531 STATUS current 1532 DESCRIPTION 1533 "A unique value, greater than zero, for each 1534 interface. It is recommended that values are assigned 1535 contiguously starting from 1. The value for each 1536 interface sub-layer must remain constant at least from 1537 one re-initialization of the entity's network 1538 management system to the next re-initialization." 1539 ::= { ifEntry 1 } 1541 ifDescr OBJECT-TYPE 1542 SYNTAX DisplayString (SIZE (0..255)) 1543 MAX-ACCESS read-only 1545 Draft Interfaces Group MIB November 1996 1547 STATUS current 1548 DESCRIPTION 1549 "A textual string containing information about the 1550 interface. This string should include the name of the 1551 manufacturer, the product name and the version of the 1552 interface hardware/software." 1553 ::= { ifEntry 2 } 1555 ifType OBJECT-TYPE 1556 SYNTAX IANAifType 1557 MAX-ACCESS read-only 1558 STATUS current 1559 DESCRIPTION 1560 "The type of interface. Additional values for ifType 1561 are assigned by the Internet Assigned Numbers 1562 Authority (IANA), through updating the syntax of the 1563 IANAifType textual convention." 1564 ::= { ifEntry 3 } 1566 ifMtu OBJECT-TYPE 1567 SYNTAX Integer32 1568 MAX-ACCESS read-only 1569 STATUS current 1570 DESCRIPTION 1571 "The size of the largest packet which can be 1572 sent/received on the interface, specified in octets. 1573 For interfaces that are used for transmitting network 1574 datagrams, this is the size of the largest network 1575 datagram that can be sent on the interface." 1576 ::= { ifEntry 4 } 1578 ifSpeed OBJECT-TYPE 1579 SYNTAX Gauge32 1580 MAX-ACCESS read-only 1581 STATUS current 1582 DESCRIPTION 1583 "An estimate of the interface's current bandwidth in 1584 bits per second. For interfaces which do not vary in 1585 bandwidth or for those where no accurate estimation 1586 can be made, this object should contain the nominal 1587 bandwidth. If the bandwidth of the interface is 1588 greater than the maximum value reportable by this 1589 object then this object should report its maximum 1590 value (4,294,967,295) and ifHighSpeed must be used to 1591 report the interace's speed. For a sub-layer which 1593 Draft Interfaces Group MIB November 1996 1595 has no concept of bandwidth, this object should be 1596 zero." 1597 ::= { ifEntry 5 } 1599 ifPhysAddress OBJECT-TYPE 1600 SYNTAX PhysAddress 1601 MAX-ACCESS read-only 1602 STATUS current 1603 DESCRIPTION 1604 "The interface's address at its protocol sub-layer. 1605 For example, for an 802.x interface, this object 1606 normally contains a MAC address. The interface's 1607 media-specific MIB must define the bit and byte 1608 ordering and the format of the value of this object. 1609 For interfaces which do not have such an address 1610 (e.g., a serial line), this object should contain an 1611 octet string of zero length." 1612 ::= { ifEntry 6 } 1614 ifAdminStatus OBJECT-TYPE 1615 SYNTAX INTEGER { 1616 up(1), -- ready to pass packets 1617 down(2), 1618 testing(3) -- in some test mode 1619 } 1620 MAX-ACCESS read-write 1621 STATUS current 1622 DESCRIPTION 1623 "The desired state of the interface. The testing(3) 1624 state indicates that no operational packets can be 1625 passed. When a managed system initializes, all 1626 interfaces start with ifAdminStatus in the down(2) 1627 state. As a result of either explicit management 1628 action or per configuration information retained by 1629 the managed system, ifAdminStatus is then changed to 1630 either the up(1) or testing(3) states (or remains in 1631 the down(2) state)." 1632 ::= { ifEntry 7 } 1634 ifOperStatus OBJECT-TYPE 1635 SYNTAX INTEGER { 1636 up(1), -- ready to pass packets 1637 down(2), 1638 testing(3), -- in some test mode 1639 unknown(4), -- status can not be determined 1641 Draft Interfaces Group MIB November 1996 1643 -- for some reason. 1644 dormant(5), 1645 notPresent(6), -- some component is missing 1646 lowerLayerDown(7) -- down due to state of 1647 -- lower-layer interface(s) 1648 } 1649 MAX-ACCESS read-only 1650 STATUS current 1651 DESCRIPTION 1652 "The current operational state of the interface. The 1653 testing(3) state indicates that no operational packets 1654 can be passed. If ifAdminStatus is down(2) then 1655 ifOperStatus should be down(2). If ifAdminStatus is 1656 changed to up(1) then ifOperStatus should change to 1657 up(1) if the interface is ready to transmit and 1658 receive network traffic; it should change to 1659 dormant(5) if the interface is waiting for external 1660 actions (such as a serial line waiting for an incoming 1661 connection); it should remain in the down(2) state if 1662 and only if there is a fault that prevents it from 1663 going to the up(1) state; it should remain in the 1664 notPresent(6) state if the interface has missing 1665 (typically, hardware) components." 1666 ::= { ifEntry 8 } 1668 ifLastChange OBJECT-TYPE 1669 SYNTAX TimeTicks 1670 MAX-ACCESS read-only 1671 STATUS current 1672 DESCRIPTION 1673 "The value of sysUpTime at the time the interface 1674 entered its current operational state. If the current 1675 state was entered prior to the last re-initialization 1676 of the local network management subsystem, then this 1677 object contains a zero value." 1678 ::= { ifEntry 9 } 1680 ifInOctets OBJECT-TYPE 1681 SYNTAX Counter32 1682 MAX-ACCESS read-only 1683 STATUS current 1684 DESCRIPTION 1685 "The total number of octets received on the interface, 1686 including framing characters. 1688 Draft Interfaces Group MIB November 1996 1690 Discontinuities in the value of this counter can occur 1691 at re-initialization of the management system, and at 1692 other times as indicated by the value of 1693 ifCounterDiscontinuityTime." 1694 ::= { ifEntry 10 } 1696 ifInUcastPkts OBJECT-TYPE 1697 SYNTAX Counter32 1698 MAX-ACCESS read-only 1699 STATUS current 1700 DESCRIPTION 1701 "The number of packets, delivered by this sub-layer to 1702 a higher (sub-)layer, which were not addressed to a 1703 multicast or broadcast address at this sub-layer. 1705 Discontinuities in the value of this counter can occur 1706 at re-initialization of the management system, and at 1707 other times as indicated by the value of 1708 ifCounterDiscontinuityTime." 1709 ::= { ifEntry 11 } 1711 ifInNUcastPkts OBJECT-TYPE 1712 SYNTAX Counter32 1713 MAX-ACCESS read-only 1714 STATUS deprecated 1715 DESCRIPTION 1716 "The number of packets, delivered by this sub-layer to 1717 a higher (sub-)layer, which were addressed to a 1718 multicast or broadcast address at this sub-layer. 1720 Discontinuities in the value of this counter can occur 1721 at re-initialization of the management system, and at 1722 other times as indicated by the value of 1723 ifCounterDiscontinuityTime. 1725 This object is deprecated in favour of 1726 ifInMulticastPkts and ifInBroadcastPkts." 1727 ::= { ifEntry 12 } 1729 ifInDiscards OBJECT-TYPE 1730 SYNTAX Counter32 1731 MAX-ACCESS read-only 1732 STATUS current 1733 DESCRIPTION 1734 "The number of inbound packets which were chosen to be 1736 Draft Interfaces Group MIB November 1996 1738 discarded even though no errors had been detected to 1739 prevent their being deliverable to a higher-layer 1740 protocol. One possible reason for discarding such a 1741 packet could be to free up buffer space. 1743 Discontinuities in the value of this counter can occur 1744 at re-initialization of the management system, and at 1745 other times as indicated by the value of 1746 ifCounterDiscontinuityTime." 1747 ::= { ifEntry 13 } 1749 ifInErrors OBJECT-TYPE 1750 SYNTAX Counter32 1751 MAX-ACCESS read-only 1752 STATUS current 1753 DESCRIPTION 1754 "For packet-oriented interfaces, the number of inbound 1755 packets that contained errors preventing them from 1756 being deliverable to a higher-layer protocol. For 1757 character-oriented or fixed-length interfaces, the 1758 number of inbound transmission units that contained 1759 errors preventing them from being deliverable to a 1760 higher-layer protocol. 1762 Discontinuities in the value of this counter can occur 1763 at re-initialization of the management system, and at 1764 other times as indicated by the value of 1765 ifCounterDiscontinuityTime." 1766 ::= { ifEntry 14 } 1768 ifInUnknownProtos OBJECT-TYPE 1769 SYNTAX Counter32 1770 MAX-ACCESS read-only 1771 STATUS current 1772 DESCRIPTION 1773 "For packet-oriented interfaces, the number of packets 1774 received via the interface which were discarded 1775 because of an unknown or unsupported protocol. For 1776 character-oriented or fixed-length interfaces that 1777 support protocol multiplexing the number of 1778 transmission units received via the interface which 1779 were discarded because of an unknown or unsupported 1780 protocol. For any interface that does not support 1781 protocol multiplexing, this counter will always be 0. 1783 Draft Interfaces Group MIB November 1996 1785 Discontinuities in the value of this counter can occur 1786 at re-initialization of the management system, and at 1787 other times as indicated by the value of 1788 ifCounterDiscontinuityTime." 1789 ::= { ifEntry 15 } 1791 ifOutOctets OBJECT-TYPE 1792 SYNTAX Counter32 1793 MAX-ACCESS read-only 1794 STATUS current 1795 DESCRIPTION 1796 "The total number of octets transmitted out of the 1797 interface, including framing characters. 1799 Discontinuities in the value of this counter can occur 1800 at re-initialization of the management system, and at 1801 other times as indicated by the value of 1802 ifCounterDiscontinuityTime." 1803 ::= { ifEntry 16 } 1805 ifOutUcastPkts OBJECT-TYPE 1806 SYNTAX Counter32 1807 MAX-ACCESS read-only 1808 STATUS current 1809 DESCRIPTION 1810 "The total number of packets that higher-level 1811 protocols requested be transmitted, and which were not 1812 addressed to a multicast or broadcast address at this 1813 sub-layer, including those that were discarded or not 1814 sent. 1816 Discontinuities in the value of this counter can occur 1817 at re-initialization of the management system, and at 1818 other times as indicated by the value of 1819 ifCounterDiscontinuityTime." 1820 ::= { ifEntry 17 } 1822 ifOutNUcastPkts OBJECT-TYPE 1823 SYNTAX Counter32 1824 MAX-ACCESS read-only 1825 STATUS deprecated 1826 DESCRIPTION 1827 "The total number of packets that higher-level 1828 protocols requested be transmitted, and which were 1829 addressed to a multicast or broadcast address at this 1831 Draft Interfaces Group MIB November 1996 1833 sub-layer, including those that were discarded or not 1834 sent. 1836 Discontinuities in the value of this counter can occur 1837 at re-initialization of the management system, and at 1838 other times as indicated by the value of 1839 ifCounterDiscontinuityTime. 1841 This object is deprecated in favour of 1842 ifOutMulticastPkts and ifOutBroadcastPkts." 1843 ::= { ifEntry 18 } 1845 ifOutDiscards OBJECT-TYPE 1846 SYNTAX Counter32 1847 MAX-ACCESS read-only 1848 STATUS current 1849 DESCRIPTION 1850 "The number of outbound packets which were chosen to 1851 be discarded even though no errors had been detected 1852 to prevent their being transmitted. One possible 1853 reason for discarding such a packet could be to free 1854 up buffer space. 1856 Discontinuities in the value of this counter can occur 1857 at re-initialization of the management system, and at 1858 other times as indicated by the value of 1859 ifCounterDiscontinuityTime." 1860 ::= { ifEntry 19 } 1862 ifOutErrors OBJECT-TYPE 1863 SYNTAX Counter32 1864 MAX-ACCESS read-only 1865 STATUS current 1866 DESCRIPTION 1867 "For packet-oriented interfaces, the number of 1868 outbound packets that could not be transmitted because 1869 of errors. For character-oriented or fixed-length 1870 interfaces, the number of outbound transmission units 1871 that could not be transmitted because of errors. 1873 Discontinuities in the value of this counter can occur 1874 at re-initialization of the management system, and at 1875 other times as indicated by the value of 1876 ifCounterDiscontinuityTime." 1877 ::= { ifEntry 20 } 1879 Draft Interfaces Group MIB November 1996 1881 ifOutQLen OBJECT-TYPE 1882 SYNTAX Gauge32 1883 MAX-ACCESS read-only 1884 STATUS deprecated 1885 DESCRIPTION 1886 "The length of the output packet queue (in packets)." 1887 ::= { ifEntry 21 } 1889 ifSpecific OBJECT-TYPE 1890 SYNTAX OBJECT IDENTIFIER 1891 MAX-ACCESS read-only 1892 STATUS deprecated 1893 DESCRIPTION 1894 "A reference to MIB definitions specific to the 1895 particular media being used to realize the interface. 1896 It is recommended that this value point to an instance 1897 of a MIB object in the media-specific MIB, i.e., that 1898 this object have the semantics associated with the 1899 InstancePointer textual convention defined in RFC 1900 1903. In fact, it is recommended that the media- 1901 specific MIB specify what value ifSpecific should/can 1902 take for values of ifType. If no MIB definitions 1903 specific to the particular media are available, the 1904 value should be set to the OBJECT IDENTIFIER { 0 0 }." 1905 ::= { ifEntry 22 } 1907 -- 1908 -- Extension to the interface table 1909 -- 1910 -- This table replaces the ifExtnsTable table. 1911 -- 1913 ifXTable OBJECT-TYPE 1914 SYNTAX SEQUENCE OF IfXEntry 1915 MAX-ACCESS not-accessible 1916 STATUS current 1917 DESCRIPTION 1918 "A list of interface entries. The number of entries 1919 is given by the value of ifNumber. This table 1920 contains additional objects for the interface table." 1921 ::= { ifMIBObjects 1 } 1923 ifXEntry OBJECT-TYPE 1924 Draft Interfaces Group MIB November 1996 1926 SYNTAX IfXEntry 1927 MAX-ACCESS not-accessible 1928 STATUS current 1929 DESCRIPTION 1930 "An entry containing additional management information 1931 applicable to a particular interface." 1932 AUGMENTS { ifEntry } 1933 ::= { ifXTable 1 } 1935 IfXEntry ::= 1936 SEQUENCE { 1937 ifName DisplayString, 1938 ifInMulticastPkts Counter32, 1939 ifInBroadcastPkts Counter32, 1940 ifOutMulticastPkts Counter32, 1941 ifOutBroadcastPkts Counter32, 1942 ifHCInOctets Counter64, 1943 ifHCInUcastPkts Counter64, 1944 ifHCInMulticastPkts Counter64, 1945 ifHCInBroadcastPkts Counter64, 1946 ifHCOutOctets Counter64, 1947 ifHCOutUcastPkts Counter64, 1948 ifHCOutMulticastPkts Counter64, 1949 ifHCOutBroadcastPkts Counter64, 1950 ifLinkUpDownTrapEnable INTEGER, 1951 ifHighSpeed Gauge32, 1952 ifPromiscuousMode TruthValue, 1953 ifConnectorPresent TruthValue, 1954 ifAlias DisplayString, 1955 ifCounterDiscontinuityTime TimeStamp 1956 } 1958 ifName OBJECT-TYPE 1959 SYNTAX DisplayString 1960 MAX-ACCESS read-only 1961 STATUS current 1962 DESCRIPTION 1963 "The textual name of the interface. The value of this 1964 object should be the name of the interface as assigned 1965 by the local device and should be suitable for use in 1966 commands entered at the device's `console'. This 1967 might be a text name, such as `le0' or a simple port 1968 number, such as `1', depending on the interface naming 1969 syntax of the device. If several entries in the 1971 Draft Interfaces Group MIB November 1996 1973 ifTable together represent a single interface as named 1974 by the device, then each will have the same value of 1975 ifName. Note that for an agent which responds to SNMP 1976 queries concerning an interface on some other 1977 (proxied) device, then the value of ifName for such an 1978 interface is the proxied device's local name for it. 1980 If there is no local name, or this object is otherwise 1981 not applicable, then this object contains a zero- 1982 length string." 1983 ::= { ifXEntry 1 } 1985 ifInMulticastPkts OBJECT-TYPE 1986 SYNTAX Counter32 1987 MAX-ACCESS read-only 1988 STATUS current 1989 DESCRIPTION 1990 "The number of packets, delivered by this sub-layer to 1991 a higher (sub-)layer, which were addressed to a 1992 multicast address at this sub-layer. For a MAC layer 1993 protocol, this includes both Group and Functional 1994 addresses. 1996 Discontinuities in the value of this counter can occur 1997 at re-initialization of the management system, and at 1998 other times as indicated by the value of 1999 ifCounterDiscontinuityTime." 2000 ::= { ifXEntry 2 } 2002 ifInBroadcastPkts OBJECT-TYPE 2003 SYNTAX Counter32 2004 MAX-ACCESS read-only 2005 STATUS current 2006 DESCRIPTION 2007 "The number of packets, delivered by this sub-layer to 2008 a higher (sub-)layer, which were addressed to a 2009 broadcast address at this sub-layer. 2011 Discontinuities in the value of this counter can occur 2012 at re-initialization of the management system, and at 2013 other times as indicated by the value of 2014 ifCounterDiscontinuityTime." 2015 ::= { ifXEntry 3 } 2017 ifOutMulticastPkts OBJECT-TYPE 2018 Draft Interfaces Group MIB November 1996 2020 SYNTAX Counter32 2021 MAX-ACCESS read-only 2022 STATUS current 2023 DESCRIPTION 2024 "The total number of packets that higher-level 2025 protocols requested be transmitted, and which were 2026 addressed to a multicast address at this sub-layer, 2027 including those that were discarded or not sent. For 2028 a MAC layer protocol, this includes both Group and 2029 Functional addresses. 2031 Discontinuities in the value of this counter can occur 2032 at re-initialization of the management system, and at 2033 other times as indicated by the value of 2034 ifCounterDiscontinuityTime." 2035 ::= { ifXEntry 4 } 2037 ifOutBroadcastPkts OBJECT-TYPE 2038 SYNTAX Counter32 2039 MAX-ACCESS read-only 2040 STATUS current 2041 DESCRIPTION 2042 "The total number of packets that higher-level 2043 protocols requested be transmitted, and which were 2044 addressed to a broadcast address at this sub-layer, 2045 including those that were discarded or not sent. 2047 Discontinuities in the value of this counter can occur 2048 at re-initialization of the management system, and at 2049 other times as indicated by the value of 2050 ifCounterDiscontinuityTime." 2051 ::= { ifXEntry 5 } 2053 -- 2054 -- High Capacity Counter objects. These objects are all 2055 -- 64 bit versions of the "basic" ifTable counters. These 2056 -- objects all have the same basic semantics as their 32-bit 2057 -- counterparts, however, their syntax has been extended 2058 -- to 64 bits. 2059 -- 2061 ifHCInOctets OBJECT-TYPE 2062 SYNTAX Counter64 2063 MAX-ACCESS read-only 2064 STATUS current 2066 Draft Interfaces Group MIB November 1996 2068 DESCRIPTION 2069 "The total number of octets received on the interface, 2070 including framing characters. This object is a 64-bit 2071 version of ifInOctets. 2073 Discontinuities in the value of this counter can occur 2074 at re-initialization of the management system, and at 2075 other times as indicated by the value of 2076 ifCounterDiscontinuityTime." 2077 ::= { ifXEntry 6 } 2079 ifHCInUcastPkts OBJECT-TYPE 2080 SYNTAX Counter64 2081 MAX-ACCESS read-only 2082 STATUS current 2083 DESCRIPTION 2084 "The number of packets, delivered by this sub-layer to 2085 a higher (sub-)layer, which were not addressed to a 2086 multicast or broadcast address at this sub-layer. 2087 This object is a 64-bit version of ifInUcastPkts. 2089 Discontinuities in the value of this counter can occur 2090 at re-initialization of the management system, and at 2091 other times as indicated by the value of 2092 ifCounterDiscontinuityTime." 2093 ::= { ifXEntry 7 } 2095 ifHCInMulticastPkts OBJECT-TYPE 2096 SYNTAX Counter64 2097 MAX-ACCESS read-only 2098 STATUS current 2099 DESCRIPTION 2100 "The number of packets, delivered by this sub-layer to 2101 a higher (sub-)layer, which were addressed to a 2102 multicast address at this sub-layer. For a MAC layer 2103 protocol, this includes both Group and Functional 2104 addresses. This object is a 64-bit version of 2105 ifInMulticastPkts. 2107 Discontinuities in the value of this counter can occur 2108 at re-initialization of the management system, and at 2109 other times as indicated by the value of 2110 ifCounterDiscontinuityTime." 2111 ::= { ifXEntry 8 } 2113 Draft Interfaces Group MIB November 1996 2115 ifHCInBroadcastPkts OBJECT-TYPE 2116 SYNTAX Counter64 2117 MAX-ACCESS read-only 2118 STATUS current 2119 DESCRIPTION 2120 "The number of packets, delivered by this sub-layer to 2121 a higher (sub-)layer, which were addressed to a 2122 broadcast address at this sub-layer. This object is a 2123 64-bit version of ifInBroadcastPkts. 2125 Discontinuities in the value of this counter can occur 2126 at re-initialization of the management system, and at 2127 other times as indicated by the value of 2128 ifCounterDiscontinuityTime." 2129 ::= { ifXEntry 9 } 2131 ifHCOutOctets OBJECT-TYPE 2132 SYNTAX Counter64 2133 MAX-ACCESS read-only 2134 STATUS current 2135 DESCRIPTION 2136 "The total number of octets transmitted out of the 2137 interface, including framing characters. This object 2138 is a 64-bit version of ifOutOctets. 2140 Discontinuities in the value of this counter can occur 2141 at re-initialization of the management system, and at 2142 other times as indicated by the value of 2143 ifCounterDiscontinuityTime." 2144 ::= { ifXEntry 10 } 2146 ifHCOutUcastPkts OBJECT-TYPE 2147 SYNTAX Counter64 2148 MAX-ACCESS read-only 2149 STATUS current 2150 DESCRIPTION 2151 "The total number of packets that higher-level 2152 protocols requested be transmitted, and which were not 2153 addressed to a multicast or broadcast address at this 2154 sub-layer, including those that were discarded or not 2155 sent. This object is a 64-bit version of 2156 ifOutUcastPkts. 2158 Discontinuities in the value of this counter can occur 2159 at re-initialization of the management system, and at 2161 Draft Interfaces Group MIB November 1996 2163 other times as indicated by the value of 2164 ifCounterDiscontinuityTime." 2165 ::= { ifXEntry 11 } 2167 ifHCOutMulticastPkts OBJECT-TYPE 2168 SYNTAX Counter64 2169 MAX-ACCESS read-only 2170 STATUS current 2171 DESCRIPTION 2172 "The total number of packets that higher-level 2173 protocols requested be transmitted, and which were 2174 addressed to a multicast address at this sub-layer, 2175 including those that were discarded or not sent. For 2176 a MAC layer protocol, this includes both Group and 2177 Functional addresses. This object is a 64-bit version 2178 of ifOutMulticastPkts. 2180 Discontinuities in the value of this counter can occur 2181 at re-initialization of the management system, and at 2182 other times as indicated by the value of 2183 ifCounterDiscontinuityTime." 2184 ::= { ifXEntry 12 } 2186 ifHCOutBroadcastPkts OBJECT-TYPE 2187 SYNTAX Counter64 2188 MAX-ACCESS read-only 2189 STATUS current 2190 DESCRIPTION 2191 "The total number of packets that higher-level 2192 protocols requested be transmitted, and which were 2193 addressed to a broadcast address at this sub-layer, 2194 including those that were discarded or not sent. This 2195 object is a 64-bit version of ifOutBroadcastPkts. 2197 Discontinuities in the value of this counter can occur 2198 at re-initialization of the management system, and at 2199 other times as indicated by the value of 2200 ifCounterDiscontinuityTime." 2201 ::= { ifXEntry 13 } 2203 ifLinkUpDownTrapEnable OBJECT-TYPE 2204 SYNTAX INTEGER { enabled(1), disabled(2) } 2205 MAX-ACCESS read-write 2206 STATUS current 2207 DESCRIPTION 2209 Draft Interfaces Group MIB November 1996 2211 "Indicates whether linkUp/linkDown traps should be 2212 generated for this interface. 2214 By default, this object should have the value 2215 enabled(1) for interfaces which do not operate on 2216 'top' of any other interface (as defined in the 2217 ifStackTable), and disabled(2) otherwise." 2218 ::= { ifXEntry 14 } 2220 ifHighSpeed OBJECT-TYPE 2221 SYNTAX Gauge32 2222 MAX-ACCESS read-only 2223 STATUS current 2224 DESCRIPTION 2225 "An estimate of the interface's current bandwidth in 2226 units of 1,000,000 bits per second. If this object 2227 reports a value of `n' then the speed of the interface 2228 is somewhere in the range of `n-500,000' to 2229 `n+499,999'. For interfaces which do not vary in 2230 bandwidth or for those where no accurate estimation 2231 can be made, this object should contain the nominal 2232 bandwidth. For a sub-layer which has no concept of 2233 bandwidth, this object should be zero." 2234 ::= { ifXEntry 15 } 2236 ifPromiscuousMode OBJECT-TYPE 2237 SYNTAX TruthValue 2238 MAX-ACCESS read-write 2239 STATUS current 2240 DESCRIPTION 2241 "This object has a value of false(2) if this interface 2242 only accepts packets/frames that are addressed to this 2243 station. This object has a value of true(1) when the 2244 station accepts all packets/frames transmitted on the 2245 media. The value true(1) is only legal on certain 2246 types of media. If legal, setting this object to a 2247 value of true(1) may require the interface to be reset 2248 before becoming effective. 2250 The value of ifPromiscuousMode does not affect the 2251 reception of broadcast and multicast packets/frames by 2252 the interface." 2253 ::= { ifXEntry 16 } 2255 ifConnectorPresent OBJECT-TYPE 2256 Draft Interfaces Group MIB November 1996 2258 SYNTAX TruthValue 2259 MAX-ACCESS read-only 2260 STATUS current 2261 DESCRIPTION 2262 "This object has the value 'true(1)' if the interface 2263 sublayer has a physical connector and the value 2264 'false(2)' otherwise." 2265 ::= { ifXEntry 17 } 2267 ifAlias OBJECT-TYPE 2268 SYNTAX DisplayString (SIZE(0..64)) 2269 MAX-ACCESS read-write 2270 STATUS current 2271 DESCRIPTION 2272 "This object is an 'alias' name for the interface as 2273 specified by a network manager, and provides a non- 2274 volatile 'handle' for the interface. 2276 On the first instantiation of an interface, the value 2277 of ifAlias associated with that interface is the 2278 zero-length string. As and when a value is written 2279 into an instance of ifAlias through a network 2280 management set operation, then the agent must retain 2281 the supplied value in the ifAlias instance associated 2282 with the same interface for as long as that interface 2283 remains instantiated, including across all re- 2284 initializations/reboots of the network management 2285 system, including those which result in a change of 2286 the interface's ifIndex value. 2288 An example of the value which a network manager might 2289 store in this object for a WAN interface is the 2290 (Telco's) circuit number/identifier of the interface. 2292 Some agents may support write-access only for 2293 interfaces having particular values of ifType. An 2294 agent which supports write access to this object is 2295 required to keep the value in non-volatile storage, 2296 but it may limit the length of new values depending on 2297 how much storage is already occupied by the current 2298 values for other interfaces." 2299 ::= { ifXEntry 18 } 2301 ifCounterDiscontinuityTime OBJECT-TYPE 2302 SYNTAX TimeStamp 2304 Draft Interfaces Group MIB November 1996 2306 MAX-ACCESS read-only 2307 STATUS current 2308 DESCRIPTION 2309 "The value of sysUpTime on the most recent occasion at 2310 which any one or more of this interface's counters 2311 suffered a discontinuity. The relevant counters are 2312 the specific instances associated with this interface 2313 of any Counter32 or Counter64 object contained in the 2314 ifTable or ifXTable. If no such discontinuities have 2315 occurred since the last re-initialization of the local 2316 management subsystem, then this object contains a zero 2317 value." 2318 ::= { ifXEntry 19 } 2320 Draft Interfaces Group MIB November 1996 2322 -- The Interface Stack Group 2323 -- 2324 -- Implementation of this group is mandatory for all systems 2325 -- 2327 ifStackTable OBJECT-TYPE 2328 SYNTAX SEQUENCE OF IfStackEntry 2329 MAX-ACCESS not-accessible 2330 STATUS current 2331 DESCRIPTION 2332 "The table containing information on the relationships 2333 between the multiple sub-layers of network interfaces. 2334 In particular, it contains information on which sub- 2335 layers run 'on top of' which other sub-layers, where 2336 each sub-layer corresponds to a conceptual row in the 2337 ifTable. For example, when the sub-layer with ifIndex 2338 value x runs over the sub-layer with ifIndex value y, 2339 then this table contains: 2341 ifStackStatus.x.y=active 2343 For each ifIndex value, I, which identifies an active 2344 interface, there are always at least two instantiated 2345 rows in this table associated with I. For one of 2346 these rows, I is the value of ifStackHigherLayer; for 2347 the other, I is the value of ifStackLowerLayer. (If I 2348 is not involved in multiplexing, then these are the 2349 only two rows associated with I.) 2351 For example, two rows exist even for an interface 2352 which has no others stacked on top or below it: 2354 ifStackStatus.0.x=active 2355 ifStackStatus.x.0=active " 2356 ::= { ifMIBObjects 2 } 2358 ifStackEntry OBJECT-TYPE 2359 SYNTAX IfStackEntry 2360 MAX-ACCESS not-accessible 2361 STATUS current 2362 DESCRIPTION 2363 "Information on a particular relationship between two 2364 sub-layers, specifying that one sub-layer runs on 2365 'top' of the other sub-layer. Each sub-layer 2367 Draft Interfaces Group MIB November 1996 2369 corresponds to a conceptual row in the ifTable." 2370 INDEX { ifStackHigherLayer, ifStackLowerLayer } 2371 ::= { ifStackTable 1 } 2373 IfStackEntry ::= 2374 SEQUENCE { 2375 ifStackHigherLayer Integer32, 2376 ifStackLowerLayer Integer32, 2377 ifStackStatus RowStatus 2378 } 2380 ifStackHigherLayer OBJECT-TYPE 2381 SYNTAX Integer32 2382 MAX-ACCESS not-accessible 2383 STATUS current 2384 DESCRIPTION 2385 "The value of ifIndex corresponding to the higher 2386 sub-layer of the relationship, i.e., the sub-layer 2387 which runs on 'top' of the sub-layer identified by the 2388 corresponding instance of ifStackLowerLayer. If there 2389 is no higher sub-layer (below the internetwork layer), 2390 then this object has the value 0." 2391 ::= { ifStackEntry 1 } 2393 ifStackLowerLayer OBJECT-TYPE 2394 SYNTAX Integer32 2395 MAX-ACCESS not-accessible 2396 STATUS current 2397 DESCRIPTION 2398 "The value of ifIndex corresponding to the lower sub- 2399 layer of the relationship, i.e., the sub-layer which 2400 runs 'below' the sub-layer identified by the 2401 corresponding instance of ifStackHigherLayer. If 2402 there is no lower sub-layer, then this object has the 2403 value 0." 2404 ::= { ifStackEntry 2 } 2406 ifStackStatus OBJECT-TYPE 2407 SYNTAX RowStatus 2408 MAX-ACCESS read-create 2409 STATUS current 2411 Draft Interfaces Group MIB November 1996 2413 DESCRIPTION 2414 "The status of the relationship between two sub- 2415 layers. 2417 Changing the value of this object from 'active' to 2418 'notInService' or 'destroy' will likely have 2419 consequences up and down the interface stack. Thus, 2420 write access to this object is likely to be 2421 inappropriate for some types of interfaces, and many 2422 implementations will choose not to support write- 2423 access for any type of interface." 2424 ::= { ifStackEntry 3 } 2426 ifStackLastChange OBJECT-TYPE 2427 SYNTAX TimeTicks 2428 MAX-ACCESS read-only 2429 STATUS current 2430 DESCRIPTION 2431 "The value of sysUpTime at the time of the last change 2432 of the (whole) interface stack. A change of the 2433 interface stack is defined to be any creation, 2434 deletion, or change in value of any instance of 2435 ifStackStatus. If the interface stack has been 2436 unchanged since the last re-initialization of the 2437 local network management subsystem, then this object 2438 contains a zero value." 2439 ::= { ifMIBObjects 6 } 2441 -- Generic Receive Address Table 2442 -- 2443 -- This group of objects is mandatory for all types of 2444 -- interfaces which can receive packets/frames addressed to 2445 -- more than one address. 2446 -- 2447 -- This table replaces the ifExtnsRcvAddr table. The main 2448 -- difference is that this table makes use of the RowStatus 2449 -- textual convention, while ifExtnsRcvAddr did not. 2451 ifRcvAddressTable OBJECT-TYPE 2452 SYNTAX SEQUENCE OF IfRcvAddressEntry 2453 MAX-ACCESS not-accessible 2454 STATUS current 2455 DESCRIPTION 2456 "This table contains an entry for each address 2458 Draft Interfaces Group MIB November 1996 2460 (broadcast, multicast, or uni-cast) for which the 2461 system will receive packets/frames on a particular 2462 interface, except as follows: 2464 - for an interface operating in promiscuous mode, 2465 entries are only required for those addresses for 2466 which the system would receive frames were it not 2467 operating in promiscuous mode. 2469 - for 802.5 functional addresses, only one entry is 2470 required, for the address which has the functional 2471 address bit ANDed with the bit mask of all functional 2472 addresses for which the interface will accept frames. 2474 A system is normally able to use any unicast address 2475 which corresponds to an entry in this table as a 2476 source address." 2477 ::= { ifMIBObjects 4 } 2479 ifRcvAddressEntry OBJECT-TYPE 2480 SYNTAX IfRcvAddressEntry 2481 MAX-ACCESS not-accessible 2482 STATUS current 2483 DESCRIPTION 2484 "A list of objects identifying an address for which 2485 the system will accept packets/frames on the 2486 particular interface identified by the index value 2487 ifIndex." 2488 INDEX { ifIndex, ifRcvAddressAddress } 2489 ::= { ifRcvAddressTable 1 } 2491 IfRcvAddressEntry ::= 2492 SEQUENCE { 2493 ifRcvAddressAddress PhysAddress, 2494 ifRcvAddressStatus RowStatus, 2495 ifRcvAddressType INTEGER 2496 } 2498 ifRcvAddressAddress OBJECT-TYPE 2499 SYNTAX PhysAddress 2500 MAX-ACCESS not-accessible 2501 STATUS current 2502 DESCRIPTION 2503 "An address for which the system will accept 2504 packets/frames on this entry's interface." 2506 Draft Interfaces Group MIB November 1996 2508 ::= { ifRcvAddressEntry 1 } 2510 ifRcvAddressStatus OBJECT-TYPE 2511 SYNTAX RowStatus 2512 MAX-ACCESS read-create 2513 STATUS current 2514 DESCRIPTION 2515 "This object is used to create and delete rows in the 2516 ifRcvAddressTable." 2518 ::= { ifRcvAddressEntry 2 } 2520 ifRcvAddressType OBJECT-TYPE 2521 SYNTAX INTEGER { 2522 other(1), 2523 volatile(2), 2524 nonVolatile(3) 2525 } 2527 MAX-ACCESS read-create 2528 STATUS current 2529 DESCRIPTION 2530 "This object has the value nonVolatile(3) for those 2531 entries in the table which are valid and will not be 2532 deleted by the next restart of the managed system. 2533 Entries having the value volatile(2) are valid and 2534 exist, but have not been saved, so that will not exist 2535 after the next restart of the managed system. Entries 2536 having the value other(1) are valid and exist but are 2537 not classified as to whether they will continue to 2538 exist after the next restart." 2540 DEFVAL { volatile } 2541 ::= { ifRcvAddressEntry 3 } 2543 Draft Interfaces Group MIB November 1996 2545 -- definition of interface-related traps. 2547 linkDown NOTIFICATION-TYPE 2548 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2549 STATUS current 2550 DESCRIPTION 2551 "A linkDown trap signifies that the SNMPv2 entity, 2552 acting in an agent role, has detected that the 2553 ifOperStatus object for one of its communication links 2554 is about to enter the down state from some other state 2555 (but not from the notPresent state). This other state 2556 is indicated by the included value of ifOperStatus." 2557 ::= { snmpTraps 3 } 2559 linkUp NOTIFICATION-TYPE 2560 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2561 STATUS current 2562 DESCRIPTION 2563 "A linkDown trap signifies that the SNMPv2 entity, 2564 acting in an agent role, has detected that the 2565 ifOperStatus object for one of its communication links 2566 left the down state and transitioned into some other 2567 state (but not into the notPresent state). This other 2568 state is indicated by the included value of 2569 ifOperStatus." 2570 ::= { snmpTraps 4 } 2572 Draft Interfaces Group MIB November 1996 2574 -- conformance information 2576 ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 } 2578 ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 } 2579 ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 } 2581 -- compliance statements 2583 ifCompliance2 MODULE-COMPLIANCE 2584 STATUS current 2585 DESCRIPTION 2586 "The compliance statement for SNMPv2 entities which 2587 have network interfaces." 2589 MODULE -- this module 2590 MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2, 2591 ifCounterDiscontinuityGroup } 2593 GROUP ifFixedLengthGroup 2594 DESCRIPTION 2595 "This group is mandatory for all network interfaces 2596 which are character-oriented or transmit data in 2597 fixed-length transmission units." 2599 GROUP ifHCFixedLengthGroup 2600 DESCRIPTION 2601 "This group is mandatory only for those network 2602 interfaces which are character-oriented or transmit 2603 data in fixed-length transmission units, and for which 2604 the value of the corresponding instance of ifSpeed is 2605 greater than 20,000,000 bits/second." 2607 GROUP ifPacketGroup 2608 DESCRIPTION 2609 "This group is mandatory for all network interfaces 2610 which are packet-oriented." 2612 GROUP ifHCPacketGroup 2613 DESCRIPTION 2614 "This group is mandatory only for those network 2615 interfaces which are packet-oriented and for which the 2616 value of the corresponding instance of ifSpeed is 2617 greater than 650,000,000 bits/second." 2619 Draft Interfaces Group MIB November 1996 2621 GROUP ifRcvAddressGroup 2622 DESCRIPTION 2623 "The applicability of this group MUST be defined by 2624 the media-specific MIBs. Media-specific MIBs must 2625 define the exact meaning, use, and semantics of the 2626 addresses in this group." 2628 OBJECT ifLinkUpDownTrapEnable 2629 MIN-ACCESS read-only 2630 DESCRIPTION 2631 "Write access is not required." 2633 OBJECT ifPromiscuousMode 2634 MIN-ACCESS read-only 2635 DESCRIPTION 2636 "Write access is not required." 2638 OBJECT ifStackStatus 2639 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2640 MIN-ACCESS read-only 2641 DESCRIPTION 2642 "Write access is not required, and only one of the six 2643 enumerated values for the RowStatus textual convention 2644 need be supported, specifically: active(1)." 2646 OBJECT ifAdminStatus 2647 SYNTAX INTEGER { up(1), down(2) } 2648 MIN-ACCESS read-only 2649 DESCRIPTION 2650 "Write access is not required, nor is support for the 2651 value testing(3)." 2653 OBJECT ifAlias 2654 MIN-ACCESS read-only 2655 DESCRIPTION 2656 "Write access is not required." 2658 ::= { ifCompliances 2 } 2660 Draft Interfaces Group MIB November 1996 2662 -- units of conformance 2664 ifGeneralInformationGroup OBJECT-GROUP 2665 OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress, 2666 ifAdminStatus, ifOperStatus, ifLastChange, 2667 ifLinkUpDownTrapEnable, ifConnectorPresent, 2668 ifHighSpeed, ifName, ifNumber, ifAlias, 2669 ifTableLastChange } 2670 STATUS current 2671 DESCRIPTION 2672 "A collection of objects providing information 2673 applicable to all network interfaces." 2674 ::= { ifGroups 10 } 2676 -- the following five groups are mutually exclusive; at most 2677 -- one of these groups is implemented for any interface 2679 ifFixedLengthGroup OBJECT-GROUP 2680 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2681 ifInErrors, ifOutErrors } 2682 STATUS current 2683 DESCRIPTION 2684 "A collection of objects providing information 2685 specific to non-high speed (non-high speed interfaces 2686 transmit and receive at speeds less than or equal to 2687 20,000,000 bits/second) character-oriented or fixed- 2688 length-transmission network interfaces." 2689 ::= { ifGroups 2 } 2691 ifHCFixedLengthGroup OBJECT-GROUP 2692 OBJECTS { ifHCInOctets, ifHCOutOctets, 2693 ifInOctets, ifOutOctets, ifInUnknownProtos, 2694 ifInErrors, ifOutErrors } 2695 STATUS current 2696 DESCRIPTION 2697 "A collection of objects providing information 2698 specific to high speed (greater than 20,000,000 2699 bits/second) character-oriented or fixed-length- 2700 transmission network interfaces." 2701 ::= { ifGroups 3 } 2703 ifPacketGroup OBJECT-GROUP 2704 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2705 ifInErrors, ifOutErrors, 2706 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2708 Draft Interfaces Group MIB November 1996 2710 ifInBroadcastPkts, ifInDiscards, 2711 ifOutUcastPkts, ifOutMulticastPkts, 2712 ifOutBroadcastPkts, ifOutDiscards, 2713 ifPromiscuousMode } 2714 STATUS current 2715 DESCRIPTION 2716 "A collection of objects providing information 2717 specific to non-high speed (non-high speed interfaces 2718 transmit and receive at speeds less than or equal to 2719 20,000,000 bits/second) packet-oriented network 2720 interfaces." 2721 ::= { ifGroups 4 } 2723 ifHCPacketGroup OBJECT-GROUP 2724 OBJECTS { ifHCInOctets, ifHCOutOctets, 2725 ifInOctets, ifOutOctets, ifInUnknownProtos, 2726 ifInErrors, ifOutErrors, 2727 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2728 ifInBroadcastPkts, ifInDiscards, 2729 ifOutUcastPkts, ifOutMulticastPkts, 2730 ifOutBroadcastPkts, ifOutDiscards, 2731 ifPromiscuousMode } 2732 STATUS current 2733 DESCRIPTION 2734 "A collection of objects providing information 2735 specific to high speed (greater than 20,000,000 2736 bits/second but less than or equal to 650,000,000 2737 bits/second) packet-oriented network interfaces." 2738 ::= { ifGroups 5 } 2740 ifVHCPacketGroup OBJECT-GROUP 2741 OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, 2742 ifHCInBroadcastPkts, ifHCOutUcastPkts, 2743 ifHCOutMulticastPkts, ifHCOutBroadcastPkts, 2744 ifHCInOctets, ifHCOutOctets, 2745 ifInOctets, ifOutOctets, ifInUnknownProtos, 2746 ifInErrors, ifOutErrors, 2747 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2748 ifInBroadcastPkts, ifInDiscards, 2749 ifOutUcastPkts, ifOutMulticastPkts, 2750 ifOutBroadcastPkts, ifOutDiscards, 2751 ifPromiscuousMode } 2752 STATUS current 2753 DESCRIPTION 2754 "A collection of objects providing information 2756 Draft Interfaces Group MIB November 1996 2758 specific to higher speed (greater than 650,000,000 2759 bits/second) packet-oriented network interfaces." 2760 ::= { ifGroups 6 } 2762 ifRcvAddressGroup OBJECT-GROUP 2763 OBJECTS { ifRcvAddressStatus, ifRcvAddressType } 2764 STATUS current 2765 DESCRIPTION 2766 "A collection of objects providing information on the 2767 multiple addresses which an interface receives." 2768 ::= { ifGroups 7 } 2770 ifStackGroup2 OBJECT-GROUP 2771 OBJECTS { ifStackStatus, ifStackLastChange } 2772 STATUS current 2773 DESCRIPTION 2774 "A collection of objects providing information on the 2775 layering of MIB-II interfaces." 2776 ::= { ifGroups 11 } 2778 ifCounterDiscontinuityGroup OBJECT-GROUP 2779 OBJECTS { ifCounterDiscontinuityTime } 2780 STATUS current 2781 DESCRIPTION 2782 "A collection of objects providing information 2783 specific to interface counter discontinuities." 2784 ::= { ifGroups 13 } 2786 Draft Interfaces Group MIB November 1996 2788 -- Deprecated Definitions - Objects 2790 -- 2791 -- The Interface Test Table 2792 -- 2793 -- This group of objects is optional. However, a media-specific 2794 -- MIB may make implementation of this group mandatory. 2795 -- 2796 -- This table replaces the ifExtnsTestTable 2797 -- 2799 ifTestTable OBJECT-TYPE 2800 SYNTAX SEQUENCE OF IfTestEntry 2801 MAX-ACCESS not-accessible 2802 STATUS deprecated 2803 DESCRIPTION 2804 "This table contains one entry per interface. It 2805 defines objects which allow a network manager to 2806 instruct an agent to test an interface for various 2807 faults. Tests for an interface are defined in the 2808 media-specific MIB for that interface. After invoking 2809 a test, the object ifTestResult can be read to 2810 determine the outcome. If an agent can not perform 2811 the test, ifTestResult is set to so indicate. The 2812 object ifTestCode can be used to provide further 2813 test-specific or interface-specific (or even 2814 enterprise-specific) information concerning the 2815 outcome of the test. Only one test can be in progress 2816 on each interface at any one time. If one test is in 2817 progress when another test is invoked, the second test 2818 is rejected. Some agents may reject a test when a 2819 prior test is active on another interface. 2821 Before starting a test, a manager-station must first 2822 obtain 'ownership' of the entry in the ifTestTable for 2823 the interface to be tested. This is accomplished with 2824 the ifTestId and ifTestStatus objects as follows: 2826 try_again: 2827 get (ifTestId, ifTestStatus) 2828 while (ifTestStatus != notInUse) 2829 /* 2830 * Loop while a test is running or some other 2831 * manager is configuring a test. 2833 Draft Interfaces Group MIB November 1996 2835 */ 2836 short delay 2837 get (ifTestId, ifTestStatus) 2838 } 2840 /* 2841 * Is not being used right now -- let's compete 2842 * to see who gets it. 2843 */ 2844 lock_value = ifTestId 2846 if ( set(ifTestId = lock_value, ifTestStatus = inUse, 2847 ifTestOwner = 'my-IP-address') == FAILURE) 2848 /* 2849 * Another manager got the ifTestEntry -- go 2850 * try again 2851 */ 2852 goto try_again; 2854 /* 2855 * I have the lock 2856 */ 2857 set up any test parameters. 2859 /* 2860 * This starts the test 2861 */ 2862 set(ifTestType = test_to_run); 2864 wait for test completion by polling ifTestResult 2866 when test completes, agent sets ifTestResult 2867 agent also sets ifTestStatus = 'notInUse' 2869 retrieve any additional test results, and ifTestId 2871 if (ifTestId == lock_value+1) results are valid 2873 A manager station first retrieves the value of the 2874 appropriate ifTestId and ifTestStatus objects, 2875 periodically repeating the retrieval if necessary, 2876 until the value of ifTestStatus is 'notInUse'. The 2877 manager station then tries to set the same ifTestId 2878 object to the value it just retrieved, the same 2879 ifTestStatus object to 'inUse', and the corresponding 2881 Draft Interfaces Group MIB November 1996 2883 ifTestOwner object to a value indicating itself. If 2884 the set operation succeeds then the manager has 2885 obtained ownership of the ifTestEntry, and the value of 2886 the ifTestId object is incremented by the agent (per 2887 the semantics of TestAndIncr). Failure of the set 2888 operation indicates that some other manager has 2889 obtained ownership of the ifTestEntry. 2891 Once ownership is obtained, any test parameters can be 2892 setup, and then the test is initiated by setting 2893 ifTestType. On completion of the test, the agent sets 2894 ifTestStatus to 'notInUse'. Once this occurs, the 2895 manager can retrieve the results. In the (rare) event 2896 that the invocation of tests by two network managers 2897 were to overlap, then there would be a possibility that 2898 the first test's results might be overwritten by the 2899 second test's results prior to the first results being 2900 read. This unlikely circumstance can be detected by a 2901 network manager retrieving ifTestId at the same time as 2902 retrieving the test results, and ensuring that the 2903 results are for the desired request. 2905 If ifTestType is not set within an abnormally long 2906 period of time after ownership is obtained, the agent 2907 should time-out the manager, and reset the value of the 2908 ifTestStatus object back to 'notInUse'. It is 2909 suggested that this time-out period be 5 minutes. 2911 In general, a management station must not retransmit a 2912 request to invoke a test for which it does not receive 2913 a response; instead, it properly inspects an agent's 2914 MIB to determine if the invocation was successful. 2915 Only if the invocation was unsuccessful, is the 2916 invocation request retransmitted. 2918 Some tests may require the interface to be taken off- 2919 line in order to execute them, or may even require the 2920 agent to reboot after completion of the test. In these 2921 circumstances, communication with the management 2922 station invoking the test may be lost until after 2923 completion of the test. An agent is not required to 2924 support such tests. However, if such tests are 2925 supported, then the agent should make every effort to 2926 transmit a response to the request which invoked the 2927 test prior to losing communication. When the agent is 2929 Draft Interfaces Group MIB November 1996 2931 restored to normal service, the results of the test are 2932 properly made available in the appropriate objects. 2933 Note that this requires that the ifIndex value assigned 2934 to an interface must be unchanged even if the test 2935 causes a reboot. An agent must reject any test for 2936 which it cannot, perhaps due to resource constraints, 2937 make available at least the minimum amount of 2938 information after that test completes." 2939 ::= { ifMIBObjects 3 } 2941 ifTestEntry OBJECT-TYPE 2942 SYNTAX IfTestEntry 2943 MAX-ACCESS not-accessible 2944 STATUS deprecated 2945 DESCRIPTION 2946 "An entry containing objects for invoking tests on an 2947 interface." 2948 AUGMENTS { ifEntry } 2949 ::= { ifTestTable 1 } 2951 IfTestEntry ::= 2952 SEQUENCE { 2953 ifTestId TestAndIncr, 2954 ifTestStatus INTEGER, 2955 ifTestType AutonomousType, 2956 ifTestResult INTEGER, 2957 ifTestCode OBJECT IDENTIFIER, 2958 ifTestOwner OwnerString 2959 } 2961 ifTestId OBJECT-TYPE 2962 SYNTAX TestAndIncr 2963 MAX-ACCESS read-write 2964 STATUS deprecated 2965 DESCRIPTION 2966 "This object identifies the current invocation of the 2967 interface's test." 2968 ::= { ifTestEntry 1 } 2970 ifTestStatus OBJECT-TYPE 2971 SYNTAX INTEGER { notInUse(1), inUse(2) } 2972 MAX-ACCESS read-write 2973 STATUS deprecated 2974 DESCRIPTION 2975 "This object indicates whether or not some manager 2977 Draft Interfaces Group MIB November 1996 2979 currently has the necessary 'ownership' required to 2980 invoke a test on this interface. A write to this 2981 object is only successful when it changes its value 2982 from 'notInUse(1)' to 'inUse(2)'. After completion of 2983 a test, the agent resets the value back to 2984 'notInUse(1)'." 2985 ::= { ifTestEntry 2 } 2987 ifTestType OBJECT-TYPE 2988 SYNTAX AutonomousType 2989 MAX-ACCESS read-write 2990 STATUS deprecated 2991 DESCRIPTION 2992 "A control variable used to start and stop operator- 2993 initiated interface tests. Most OBJECT IDENTIFIER 2994 values assigned to tests are defined elsewhere, in 2995 association with specific types of interface. 2996 However, this document assigns a value for a full- 2997 duplex loopback test, and defines the special meanings 2998 of the subject identifier: 3000 noTest OBJECT IDENTIFIER ::= { 0 0 } 3002 When the value noTest is written to this object, no 3003 action is taken unless a test is in progress, in which 3004 case the test is aborted. Writing any other value to 3005 this object is only valid when no test is currently in 3006 progress, in which case the indicated test is 3007 initiated. 3009 When read, this object always returns the most recent 3010 value that ifTestType was set to. If it has not been 3011 set since the last initialization of the network 3012 management subsystem on the agent, a value of noTest 3013 is returned." 3014 ::= { ifTestEntry 3 } 3016 ifTestResult OBJECT-TYPE 3017 SYNTAX INTEGER { 3018 none(1), -- no test yet requested 3019 success(2), 3020 inProgress(3), 3021 notSupported(4), 3022 unAbleToRun(5), -- due to state of system 3023 aborted(6), 3025 Draft Interfaces Group MIB November 1996 3027 failed(7) 3028 } 3029 MAX-ACCESS read-only 3030 STATUS deprecated 3031 DESCRIPTION 3032 "This object contains the result of the most recently 3033 requested test, or the value none(1) if no tests have 3034 been requested since the last reset. Note that this 3035 facility provides no provision for saving the results 3036 of one test when starting another, as could be 3037 required if used by multiple managers concurrently." 3038 ::= { ifTestEntry 4 } 3040 ifTestCode OBJECT-TYPE 3041 SYNTAX OBJECT IDENTIFIER 3042 MAX-ACCESS read-only 3043 STATUS deprecated 3044 DESCRIPTION 3045 "This object contains a code which contains more 3046 specific information on the test result, for example 3047 an error-code after a failed test. Error codes and 3048 other values this object may take are specific to the 3049 type of interface and/or test. The value may have the 3050 semantics of either the AutonomousType or 3051 InstancePointer textual conventions as defined in RFC 3052 1903. The identifier: 3054 testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } 3056 is defined for use if no additional result code is 3057 available." 3058 ::= { ifTestEntry 5 } 3060 ifTestOwner OBJECT-TYPE 3061 SYNTAX OwnerString 3062 MAX-ACCESS read-write 3063 STATUS deprecated 3064 DESCRIPTION 3065 "The entity which currently has the 'ownership' 3066 required to invoke a test on this interface." 3067 ::= { ifTestEntry 6 } 3069 Draft Interfaces Group MIB November 1996 3071 -- Deprecated Definitions - Groups 3073 ifGeneralGroup OBJECT-GROUP 3074 OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress, 3075 ifAdminStatus, ifOperStatus, ifLastChange, 3076 ifLinkUpDownTrapEnable, ifConnectorPresent, 3077 ifHighSpeed, ifName } 3078 STATUS deprecated 3079 DESCRIPTION 3080 "A collection of objects deprecated in favour of 3081 ifGeneralInformationGroup." 3082 ::= { ifGroups 1 } 3084 ifTestGroup OBJECT-GROUP 3085 OBJECTS { ifTestId, ifTestStatus, ifTestType, 3086 ifTestResult, ifTestCode, ifTestOwner } 3087 STATUS deprecated 3088 DESCRIPTION 3089 "A collection of objects providing the ability to 3090 invoke tests on an interface." 3091 ::= { ifGroups 8 } 3093 ifStackGroup OBJECT-GROUP 3094 OBJECTS { ifStackStatus } 3095 STATUS deprecated 3096 DESCRIPTION 3097 "The previous collection of objects providing 3098 information on the layering of MIB-II interfaces." 3099 ::= { ifGroups 9 } 3101 ifOldObjectsGroup OBJECT-GROUP 3102 OBJECTS { ifInNUcastPkts, ifOutNUcastPkts, 3103 ifOutQLen, ifSpecific } 3104 STATUS deprecated 3105 DESCRIPTION 3106 "The collection of objects deprecated from the 3107 original MIB-II interfaces group." 3108 ::= { ifGroups 12 } 3110 -- Deprecated Definitions - Compliance 3111 Draft Interfaces Group MIB November 1996 3113 ifCompliance MODULE-COMPLIANCE 3114 STATUS deprecated 3115 DESCRIPTION 3116 "The previous compliance statement for SNMPv2 entities 3117 which have network interfaces." 3119 MODULE -- this module 3120 MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup } 3122 GROUP ifFixedLengthGroup 3123 DESCRIPTION 3124 "This group is mandatory for all network interfaces 3125 which are character-oriented or transmit data in 3126 fixed-length transmission units." 3128 GROUP ifHCFixedLengthGroup 3129 DESCRIPTION 3130 "This group is mandatory only for those network 3131 interfaces which are character-oriented or transmit 3132 data in fixed-length transmission units, and for which 3133 the value of the corresponding instance of ifSpeed is 3134 greater than 20,000,000 bits/second." 3136 GROUP ifPacketGroup 3137 DESCRIPTION 3138 "This group is mandatory for all network interfaces 3139 which are packet-oriented." 3141 GROUP ifHCPacketGroup 3142 DESCRIPTION 3143 "This group is mandatory only for those network 3144 interfaces which are packet-oriented and for which the 3145 value of the corresponding instance of ifSpeed is 3146 greater than 650,000,000 bits/second." 3148 GROUP ifTestGroup 3149 DESCRIPTION 3150 "This group is optional. Media-specific MIBs which 3151 require interface tests are strongly encouraged to use 3152 this group for invoking tests and reporting results. 3153 A medium specific MIB which has mandatory tests may 3154 make implementation of this group mandatory." 3156 GROUP ifRcvAddressGroup 3157 DESCRIPTION 3159 Draft Interfaces Group MIB November 1996 3161 "The applicability of this group MUST be defined by 3162 the media-specific MIBs. Media-specific MIBs must 3163 define the exact meaning, use, and semantics of the 3164 addresses in this group." 3166 OBJECT ifLinkUpDownTrapEnable 3167 MIN-ACCESS read-only 3168 DESCRIPTION 3169 "Write access is not required." 3171 OBJECT ifPromiscuousMode 3172 MIN-ACCESS read-only 3173 DESCRIPTION 3174 "Write access is not required." 3176 OBJECT ifStackStatus 3177 SYNTAX INTEGER { active(1) } -- subset of RowStatus 3178 MIN-ACCESS read-only 3179 DESCRIPTION 3180 "Write access is not required, and only one of the six 3181 enumerated values for the RowStatus textual convention 3182 need be supported, specifically: active(1)." 3184 OBJECT ifAdminStatus 3185 SYNTAX INTEGER { up(1), down(2) } 3186 MIN-ACCESS read-only 3187 DESCRIPTION 3188 "Write access is not required, nor is support for the 3189 value testing(3)." 3190 ::= { ifCompliances 1 } 3192 END 3193 Draft Interfaces Group MIB November 1996 3195 7. Acknowledgements 3197 This memo has been produced by the IETF's Interfaces MIB working- 3198 group. 3200 The original proposal evolved from conversations and discussions 3201 with many people, including at least the following: Fred Baker, 3202 Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj 3203 Tesink, and Dean Throop. 3205 Draft Interfaces Group MIB November 1996 3207 8. References 3209 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 3210 S. Waldbusser, "Structure of Management Information for 3211 version 2 of the Simple Network Management Protocol 3212 (SNMPv2)", RFC 1902, January 1996. 3214 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 3215 S. Waldbusser, "Textual Conventions for version 2 of the 3216 Simple Network Management Protocol (SNMPv2)", RFC 1903, 3217 January 1996. 3219 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 3220 S. Waldbusser, "Protocol Operations for version 2 of the 3221 Simple Network Management Protocol (SNMPv2)", RFC 1905, 3222 January 1996. 3224 [4] McCloghrie, K., and M. Rose, "Management Information Base for 3225 Network Management of TCP/IP-based internets - MIB-II", RFC 3226 1213, Hughes LAN Systems, Performance Systems International, 3227 March 1991. 3229 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 3230 Network Management Protocol", RFC 1157, SNMP Research, 3231 Performance Systems International, Performance Systems 3232 International, MIT Laboratory for Computer Science, May 1990. 3234 [6] J. Postel, "Internet Protocol", RFC 791, Information Sciences 3235 Institute, USC, September 1981. 3237 [7] K. McCloghrie, "Extensions to the Generic-Interface MIB", RFC 3238 1229, Hughes LAN Systems, May 1991. 3240 [8] ATM Forum Technical Committee, "LAN Emulation Client 3241 Management: Version 1.0 Specification", af-lane-0044.000, ATM 3242 Forum, September 1995. 3244 [9] B. Stewart "Definitions of Managed Objects for Character 3245 Stream Devices using SMIv2", RFC 1658, Xyplex Inc., July 3246 1994. 3248 Draft Interfaces Group MIB November 1996 3250 9. Security Considerations 3252 Security issues are not discussed in this memo. 3254 10. Authors' Address 3256 Keith McCloghrie 3257 Cisco Systems, Inc. 3258 170 West Tasman Drive 3259 San Jose, CA 95134-1706 3261 Phone: 408-526-5260 3262 Email: kzm@cisco.com" 3264 Frank Kastenholz 3265 FTP Software 3266 2 High Street 3267 North Andover, Mass. USA 01845 3269 Phone: (508)685-4000 3270 Email: kasten@ftp.com 3272 Draft Interfaces Group MIB November 1996 3274 Table of Contents 3276 1 Introduction .............................................. 2 3277 1.1 Change Log .............................................. 2 3278 2 The SNMP Network Management Framework ..................... 5 3279 2.1 Object Definitions ...................................... 5 3280 3 Experience with the Interfaces Group ...................... 6 3281 3.1 Clarifications/Revisions ................................ 6 3282 3.1.1 Interface Sub-Layers .................................. 6 3283 3.1.2 Guidance on Defining Sub-layers ....................... 9 3284 3.1.3 Virtual Circuits ...................................... 11 3285 3.1.4 Bit, Character, and Fixed-Length Interfaces ........... 11 3286 3.1.5 Interface Numbering ................................... 13 3287 3.1.6 Counter Size .......................................... 18 3288 3.1.7 Interface Speed ....................................... 20 3289 3.1.8 Multicast/Broadcast Counters .......................... 21 3290 3.1.9 Trap Enable ........................................... 21 3291 3.1.10 Addition of New ifType values ........................ 22 3292 3.1.11 InterfaceIndex Textual Convention .................... 22 3293 3.1.12 New states for IfOperStatus .......................... 22 3294 3.1.13 IfAdminStatus and IfOperStatus ....................... 23 3295 3.1.14 IfOperStatus in an Interface Stack ................... 25 3296 3.1.15 Traps ................................................ 25 3297 3.1.16 ifSpecific ........................................... 27 3298 3.1.17 Creation/Deletion of Interfaces ...................... 27 3299 3.1.18 All Values Must be Known ............................. 28 3300 4 Media-Specific MIB Applicability .......................... 30 3301 5 Overview .................................................. 31 3302 6 Interfaces Group Definitions .............................. 32 3303 7 Acknowledgements .......................................... 74 3304 8 References ................................................ 75 3305 9 Security Considerations ................................... 76 3306 10 Authors' Address ......................................... 76