idnits 2.17.1 draft-ietf-ifmib-ifmib2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC2233, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC1573, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3177 has weird spacing: '...imed to perta...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (11 January 2000) is 8864 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) -- Looks like a reference, but probably isn't: 'RFC2026' on line 15 ** Obsolete normative reference: RFC 2571 (ref. '1') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '11') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '12') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '14') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '15') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 1229 (ref. '19') (Obsoleted by RFC 1573) -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Obsolete normative reference: RFC 2570 (ref. '22') (Obsoleted by RFC 3410) Summary: 19 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith McCloghrie 2 Internet Draft Cisco Systems 3 Obsoletes: 1573, 2233 Frank Kastenholz 4 Argon Networks 5 11 January 2000 7 The Interfaces Group MIB 9 draft-ietf-ifmib-ifmib2-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this document is unlimited. Please send comments 34 to the Interfaces MIB Working Group at if-mib@vnd.tek.com. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 1. Introduction 42 This memo defines a portion of the Management Information Base 43 (MIB) for use with network management protocols in the Internet 44 community. In particular, it describes managed objects used for 45 managing Network Interfaces. This memo discusses the 'interfaces' 46 group of MIB-II [17], especially the experience gained from the 47 definition of numerous media-specific MIB modules for use in 48 conjunction with the 'interfaces' group for managing various sub- 49 layers beneath the internetwork-layer. It specifies 50 clarifications to, and extensions of, the architectural issues 51 within the MIB-II model of the 'interfaces' group. This memo 52 obsoletes RFCs 1573 and 2233, the previous versions of the 53 Interfaces Group MIB. 55 The key words "MUST" and "MUST NOT" in this document are to be 56 interpreted as described in RFC 2119 [16]. 58 2. The SNMP Network Management Framework 60 The SNMP Management Framework presently consists of five major 61 components: 63 o An overall architecture, described in RFC 2571 [1]. 65 o Mechanisms for describing and naming objects and events for 66 the purpose of management. The first version of this 67 Structure of Management Information (SMI) is called SMIv1 and 68 described in STD 16/RFC 1155 [2], STD 16/RFC 1212 [3] and RFC 69 1215 [4]. The second version, called SMIv2, is described in 70 STD 58, which consists of RFC 2578 [5], RFC 2579 [6] and RFC 71 2580 [7]. 73 o Message protocols for transferring management information. 74 The first version of the SNMP message protocol is called 75 SNMPv1 and described in STD 15/RFC 1157 [8]. A second 76 version of the SNMP message protocol, which is not an 77 Internet standards track protocol, is called SNMPv2c and 78 described in RFC 1901 [9] and RFC 1906 [10]. The third 79 version of the message protocol is called SNMPv3 and 80 described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. 82 o Protocol operations for accessing management information. 83 The first set of protocol operations and associated PDU 84 formats is described in STD 15/RFC 1157 [8]. A second set of 85 protocol operations and associated PDU formats is described 86 in RFC 1905 [13]. 88 o A set of fundamental applications described in RFC 2573 [14] 89 and the view-based access control mechanism described in RFC 90 2575 [15]. 92 A more detailed introduction to the current SNMP Management 93 Framework can be found in RFC 2570 [22]. 95 Managed objects are accessed via a virtual information store, 96 termed the Management Information Base or MIB. Objects in the MIB 97 are defined using the mechanisms defined in the SMI. 99 This memo specifies a MIB module that is compliant to the SMIv2. 100 A MIB conforming to the SMIv1 can be produced through the 101 appropriate translations. The resulting translated MIB must be 102 semantically equivalent, except where objects or events are 103 omitted because no translation is possible (e.g., use of 104 Counter64). Some machine readable information in SMIv2 will be 105 converted into textual descriptions in SMIv1 during the 106 translation process. However, this loss of machine readable 107 information is not considered to change the semantics of the MIB. 109 3. Experience with the Interfaces Group 111 One of the strengths of internetwork-layer protocols such as IP 112 [18] is that they are designed to run over any network interface. 113 In achieving this, IP considers any and all protocols it runs over 114 as a single "network interface" layer. A similar view is taken by 115 other internetwork-layer protocols. This concept is represented 116 in MIB-II by the 'interfaces' group which defines a generic set of 117 managed objects such that any network interface can be managed in 118 an interface-independent manner through these managed objects. 119 The 'interfaces' group provides the means for additional managed 120 objects specific to particular types of network interface (e.g., a 121 specific medium such as Ethernet) to be defined as extensions to 122 the 'interfaces' group for media-specific management. Since the 123 standardization of MIB-II, many such media-specific MIB modules 124 have been defined. 126 Experience in defining these media-specific MIB modules has shown 127 that the model defined by MIB-II is too simplistic and/or static 128 for some types of media-specific management. As a result, some of 129 these media-specific MIB modules assume an evolution or loosening 130 of the model. This memo documents and standardizes that evolution 131 of the model and fills in the gaps caused by that evolution. This 132 memo also incorporates the interfaces group extensions documented 133 in RFC 1229 [19]. 135 3.1. Clarifications/Revisions 137 There are several areas for which experience has indicated that 138 clarification, revision, or extension of the model would be 139 helpful. The following sections discuss the changes in the 140 interfaces group adopted by this memo in each of these areas. 142 In some sections, one or more paragraphs contain discussion of 143 rejected alternatives to the model adopted in this memo. Readers 144 not familiar with the MIB-II model and not interested in the 145 rationale behind the new model may want to skip these paragraphs. 147 3.1.1. Interface Sub-Layers 149 Experience in defining media-specific management information has 150 shown the need to distinguish between the multiple sub-layers 151 beneath the internetwork-layer. In addition, there is a need to 152 manage these sub-layers in devices (e.g., MAC-layer bridges) which 153 are unaware of which, if any, internetwork protocols run over 154 these sub-layers. As such, a model of having a single conceptual 155 row in the interfaces table (MIB-II's ifTable) represent a whole 156 interface underneath the internetwork-layer, and having a single 157 associated media-specific MIB module (referenced via the ifType 158 object) is too simplistic. A further problem arises with the 159 value of the ifType object which has enumerated values for each 160 type of interface. 162 Consider, for example, an interface with PPP running over an HDLC 163 link which uses a RS232-like connector. Each of these sub-layers 164 has its own media-specific MIB module. If all of this is 165 represented by a single conceptual row in the ifTable, then an 166 enumerated value for ifType is needed for that specific 167 combination which maps to the specific combination of media- 168 specific MIBs. Furthermore, such a model still lacks a method to 169 describe the relationship of all the sub-layers of the MIB stack. 171 An associated problem is that of upward and downward multiplexing 172 of the sub-layers. An example of upward multiplexing is MLP 173 (Multi-Link-Procedure) which provides load-sharing over several 174 serial lines by appearing as a single point-to-point link to the 175 sub-layer(s) above. An example of downward multiplexing would be 176 several instances of PPP, each framed within a separate X.25 177 virtual circuit, all of which run over one fractional T1 channel, 178 concurrently with other uses of the T1 link. The MIB structure 179 must allow these sorts of relationships to be described. 181 Several solutions for representing multiple sub-layers were 182 rejected. One was to retain the concept of one conceptual row for 183 all the sub-layers of an interface and have each media-specific 184 MIB module identify its "superior" and "subordinate" sub-layers 185 through OBJECT IDENTIFIER "pointers". This scheme would have 186 several drawbacks: the superior/subordinate pointers would be 187 contained in the media-specific MIB modules; thus, a manager could 188 not learn the structure of an interface without inspecting 189 multiple pointers in different MIB modules; this would be overly 190 complex and only possible if the manager had knowledge of all the 191 relevant media-specific MIB modules; MIB modules would all need to 192 be retrofitted with these new "pointers"; this scheme would not 193 adequately address the problem of upward and downward 194 multiplexing; and finally, enumerated values of ifType would be 195 needed for each combination of sub-layers. Another rejected 196 solution also retained the concept of one conceptual row for all 197 the sub-layers of an interface but had a new separate MIB table to 198 identify the "superior" and "subordinate" sub-layers and to 199 contain OBJECT IDENTIFIER "pointers" to the media-specific MIB 200 module for each sub-layer. Effectively, one conceptual row in the 201 ifTable would represent each combination of sub-layers between the 202 internetwork-layer and the wire. While this scheme has fewer 203 drawbacks, it still would not support downward multiplexing, such 204 as PPP over MLP: observe that MLP makes two (or more) serial lines 205 appear to the layers above as a single physical interface, and 206 thus PPP over MLP should appear to the internetwork-layer as a 207 single interface; in contrast, this scheme would result in two (or 208 more) conceptual rows in the ifTable, both of which the 209 internetwork-layer would run over. This scheme would also require 210 enumerated values of ifType for each combination of sub-layers. 212 The solution adopted by this memo is to have an individual 213 conceptual row in the ifTable to represent each sub-layer, and 214 have a new separate MIB table (the ifStackTable, see section 6 215 below) to identify the "superior" and "subordinate" sub-layers 216 through INTEGER "pointers" to the appropriate conceptual rows in 217 the ifTable. This solution supports both upward and downward 218 multiplexing, allows the IANAifType to Media-Specific MIB mapping 219 to identify the media-specific MIB module for that sub-layer, such 220 that the new table need only be referenced to obtain information 221 about layering, and it only requires enumerated values of ifType 222 for each sub-layer, not for combinations of them. However, it 223 does require that the descriptions of some objects in the ifTable 224 (specifically, ifType, ifPhysAddress, ifInUcastPkts, and 225 ifOutUcastPkts) be generalized so as to apply to any sub-layer 226 (rather than only to a sub-layer immediately beneath the network 227 layer as previously), plus some (specifically, ifSpeed) which need 228 to have appropriate values identified for use when a generalized 229 definition does not apply to a particular sub-layer. 231 In addition, this adopted solution makes no requirement that a 232 device, in which a sub-layer is instrumented by a conceptual row 233 of the ifTable, be aware of whether an internetwork protocol runs 234 on top of (i.e., at some layer above) that sub-layer. In fact, 235 the counters of packets received on an interface are defined as 236 counting the number "delivered to a higher-layer protocol". This 237 meaning of "higher-layer" includes: 239 (1) Delivery to a forwarding module which accepts 240 packets/frames/octets and forwards them on at the same 241 protocol layer. For example, for the purposes of this 242 definition, the forwarding module of a MAC-layer bridge is 243 considered as a "higher-layer" to the MAC-layer of each 244 port on the bridge. 246 (2) Delivery to a higher sub-layer within a interface stack. 247 For example, for the purposes of this definition, if a PPP 248 module operated directly over a serial interface, the PPP 249 module would be considered the higher sub-layer to the 250 serial interface. 252 (3) Delivery to a higher protocol layer which does not do 253 packet forwarding for sub-layers that are "at the top of" 254 the interface stack. For example, for the purposes of this 255 definition, the local IP module would be considered the 256 higher layer to a SLIP serial interface. 258 Similarly, for output, the counters of packets transmitted out an 259 interface are defined as counting the number "that higher-level 260 protocols requested to be transmitted". This meaning of "higher- 261 layer" includes: 263 (1) A forwarding module, at the same protocol layer, which 264 transmits packets/frames/octets that were received on an 265 different interface. For example, for the purposes of this 266 definition, the forwarding module of a MAC-layer bridge is 267 considered as a "higher-layer" to the MAC-layer of each 268 port on the bridge. 270 (2) The next higher sub-layer within an interface stack. For 271 example, for the purposes of this definition, if a PPP 272 module operated directly over a serial interface, the PPP 273 module would be a "higher layer" to the serial interface. 275 (3) For sub-layers that are "at the top of" the interface 276 stack, a higher element in the network protocol stack. For 277 example, for the purposes of this definition, the local IP 278 module would be considered the higher layer to an Ethernet 279 interface. 281 3.1.2. Guidance on Defining Sub-layers 283 The designer of a media-specific MIB must decide whether to divide 284 the interface into sub-layers or not, and if so, how to make the 285 divisions. The following guidance is offered to assist the media- 286 specific MIB designer in these decisions. 288 In general, the number of entries in the ifTable should be kept to 289 the minimum required for network management. In particular, a 290 group of related interfaces should be treated as a single 291 interface with one entry in the ifTable providing that: 293 (1) None of the group of interfaces performs multiplexing for 294 any other interface in the agent, 296 (2) There is a meaningful and useful way for all of the 297 ifTable's information (e.g., the counters, and the status 298 variables), and all of the ifTable's capabilities (e.g., 299 write access to ifAdminStatus), to apply to the group of 300 interfaces as a whole. 302 Under these circumstances, there should be one entry in the 303 ifTable for such a group of interfaces, and any internal structure 304 which needs to be represented to network management should be 305 captured in a MIB module specific to the particular type of 306 interface. 308 Note that application of bullet 2 above to the ifTable's ifType 309 object requires that there is a meaningful media-specific MIB and 310 a meaningful ifType value which apply to the group of interfaces 311 as a whole. For example, it is not appropriate to treat an HDLC 312 sub-layer and an RS-232 sub-layer as a single ifTable entry when 313 the media-specific MIBs and the ifType values for HDLC and RS-232 314 are separate (rather than combined). 316 Subject to the above, it is appropriate to assign an ifIndex value 317 to any interface that can occur in an interface stack (in the 318 ifStackTable) where the bottom of the stack is a physical 319 interface (ifConnectorPresent has the value 'true') and there is a 320 layer-3 or other application that "points down" to the top of this 321 stack. An example of an application that points down to the top 322 of the stack is the Character MIB [21]. 324 Note that the sub-layers of an interface on one device will 325 sometimes be different from the sub-layers of the interconnected 326 interface of another device; for example, for a frame-relay DTE 327 interface connected a frameRelayService interface, the inter- 328 connected DTE and DCE interfaces have different ifType values and 329 media-specific MIBs. 331 These guidelines are just that, guidelines. The designer of a 332 media-specific MIB is free to lay out the MIB in whatever SMI 333 conformant manner is desired. However, in doing so, the media- 334 specific MIB MUST completely specify the sub-layering model used 335 for the MIB, and provide the assumptions, reasoning, and rationale 336 used to develop that model. 338 3.1.3. Virtual Circuits 340 Several of the sub-layers for which media-specific MIB modules 341 have been defined are connection oriented (e.g., Frame Relay, 342 X.25). Experience has shown that each effort to define such a MIB 343 module revisits the question of whether separate conceptual rows 344 in the ifTable are needed for each virtual circuit. Most, if not 345 all, of these efforts to date have decided to have all virtual 346 circuits reference a single conceptual row in the ifTable. 348 This memo strongly recommends that connection-oriented sub-layers 349 do not have a conceptual row in the ifTable for each virtual 350 circuit. This avoids the proliferation of conceptual rows, 351 especially those which have considerable redundant information. 352 (Note, as a comparison, that connection-less sub-layers do not 353 have conceptual rows for each remote address.) There may, 354 however, be circumstances under which it is appropriate for a 355 virtual circuit of a connection-oriented sub-layer to have its own 356 conceptual row in the ifTable; an example of this might be PPP 357 over an X.25 virtual circuit. The MIB in section 6 of this memo 358 supports such circumstances. 360 If a media-specific MIB wishes to assign an entry in the ifTable 361 to each virtual circuit, the MIB designer must present the 362 rationale for this decision in the media-specific MIB's 363 specification. 365 3.1.4. Bit, Character, and Fixed-Length Interfaces 367 RS-232 is an example of a character-oriented sub-layer over which 368 (e.g., through use of PPP) IP datagrams can be sent. Due to the 369 packet-based nature of many of the objects in the ifTable, 370 experience has shown that it is not appropriate to have a 371 character-oriented sub-layer represented by a whole conceptual row 372 in the ifTable. 374 Experience has also shown that it is sometimes desirable to have 375 some management information for bit-oriented interfaces, which are 376 similarly difficult to represent by a whole conceptual row in the 377 ifTable. For example, to manage the channels of a DS1 circuit, 378 where only some of the channels are carrying packet-based data. 380 A further complication is that some subnetwork technologies 381 transmit data in fixed length transmission units. One example of 382 such a technology is cell relay, and in particular Asynchronous 383 Transfer Mode (ATM), which transmits data in fixed-length cells. 384 Representing such a interface as a packet-based interface produces 385 redundant objects if the relationship between the number of 386 packets and the number of octets in either direction is fixed by 387 the size of the transmission unit (e.g., the size of a cell). 389 About half the objects in the ifTable are applicable to every type 390 of interface: packet-oriented, character-oriented, and bit- 391 oriented. Of the other half, two are applicable to both 392 character-oriented and packet-oriented interfaces, and the rest 393 are applicable only to packet-oriented interfaces. Thus, while it 394 is desirable for consistency to be able to represent any/all types 395 of interfaces in the ifTable, it is not possible to implement the 396 full ifTable for bit- and character-oriented sub-layers. 398 A rejected solution to this problem would be to split the ifTable 399 into two (or more) new MIB tables, one of which would contain 400 objects that are relevant only to packet-oriented interfaces 401 (e.g., PPP), and another that may be used by all interfaces. This 402 is highly undesirable since it would require changes in every 403 agent implementing the ifTable (i.e., just about every existing 404 SNMP agent). 406 The solution adopted in this memo builds upon the fact that 407 compliance statements in SNMPv2 (in contrast to SNMPv1) refer to 408 object groups, where object groups are explicitly defined by 409 listing the objects they contain. Thus, in SNMPv2, multiple 410 compliance statements can be specified, one for all interfaces and 411 additional ones for specific types of interfaces. The separate 412 compliance statements can be based on separate object groups, 413 where the object group for all interfaces can contain only those 414 objects from the ifTable which are appropriate for every type of 415 interfaces. Using this solution, every sub-layer can have its own 416 conceptual row in the ifTable. 418 Thus, section 6 of this memo contains definitions of the objects 419 of the existing 'interfaces' group of MIB-II, in a manner which is 420 both SNMPv2-compliant and semantically-equivalent to the existing 421 MIB-II definitions. With equivalent semantics, and with the BER 422 ("on the wire") encodings unchanged, these definitions retain the 423 same OBJECT IDENTIFIER values as assigned by MIB-II. Thus, in 424 general, no rewrite of existing agents which conform to MIB-II and 425 the ifExtensions MIB is required. 427 In addition, this memo defines several object groups for the 428 purposes of defining which objects apply to which types of 429 interface: 431 (1) the ifGeneralInformationGroup. This group contains those 432 objects applicable to all types of network interfaces, 433 including bit-oriented interfaces. 435 (2) the ifPacketGroup. This group contains those objects 436 applicable to packet-oriented network interfaces. 438 (3) the ifFixedLengthGroup. This group contains the objects 439 applicable not only to character-oriented interfaces, such 440 as RS-232, but also to those subnetwork technologies, such 441 as cell-relay/ATM, which transmit data in fixed length 442 transmission units. As well as the octet counters, there 443 are also a few other counters (e.g., the error counters) 444 which are useful for this type of interface, but are 445 currently defined as being packet-oriented. To accommodate 446 this, the definitions of these counters are generalized to 447 apply to character-oriented interfaces and fixed-length- 448 transmission interfaces. 450 It should be noted that the octet counters in the ifTable 451 aggregate octet counts for unicast and non-unicast packets into a 452 single octet counter per direction (received/transmitted). Thus, 453 with the above definition of fixed-length-transmission interfaces, 454 where such interfaces which support non-unicast packets, separate 455 counts of unicast and multicast/broadcast transmissions can only 456 be maintained in a media-specific MIB module. 458 3.1.5. Interface Numbering 460 MIB-II defines an object, ifNumber, whose value represents: 462 "The number of network interfaces (regardless of their 463 current state) present on this system." 465 Each interface is identified by a unique value of the ifIndex 466 object, and the description of ifIndex constrains its value as 467 follows: 469 "Its value ranges between 1 and the value of ifNumber. The 470 value for each interface must remain constant at least from 471 one re-initialization of the entity's network management 472 system to the next re-initialization." 474 This constancy requirement on the value of ifIndex for a 475 particular interface is vital for efficient management. However, 476 an increasing number of devices allow for the dynamic 477 addition/removal of network interfaces. One example of this is a 478 dynamic ability to configure the use of SLIP/PPP over a character- 479 oriented port. For such dynamic additions/removals, the 480 combination of the constancy requirement and the restriction that 481 the value of ifIndex is less than ifNumber is problematic. 483 Redefining ifNumber to be the largest value of ifIndex was 484 rejected since it would not help. Such a re-definition would 485 require ifNumber to be deprecated and the utility of the redefined 486 object would be questionable. Alternatively, ifNumber could be 487 deprecated and not replaced. However, the deprecation of ifNumber 488 would require a change to that portion of ifIndex's definition 489 which refers to ifNumber. So, since the definition of ifIndex 490 must be changed anyway in order to solve the problem, changes to 491 ifNumber do not benefit the solution. 493 The solution adopted in this memo is just to delete the 494 requirement that the value of ifIndex must be less than the value 495 of ifNumber, and to retain ifNumber with its current definition. 496 This is a minor change in the semantics of ifIndex; however, all 497 existing agent implementations conform to this new definition, and 498 in the interests of not requiring changes to existing agent 499 implementations and to the many existing media-specific MIBs, this 500 memo assumes that this change does not require ifIndex to be 501 deprecated. Experience indicates that this assumption does 502 "break" a few management applications, but this is considered 503 preferable to breaking all agent implementations. 505 This solution also results in the possibility of "holes" in the 506 ifTable, i.e., the ifIndex values of conceptual rows in the 507 ifTable are not necessarily contiguous, but SNMP's GetNext (and 508 SNMPv2's GetBulk) operation easily deals with such holes. The 509 value of ifNumber still represents the number of conceptual rows, 510 which increases/decreases as new interfaces are dynamically 511 added/removed. 513 The requirement for constancy (between re-initializations) of an 514 interface's ifIndex value is met by requiring that after an 515 interface is dynamically removed, its ifIndex value is not re-used 516 by a *different* dynamically added interface until after the 517 following re-initialization of the network management system. 518 This avoids the need for assignment (in advance) of ifIndex values 519 for all possible interfaces that might be added dynamically. The 520 exact meaning of a "different" interface is hard to define, and 521 there will be gray areas. Any firm definition in this document 522 would likely turn out to be inadequate. Instead, implementors 523 must choose what it means in their particular situation, subject 524 to the following rules: 526 (1) a previously-unused value of ifIndex must be assigned to a 527 dynamically added interface if an agent has no knowledge of 528 whether the interface is the "same" or "different" to a 529 previously incarnated interface. 531 (2) a management station, not noticing that an interface has 532 gone away and another has come into existence, must not be 533 confused when calculating the difference between the 534 counter values retrieved on successive polls for a 535 particular ifIndex value. 537 When the new interface is the same as an old interface, but a 538 discontinuity in the value of the interface's counters cannot be 539 avoided, the ifTable has (until now) required that a new ifIndex 540 value be assigned to the returning interface. That is, either all 541 counter values have had to be retained during the absence of an 542 interface in order to use the same ifIndex value on that 543 interface's return, or else a new ifIndex value has had to be 544 assigned to the returning interface. Both alternatives have 545 proved to be burdensome to some implementations: 547 (1) maintaining the counter values may not be possible (e.g., 548 if they are maintained on removable hardware), 550 (2) using a new ifIndex value presents extra work for 551 management applications. While the potential need for such 552 extra work is unavoidable on agent re-initializations, it 553 is desirable to avoid it between re-initializations. 555 To address this, a new object, ifCounterDiscontinuityTime, has 556 been defined to record the time of the last discontinuity in an 557 interface's counters. By monitoring the value of this new object, 558 a management application can now detect counter discontinuities 559 without the ifIndex value of the interface being changed. Thus, 560 an agent which implements this new object should, when a new 561 interface is the same as an old interface, retain that interface's 562 ifIndex value and update if necessary the interface's value of 563 ifCounterDiscontinuityTime. With this new object, a management 564 application must, when calculating differences between counter 565 values retrieved on successive polls, discard any calculated 566 difference for which the value of ifCounterDiscontinuityTime is 567 different for the two polls. (Note that this test must be 568 performed in addition to the normal checking of sysUpTime to 569 detect an agent re-initialization.) Since such discards are a 570 waste of network management processing and bandwidth, an agent 571 should not update the value of ifCounterDiscontinuityTime unless 572 absolutely necessary. 574 While defining this new object is a change in the semantics of the 575 ifTable counter objects, it is impractical to deprecate and 576 redefine all these counters because of their wide deployment and 577 importance. Also, a survey of implementations indicates that many 578 agents and management applications do not correctly implement this 579 aspect of the current semantics (because of the burdensome issues 580 mentioned above), such that the practical implications of such a 581 change is small. Thus, this breach of the SMI's rules is 582 considered to be acceptable. 584 Note, however, that the addition of ifCounterDiscontinuityTime 585 does not change the fact that: 587 it is necessary at certain times for the assignment of 588 ifIndex values to change on a re-initialization of the agent 589 (such as a reboot). 591 The possibility of ifIndex value re-assignment must be accommodated by a 592 management application whenever the value of sysUpTime is reset to zero. 594 Note also that some agents support multiple "naming scopes", e.g., for 595 an SNMPv1 agent, multiple values of the SNMPv1 community string. For 596 such an agent (e.g., a CNM agent which supports a different subset of 597 interfaces for different customers), there is no required relationship 598 between the ifIndex values which identify interfaces in one naming scope 599 and those which identify interfaces in another naming scope. It is the 600 agent's choice as to whether the same or different ifIndex values 601 identify the same or different interfaces in different naming scopes. 603 Because of the restriction of the value of ifIndex to be less than 604 ifNumber, interfaces have been numbered with small integer values. This 605 has led to the ability by humans to use the ifIndex values as (somewhat) 606 user-friendly names for network interfaces (e.g., "interface number 3"). 607 With the relaxation of the restriction on the value of ifIndex, there is 608 now the possibility that ifIndex values could be assigned as very large 609 numbers (e.g., memory addresses). Such numbers would be much less user- 610 friendly. Therefore, this memo recommends that ifIndex values still be 611 assigned as (relatively) small integer values starting at 1, even though 612 the values in use at any one time are not necessarily contiguous. (Note 613 that this makes remembering which values have been assigned easy for 614 agents which dynamically add new interfaces) 616 A new problem is introduced by representing each sub-layer as an ifTable 617 entry. Previously, there usually was a simple, direct, mapping of 618 interfaces to the physical ports on systems. This mapping would be 619 based on the ifIndex value. However, by having an ifTable entry for 620 each interface sub-layer, mapping from interfaces to physical ports 621 becomes increasingly problematic. 623 To address this issue, a new object, ifName, is added to the MIB. This 624 object contains the device's local name (e.g., the name used at the 625 device's local console) for the interface of which the relevant entry in 626 the ifTable is a component. For example, consider a router having an 627 interface composed of PPP running over an RS-232 port. If the router 628 uses the name "wan1" for the (combined) interface, then the ifName 629 objects for the corresponding PPP and RS-232 entries in the ifTable 630 would both have the value "wan1". On the other hand, if the router uses 631 the name "wan1.1" for the PPP interface and "wan1.2" for the RS-232 632 port, then the ifName objects for the corresponding PPP and RS-232 633 entries in the ifTable would have the values "wan1.1" and "wan1.2", 634 respectively. As an another example, consider an agent which responds 635 to SNMP queries concerning an interface on some other (proxied) device: 636 if such a proxied device associates a particular identifier with an 637 interface, then it is appropriate to use this identifier as the value of 638 the interface's ifName, since the local console in this case is that of 639 the proxied device. 641 In contrast, the existing ifDescr object is intended to contain a 642 description of an interface, whereas another new object, ifAlias, 643 provides a location in which a network management application can store 644 a non-volatile interface-naming value of its own choice. The ifAlias 645 object allows a network manager to give one or more interfaces their own 646 unique names, irrespective of any interface-stack relationship. 647 Further, the ifAlias name is non-volatile, and thus an interface must 648 retain its assigned ifAlias value across reboots, even if an agent 649 chooses a new ifIndex value for the interface. 651 3.1.6. Counter Size 653 As the speed of network media increase, the minimum time in which a 32 654 bit counter will wrap decreases. For example, a 10Mbs stream of back- 655 to-back, full-size packets causes ifInOctets to wrap in just over 57 656 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and at 1Gbs, 657 the minimum is 34 seconds. Requiring that interfaces be polled 658 frequently enough not to miss a counter wrap is increasingly 659 problematic. 661 A rejected solution to this problem was to scale the counters; for 662 example, ifInOctets could be changed to count received octets in, say, 663 1024 byte blocks. While it would provide acceptable functionality at 664 high rates of the counted-events, at low rates it suffers. If there is 665 little traffic on an interface, there might be a significant interval 666 before enough of the counted-events occur to cause the scaled counter to 667 be incremented. Traffic would then appear to be very bursty, leading to 668 incorrect conclusions of the network's performance. 670 Instead, this memo adopts expanded, 64 bit, counters. These counters 671 are provided in new "high capacity" groups. The old, 32-bit, counters 672 have not been deprecated. The 64-bit counters are to be used only when 673 the 32-bit counters do not provide enough capacity; that is, when the 32 674 bit counters could wrap too fast. 676 For interfaces that operate at 20,000,000 (20 million) bits per second 677 or less, 32-bit byte and packet counters MUST be supported. For 678 interfaces that operate faster than 20,000,000 bits/second, and slower 679 than 650,000,000 bits/second, 32-bit packet counters MUST be supported 680 and 64-bit octet counters MUST be supported. For interfaces that 681 operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 682 64-bit octet counters MUST be supported. 684 These speed thresholds were chosen as reasonable compromises based on 685 the following: 687 (1) The cost of maintaining 64-bit counters is relatively high, so 688 minimizing the number of agents which must support them is 689 desirable. Common interfaces (such as 10Mbs Ethernet) should not 690 require them. 692 (2) 64-bit counters are a new feature, introduced in SNMPv2. It is 693 reasonable to expect that support for them will be spotty for the 694 immediate future. Thus, we wish to limit them to as few systems 695 as possible. This, in effect, means that 64-bit counters should 696 be limited to higher speed interfaces. Ethernet (10,000,000 bps) 697 and Token Ring (16,000,000 bps) are fairly wide-spread so it 698 seems reasonable to not require 64-bit counters for these 699 interfaces. 701 (3) The 32-bit octet counters will wrap in the following times, for 702 the following interfaces (when transmitting maximum-sized packets 703 back-to-back): 705 - 10Mbs Ethernet: 57 minutes, 707 - 16Mbs Token Ring: 36 minutes, 708 - a US T3 line (45 megabits): 12 minutes, 710 - FDDI: 5.7 minutes 712 (4) The 32-bit packet counters wrap in about 57 minutes when 64-byte 713 packets are transmitted back-to-back on a 650,000,000 bit/second 714 link. 716 As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit 717 octet counter to wrap in just under 5 years. Conversely, an 81,000,000 718 terabit/second link is required to cause a 64-bit counter to wrap in 30 719 minutes. We believe that, while technology rapidly marches forward, 720 this link speed will not be achieved for at least several years, leaving 721 sufficient time to evaluate the introduction of 96 bit counters. 723 When 64-bit counters are in use, the 32-bit counters MUST still be 724 available. They will report the low 32-bits of the associated 64-bit 725 count (e.g., ifInOctets will report the least significant 32 bits of 726 ifHCInOctets). This enhances inter-operability with existing 727 implementations at a very minimal cost to agents. 729 The new "high capacity" groups are: 731 (1) the ifHCFixedLengthGroup for character-oriented/fixed-length 732 interfaces, and the ifHCPacketGroup for packet-based interfaces; 733 both of these groups include 64 bit counters for octets, and 735 (2) the ifVHCPacketGroup for packet-based interfaces; this group 736 includes 64 bit counters for octets and packets. 738 3.1.7. Interface Speed 740 Network speeds are increasing. The range of ifSpeed is limited to 741 reporting a maximum speed of (2**31)-1 bits/second, or approximately 742 2.2Gbs. SONET defines an OC-48 interface, which is defined at operating 743 at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs. Thus, ifSpeed 744 is insufficient for the future, and this memo defines an additional 745 object: ifHighSpeed. 747 The ifHighSpeed object reports the speed of the interface in 1,000,000 748 (1 million) bits/second units. Thus, the true speed of the interface 749 will be the value reported by this object, plus or minus 500,000 750 bits/second. 752 Other alternatives considered (but rejected) were: 754 (1) Making the interface speed a 64-bit gauge. This was rejected 755 since the current SMI does not allow such a syntax. 757 Furthermore, even if 64-bit gauges were available, their use would 758 require additional complexity in agents due to an increased 759 requirement for 64-bit operations. 761 (2) We also considered making "high-32 bit" and "low-32-bit" objects 762 which, when combined, would be a 64-bit value. This simply 763 seemed overly complex for what we are trying to do. 765 Furthermore, a full 64-bits of precision does not seem necessary. 766 The value of ifHighSpeed will be the only report of interface speed 767 for interfaces that are faster than 4,294,967,295 bits per second. 768 At this speed, the granularity of ifHighSpeed will be 1,000,000 769 bits per second, thus the error will be 1/4294, or about 0.02%. 770 This seems reasonable. 772 (3) Adding a "scale" object, which would define the units which 773 ifSpeed's value is. 775 This would require two additional objects; one for the scaling 776 object, and one to replace the current ifSpeed. This later object 777 is required since the semantics of ifSpeed would be significantly 778 altered, and manager stations which do not understand the new 779 semantics would be confused. 781 3.1.8. Multicast/Broadcast Counters 783 In MIB-II, the ifTable counters for multicast and broadcast packets are 784 combined as counters of non-unicast packets. In contrast, the 785 ifExtensions MIB [19] defined one set of counters for multicast, and a 786 separate set for broadcast packets. With the separate counters, the 787 original combined counters become redundant. To avoid this redundancy, 788 the non-unicast counters are deprecated. 790 For the output broadcast and multicast counters defined in RFC 1229, 791 their definitions varied slightly from the packet counters in the 792 ifTable, in that they did not count errors/discarded packets. Thus, 793 this memo defines new objects with better aligned definitions. Counters 794 with 64 bits of range are also needed, as explained above. 796 3.1.9. Trap Enable 798 In the multi-layer interface model, each sub-layer for which there is an 799 entry in the ifTable can generate linkUp/linkDown Traps. Since 800 interface state changes would tend to propagate through the interface 801 (from top to bottom, or bottom to top), it is likely that several traps 802 would be generated for each linkUp/linkDown occurrence. 804 It is desirable to provide a mechanism for manager stations to control 805 the generation of these traps. To this end, the ifLinkUpDownTrapEnable 806 object has been added. This object allows managers to limit generation 807 of traps to just the sub-layers of interest. 809 The default setting should limit the number of traps generated to one 810 per interface per linkUp/linkDown event. Furthermore, it seems that the 811 state changes of most interest to network managers occur at the lowest 812 level of an interface stack. Therefore we specify that by default, only 813 the lowest sub-layer of the interface generate traps. 815 3.1.10. Addition of New ifType values 817 Over time, there is the need to add new ifType enumerated values for new 818 interface types. If the syntax of ifType were defined in the MIB in 819 section 6, then a new version of this MIB would have to be re-issued in 820 order to define new values. In the past, re-issuing of a MIB has 821 occurred only after several years. 823 Therefore, the syntax of ifType is changed to be a textual convention, 824 such that the enumerated integer values are now defined in the textual 825 convention, IANAifType, defined in a different document. This allows 826 additional values to be documented without having to re-issue a new 827 version of this document. The Internet Assigned Number Authority (IANA) 828 is responsible for the assignment of all Internet numbers, including 829 various SNMP-related numbers, and specifically, new ifType values. 831 3.1.11. InterfaceIndex Textual Convention 833 A new textual convention, InterfaceIndex, has been defined. This 834 textual convention "contains" all of the semantics of the ifIndex 835 object. This allows other MIB modules to easily import the semantics of 836 ifIndex. 838 3.1.12. New states for IfOperStatus 840 Three new states have been added to ifOperStatus: 'dormant', 841 'notPresent', and 'lowerLayerDown'. 843 The dormant state indicates that the relevant interface is not actually 844 in a condition to pass packets (i.e., it is not 'up') but is in a 845 "pending" state, waiting for some external event. For "on-demand" 846 interfaces, this new state identifies the situation where the interface 847 is waiting for events to place it in the up state. Examples of such 848 events might be: 850 (1) having packets to transmit before establishing a connection to a 851 remote system; 853 (2) having a remote system establish a connection to the interface 854 (e.g. dialing up to a slip-server). 856 The notPresent state is a refinement on the down state which indicates 857 that the relevant interface is down specifically because some component 858 (typically, a hardware component) is not present in the managed system. 859 Examples of use of the notPresent state are: 861 (1) to allow an interface's conceptual row including its counter 862 values to be retained across a "hot swap" of a card/module, 863 and/or 865 (2) to allow an interface's conceptual row to be created, and thereby 866 enable interfaces to be pre-configured prior to installation of 867 the hardware needed to make the interface operational. 869 Agents are not required to support interfaces in the notPresent state. 870 However, from a conceptual viewpoint, when a row in the ifTable is 871 created, it first enters the notPresent state and then subsequently 872 transitions into the down state; similarly, when a row in the ifTable is 873 deleted, it first enters the notPresent state and then subsequently the 874 object instances are deleted. For an agent with no support for 875 notPresent, both of these transitions (from the notPresent state to the 876 down state, and from the notPresent state to the instances being 877 removed) are immediate, i.e., the transition does not last long enough 878 to be recorded by ifOperStatus. Even for those agents which do support 879 interfaces in the notPresent state, the length of time and conditions 880 under which an interface stays in the notPresent state is 881 implementation-specific. 883 The lowerLayerDown state is also a refinement on the down state. This 884 new state indicates that this interface runs "on top of" one or more 885 other interfaces (see ifStackTable) and that this interface is down 886 specifically because one or more of these lower-layer interfaces are 887 down. 889 3.1.13. IfAdminStatus and IfOperStatus 891 The down state of ifOperStatus now has two meanings, depending on the 892 value of ifAdminStatus. 894 (1) if ifAdminStatus is not down and ifOperStatus is down then a 895 fault condition is presumed to exist on the interface. 897 (2) if ifAdminStatus is down, then ifOperStatus will normally also be 898 down (or notPresent) i.e., there is not (necessarily) a fault 899 condition on the interface. 901 Note that when ifAdminStatus transitions to down, ifOperStatus will 902 normally also transition to down. In this situation, it is possible 903 that ifOperStatus's transition will not occur immediately, but rather 904 after a small time lag to complete certain operations before going 905 "down"; for example, it might need to finish transmitting a packet. If 906 a manager station finds that ifAdminStatus is down and ifOperStatus is 907 not down for a particular interface, the manager station should wait a 908 short while and check again. If the condition still exists, only then 909 should it raise an error indication. Naturally, it should also ensure 910 that ifLastChange has not changed during this interval. 912 Whenever an interface table entry is created (usually as a result of 913 system initialization), the relevant instance of ifAdminStatus is set to 914 down, and ifOperStatus will be down or notPresent. 916 An interface may be enabled in two ways: either as a result of explicit 917 management action (e.g. setting ifAdminStatus to up) or as a result of 918 the managed system's initialization process. When ifAdminStatus changes 919 to the up state, the related ifOperStatus should do one of the 920 following: 922 (1) Change to the up state if and only if the interface is able to 923 send and receive packets. 925 (2) Change to the lowerLayerDown state if and only if the interface 926 is prevented from entering the up state because of the state of 927 one or more of the interfaces beneath it in the interface stack. 929 (3) Change to the dormant state if and only if the interface is found 930 to be operable, but the interface is waiting for other, external, 931 events to occur before it can transmit or receive packets. 932 Presumably when the expected events occur, the interface will 933 then change to the up state. 935 (4) Remain in the down state if an error or other fault condition is 936 detected on the interface. 938 (5) Change to the unknown state if, for some reason, the state of the 939 interface can not be ascertained. 941 (6) Change to the testing state if some test(s) must be performed on 942 the interface. Presumably after completion of the test, the 943 interface's state will change to up, dormant, or down, as 944 appropriate. 946 (7) Remain in the notPresent state if interface components are 947 missing. 949 3.1.14. IfOperStatus in an Interface Stack 951 When an interface is a part of an interface-stack, but is not the lowest 952 interface in the stack, then: 954 (1) ifOperStatus has the value 'up' if it is able to pass packets due 955 to one or more interfaces below it in the stack being 'up', 956 irrespective of whether other interfaces below it are 'down', 957 'dormant', 'notPresent', 'lowerLayerDown', 'unknown' or 958 'testing'. 960 (2) ifOperStatus may have the value 'up' or 'dormant' if one or more 961 interfaces below it in the stack are 'dormant', and all others 962 below it are either 'down', 'dormant', 'notPresent', 963 'lowerLayerDown', 'unknown' or 'testing'. 965 (3) ifOperStatus has the value 'lowerLayerDown' while all interfaces 966 below it in the stack are either 'down', 'notPresent', 967 'lowerLayerDown', or 'testing'. 969 3.1.15. Traps 971 The exact definition of when linkUp and linkDown traps are generated has 972 been changed to reflect the changes to ifAdminStatus and ifOperStatus. 974 Operational experience indicates that management stations are most 975 concerned with an interface being in the down state and the fact that 976 this state may indicate a failure. Thus, it is most useful to 977 instrument transitions into/out of either the up state or the down 978 state. 980 Instrumenting transitions into or out of the up state was rejected since 981 it would have the drawback that a demand interface might have many 982 transitions between up and dormant, leading to many linkUp traps and no 983 linkDown traps. Furthermore, if a node's only interface is the demand 984 interface, then a transition to dormant would entail generation of a 985 linkDown trap, necessitating bringing the link to the up state (and a 986 linkUp trap)!! 988 On the other hand, instrumenting transitions into or out of the down 989 state (to/from all other states except notPresent) has the advantages: 991 (1) A transition into the down state (from a state other than 992 notPresent) will occur when an error is detected on an interface. 993 Error conditions are presumably of great interest to network 994 managers. 996 (2) Departing the down state (to a state other than the notPresent 997 state) generally indicates that the interface is going to either 998 up or dormant, both of which are considered "healthy" states. 1000 Furthermore, it is believed that generating traps on transitions into or 1001 out of the down state (except to/from the notPresent state) is generally 1002 consistent with current usage and interpretation of these traps by 1003 manager stations. 1005 Transitions to/from the notPresent state are concerned with the 1006 insertion and removal of hardware, and are outside the scope of these 1007 traps. 1009 Therefore, this memo defines that LinkUp and linkDown traps are 1010 generated just after ifOperStatus leaves, or just before it enters, the 1011 down state, respectively; except that LinkUp and linkDown traps are 1012 never generated on transitions to/from the notPresent state. For the 1013 purpose of deciding when these traps occur, the lowerLayerDown state and 1014 the down state are considered to be equivalent, i.e., there is no trap 1015 on transition from lowerLayerDown into down, and there is a trap on 1016 transition from any other state except down (and notPresent) into 1017 lowerLayerDown. 1019 Note that this definition allows a node with only one interface to 1020 transmit a linkDown trap before that interface goes down. (Of course, 1021 when the interface is going down because of a failure condition, the 1022 linkDown trap probably cannot be successfully transmitted anyway.) 1024 Some interfaces perform a link "training" function when trying to bring 1025 the interface up. In the event that such an interface were defective, 1026 then the training function would fail and the interface would remain 1027 down, and the training function might be repeated at appropriate 1028 intervals. If the interface, while performing this training function, 1029 were considered to the in the testing state, then linkUp and linkDown 1030 traps would be generated for each start and end of the training 1031 function. This is not the intent of the linkUp and linkDown traps, and 1032 therefore, while performing such a training function, the interface's 1033 state should be represented as down. 1035 An exception to the above generation of linkUp/linkDown traps on changes 1036 in ifOperStatus, occurs when an interface is "flapping", i.e., when it 1037 is rapidly oscillating between the up and down states. If traps were 1038 generated for each such oscillation, the network and the network 1039 management system would be flooded with unnecessary traps. In such a 1040 situation, the agent should limit the rate at which it generates traps. 1042 3.1.16. ifSpecific 1044 The original definition of the OBJECT IDENTIFIER value of ifSpecific was 1045 not sufficiently clear. As a result, different implementors used it 1046 differently, and confusion resulted. Some implementations set the value 1047 of ifSpecific to the OBJECT IDENTIFIER that defines the media-specific 1048 MIB, i.e., the "foo" of: 1049 foo OBJECT IDENTIFIER ::= { transmission xxx } 1051 while others set it to be OBJECT IDENTIFIER of the specific table or 1052 entry in the appropriate media-specific MIB (i.e., fooTable or 1053 fooEntry), while still others set it be the OBJECT IDENTIFIER of the 1054 index object of the table's row, including instance identifier, (i.e., 1055 fooIfIndex.ifIndex). A definition based on the latter would not be 1056 sufficient unless it also allowed for media-specific MIBs which include 1057 several tables, where each table has its own (different) indexing. 1059 The only definition that can both be made explicit and can cover all the 1060 useful situations is to have ifSpecific be the most general value for 1061 the media-specific MIB module (the first example given above). This 1062 effectively makes it redundant because it contains no more information 1063 than is provided by ifType. Thus, ifSpecific has been deprecated. 1065 3.1.17. Creation/Deletion of Interfaces 1067 While some interfaces, for example, most physical interfaces, cannot be 1068 created via network management, other interfaces such as logical 1069 interfaces sometimes can be. The ifTable contains only generic 1070 information about an interface. Almost all 'create-able' interfaces 1071 have other, media-specific, information through which configuration 1072 parameters may be supplied prior to creating such an interface. Thus, 1073 the ifTable does not itself support the creation or deletion of an 1074 interface (specifically, it has no RowStatus [6] column). Rather, if a 1075 particular interface type supports the dynamic creation and/or deletion 1076 of an interface of that type, then that media-specific MIB should 1077 include an appropriate RowStatus object (see the ATM LAN-Emulation 1078 Client MIB [20] for an example of a MIB which does this). Typically, 1079 when such a RowStatus object is created/deleted, then the conceptual row 1080 in the ifTable appears/disappears as a by-product, and an ifIndex value 1081 (chosen by the agent) is stored in an appropriate object in the media- 1082 specific MIB. 1084 3.1.18. All Values Must be Known 1086 There are a number of situations where an agent does not know the value 1087 of one or more objects for a particular interface. In all such 1088 circumstances, an agent MUST NOT instantiate an object with an incorrect 1089 value; rather, it MUST respond with the appropriate error/exception 1090 condition (e.g., noSuchInstance for SNMPv2). 1092 One example is where an agent is unable to count the occurrences defined 1093 by one (or more) of the ifTable counters. In this circumstance, the 1094 agent MUST NOT instantiate the particular counter with a value of, say, 1095 zero. To do so would be to provide mis-information to a network 1096 management application reading the zero value, and thereby assuming that 1097 there have been no occurrences of the event (e.g., no input errors 1098 because ifInErrors is always zero). 1100 Sometimes the lack of knowledge of an object's value is temporary. For 1101 example, when the MTU of an interface is a configured value and a device 1102 dynamically learns the configured value through (after) exchanging 1103 messages over the interface (e.g., ATM LAN-Emulation [20]). In such a 1104 case, the value is not known until after the ifTable entry has already 1105 been created. In such a case, the ifTable entry should be created 1106 without an instance of the object whose value is unknown; later, when 1107 the value becomes known, the missing object can then be instantiated 1108 (e.g., the instance of ifMtu is only instantiated once the interface's 1109 MTU becomes known). 1111 As a result of this "known values" rule, management applications MUST be 1112 able to cope with the responses to retrieving the object instances 1113 within a conceptual row of the ifTable revealing that some of the row's 1114 columnar objects are missing/not available. 1116 4. Media-Specific MIB Applicability 1118 The exact use and semantics of many objects in this MIB are open to some 1119 interpretation. This is a result of the generic nature of this MIB. It 1120 is not always possible to come up with specific, unambiguous, text that 1121 covers all cases and yet preserves the generic nature of the MIB. 1123 Therefore, it is incumbent upon a media-specific MIB designer to, 1124 wherever necessary, clarify the use of the objects in this MIB with 1125 respect to the media-specific MIB. 1127 Specific areas of clarification include 1129 Layering Model 1130 The media-specific MIB designer MUST completely and unambiguously 1131 specify the layering model used. Each individual sub-layer must be 1132 identified, as must the ifStackTable's portrayal of the 1133 relationship(s) between the sub-layers. 1135 Virtual Circuits 1136 The media-specific MIB designer MUST specify whether virtual 1137 circuits are assigned entries in the ifTable or not. If they are, 1138 compelling rationale must be presented. 1140 ifRcvAddressTable 1141 The media-specific MIB designer MUST specify the applicability of 1142 the ifRcvAddressTable. 1144 ifType 1145 For each of the ifType values to which the media-specific MIB 1146 applies, it must specify the mapping of ifType values to media- 1147 specific MIB module(s) and instances of MIB objects within those 1148 modules. 1150 ifXxxOctets 1151 The definitions of ifInOctets and ifOutOctets (and similarly, 1152 ifHCInOctets and ifHCOutOctets) specify that their values include 1153 framing characters. The media-specific MIB designer MUST specify 1154 any special conditions of the media concerning the inclusion of 1155 framing characters, especially with respect to frames with errors. 1157 However, wherever this interface MIB is specific in the semantics, 1158 DESCRIPTION, or applicability of objects, the media-specific MIB 1159 designer MUST NOT change said semantics, DESCRIPTION, or applicability. 1161 5. Overview 1163 This MIB consists of 4 tables: 1165 ifTable 1166 This table is the ifTable from MIB-II. 1168 ifXTable 1169 This table contains objects that have been added to the Interface 1170 MIB as a result of the Interface Evolution effort, or replacements 1171 for objects of the original (MIB-II) ifTable that were deprecated 1172 because the semantics of said objects have significantly changed. 1173 This table also contains objects that were previously in the 1174 ifExtnsTable. 1176 ifStackTable 1177 This table contains objects that define the relationships among the 1178 sub-layers of an interface. 1180 ifRcvAddressTable 1181 This table contains objects that are used to define the media-level 1182 addresses which this interface will receive. This table is a 1183 generic table. The designers of media-specific MIBs must define 1184 exactly how this table applies to their specific MIB. 1186 6. Interfaces Group Definitions 1188 IF-MIB DEFINITIONS ::= BEGIN 1190 IMPORTS 1191 MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, 1192 Integer32, TimeTicks, mib-2, 1193 NOTIFICATION-TYPE FROM SNMPv2-SMI 1194 TEXTUAL-CONVENTION, DisplayString, 1195 PhysAddress, TruthValue, RowStatus, 1196 TimeStamp, AutonomousType, TestAndIncr FROM SNMPv2-TC 1197 MODULE-COMPLIANCE, OBJECT-GROUP, 1198 NOTIFICATION-GROUP FROM SNMPv2-CONF 1199 snmpTraps FROM SNMPv2-MIB 1200 IANAifType FROM IANAifType-MIB; 1202 ifMIB MODULE-IDENTITY 1203 LAST-UPDATED "9910110000Z" 1204 ORGANIZATION "IETF Interfaces MIB Working Group" 1205 CONTACT-INFO 1206 " Keith McCloghrie 1207 Cisco Systems, Inc. 1208 170 West Tasman Drive 1209 San Jose, CA 95134-1706 1210 US 1212 408-526-5260 1213 kzm@cisco.com" 1214 DESCRIPTION 1215 "The MIB module to describe generic objects for network 1216 interface sub-layers. This MIB is an updated version of 1217 MIB-II's ifTable, and incorporates the extensions defined in 1218 RFC 1229." 1219 REVISION "9910110000Z" 1220 DESCRIPTION -- xxxx to be filled in by RFC-EDITOR 1221 "Clarifications agreed upon by the Interfaces MIB WG, and 1222 published as RFC xxxx." 1223 REVISION "9602282155Z" 1224 DESCRIPTION 1225 "Revisions made by the Interfaces MIB WG, and published in 1226 RFC 2233." 1227 REVISION "9311082155Z" 1228 DESCRIPTION 1229 "Initial revision, published as part of RFC 1573." 1231 ::= { mib-2 31 } 1233 ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 } 1235 interfaces OBJECT IDENTIFIER ::= { mib-2 2 } 1237 -- 1238 -- Textual Conventions 1239 -- 1241 -- OwnerString has the same semantics as used in RFC 1271 1243 OwnerString ::= TEXTUAL-CONVENTION 1244 DISPLAY-HINT "255a" 1245 STATUS deprecated 1246 DESCRIPTION 1247 "This data type is used to model an administratively 1248 assigned name of the owner of a resource. This information 1249 is taken from the NVT ASCII character set. It is suggested 1250 that this name contain one or more of the following: ASCII 1251 form of the manager station's transport address, management 1252 station name (e.g., domain name), network management 1253 personnel's name, location, or phone number. In some cases 1254 the agent itself will be the owner of an entry. In these 1255 cases, this string shall be set to a string starting with 1256 'agent'." 1257 SYNTAX OCTET STRING (SIZE(0..255)) 1259 -- InterfaceIndex contains the semantics of ifIndex and should be used 1260 -- for any objects defined in other MIB modules that need these semantics. 1262 InterfaceIndex ::= TEXTUAL-CONVENTION 1263 DISPLAY-HINT "d" 1264 STATUS current 1265 DESCRIPTION 1266 "A unique value, greater than zero, for each interface or 1267 interface sub-layer in the managed system. It is 1268 recommended that values are assigned contiguously starting 1269 from 1. The value for each interface sub-layer must remain 1270 constant at least from one re-initialization of the entity's 1271 network management system to the next re-initialization." 1272 SYNTAX Integer32 (1..2147483647) 1274 InterfaceIndexOrZero ::= TEXTUAL-CONVENTION 1275 DISPLAY-HINT "d" 1276 STATUS current 1277 DESCRIPTION 1278 "This textual convention is an extension of the 1279 InterfaceIndex convention. The latter defines a greater 1280 than zero value used to identify an interface or interface 1281 sub-layer in the managed system. This extension permits the 1282 additional value of zero. the value zero is object-specific 1283 and must therefore be defined as part of the description of 1284 any object which uses this syntax. Examples of the usage of 1285 zero might include situations where interface was unknown, 1286 or when none or all interfaces need to be referenced." 1287 SYNTAX Integer32 (0..2147483647) 1289 ifNumber OBJECT-TYPE 1290 SYNTAX Integer32 1291 MAX-ACCESS read-only 1292 STATUS current 1293 DESCRIPTION 1294 "The number of network interfaces (regardless of their 1295 current state) present on this system." 1296 ::= { interfaces 1 } 1298 ifTableLastChange OBJECT-TYPE 1299 SYNTAX TimeTicks 1300 MAX-ACCESS read-only 1301 STATUS current 1302 DESCRIPTION 1303 "The value of sysUpTime at the time of the last creation or 1304 deletion of an entry in the ifTable. If the number of 1305 entries has been unchanged since the last re-initialization 1306 of the local network management subsystem, then this object 1307 contains a zero value." 1308 ::= { ifMIBObjects 5 } 1310 -- the Interfaces table 1312 -- The Interfaces table contains information on the entity's 1313 -- interfaces. Each sub-layer below the internetwork-layer 1314 -- of a network interface is considered to be an interface. 1316 ifTable OBJECT-TYPE 1317 SYNTAX SEQUENCE OF IfEntry 1318 MAX-ACCESS not-accessible 1319 STATUS current 1320 DESCRIPTION 1321 "A list of interface entries. The number of entries is 1322 given by the value of ifNumber." 1323 ::= { interfaces 2 } 1325 ifEntry OBJECT-TYPE 1326 SYNTAX IfEntry 1327 MAX-ACCESS not-accessible 1328 STATUS current 1329 DESCRIPTION 1330 "An entry containing management information applicable to a 1331 particular interface." 1332 INDEX { ifIndex } 1333 ::= { ifTable 1 } 1335 IfEntry ::= 1336 SEQUENCE { 1337 ifIndex InterfaceIndex, 1338 ifDescr DisplayString, 1339 ifType IANAifType, 1340 ifMtu Integer32, 1341 ifSpeed Gauge32, 1342 ifPhysAddress PhysAddress, 1343 ifAdminStatus INTEGER, 1344 ifOperStatus INTEGER, 1345 ifLastChange TimeTicks, 1346 ifInOctets Counter32, 1347 ifInUcastPkts Counter32, 1348 ifInNUcastPkts Counter32, -- deprecated 1349 ifInDiscards Counter32, 1350 ifInErrors Counter32, 1351 ifInUnknownProtos Counter32, 1352 ifOutOctets Counter32, 1353 ifOutUcastPkts Counter32, 1354 ifOutNUcastPkts Counter32, -- deprecated 1355 ifOutDiscards Counter32, 1356 ifOutErrors Counter32, 1357 ifOutQLen Gauge32, -- deprecated 1358 ifSpecific OBJECT IDENTIFIER -- deprecated 1359 } 1361 ifIndex OBJECT-TYPE 1362 SYNTAX InterfaceIndex 1363 MAX-ACCESS read-only 1364 STATUS current 1365 DESCRIPTION 1366 "A unique value, greater than zero, for each interface. It 1367 is recommended that values are assigned contiguously 1368 starting from 1. The value for each interface sub-layer 1369 must remain constant at least from one re-initialization of 1370 the entity's network management system to the next re- 1371 initialization." 1372 ::= { ifEntry 1 } 1374 ifDescr OBJECT-TYPE 1375 SYNTAX DisplayString (SIZE (0..255)) 1376 MAX-ACCESS read-only 1377 STATUS current 1378 DESCRIPTION 1379 "A textual string containing information about the 1380 interface. This string should include the name of the 1381 manufacturer, the product name and the version of the 1382 interface hardware/software." 1383 ::= { ifEntry 2 } 1385 ifType OBJECT-TYPE 1386 SYNTAX IANAifType 1387 MAX-ACCESS read-only 1388 STATUS current 1389 DESCRIPTION 1390 "The type of interface. Additional values for ifType are 1391 assigned by the Internet Assigned Numbers Authority (IANA), 1392 through updating the syntax of the IANAifType textual 1393 convention." 1394 ::= { ifEntry 3 } 1396 ifMtu OBJECT-TYPE 1397 SYNTAX Integer32 1398 MAX-ACCESS read-only 1399 STATUS current 1400 DESCRIPTION 1401 "The size of the largest packet which can be sent/received 1402 on the interface, specified in octets. For interfaces that 1403 are used for transmitting network datagrams, this is the 1404 size of the largest network datagram that can be sent on the 1405 interface." 1406 ::= { ifEntry 4 } 1408 ifSpeed OBJECT-TYPE 1409 SYNTAX Gauge32 1410 MAX-ACCESS read-only 1411 STATUS current 1412 DESCRIPTION 1413 "An estimate of the interface's current bandwidth in bits 1414 per second. For interfaces which do not vary in bandwidth 1415 or for those where no accurate estimation can be made, this 1416 object should contain the nominal bandwidth. If the 1417 bandwidth of the interface is greater than the maximum value 1418 reportable by this object then this object should report its 1419 maximum value (4,294,967,295) and ifHighSpeed must be used 1420 to report the interace's speed. For a sub-layer which has 1421 no concept of bandwidth, this object should be zero." 1423 ::= { ifEntry 5 } 1425 ifPhysAddress OBJECT-TYPE 1426 SYNTAX PhysAddress 1427 MAX-ACCESS read-only 1428 STATUS current 1429 DESCRIPTION 1430 "The interface's address at its protocol sub-layer. For 1431 example, for an 802.x interface, this object normally 1432 contains a MAC address. The interface's media-specific MIB 1433 must define the bit and byte ordering and the format of the 1434 value of this object. For interfaces which do not have such 1435 an address (e.g., a serial line), this object should contain 1436 an octet string of zero length." 1437 ::= { ifEntry 6 } 1439 ifAdminStatus OBJECT-TYPE 1440 SYNTAX INTEGER { 1441 up(1), -- ready to pass packets 1442 down(2), 1443 testing(3) -- in some test mode 1444 } 1445 MAX-ACCESS read-write 1446 STATUS current 1447 DESCRIPTION 1448 "The desired state of the interface. The testing(3) state 1449 indicates that no operational packets can be passed. When a 1450 managed system initializes, all interfaces start with 1451 ifAdminStatus in the down(2) state. As a result of either 1452 explicit management action or per configuration information 1453 retained by the managed system, ifAdminStatus is then 1454 changed to either the up(1) or testing(3) states (or remains 1455 in the down(2) state)." 1456 ::= { ifEntry 7 } 1458 ifOperStatus OBJECT-TYPE 1459 SYNTAX INTEGER { 1460 up(1), -- ready to pass packets 1461 down(2), 1462 testing(3), -- in some test mode 1463 unknown(4), -- status can not be determined 1464 -- for some reason. 1465 dormant(5), 1466 notPresent(6), -- some component is missing 1467 lowerLayerDown(7) -- down due to state of 1468 -- lower-layer interface(s) 1469 } 1470 MAX-ACCESS read-only 1471 STATUS current 1472 DESCRIPTION 1473 "The current operational state of the interface. The 1474 testing(3) state indicates that no operational packets can 1475 be passed. If ifAdminStatus is down(2) then ifOperStatus 1476 should be down(2). If ifAdminStatus is changed to up(1) 1477 then ifOperStatus should change to up(1) if the interface is 1478 ready to transmit and receive network traffic; it should 1479 change to dormant(5) if the interface is waiting for 1480 external actions (such as a serial line waiting for an 1481 incoming connection); it should remain in the down(2) state 1482 if and only if there is a fault that prevents it from going 1483 to the up(1) state; it should remain in the notPresent(6) 1484 state if the interface has missing (typically, hardware) 1485 components." 1486 ::= { ifEntry 8 } 1488 ifLastChange OBJECT-TYPE 1489 SYNTAX TimeTicks 1490 MAX-ACCESS read-only 1491 STATUS current 1492 DESCRIPTION 1493 "The value of sysUpTime at the time the interface entered 1494 its current operational state. If the current state was 1495 entered prior to the last re-initialization of the local 1496 network management subsystem, then this object contains a 1497 zero value." 1498 ::= { ifEntry 9 } 1500 ifInOctets OBJECT-TYPE 1501 SYNTAX Counter32 1502 MAX-ACCESS read-only 1503 STATUS current 1504 DESCRIPTION 1505 "The total number of octets received on the interface, 1506 including framing characters. 1508 Discontinuities in the value of this counter can occur at 1509 re-initialization of the management system, and at other 1510 times as indicated by the value of 1511 ifCounterDiscontinuityTime." 1512 ::= { ifEntry 10 } 1514 ifInUcastPkts OBJECT-TYPE 1515 SYNTAX Counter32 1516 MAX-ACCESS read-only 1517 STATUS current 1518 DESCRIPTION 1519 "The number of packets, delivered by this sub-layer to a 1520 higher (sub-)layer, which were not addressed to a multicast 1521 or broadcast address at this sub-layer. 1523 Discontinuities in the value of this counter can occur at 1524 re-initialization of the management system, and at other 1525 times as indicated by the value of 1526 ifCounterDiscontinuityTime." 1527 ::= { ifEntry 11 } 1529 ifInNUcastPkts OBJECT-TYPE 1530 SYNTAX Counter32 1531 MAX-ACCESS read-only 1532 STATUS deprecated 1533 DESCRIPTION 1534 "The number of packets, delivered by this sub-layer to a 1535 higher (sub-)layer, which were addressed to a multicast or 1536 broadcast address at this sub-layer. 1538 Discontinuities in the value of this counter can occur at 1539 re-initialization of the management system, and at other 1540 times as indicated by the value of 1541 ifCounterDiscontinuityTime. 1543 This object is deprecated in favour of ifInMulticastPkts and 1544 ifInBroadcastPkts." 1545 ::= { ifEntry 12 } 1547 ifInDiscards OBJECT-TYPE 1548 SYNTAX Counter32 1549 MAX-ACCESS read-only 1550 STATUS current 1551 DESCRIPTION 1552 "The number of inbound packets which were chosen to be 1553 discarded even though no errors had been detected to prevent 1554 their being deliverable to a higher-layer protocol. One 1555 possible reason for discarding such a packet could be to 1556 free up buffer space. 1558 Discontinuities in the value of this counter can occur at 1559 re-initialization of the management system, and at other 1560 times as indicated by the value of 1561 ifCounterDiscontinuityTime." 1562 ::= { ifEntry 13 } 1564 ifInErrors OBJECT-TYPE 1565 SYNTAX Counter32 1566 MAX-ACCESS read-only 1567 STATUS current 1568 DESCRIPTION 1569 "For packet-oriented interfaces, the number of inbound 1570 packets that contained errors preventing them from being 1571 deliverable to a higher-layer protocol. For character- 1572 oriented or fixed-length interfaces, the number of inbound 1573 transmission units that contained errors preventing them 1574 from being deliverable to a higher-layer protocol. 1576 Discontinuities in the value of this counter can occur at 1577 re-initialization of the management system, and at other 1578 times as indicated by the value of 1579 ifCounterDiscontinuityTime." 1580 ::= { ifEntry 14 } 1582 ifInUnknownProtos OBJECT-TYPE 1583 SYNTAX Counter32 1584 MAX-ACCESS read-only 1585 STATUS current 1586 DESCRIPTION 1587 "For packet-oriented interfaces, the number of packets 1588 received via the interface which were discarded because of 1589 an unknown or unsupported protocol. For character-oriented 1590 or fixed-length interfaces that support protocol 1591 multiplexing the number of transmission units received via 1592 the interface which were discarded because of an unknown or 1593 unsupported protocol. For any interface that does not 1594 support protocol multiplexing, this counter will always be 1595 0. 1597 Discontinuities in the value of this counter can occur at 1598 re-initialization of the management system, and at other 1599 times as indicated by the value of 1600 ifCounterDiscontinuityTime." 1601 ::= { ifEntry 15 } 1603 ifOutOctets OBJECT-TYPE 1604 SYNTAX Counter32 1605 MAX-ACCESS read-only 1606 STATUS current 1607 DESCRIPTION 1608 "The total number of octets transmitted out of the 1609 interface, including framing characters. 1611 Discontinuities in the value of this counter can occur at 1612 re-initialization of the management system, and at other 1613 times as indicated by the value of 1614 ifCounterDiscontinuityTime." 1615 ::= { ifEntry 16 } 1617 ifOutUcastPkts OBJECT-TYPE 1618 SYNTAX Counter32 1619 MAX-ACCESS read-only 1620 STATUS current 1621 DESCRIPTION 1622 "The total number of packets that higher-level protocols 1623 requested be transmitted, and which were not addressed to a 1624 multicast or broadcast address at this sub-layer, including 1625 those that were discarded or not sent. 1627 Discontinuities in the value of this counter can occur at 1628 re-initialization of the management system, and at other 1629 times as indicated by the value of 1630 ifCounterDiscontinuityTime." 1631 ::= { ifEntry 17 } 1633 ifOutNUcastPkts OBJECT-TYPE 1634 SYNTAX Counter32 1635 MAX-ACCESS read-only 1636 STATUS deprecated 1637 DESCRIPTION 1638 "The total number of packets that higher-level protocols 1639 requested be transmitted, and which were addressed to a 1640 multicast or broadcast address at this sub-layer, including 1641 those that were discarded or not sent. 1643 Discontinuities in the value of this counter can occur at 1644 re-initialization of the management system, and at other 1645 times as indicated by the value of 1646 ifCounterDiscontinuityTime. 1648 This object is deprecated in favour of ifOutMulticastPkts 1649 and ifOutBroadcastPkts." 1650 ::= { ifEntry 18 } 1652 ifOutDiscards OBJECT-TYPE 1653 SYNTAX Counter32 1654 MAX-ACCESS read-only 1655 STATUS current 1656 DESCRIPTION 1657 "The number of outbound packets which were chosen to be 1658 discarded even though no errors had been detected to prevent 1659 their being transmitted. One possible reason for discarding 1660 such a packet could be to free up buffer space. 1662 Discontinuities in the value of this counter can occur at 1663 re-initialization of the management system, and at other 1664 times as indicated by the value of 1665 ifCounterDiscontinuityTime." 1666 ::= { ifEntry 19 } 1668 ifOutErrors OBJECT-TYPE 1669 SYNTAX Counter32 1670 MAX-ACCESS read-only 1671 STATUS current 1672 DESCRIPTION 1673 "For packet-oriented interfaces, the number of outbound 1674 packets that could not be transmitted because of errors. 1675 For character-oriented or fixed-length interfaces, the 1676 number of outbound transmission units that could not be 1677 transmitted because of errors. 1679 Discontinuities in the value of this counter can occur at 1680 re-initialization of the management system, and at other 1681 times as indicated by the value of 1682 ifCounterDiscontinuityTime." 1683 ::= { ifEntry 20 } 1685 ifOutQLen OBJECT-TYPE 1686 SYNTAX Gauge32 1687 MAX-ACCESS read-only 1688 STATUS deprecated 1689 DESCRIPTION 1690 "The length of the output packet queue (in packets)." 1691 ::= { ifEntry 21 } 1693 ifSpecific OBJECT-TYPE 1694 SYNTAX OBJECT IDENTIFIER 1695 MAX-ACCESS read-only 1696 STATUS deprecated 1697 DESCRIPTION 1698 "A reference to MIB definitions specific to the particular 1699 media being used to realize the interface. It is 1700 recommended that this value point to an instance of a MIB 1701 object in the media-specific MIB, i.e., that this object 1702 have the semantics associated with the InstancePointer 1703 textual convention defined in RFC 2579. In fact, it is 1704 recommended that the media-specific MIB specify what value 1705 ifSpecific should/can take for values of ifType. If no MIB 1706 definitions specific to the particular media are available, 1707 the value should be set to the OBJECT IDENTIFIER { 0 0 }." 1708 ::= { ifEntry 22 } 1710 -- 1711 -- Extension to the interface table 1712 -- 1713 -- This table replaces the ifExtnsTable table. 1714 -- 1716 ifXTable OBJECT-TYPE 1717 SYNTAX SEQUENCE OF IfXEntry 1718 MAX-ACCESS not-accessible 1719 STATUS current 1720 DESCRIPTION 1721 "A list of interface entries. The number of entries is 1722 given by the value of ifNumber. This table contains 1723 additional objects for the interface table." 1724 ::= { ifMIBObjects 1 } 1726 ifXEntry OBJECT-TYPE 1727 SYNTAX IfXEntry 1728 MAX-ACCESS not-accessible 1729 STATUS current 1730 DESCRIPTION 1731 "An entry containing additional management information 1732 applicable to a particular interface." 1733 AUGMENTS { ifEntry } 1734 ::= { ifXTable 1 } 1736 IfXEntry ::= 1737 SEQUENCE { 1738 ifName DisplayString, 1739 ifInMulticastPkts Counter32, 1740 ifInBroadcastPkts Counter32, 1741 ifOutMulticastPkts Counter32, 1742 ifOutBroadcastPkts Counter32, 1743 ifHCInOctets Counter64, 1744 ifHCInUcastPkts Counter64, 1745 ifHCInMulticastPkts Counter64, 1746 ifHCInBroadcastPkts Counter64, 1747 ifHCOutOctets Counter64, 1748 ifHCOutUcastPkts Counter64, 1749 ifHCOutMulticastPkts Counter64, 1750 ifHCOutBroadcastPkts Counter64, 1751 ifLinkUpDownTrapEnable INTEGER, 1752 ifHighSpeed Gauge32, 1753 ifPromiscuousMode TruthValue, 1754 ifConnectorPresent TruthValue, 1755 ifAlias DisplayString, 1756 ifCounterDiscontinuityTime TimeStamp 1757 } 1759 ifName OBJECT-TYPE 1760 SYNTAX DisplayString 1761 MAX-ACCESS read-only 1762 STATUS current 1763 DESCRIPTION 1764 "The textual name of the interface. The value of this 1765 object should be the name of the interface as assigned by 1766 the local device and should be suitable for use in commands 1767 entered at the device's `console'. This might be a text 1768 name, such as `le0' or a simple port number, such as `1', 1769 depending on the interface naming syntax of the device. If 1770 several entries in the ifTable together represent a single 1771 interface as named by the device, then each will have the 1772 same value of ifName. Note that for an agent which responds 1773 to SNMP queries concerning an interface on some other 1774 (proxied) device, then the value of ifName for such an 1775 interface is the proxied device's local name for it. 1777 If there is no local name, or this object is otherwise not 1778 applicable, then this object contains a zero-length string." 1779 ::= { ifXEntry 1 } 1781 ifInMulticastPkts OBJECT-TYPE 1782 SYNTAX Counter32 1783 MAX-ACCESS read-only 1784 STATUS current 1785 DESCRIPTION 1786 "The number of packets, delivered by this sub-layer to a 1787 higher (sub-)layer, which were addressed to a multicast 1788 address at this sub-layer. For a MAC layer protocol, this 1789 includes both Group and Functional addresses. 1791 Discontinuities in the value of this counter can occur at 1792 re-initialization of the management system, and at other 1793 times as indicated by the value of 1794 ifCounterDiscontinuityTime." 1795 ::= { ifXEntry 2 } 1797 ifInBroadcastPkts OBJECT-TYPE 1798 SYNTAX Counter32 1799 MAX-ACCESS read-only 1800 STATUS current 1801 DESCRIPTION 1802 "The number of packets, delivered by this sub-layer to a 1803 higher (sub-)layer, which were addressed to a broadcast 1804 address at this sub-layer. 1806 Discontinuities in the value of this counter can occur at 1807 re-initialization of the management system, and at other 1808 times as indicated by the value of 1809 ifCounterDiscontinuityTime." 1810 ::= { ifXEntry 3 } 1812 ifOutMulticastPkts OBJECT-TYPE 1813 SYNTAX Counter32 1814 MAX-ACCESS read-only 1815 STATUS current 1816 DESCRIPTION 1817 "The total number of packets that higher-level protocols 1818 requested be transmitted, and which were addressed to a 1819 multicast address at this sub-layer, including those that 1820 were discarded or not sent. For a MAC layer protocol, this 1821 includes both Group and Functional addresses. 1823 Discontinuities in the value of this counter can occur at 1824 re-initialization of the management system, and at other 1825 times as indicated by the value of 1826 ifCounterDiscontinuityTime." 1827 ::= { ifXEntry 4 } 1829 ifOutBroadcastPkts OBJECT-TYPE 1830 SYNTAX Counter32 1831 MAX-ACCESS read-only 1832 STATUS current 1833 DESCRIPTION 1834 "The total number of packets that higher-level protocols 1835 requested be transmitted, and which were addressed to a 1836 broadcast address at this sub-layer, including those that 1837 were discarded or not sent. 1839 Discontinuities in the value of this counter can occur at 1840 re-initialization of the management system, and at other 1841 times as indicated by the value of 1842 ifCounterDiscontinuityTime." 1843 ::= { ifXEntry 5 } 1845 -- 1846 -- High Capacity Counter objects. These objects are all 1847 -- 64 bit versions of the "basic" ifTable counters. These 1848 -- objects all have the same basic semantics as their 32-bit 1849 -- counterparts, however, their syntax has been extended 1850 -- to 64 bits. 1851 -- 1853 ifHCInOctets OBJECT-TYPE 1854 SYNTAX Counter64 1855 MAX-ACCESS read-only 1856 STATUS current 1857 DESCRIPTION 1858 "The total number of octets received on the interface, 1859 including framing characters. This object is a 64-bit 1860 version of ifInOctets. 1862 Discontinuities in the value of this counter can occur at 1863 re-initialization of the management system, and at other 1864 times as indicated by the value of 1865 ifCounterDiscontinuityTime." 1866 ::= { ifXEntry 6 } 1868 ifHCInUcastPkts OBJECT-TYPE 1869 SYNTAX Counter64 1870 MAX-ACCESS read-only 1871 STATUS current 1872 DESCRIPTION 1873 "The number of packets, delivered by this sub-layer to a 1874 higher (sub-)layer, which were not addressed to a multicast 1875 or broadcast address at this sub-layer. This object is a 1876 64-bit version of ifInUcastPkts. 1878 Discontinuities in the value of this counter can occur at 1879 re-initialization of the management system, and at other 1880 times as indicated by the value of 1881 ifCounterDiscontinuityTime." 1882 ::= { ifXEntry 7 } 1884 ifHCInMulticastPkts OBJECT-TYPE 1885 SYNTAX Counter64 1886 MAX-ACCESS read-only 1887 STATUS current 1888 DESCRIPTION 1889 "The number of packets, delivered by this sub-layer to a 1890 higher (sub-)layer, which were addressed to a multicast 1891 address at this sub-layer. For a MAC layer protocol, this 1892 includes both Group and Functional addresses. This object 1893 is a 64-bit version of ifInMulticastPkts. 1895 Discontinuities in the value of this counter can occur at 1896 re-initialization of the management system, and at other 1897 times as indicated by the value of 1898 ifCounterDiscontinuityTime." 1899 ::= { ifXEntry 8 } 1901 ifHCInBroadcastPkts OBJECT-TYPE 1902 SYNTAX Counter64 1903 MAX-ACCESS read-only 1904 STATUS current 1905 DESCRIPTION 1906 "The number of packets, delivered by this sub-layer to a 1907 higher (sub-)layer, which were addressed to a broadcast 1908 address at this sub-layer. This object is a 64-bit version 1909 of ifInBroadcastPkts. 1911 Discontinuities in the value of this counter can occur at 1912 re-initialization of the management system, and at other 1913 times as indicated by the value of 1914 ifCounterDiscontinuityTime." 1915 ::= { ifXEntry 9 } 1917 ifHCOutOctets OBJECT-TYPE 1918 SYNTAX Counter64 1919 MAX-ACCESS read-only 1920 STATUS current 1921 DESCRIPTION 1922 "The total number of octets transmitted out of the 1923 interface, including framing characters. This object is a 1924 64-bit version of ifOutOctets. 1926 Discontinuities in the value of this counter can occur at 1927 re-initialization of the management system, and at other 1928 times as indicated by the value of 1929 ifCounterDiscontinuityTime." 1930 ::= { ifXEntry 10 } 1932 ifHCOutUcastPkts OBJECT-TYPE 1933 SYNTAX Counter64 1934 MAX-ACCESS read-only 1935 STATUS current 1936 DESCRIPTION 1937 "The total number of packets that higher-level protocols 1938 requested be transmitted, and which were not addressed to a 1939 multicast or broadcast address at this sub-layer, including 1940 those that were discarded or not sent. This object is a 1941 64-bit version of ifOutUcastPkts. 1943 Discontinuities in the value of this counter can occur at 1944 re-initialization of the management system, and at other 1945 times as indicated by the value of 1946 ifCounterDiscontinuityTime." 1947 ::= { ifXEntry 11 } 1949 ifHCOutMulticastPkts OBJECT-TYPE 1950 SYNTAX Counter64 1951 MAX-ACCESS read-only 1952 STATUS current 1953 DESCRIPTION 1954 "The total number of packets that higher-level protocols 1955 requested be transmitted, and which were addressed to a 1956 multicast address at this sub-layer, including those that 1957 were discarded or not sent. For a MAC layer protocol, this 1958 includes both Group and Functional addresses. This object 1959 is a 64-bit version of ifOutMulticastPkts. 1961 Discontinuities in the value of this counter can occur at 1962 re-initialization of the management system, and at other 1963 times as indicated by the value of 1964 ifCounterDiscontinuityTime." 1965 ::= { ifXEntry 12 } 1967 ifHCOutBroadcastPkts OBJECT-TYPE 1968 SYNTAX Counter64 1969 MAX-ACCESS read-only 1970 STATUS current 1971 DESCRIPTION 1972 "The total number of packets that higher-level protocols 1973 requested be transmitted, and which were addressed to a 1974 broadcast address at this sub-layer, including those that 1975 were discarded or not sent. This object is a 64-bit version 1976 of ifOutBroadcastPkts. 1978 Discontinuities in the value of this counter can occur at 1979 re-initialization of the management system, and at other 1980 times as indicated by the value of 1981 ifCounterDiscontinuityTime." 1982 ::= { ifXEntry 13 } 1984 ifLinkUpDownTrapEnable OBJECT-TYPE 1985 SYNTAX INTEGER { enabled(1), disabled(2) } 1986 MAX-ACCESS read-write 1987 STATUS current 1988 DESCRIPTION 1989 "Indicates whether linkUp/linkDown traps should be generated 1990 for this interface. 1992 By default, this object should have the value enabled(1) for 1993 interfaces which do not operate on 'top' of any other 1994 interface (as defined in the ifStackTable), and disabled(2) 1995 otherwise." 1996 ::= { ifXEntry 14 } 1998 ifHighSpeed OBJECT-TYPE 1999 SYNTAX Gauge32 2000 MAX-ACCESS read-only 2001 STATUS current 2002 DESCRIPTION 2003 "An estimate of the interface's current bandwidth in units 2004 of 1,000,000 bits per second. If this object reports a 2005 value of `n' then the speed of the interface is somewhere in 2006 the range of `n-500,000' to `n+499,999'. For interfaces 2007 which do not vary in bandwidth or for those where no 2008 accurate estimation can be made, this object should contain 2009 the nominal bandwidth. For a sub-layer which has no concept 2010 of bandwidth, this object should be zero." 2011 ::= { ifXEntry 15 } 2013 ifPromiscuousMode OBJECT-TYPE 2014 SYNTAX TruthValue 2015 MAX-ACCESS read-write 2016 STATUS current 2017 DESCRIPTION 2018 "This object has a value of false(2) if this interface only 2019 accepts packets/frames that are addressed to this station. 2020 This object has a value of true(1) when the station accepts 2021 all packets/frames transmitted on the media. The value 2022 true(1) is only legal on certain types of media. If legal, 2023 setting this object to a value of true(1) may require the 2024 interface to be reset before becoming effective. 2026 The value of ifPromiscuousMode does not affect the reception 2027 of broadcast and multicast packets/frames by the interface." 2028 ::= { ifXEntry 16 } 2030 ifConnectorPresent OBJECT-TYPE 2031 SYNTAX TruthValue 2032 MAX-ACCESS read-only 2033 STATUS current 2034 DESCRIPTION 2035 "This object has the value 'true(1)' if the interface 2036 sublayer has a physical connector and the value 'false(2)' 2037 otherwise." 2038 ::= { ifXEntry 17 } 2040 ifAlias OBJECT-TYPE 2041 SYNTAX DisplayString (SIZE(0..64)) 2042 MAX-ACCESS read-write 2043 STATUS current 2044 DESCRIPTION 2045 "This object is an 'alias' name for the interface as 2046 specified by a network manager, and provides a non-volatile 2047 'handle' for the interface. 2049 On the first instantiation of an interface, the value of 2050 ifAlias associated with that interface is the zero-length 2051 string. As and when a value is written into an instance of 2052 ifAlias through a network management set operation, then the 2053 agent must retain the supplied value in the ifAlias instance 2054 associated with the same interface for as long as that 2055 interface remains instantiated, including across all re- 2056 initializations/reboots of the network management system, 2057 including those which result in a change of the interface's 2058 ifIndex value. 2060 An example of the value which a network manager might store 2061 in this object for a WAN interface is the (Telco's) circuit 2062 number/identifier of the interface. 2064 Some agents may support write-access only for interfaces 2065 having particular values of ifType. An agent which supports 2066 write access to this object is required to keep the value in 2067 non-volatile storage, but it may limit the length of new 2068 values depending on how much storage is already occupied by 2069 the current values for other interfaces." 2070 ::= { ifXEntry 18 } 2072 ifCounterDiscontinuityTime OBJECT-TYPE 2073 SYNTAX TimeStamp 2074 MAX-ACCESS read-only 2075 STATUS current 2076 DESCRIPTION 2077 "The value of sysUpTime on the most recent occasion at which 2078 any one or more of this interface's counters suffered a 2079 discontinuity. The relevant counters are the specific 2080 instances associated with this interface of any Counter32 or 2081 Counter64 object contained in the ifTable or ifXTable. If 2082 no such discontinuities have occurred since the last re- 2083 initialization of the local management subsystem, then this 2084 object contains a zero value." 2085 ::= { ifXEntry 19 } 2087 -- The Interface Stack Group 2088 -- 2089 -- Implementation of this group is optional, but strongly recommended 2090 -- for all systems 2091 -- 2093 ifStackTable OBJECT-TYPE 2094 SYNTAX SEQUENCE OF IfStackEntry 2095 MAX-ACCESS not-accessible 2096 STATUS current 2097 DESCRIPTION 2098 "The table containing information on the relationships 2099 between the multiple sub-layers of network interfaces. In 2100 particular, it contains information on which sub-layers run 2101 'on top of' which other sub-layers, where each sub-layer 2102 corresponds to a conceptual row in the ifTable. For 2103 example, when the sub-layer with ifIndex value x runs over 2104 the sub-layer with ifIndex value y, then this table 2105 contains: 2107 ifStackStatus.x.y=active 2109 For each ifIndex value, I, which identifies an active 2110 interface, there are always at least two instantiated rows 2111 in this table associated with I. For one of these rows, I 2112 is the value of ifStackHigherLayer; for the other, I is the 2113 value of ifStackLowerLayer. (If I is not involved in 2114 multiplexing, then these are the only two rows associated 2115 with I.) 2117 For example, two rows exist even for an interface which has 2118 no others stacked on top or below it: 2120 ifStackStatus.0.x=active 2121 ifStackStatus.x.0=active " 2122 ::= { ifMIBObjects 2 } 2124 ifStackEntry OBJECT-TYPE 2125 SYNTAX IfStackEntry 2126 MAX-ACCESS not-accessible 2127 STATUS current 2128 DESCRIPTION 2129 "Information on a particular relationship between two sub- 2130 layers, specifying that one sub-layer runs on 'top' of the 2131 other sub-layer. Each sub-layer corresponds to a conceptual 2132 row in the ifTable." 2133 INDEX { ifStackHigherLayer, ifStackLowerLayer } 2134 ::= { ifStackTable 1 } 2136 IfStackEntry ::= 2137 SEQUENCE { 2138 ifStackHigherLayer InterfaceIndexOrZero, 2139 ifStackLowerLayer InterfaceIndexOrZero, 2140 ifStackStatus RowStatus 2141 } 2143 ifStackHigherLayer OBJECT-TYPE 2144 SYNTAX InterfaceIndexOrZero 2145 MAX-ACCESS not-accessible 2146 STATUS current 2147 DESCRIPTION 2148 "The value of ifIndex corresponding to the higher sub-layer 2149 of the relationship, i.e., the sub-layer which runs on 'top' 2150 of the sub-layer identified by the corresponding instance of 2151 ifStackLowerLayer. If there is no higher sub-layer (below 2152 the internetwork layer), then this object has the value 0." 2153 ::= { ifStackEntry 1 } 2155 ifStackLowerLayer OBJECT-TYPE 2156 SYNTAX InterfaceIndexOrZero 2157 MAX-ACCESS not-accessible 2158 STATUS current 2159 DESCRIPTION 2160 "The value of ifIndex corresponding to the lower sub-layer 2161 of the relationship, i.e., the sub-layer which runs 'below' 2162 the sub-layer identified by the corresponding instance of 2163 ifStackHigherLayer. If there is no lower sub-layer, then 2164 this object has the value 0." 2165 ::= { ifStackEntry 2 } 2167 ifStackStatus OBJECT-TYPE 2168 SYNTAX RowStatus 2169 MAX-ACCESS read-create 2170 STATUS current 2171 DESCRIPTION 2172 "The status of the relationship between two sub-layers. 2174 Changing the value of this object from 'active' to 2175 'notInService' or 'destroy' will likely have consequences up 2176 and down the interface stack. Thus, write access to this 2177 object is likely to be inappropriate for some types of 2178 interfaces, and many implementations will choose not to 2179 support write-access for any type of interface." 2180 ::= { ifStackEntry 3 } 2182 ifStackLastChange OBJECT-TYPE 2183 SYNTAX TimeTicks 2184 MAX-ACCESS read-only 2185 STATUS current 2186 DESCRIPTION 2187 "The value of sysUpTime at the time of the last change of 2188 the (whole) interface stack. A change of the interface 2189 stack is defined to be any creation, deletion, or change in 2190 value of any instance of ifStackStatus. If the interface 2191 stack has been unchanged since the last re-initialization of 2192 the local network management subsystem, then this object 2193 contains a zero value." 2194 ::= { ifMIBObjects 6 } 2196 -- Generic Receive Address Table 2197 -- 2198 -- This group of objects is mandatory for all types of 2199 -- interfaces which can receive packets/frames addressed to 2200 -- more than one address. 2201 -- 2202 -- This table replaces the ifExtnsRcvAddr table. The main 2203 -- difference is that this table makes use of the RowStatus 2204 -- textual convention, while ifExtnsRcvAddr did not. 2206 ifRcvAddressTable OBJECT-TYPE 2207 SYNTAX SEQUENCE OF IfRcvAddressEntry 2208 MAX-ACCESS not-accessible 2209 STATUS current 2210 DESCRIPTION 2211 "This table contains an entry for each address (broadcast, 2212 multicast, or uni-cast) for which the system will receive 2213 packets/frames on a particular interface, except as follows: 2215 - for an interface operating in promiscuous mode, entries 2216 are only required for those addresses for which the system 2217 would receive frames were it not operating in promiscuous 2218 mode. 2220 - for 802.5 functional addresses, only one entry is 2221 required, for the address which has the functional address 2222 bit ANDed with the bit mask of all functional addresses for 2223 which the interface will accept frames. 2225 A system is normally able to use any unicast address which 2226 corresponds to an entry in this table as a source address." 2227 ::= { ifMIBObjects 4 } 2229 ifRcvAddressEntry OBJECT-TYPE 2230 SYNTAX IfRcvAddressEntry 2231 MAX-ACCESS not-accessible 2232 STATUS current 2233 DESCRIPTION 2234 "A list of objects identifying an address for which the 2235 system will accept packets/frames on the particular 2236 interface identified by the index value ifIndex." 2237 INDEX { ifIndex, ifRcvAddressAddress } 2238 ::= { ifRcvAddressTable 1 } 2240 IfRcvAddressEntry ::= 2241 SEQUENCE { 2242 ifRcvAddressAddress PhysAddress, 2243 ifRcvAddressStatus RowStatus, 2244 ifRcvAddressType INTEGER 2245 } 2247 ifRcvAddressAddress OBJECT-TYPE 2248 SYNTAX PhysAddress 2249 MAX-ACCESS not-accessible 2250 STATUS current 2251 DESCRIPTION 2252 "An address for which the system will accept packets/frames 2253 on this entry's interface." 2254 ::= { ifRcvAddressEntry 1 } 2256 ifRcvAddressStatus OBJECT-TYPE 2257 SYNTAX RowStatus 2258 MAX-ACCESS read-create 2259 STATUS current 2260 DESCRIPTION 2261 "This object is used to create and delete rows in the 2262 ifRcvAddressTable." 2264 ::= { ifRcvAddressEntry 2 } 2266 ifRcvAddressType OBJECT-TYPE 2267 SYNTAX INTEGER { 2268 other(1), 2269 volatile(2), 2270 nonVolatile(3) 2271 } 2273 MAX-ACCESS read-create 2274 STATUS current 2275 DESCRIPTION 2276 "This object has the value nonVolatile(3) for those entries 2277 in the table which are valid and will not be deleted by the 2278 next restart of the managed system. Entries having the 2279 value volatile(2) are valid and exist, but have not been 2280 saved, so that will not exist after the next restart of the 2281 managed system. Entries having the value other(1) are valid 2282 and exist but are not classified as to whether they will 2283 continue to exist after the next restart." 2285 DEFVAL { volatile } 2286 ::= { ifRcvAddressEntry 3 } 2288 -- definition of interface-related traps. 2290 linkDown NOTIFICATION-TYPE 2291 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2292 STATUS current 2293 DESCRIPTION 2294 "A linkDown trap signifies that the SNMP entity, acting in 2295 an agent role, has detected that the ifOperStatus object for 2296 one of its communication links is about to enter the down 2297 state from some other state (but not from the notPresent 2298 state). This other state is indicated by the included value 2299 of ifOperStatus." 2300 ::= { snmpTraps 3 } 2302 linkUp NOTIFICATION-TYPE 2303 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2304 STATUS current 2305 DESCRIPTION 2306 "A linkUp trap signifies that the SNMP entity, acting in an 2307 agent role, has detected that the ifOperStatus object for 2308 one of its communication links left the down state and 2309 transitioned into some other state (but not into the 2310 notPresent state). This other state is indicated by the 2311 included value of ifOperStatus." 2312 ::= { snmpTraps 4 } 2314 -- conformance information 2316 ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 } 2318 ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 } 2319 ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 } 2321 -- compliance statements 2323 ifCompliance3 MODULE-COMPLIANCE 2324 STATUS current 2325 DESCRIPTION 2326 "The compliance statement for SNMP entities which have 2327 network interfaces." 2329 MODULE -- this module 2330 MANDATORY-GROUPS { ifGeneralInformationGroup, 2331 linkUpDownNotificationsGroup } 2333 -- The groups: 2334 -- ifFixedLengthGroup 2335 -- ifHCFixedLengthGroup 2336 -- ifPacketGroup 2337 -- ifHCPacketGroup 2338 -- ifVHCPacketGroup 2339 -- are mutually exclusive; at most one of these groups is implemented 2340 -- for a particular interface. When any of these groups is implemented 2341 -- for a particular interface, then ifCounterDiscontinuityGroup must 2342 -- also be implemented for that interface. 2344 GROUP ifFixedLengthGroup 2345 DESCRIPTION 2346 "This group is mandatory for those network interfaces which 2347 are character-oriented or transmit data in fixed-length 2348 transmission units, and for which the value of the 2349 corresponding instance of ifSpeed is less than or equal to 2350 20,000,000 bits/second." 2352 GROUP ifHCFixedLengthGroup 2353 DESCRIPTION 2354 "This group is mandatory for those network interfaces which 2355 are character-oriented or transmit data in fixed-length 2356 transmission units, and for which the value of the 2357 corresponding instance of ifSpeed is greater than 20,000,000 2358 bits/second." 2360 GROUP ifPacketGroup 2361 DESCRIPTION 2362 "This group is mandatory for those network interfaces which 2363 are packet-oriented, and for which the value of the 2364 corresponding instance of ifSpeed is less than or equal to 2365 20,000,000 bits/second." 2367 GROUP ifHCPacketGroup 2368 DESCRIPTION 2369 "This group is mandatory only for those network interfaces 2370 which are packet-oriented and for which the value of the 2371 corresponding instance of ifSpeed is greater than 20,000,000 2372 bits/second but less than or equal to 650,000,000 2373 bits/second." 2375 GROUP ifVHCPacketGroup 2376 DESCRIPTION 2377 "This group is mandatory only for those network interfaces 2378 which are packet-oriented and for which the value of the 2379 corresponding instance of ifSpeed is greater than 2380 650,000,000 bits/second." 2382 GROUP ifCounterDiscontinuityGroup 2383 DESCRIPTION 2384 "This group is mandatory for those network interfaces that 2385 are required to maintain counters (i.e., those for which one 2386 of the ifFixedLengthGroup, ifHCFixedLengthGroup, 2387 ifPacketGroup, ifHCPacketGroup, or ifVHCPacketGroup is 2388 mandatory)." 2390 GROUP ifRcvAddressGroup 2391 DESCRIPTION 2392 "The applicability of this group MUST be defined by the 2393 media-specific MIBs. Media-specific MIBs must define the 2394 exact meaning, use, and semantics of the addresses in this 2395 group." 2397 OBJECT ifLinkUpDownTrapEnable 2398 MIN-ACCESS read-only 2399 DESCRIPTION 2400 "Write access is not required." 2402 OBJECT ifPromiscuousMode 2403 MIN-ACCESS read-only 2404 DESCRIPTION 2405 "Write access is not required." 2407 OBJECT ifAdminStatus 2408 SYNTAX INTEGER { up(1), down(2) } 2409 MIN-ACCESS read-only 2410 DESCRIPTION 2411 "Write access is not required, nor is support for the value 2412 testing(3)." 2414 OBJECT ifAlias 2415 MIN-ACCESS read-only 2416 DESCRIPTION 2417 "Write access is not required." 2419 ::= { ifCompliances 3 } 2421 -- units of conformance 2423 ifGeneralInformationGroup OBJECT-GROUP 2424 OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress, 2425 ifAdminStatus, ifOperStatus, ifLastChange, 2426 ifLinkUpDownTrapEnable, ifConnectorPresent, 2427 ifHighSpeed, ifName, ifNumber, ifAlias, 2428 ifTableLastChange } 2429 STATUS current 2430 DESCRIPTION 2431 "A collection of objects providing information applicable to 2432 all network interfaces." 2433 ::= { ifGroups 10 } 2435 -- the following five groups are mutually exclusive; at most 2436 -- one of these groups is implemented for any interface 2438 ifFixedLengthGroup OBJECT-GROUP 2439 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2440 ifInErrors, ifOutErrors } 2441 STATUS current 2442 DESCRIPTION 2443 "A collection of objects providing information specific to 2444 non-high speed (non-high speed interfaces transmit and 2445 receive at speeds less than or equal to 20,000,000 2446 bits/second) character-oriented or fixed-length-transmission 2447 network interfaces." 2448 ::= { ifGroups 2 } 2450 ifHCFixedLengthGroup OBJECT-GROUP 2451 OBJECTS { ifHCInOctets, ifHCOutOctets, 2452 ifInOctets, ifOutOctets, ifInUnknownProtos, 2453 ifInErrors, ifOutErrors } 2454 STATUS current 2455 DESCRIPTION 2456 "A collection of objects providing information specific to 2457 high speed (greater than 20,000,000 bits/second) character- 2458 oriented or fixed-length-transmission network interfaces." 2459 ::= { ifGroups 3 } 2461 ifPacketGroup OBJECT-GROUP 2462 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2463 ifInErrors, ifOutErrors, 2464 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2465 ifInBroadcastPkts, ifInDiscards, 2466 ifOutUcastPkts, ifOutMulticastPkts, 2467 ifOutBroadcastPkts, ifOutDiscards, 2468 ifPromiscuousMode } 2469 STATUS current 2470 DESCRIPTION 2471 "A collection of objects providing information specific to 2472 non-high speed (non-high speed interfaces transmit and 2473 receive at speeds less than or equal to 20,000,000 2474 bits/second) packet-oriented network interfaces." 2475 ::= { ifGroups 4 } 2477 ifHCPacketGroup OBJECT-GROUP 2478 OBJECTS { ifHCInOctets, ifHCOutOctets, 2479 ifInOctets, ifOutOctets, ifInUnknownProtos, 2480 ifInErrors, ifOutErrors, 2481 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2482 ifInBroadcastPkts, ifInDiscards, 2483 ifOutUcastPkts, ifOutMulticastPkts, 2484 ifOutBroadcastPkts, ifOutDiscards, 2485 ifPromiscuousMode } 2486 STATUS current 2487 DESCRIPTION 2488 "A collection of objects providing information specific to 2489 high speed (greater than 20,000,000 bits/second but less 2490 than or equal to 650,000,000 bits/second) packet-oriented 2491 network interfaces." 2492 ::= { ifGroups 5 } 2494 ifVHCPacketGroup OBJECT-GROUP 2495 OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, 2496 ifHCInBroadcastPkts, ifHCOutUcastPkts, 2497 ifHCOutMulticastPkts, ifHCOutBroadcastPkts, 2498 ifHCInOctets, ifHCOutOctets, 2499 ifInOctets, ifOutOctets, ifInUnknownProtos, 2500 ifInErrors, ifOutErrors, 2501 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2502 ifInBroadcastPkts, ifInDiscards, 2503 ifOutUcastPkts, ifOutMulticastPkts, 2504 ifOutBroadcastPkts, ifOutDiscards, 2505 ifPromiscuousMode } 2506 STATUS current 2507 DESCRIPTION 2508 "A collection of objects providing information specific to 2509 higher speed (greater than 650,000,000 bits/second) packet- 2510 oriented network interfaces." 2512 ::= { ifGroups 6 } 2514 ifRcvAddressGroup OBJECT-GROUP 2515 OBJECTS { ifRcvAddressStatus, ifRcvAddressType } 2516 STATUS current 2517 DESCRIPTION 2518 "A collection of objects providing information on the 2519 multiple addresses which an interface receives." 2520 ::= { ifGroups 7 } 2522 ifStackGroup2 OBJECT-GROUP 2523 OBJECTS { ifStackStatus, ifStackLastChange } 2524 STATUS current 2525 DESCRIPTION 2526 "A collection of objects providing information on the 2527 layering of MIB-II interfaces." 2528 ::= { ifGroups 11 } 2530 ifCounterDiscontinuityGroup OBJECT-GROUP 2531 OBJECTS { ifCounterDiscontinuityTime } 2532 STATUS current 2533 DESCRIPTION 2534 "A collection of objects providing information specific to 2535 interface counter discontinuities." 2536 ::= { ifGroups 13 } 2538 linkUpDownNotificationsGroup NOTIFICATION-GROUP 2539 NOTIFICATIONS { linkUp, linkDown } 2540 STATUS current 2541 DESCRIPTION 2542 "The notifications which indicate specific changes in the 2543 value of ifOperStatus." 2544 ::= { ifGroups 14 } 2546 -- Deprecated Definitions - Objects 2548 -- 2549 -- The Interface Test Table 2550 -- 2551 -- This group of objects is optional. However, a media-specific 2552 -- MIB may make implementation of this group mandatory. 2553 -- 2554 -- This table replaces the ifExtnsTestTable 2555 -- 2557 ifTestTable OBJECT-TYPE 2558 SYNTAX SEQUENCE OF IfTestEntry 2559 MAX-ACCESS not-accessible 2560 STATUS deprecated 2561 DESCRIPTION 2562 "This table contains one entry per interface. It defines 2563 objects which allow a network manager to instruct an agent 2564 to test an interface for various faults. Tests for an 2565 interface are defined in the media-specific MIB for that 2566 interface. After invoking a test, the object ifTestResult 2567 can be read to determine the outcome. If an agent can not 2568 perform the test, ifTestResult is set to so indicate. The 2569 object ifTestCode can be used to provide further test- 2570 specific or interface-specific (or even enterprise-specific) 2571 information concerning the outcome of the test. Only one 2572 test can be in progress on each interface at any one time. 2573 If one test is in progress when another test is invoked, the 2574 second test is rejected. Some agents may reject a test when 2575 a prior test is active on another interface. 2577 Before starting a test, a manager-station must first obtain 2578 'ownership' of the entry in the ifTestTable for the 2579 interface to be tested. This is accomplished with the 2580 ifTestId and ifTestStatus objects as follows: 2582 try_again: 2583 get (ifTestId, ifTestStatus) 2584 while (ifTestStatus != notInUse) 2585 /* 2586 * Loop while a test is running or some other 2587 * manager is configuring a test. 2588 */ 2589 short delay 2590 get (ifTestId, ifTestStatus) 2591 } 2593 /* 2594 * Is not being used right now -- let's compete 2595 * to see who gets it. 2596 */ 2597 lock_value = ifTestId 2599 if ( set(ifTestId = lock_value, ifTestStatus = inUse, 2600 ifTestOwner = 'my-IP-address') == FAILURE) 2601 /* 2602 * Another manager got the ifTestEntry -- go 2603 * try again 2604 */ 2605 goto try_again; 2607 /* 2608 * I have the lock 2609 */ 2610 set up any test parameters. 2612 /* 2613 * This starts the test 2614 */ 2615 set(ifTestType = test_to_run); 2617 wait for test completion by polling ifTestResult 2619 when test completes, agent sets ifTestResult 2620 agent also sets ifTestStatus = 'notInUse' 2622 retrieve any additional test results, and ifTestId 2624 if (ifTestId == lock_value+1) results are valid 2626 A manager station first retrieves the value of the 2627 appropriate ifTestId and ifTestStatus objects, periodically 2628 repeating the retrieval if necessary, until the value of 2629 ifTestStatus is 'notInUse'. The manager station then tries 2630 to set the same ifTestId object to the value it just 2631 retrieved, the same ifTestStatus object to 'inUse', and the 2632 corresponding ifTestOwner object to a value indicating 2633 itself. If the set operation succeeds then the manager has 2634 obtained ownership of the ifTestEntry, and the value of the 2635 ifTestId object is incremented by the agent (per the 2636 semantics of TestAndIncr). Failure of the set operation 2637 indicates that some other manager has obtained ownership of 2638 the ifTestEntry. 2640 Once ownership is obtained, any test parameters can be 2641 setup, and then the test is initiated by setting ifTestType. 2642 On completion of the test, the agent sets ifTestStatus to 2643 'notInUse'. Once this occurs, the manager can retrieve the 2644 results. In the (rare) event that the invocation of tests 2645 by two network managers were to overlap, then there would be 2646 a possibility that the first test's results might be 2647 overwritten by the second test's results prior to the first 2648 results being read. This unlikely circumstance can be 2649 detected by a network manager retrieving ifTestId at the 2650 same time as retrieving the test results, and ensuring that 2651 the results are for the desired request. 2653 If ifTestType is not set within an abnormally long period of 2654 time after ownership is obtained, the agent should time-out 2655 the manager, and reset the value of the ifTestStatus object 2656 back to 'notInUse'. It is suggested that this time-out 2657 period be 5 minutes. 2659 In general, a management station must not retransmit a 2660 request to invoke a test for which it does not receive a 2661 response; instead, it properly inspects an agent's MIB to 2662 determine if the invocation was successful. Only if the 2663 invocation was unsuccessful, is the invocation request 2664 retransmitted. 2666 Some tests may require the interface to be taken off-line in 2667 order to execute them, or may even require the agent to 2668 reboot after completion of the test. In these 2669 circumstances, communication with the management station 2670 invoking the test may be lost until after completion of the 2671 test. An agent is not required to support such tests. 2672 However, if such tests are supported, then the agent should 2673 make every effort to transmit a response to the request 2674 which invoked the test prior to losing communication. When 2675 the agent is restored to normal service, the results of the 2676 test are properly made available in the appropriate objects. 2677 Note that this requires that the ifIndex value assigned to 2678 an interface must be unchanged even if the test causes a 2679 reboot. An agent must reject any test for which it cannot, 2680 perhaps due to resource constraints, make available at least 2681 the minimum amount of information after that test 2682 completes." 2683 ::= { ifMIBObjects 3 } 2685 ifTestEntry OBJECT-TYPE 2686 SYNTAX IfTestEntry 2687 MAX-ACCESS not-accessible 2688 STATUS deprecated 2689 DESCRIPTION 2690 "An entry containing objects for invoking tests on an 2691 interface." 2692 AUGMENTS { ifEntry } 2693 ::= { ifTestTable 1 } 2695 IfTestEntry ::= 2696 SEQUENCE { 2697 ifTestId TestAndIncr, 2698 ifTestStatus INTEGER, 2699 ifTestType AutonomousType, 2700 ifTestResult INTEGER, 2701 ifTestCode OBJECT IDENTIFIER, 2702 ifTestOwner OwnerString 2703 } 2705 ifTestId OBJECT-TYPE 2706 SYNTAX TestAndIncr 2707 MAX-ACCESS read-write 2708 STATUS deprecated 2709 DESCRIPTION 2710 "This object identifies the current invocation of the 2711 interface's test." 2712 ::= { ifTestEntry 1 } 2714 ifTestStatus OBJECT-TYPE 2715 SYNTAX INTEGER { notInUse(1), inUse(2) } 2716 MAX-ACCESS read-write 2717 STATUS deprecated 2718 DESCRIPTION 2719 "This object indicates whether or not some manager currently 2720 has the necessary 'ownership' required to invoke a test on 2721 this interface. A write to this object is only successful 2722 when it changes its value from 'notInUse(1)' to 'inUse(2)'. 2723 After completion of a test, the agent resets the value back 2724 to 'notInUse(1)'." 2726 ::= { ifTestEntry 2 } 2728 ifTestType OBJECT-TYPE 2729 SYNTAX AutonomousType 2730 MAX-ACCESS read-write 2731 STATUS deprecated 2732 DESCRIPTION 2733 "A control variable used to start and stop operator- 2734 initiated interface tests. Most OBJECT IDENTIFIER values 2735 assigned to tests are defined elsewhere, in association with 2736 specific types of interface. However, this document assigns 2737 a value for a full-duplex loopback test, and defines the 2738 special meanings of the subject identifier: 2740 noTest OBJECT IDENTIFIER ::= { 0 0 } 2742 When the value noTest is written to this object, no action 2743 is taken unless a test is in progress, in which case the 2744 test is aborted. Writing any other value to this object is 2745 only valid when no test is currently in progress, in which 2746 case the indicated test is initiated. 2748 When read, this object always returns the most recent value 2749 that ifTestType was set to. If it has not been set since 2750 the last initialization of the network management subsystem 2751 on the agent, a value of noTest is returned." 2752 ::= { ifTestEntry 3 } 2754 ifTestResult OBJECT-TYPE 2755 SYNTAX INTEGER { 2756 none(1), -- no test yet requested 2757 success(2), 2758 inProgress(3), 2759 notSupported(4), 2760 unAbleToRun(5), -- due to state of system 2761 aborted(6), 2762 failed(7) 2763 } 2764 MAX-ACCESS read-only 2765 STATUS deprecated 2766 DESCRIPTION 2767 "This object contains the result of the most recently 2768 requested test, or the value none(1) if no tests have been 2769 requested since the last reset. Note that this facility 2770 provides no provision for saving the results of one test 2771 when starting another, as could be required if used by 2772 multiple managers concurrently." 2773 ::= { ifTestEntry 4 } 2775 ifTestCode OBJECT-TYPE 2776 SYNTAX OBJECT IDENTIFIER 2777 MAX-ACCESS read-only 2778 STATUS deprecated 2779 DESCRIPTION 2780 "This object contains a code which contains more specific 2781 information on the test result, for example an error-code 2782 after a failed test. Error codes and other values this 2783 object may take are specific to the type of interface and/or 2784 test. The value may have the semantics of either the 2785 AutonomousType or InstancePointer textual conventions as 2786 defined in RFC 2579. The identifier: 2788 testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } 2790 is defined for use if no additional result code is 2791 available." 2792 ::= { ifTestEntry 5 } 2794 ifTestOwner OBJECT-TYPE 2795 SYNTAX OwnerString 2796 MAX-ACCESS read-write 2797 STATUS deprecated 2798 DESCRIPTION 2799 "The entity which currently has the 'ownership' required to 2800 invoke a test on this interface." 2801 ::= { ifTestEntry 6 } 2803 -- Deprecated Definitions - Groups 2805 ifGeneralGroup OBJECT-GROUP 2806 OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress, 2807 ifAdminStatus, ifOperStatus, ifLastChange, 2808 ifLinkUpDownTrapEnable, ifConnectorPresent, 2809 ifHighSpeed, ifName } 2810 STATUS deprecated 2811 DESCRIPTION 2812 "A collection of objects deprecated in favour of 2813 ifGeneralInformationGroup." 2814 ::= { ifGroups 1 } 2816 ifTestGroup OBJECT-GROUP 2817 OBJECTS { ifTestId, ifTestStatus, ifTestType, 2818 ifTestResult, ifTestCode, ifTestOwner } 2819 STATUS deprecated 2820 DESCRIPTION 2821 "A collection of objects providing the ability to invoke 2822 tests on an interface." 2823 ::= { ifGroups 8 } 2825 ifStackGroup OBJECT-GROUP 2826 OBJECTS { ifStackStatus } 2827 STATUS deprecated 2828 DESCRIPTION 2829 "The previous collection of objects providing information on 2830 the layering of MIB-II interfaces." 2831 ::= { ifGroups 9 } 2833 ifOldObjectsGroup OBJECT-GROUP 2834 OBJECTS { ifInNUcastPkts, ifOutNUcastPkts, 2835 ifOutQLen, ifSpecific } 2836 STATUS deprecated 2837 DESCRIPTION 2838 "The collection of objects deprecated from the original MIB- 2839 II interfaces group." 2840 ::= { ifGroups 12 } 2842 -- Deprecated Definitions - Compliance 2844 ifCompliance MODULE-COMPLIANCE 2845 STATUS deprecated 2846 DESCRIPTION 2847 "A compliance statement defined in a previous version of 2848 this MIB module, for SNMP entities which have network 2849 interfaces." 2851 MODULE -- this module 2852 MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup } 2854 GROUP ifFixedLengthGroup 2855 DESCRIPTION 2856 "This group is mandatory for all network interfaces which 2857 are character-oriented or transmit data in fixed-length 2858 transmission units." 2860 GROUP ifHCFixedLengthGroup 2861 DESCRIPTION 2862 "This group is mandatory only for those network interfaces 2863 which are character-oriented or transmit data in fixed- 2864 length transmission units, and for which the value of the 2865 corresponding instance of ifSpeed is greater than 20,000,000 2866 bits/second." 2868 GROUP ifPacketGroup 2869 DESCRIPTION 2870 "This group is mandatory for all network interfaces which 2871 are packet-oriented." 2873 GROUP ifHCPacketGroup 2874 DESCRIPTION 2875 "This group is mandatory only for those network interfaces 2876 which are packet-oriented and for which the value of the 2877 corresponding instance of ifSpeed is greater than 2878 650,000,000 bits/second." 2880 GROUP ifTestGroup 2881 DESCRIPTION 2882 "This group is optional. Media-specific MIBs which require 2883 interface tests are strongly encouraged to use this group 2884 for invoking tests and reporting results. A medium specific 2885 MIB which has mandatory tests may make implementation of 2886 this group mandatory." 2888 GROUP ifRcvAddressGroup 2889 DESCRIPTION 2890 "The applicability of this group MUST be defined by the 2891 media-specific MIBs. Media-specific MIBs must define the 2892 exact meaning, use, and semantics of the addresses in this 2893 group." 2895 OBJECT ifLinkUpDownTrapEnable 2896 MIN-ACCESS read-only 2897 DESCRIPTION 2898 "Write access is not required." 2900 OBJECT ifPromiscuousMode 2901 MIN-ACCESS read-only 2902 DESCRIPTION 2903 "Write access is not required." 2905 OBJECT ifStackStatus 2906 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2907 MIN-ACCESS read-only 2908 DESCRIPTION 2909 "Write access is not required, and only one of the six 2910 enumerated values for the RowStatus textual convention need 2911 be supported, specifically: active(1)." 2913 OBJECT ifAdminStatus 2914 SYNTAX INTEGER { up(1), down(2) } 2915 MIN-ACCESS read-only 2916 DESCRIPTION 2917 "Write access is not required, nor is support for the value 2918 testing(3)." 2919 ::= { ifCompliances 1 } 2921 ifCompliance2 MODULE-COMPLIANCE 2922 STATUS deprecated 2923 DESCRIPTION 2924 "A compliance statement defined in a previous version of 2925 this MIB module, for SNMP entities which have network 2926 interfaces." 2928 MODULE -- this module 2929 MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2, 2930 ifCounterDiscontinuityGroup } 2932 GROUP ifFixedLengthGroup 2933 DESCRIPTION 2934 "This group is mandatory for all network interfaces which 2935 are character-oriented or transmit data in fixed-length 2936 transmission units." 2938 GROUP ifHCFixedLengthGroup 2939 DESCRIPTION 2940 "This group is mandatory only for those network interfaces 2941 which are character-oriented or transmit data in fixed- 2942 length transmission units, and for which the value of the 2943 corresponding instance of ifSpeed is greater than 20,000,000 2944 bits/second." 2946 GROUP ifPacketGroup 2947 DESCRIPTION 2948 "This group is mandatory for all network interfaces which 2949 are packet-oriented." 2951 GROUP ifHCPacketGroup 2952 DESCRIPTION 2953 "This group is mandatory only for those network interfaces 2954 which are packet-oriented and for which the value of the 2955 corresponding instance of ifSpeed is greater than 2956 650,000,000 bits/second." 2958 GROUP ifRcvAddressGroup 2959 DESCRIPTION 2960 "The applicability of this group MUST be defined by the 2961 media-specific MIBs. Media-specific MIBs must define the 2962 exact meaning, use, and semantics of the addresses in this 2963 group." 2965 OBJECT ifLinkUpDownTrapEnable 2966 MIN-ACCESS read-only 2967 DESCRIPTION 2968 "Write access is not required." 2970 OBJECT ifPromiscuousMode 2971 MIN-ACCESS read-only 2972 DESCRIPTION 2973 "Write access is not required." 2975 OBJECT ifStackStatus 2976 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2977 MIN-ACCESS read-only 2978 DESCRIPTION 2979 "Write access is not required, and only one of the six 2980 enumerated values for the RowStatus textual convention need 2981 be supported, specifically: active(1)." 2983 OBJECT ifAdminStatus 2984 SYNTAX INTEGER { up(1), down(2) } 2985 MIN-ACCESS read-only 2986 DESCRIPTION 2987 "Write access is not required, nor is support for the value 2988 testing(3)." 2990 OBJECT ifAlias 2991 MIN-ACCESS read-only 2992 DESCRIPTION 2993 "Write access is not required." 2995 ::= { ifCompliances 2 } 2997 END 2998 7. Acknowledgements 3000 This memo has been produced by the IETF's Interfaces MIB working-group. 3002 The original proposal evolved from conversations and discussions with 3003 many people, including at least the following: Fred Baker, Ted Brunner, 3004 Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and Dean Throop. 3006 8. References 3008 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 3009 Describing SNMP Management Frameworks", RFC 2571, Cabletron 3010 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 3011 1999. 3013 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 3014 Management Information for TCP/IP-based Internets", STD 16, RFC 3015 1155, Performance Systems International, Hughes LAN Systems, May 3016 1990. 3018 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 3019 1212, Performance Systems International, Hughes LAN Systems, March 3020 1991. 3022 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 3023 RFC 1215, Performance Systems International, March 1991. 3025 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. 3026 and S. Waldbusser, "Structure of Management Information Version 2 3027 (SMIv2)", STD 58, RFC 2578, April 1999. 3029 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. 3030 and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 3031 2579, April 1999. 3033 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. 3034 and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 3035 2580, April 1999. 3037 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 3038 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 3039 Systems International, Performance Systems International, MIT 3040 Laboratory for Computer Science, May 1990. 3042 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 3043 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 3044 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 3045 Inc., International Network Services, January 1996. 3047 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 3048 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 3049 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco 3050 Systems, Inc., Dover Beach Consulting, Inc., International Network 3051 Services, January 1996. 3053 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 3054 Processing and Dispatching for the Simple Network Management 3055 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 3056 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 3058 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 3059 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3060 2574, IBM T. J. Watson Research, January 1998. 3062 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 3063 Waldbusser, "Protocol Operations for Version 2 of the Simple 3064 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 3065 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 3066 International Network Services, January 1996. 3068 [14] Levi, D., Meyer, P., and B. Stewart, "SMPv3 Applications", RFC 3069 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 3070 Systems, January 1998. 3072 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 3073 Control Model (VACM) for the Simple Network Management Protocol 3074 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 3075 Cisco Systems, Inc., January 1998. 3077 [16] S. Bradner, "Key words for use in RFCs to Indicate Requirements 3078 Levels", RFC 2119, Harvard University, March 1997. 3080 [17] McCloghrie, K., and M. Rose, "Management Information Base for 3081 Network Management of TCP/IP-based internets - MIB-II", RFC 1213, 3082 Hughes LAN Systems, Performance Systems International, March 1991. 3084 [18] J. Postel, "Internet Protocol", RFC 791, Information Sciences 3085 Institute, USC, September 1981. 3087 [19] K. McCloghrie, "Extensions to the Generic-Interface MIB", RFC 1229, 3088 Hughes LAN Systems, May 1991. 3090 [20] ATM Forum Technical Committee, "LAN Emulation Client Management: 3091 Version 1.0 Specification", af-lane-0044.000, ATM Forum, September 3092 1995. 3094 [21] B. Stewart, "Definitions of Managed Objects for Character Stream 3095 Devices using SMIv2", RFC 1658, Xyplex Inc., July 1994. 3097 [22] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to 3098 Version 3 of the Internet-standard Network Management Framework", 3099 RFC 2570, April 1999. 3101 9. Security Considerations 3103 There are a number of management objects defined in this MIB that have a 3104 MAX-ACCESS clause of read-write and/or read-create. Such objects may be 3105 considered sensitive or vulnerable in some network environments. The 3106 support for SET operations in a non-secure environment without proper 3107 protection can have a negative effect on network operations. 3109 In particular, write-able objects allow an administrator to control the 3110 interfaces and to perform tests on the interfaces, and unauthorized 3111 access to these could cause a denial of service, or in combination with 3112 other (e.g., physical) security breaches, could cause unauthorized 3113 connectivity to a device. 3115 SNMPv1 by itself is not a secure environment. Even if the network 3116 itself is secure (for example by using IPSec), even then, there is no 3117 control as to who on the secure network is allowed to access and GET/SET 3118 (read/change/create/delete) the objects in this MIB. 3120 It is recommended that the implementers consider the security features 3121 as provided by the SNMPv3 framework. Specifically, the use of the User- 3122 based Security Model RFC 2574 [12] and the View- based Access Control 3123 Model RFC 2575 [15] is recommended. 3125 It is then a customer/user responsibility to ensure that the SNMP entity 3126 giving access to an instance of this MIB, is properly configured to give 3127 access to the objects only to those principals (users) that have 3128 legitimate rights to indeed GET or SET (change/create/delete) them. 3130 10. Authors' Addresses 3132 Keith McCloghrie 3133 Cisco Systems, Inc. 3134 170 West Tasman Drive 3135 San Jose, CA 95134-1706 3137 Phone: 408-526-5260 3138 Email: kzm@cisco.com" 3140 Frank Kastenholz 3141 Argon Networks 3142 25 Porter Rd 3143 Littleton Ma 01460 3144 Phone: (508)685-4000 3145 Email: kasten@argon.com 3147 11. Changes from RFC 2233 3149 Added linkUpDownNotificationsGroup. 3151 Changed the status of the definition of OwnerString in this MIB to 3152 be deprecated, because it is only used by ifTestOwner, which is now 3153 deprecated, and because other MIBs should import OwnerString from 3154 RFC 1757 or its successors. 3156 Added ifCompliance3 as a replacement for ifCompliance2 to omit the 3157 ifStackGroup2 group, and add linkUpDownNotificationsGroup. Also, 3158 corrected the omission of ifVHCPacketGroup, and typos in the 3159 DESCRIPTIONs of ifHCPacketGroup and ifFixedLengthGroup. Obsoleted 3160 ifCompliance2. 3162 Modified syntax of ifStackHigherLayer and ifStackLowerLayer to be 3163 InterfaceIndexOrZero. 3165 Added requirement that media-specific MIB designers specify any 3166 special conditions concerning the counting of framing characters in 3167 ifInOctets and ifOutOctets. 3169 Corrected a typo in the DESCRIPTION of the linkUp notification. 3171 Modified the introductory SNMP Network Management Framework 3172 boilerplate text. 3174 12. Notice on Intellectual Property 3176 The IETF takes no position regarding the validity or scope of any 3177 intellectual property or other rights that might be claimed to pertain 3178 to the implementation or use of the technology described in this 3179 document or the extent to which any license under such rights might or 3180 might not be available; neither does it represent that it has made any 3181 effort to identify any such rights. Information on the IETF's 3182 procedures with respect to rights in standards-track and standards- 3183 related documentation can be found in BCP-11. Copies of claims of 3184 rights made available for publication and any assurances of licenses to 3185 be made available, or the result of an attempt made to obtain a general 3186 license or permission for the use of such proprietary rights by 3187 implementors or users of this specification can be obtained from the 3188 IETF Secretariat. 3190 The IETF invites any interested party to bring to its attention any 3191 copyrights, patents or patent applications, or other proprietary rights 3192 which may cover technology that may be required to practice this 3193 standard. Please address the information to the IETF Executive 3194 Director. 3196 13. Full Copyright Statement 3198 Copyright (C) The Internet Society (2000). All Rights Reserved. 3200 This document and translations of it may be copied and furnished to 3201 others, and derivative works that comment on or otherwise explain it or 3202 assist in its implmentation may be prepared, copied, published and 3203 distributed, in whole or in part, without restriction of any kind, 3204 provided that the above copyright notice and this paragraph are included 3205 on all such copies and derivative works. However, this document itself 3206 may not be modified in any way, such as by removing the copyright notice 3207 or references to the Internet Society or other Internet organizations, 3208 except as needed for the purpose of developing Internet standards in 3209 which case the procedures for copyrights defined in the Internet 3210 Standards process must be followed, or as required to translate it into 3211 languages other than English. 3213 The limited permissions granted above are perpetual and will not be 3214 revoked by the Internet Society or its successors or assigns. 3216 This document and the information contained herein is provided on an "AS 3217 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3218 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3219 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3220 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3221 FITNESS FOR A PARTICULAR PURPOSE." 3222 Table of Contents 3224 1 Introduction .................................................... 2 3225 2 The SNMP Network Management Framework ........................... 2 3226 3 Experience with the Interfaces Group ............................ 3 3227 3.1 Clarifications/Revisions ...................................... 4 3228 3.1.1 Interface Sub-Layers ........................................ 4 3229 3.1.2 Guidance on Defining Sub-layers ............................. 7 3230 3.1.3 Virtual Circuits ............................................ 8 3231 3.1.4 Bit, Character, and Fixed-Length Interfaces ................. 9 3232 3.1.5 Interface Numbering ......................................... 11 3233 3.1.6 Counter Size ................................................ 15 3234 3.1.7 Interface Speed ............................................. 17 3235 3.1.8 Multicast/Broadcast Counters ................................ 18 3236 3.1.9 Trap Enable ................................................. 19 3237 3.1.10 Addition of New ifType values .............................. 19 3238 3.1.11 InterfaceIndex Textual Convention .......................... 19 3239 3.1.12 New states for IfOperStatus ................................ 20 3240 3.1.13 IfAdminStatus and IfOperStatus ............................. 21 3241 3.1.14 IfOperStatus in an Interface Stack ......................... 22 3242 3.1.15 Traps ...................................................... 22 3243 3.1.16 ifSpecific ................................................. 24 3244 3.1.17 Creation/Deletion of Interfaces ............................ 25 3245 3.1.18 All Values Must be Known ................................... 25 3246 4 Media-Specific MIB Applicability ................................ 27 3247 5 Overview ........................................................ 28 3248 6 Interfaces Group Definitions .................................... 29 3249 7 Acknowledgements ................................................ 73 3250 8 References ...................................................... 73 3251 9 Security Considerations ......................................... 76 3252 10 Authors' Addresses ............................................. 76 3253 11 Changes from RFC 2233 .......................................... 78 3254 12 Notice on Intellectual Property ................................ 79 3255 13 Full Copyright Statement ....................................... 79