idnits 2.17.1 draft-ietf-ifmib-ifmib2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 84 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 81 pages 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 3162 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 October 1999) is 8963 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 (~~), 6 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 October 1999 7 The Interfaces Group MIB 9 draft-ietf-ifmib-ifmib2-01.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 (1999). 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 used. For interfaces 678 that operate faster than 20,000,000 bits/second, and slower than 679 650,000,000 bits/second, 32-bit packet counters MUST be used and 64-bit 680 octet counters MUST be used. For interfaces that operate at 650,000,000 681 bits/second or faster, 64-bit packet counters AND 64-bit octet counters 682 MUST be used. 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. 1014 Note that this definition allows a node with only one interface to 1015 transmit a linkDown trap before that interface goes down. (Of course, 1016 when the interface is going down because of a failure condition, the 1017 linkDown trap probably cannot be successfully transmitted anyway.) 1018 Some interfaces perform a link "training" function when trying to bring 1019 the interface up. In the event that such an interface were defective, 1020 then the training function would fail and the interface would remain 1021 down, and the training function might be repeated at appropriate 1022 intervals. If the interface, while performing this training function, 1023 were considered to the in the testing state, then linkUp and linkDown 1024 traps would be generated for each start and end of the training 1025 function. This is not the intent of the linkUp and linkDown traps, and 1026 therefore, while performing such a training function, the interface's 1027 state should be represented as down. 1029 An exception to the above generation of linkUp/linkDown traps on changes 1030 in ifOperStatus, occurs when an interface is "flapping", i.e., when it 1031 is rapidly oscillating between the up and down states. If traps were 1032 generated for each such oscillation, the network and the network 1033 management system would be flooded with unnecessary traps. In such a 1034 situation, the agent should limit the rate at which it generates traps. 1036 3.1.16. ifSpecific 1038 The original definition of the OBJECT IDENTIFIER value of ifSpecific was 1039 not sufficiently clear. As a result, different implementors used it 1040 differently, and confusion resulted. Some implementations set the value 1041 of ifSpecific to the OBJECT IDENTIFIER that defines the media-specific 1042 MIB, i.e., the "foo" of: 1043 foo OBJECT IDENTIFIER ::= { transmission xxx } 1045 while others set it to be OBJECT IDENTIFIER of the specific table or 1046 entry in the appropriate media-specific MIB (i.e., fooTable or 1047 fooEntry), while still others set it be the OBJECT IDENTIFIER of the 1048 index object of the table's row, including instance identifier, (i.e., 1049 fooIfIndex.ifIndex). A definition based on the latter would not be 1050 sufficient unless it also allowed for media-specific MIBs which include 1051 several tables, where each table has its own (different) indexing. 1053 The only definition that can both be made explicit and can cover all the 1054 useful situations is to have ifSpecific be the most general value for 1055 the media-specific MIB module (the first example given above). This 1056 effectively makes it redundant because it contains no more information 1057 than is provided by ifType. Thus, ifSpecific has been deprecated. 1059 3.1.17. Creation/Deletion of Interfaces 1061 While some interfaces, for example, most physical interfaces, cannot be 1062 created via network management, other interfaces such as logical 1063 interfaces sometimes can be. The ifTable contains only generic 1064 information about an interface. Almost all 'create-able' interfaces 1065 have other, media-specific, information through which configuration 1066 parameters may be supplied prior to creating such an interface. Thus, 1067 the ifTable does not itself support the creation or deletion of an 1068 interface (specifically, it has no RowStatus [6] column). Rather, if a 1069 particular interface type supports the dynamic creation and/or deletion 1070 of an interface of that type, then that media-specific MIB should 1071 include an appropriate RowStatus object (see the ATM LAN-Emulation 1072 Client MIB [20] for an example of a MIB which does this). Typically, 1073 when such a RowStatus object is created/deleted, then the conceptual row 1074 in the ifTable appears/disappears as a by-product, and an ifIndex value 1075 (chosen by the agent) is stored in an appropriate object in the media- 1076 specific MIB. 1078 3.1.18. All Values Must be Known 1080 There are a number of situations where an agent does not know the value 1081 of one or more objects for a particular interface. In all such 1082 circumstances, an agent MUST NOT instantiate an object with an incorrect 1083 value; rather, it MUST respond with the appropriate error/exception 1084 condition (e.g., noSuchInstance for SNMPv2). 1086 One example is where an agent is unable to count the occurrences defined 1087 by one (or more) of the ifTable counters. In this circumstance, the 1088 agent MUST NOT instantiate the particular counter with a value of, say, 1089 zero. To do so would be to provide mis-information to a network 1090 management application reading the zero value, and thereby assuming that 1091 there have been no occurrences of the event (e.g., no input errors 1092 because ifInErrors is always zero). 1094 Sometimes the lack of knowledge of an object's value is temporary. For 1095 example, when the MTU of an interface is a configured value and a device 1096 dynamically learns the configured value through (after) exchanging 1097 messages over the interface (e.g., ATM LAN-Emulation [20]). In such a 1098 case, the value is not known until after the ifTable entry has already 1099 been created. In such a case, the ifTable entry should be created 1100 without an instance of the object whose value is unknown; later, when 1101 the value becomes known, the missing object can then be instantiated 1102 (e.g., the instance of ifMtu is only instantiated once the interface's 1103 MTU becomes known). 1105 As a result of this "known values" rule, management applications MUST be 1106 able to cope with the responses to retrieving the object instances 1107 within a conceptual row of the ifTable revealing that some of the row's 1108 columnar objects are missing/not available. 1110 4. Media-Specific MIB Applicability 1112 The exact use and semantics of many objects in this MIB are open to some 1113 interpretation. This is a result of the generic nature of this MIB. It 1114 is not always possible to come up with specific, unambiguous, text that 1115 covers all cases and yet preserves the generic nature of the MIB. 1117 Therefore, it is incumbent upon a media-specific MIB designer to, 1118 wherever necessary, clarify the use of the objects in this MIB with 1119 respect to the media-specific MIB. 1121 Specific areas of clarification include 1123 Layering Model 1124 The media-specific MIB designer MUST completely and unambiguously 1125 specify the layering model used. Each individual sub-layer must be 1126 identified, as must the ifStackTable's portrayal of the 1127 relationship(s) between the sub-layers. 1129 Virtual Circuits 1130 The media-specific MIB designer MUST specify whether virtual 1131 circuits are assigned entries in the ifTable or not. If they are, 1132 compelling rationale must be presented. 1134 ifRcvAddressTable 1135 The media-specific MIB designer MUST specify the applicability of 1136 the ifRcvAddressTable. 1138 ifType 1139 For each of the ifType values to which the media-specific MIB 1140 applies, it must specify the mapping of ifType values to media- 1141 specific MIB module(s) and instances of MIB objects within those 1142 modules. 1144 ifXxxOctets 1145 The definitions of ifInOctets and ifOutOctets (and similarly, 1146 ifHCInOctets and ifHCOutOctets) specify that their values include 1147 framing characters. The media-specific MIB designer MUST specify 1148 any special conditions of the media concerning the inclusion of 1149 framing characters, especially with respect to frames with errors. 1151 However, wherever this interface MIB is specific in the semantics, 1152 DESCRIPTION, or applicability of objects, the media-specific MIB 1153 designer MUST NOT change said semantics, DESCRIPTION, or applicability. 1155 5. Overview 1157 This MIB consists of 4 tables: 1159 ifTable 1160 This table is the ifTable from MIB-II. 1162 ifXTable 1163 This table contains objects that have been added to the Interface 1164 MIB as a result of the Interface Evolution effort, or replacements 1165 for objects of the original (MIB-II) ifTable that were deprecated 1166 because the semantics of said objects have significantly changed. 1167 This table also contains objects that were previously in the 1168 ifExtnsTable. 1170 ifStackTable 1171 This table contains objects that define the relationships among the 1172 sub-layers of an interface. 1174 ifRcvAddressTable 1175 This table contains objects that are used to define the media-level 1176 addresses which this interface will receive. This table is a 1177 generic table. The designers of media-specific MIBs must define 1178 exactly how this table applies to their specific MIB. 1180 6. Interfaces Group Definitions 1182 IF-MIB DEFINITIONS ::= BEGIN 1184 IMPORTS 1185 MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, 1186 Integer32, TimeTicks, mib-2, 1187 NOTIFICATION-TYPE FROM SNMPv2-SMI 1188 TEXTUAL-CONVENTION, DisplayString, 1189 PhysAddress, TruthValue, RowStatus, 1190 TimeStamp, AutonomousType, TestAndIncr FROM SNMPv2-TC 1191 MODULE-COMPLIANCE, OBJECT-GROUP, 1192 NOTIFICATION-GROUP FROM SNMPv2-CONF 1193 snmpTraps FROM SNMPv2-MIB 1194 IANAifType FROM IANAifType-MIB; 1196 ifMIB MODULE-IDENTITY 1197 LAST-UPDATED "9910110000Z" 1198 ORGANIZATION "IETF Interfaces MIB Working Group" 1199 CONTACT-INFO 1200 " Keith McCloghrie 1201 Cisco Systems, Inc. 1202 170 West Tasman Drive 1203 San Jose, CA 95134-1706 1204 US 1206 408-526-5260 1207 kzm@cisco.com" 1208 DESCRIPTION 1209 "The MIB module to describe generic objects for network 1210 interface sub-layers. This MIB is an updated version of 1211 MIB-II's ifTable, and incorporates the extensions defined in 1212 RFC 1229." 1213 REVISION "9910110000Z" 1214 DESCRIPTION -- xxxx to be filled in by RFC-EDITOR 1215 "Clarifications agreed upon by the Interfaces MIB WG, and 1216 published as RFC xxxx." 1217 REVISION "9602282155Z" 1218 DESCRIPTION 1219 "Revisions made by the Interfaces MIB WG, and published in 1220 RFC 2233." 1221 REVISION "9311082155Z" 1222 DESCRIPTION 1223 "Initial revision, published as part of RFC 1573." 1225 ::= { mib-2 31 } 1227 ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 } 1229 interfaces OBJECT IDENTIFIER ::= { mib-2 2 } 1231 -- 1232 -- Textual Conventions 1233 -- 1235 -- OwnerString has the same semantics as used in RFC 1271 1237 OwnerString ::= TEXTUAL-CONVENTION 1238 DISPLAY-HINT "255a" 1239 STATUS deprecated 1240 DESCRIPTION 1241 "This data type is used to model an administratively 1242 assigned name of the owner of a resource. This information 1243 is taken from the NVT ASCII character set. It is suggested 1244 that this name contain one or more of the following: ASCII 1245 form of the manager station's transport address, management 1246 station name (e.g., domain name), network management 1247 personnel's name, location, or phone number. In some cases 1248 the agent itself will be the owner of an entry. In these 1249 cases, this string shall be set to a string starting with 1250 'agent'." 1251 SYNTAX OCTET STRING (SIZE(0..255)) 1253 -- InterfaceIndex contains the semantics of ifIndex and should be used 1254 -- for any objects defined in other MIB modules that need these semantics. 1256 InterfaceIndex ::= TEXTUAL-CONVENTION 1257 DISPLAY-HINT "d" 1258 STATUS current 1259 DESCRIPTION 1260 "A unique value, greater than zero, for each interface or 1261 interface sub-layer in the managed system. It is 1262 recommended that values are assigned contiguously starting 1263 from 1. The value for each interface sub-layer must remain 1264 constant at least from one re-initialization of the entity's 1265 network management system to the next re-initialization." 1266 SYNTAX Integer32 (1..2147483647) 1268 InterfaceIndexOrZero ::= TEXTUAL-CONVENTION 1269 DISPLAY-HINT "d" 1270 STATUS current 1271 DESCRIPTION 1272 "This textual convention is an extension of the 1273 InterfaceIndex convention. The latter defines a greater 1274 than zero value used to identify an interface or interface 1275 sub-layer in the managed system. This extension permits the 1276 additional value of zero. the value zero is object-specific 1277 and must therefore be defined as part of the description of 1278 any object which uses this syntax. Examples of the usage of 1279 zero might include situations where interface was unknown, 1280 or when none or all interfaces need to be referenced." 1281 SYNTAX Integer32 (0..2147483647) 1283 ifNumber OBJECT-TYPE 1284 SYNTAX Integer32 1285 MAX-ACCESS read-only 1286 STATUS current 1287 DESCRIPTION 1288 "The number of network interfaces (regardless of their 1289 current state) present on this system." 1290 ::= { interfaces 1 } 1292 ifTableLastChange OBJECT-TYPE 1293 SYNTAX TimeTicks 1294 MAX-ACCESS read-only 1295 STATUS current 1296 DESCRIPTION 1297 "The value of sysUpTime at the time of the last creation or 1298 deletion of an entry in the ifTable. If the number of 1299 entries has been unchanged since the last re-initialization 1300 of the local network management subsystem, then this object 1301 contains a zero value." 1302 ::= { ifMIBObjects 5 } 1304 -- the Interfaces table 1306 -- The Interfaces table contains information on the entity's 1307 -- interfaces. Each sub-layer below the internetwork-layer 1308 -- of a network interface is considered to be an interface. 1310 ifTable OBJECT-TYPE 1311 SYNTAX SEQUENCE OF IfEntry 1312 MAX-ACCESS not-accessible 1313 STATUS current 1314 DESCRIPTION 1315 "A list of interface entries. The number of entries is 1316 given by the value of ifNumber." 1317 ::= { interfaces 2 } 1319 ifEntry OBJECT-TYPE 1320 SYNTAX IfEntry 1321 MAX-ACCESS not-accessible 1322 STATUS current 1323 DESCRIPTION 1324 "An entry containing management information applicable to a 1325 particular interface." 1326 INDEX { ifIndex } 1327 ::= { ifTable 1 } 1329 IfEntry ::= 1330 SEQUENCE { 1331 ifIndex InterfaceIndex, 1332 ifDescr DisplayString, 1333 ifType IANAifType, 1334 ifMtu Integer32, 1335 ifSpeed Gauge32, 1336 ifPhysAddress PhysAddress, 1337 ifAdminStatus INTEGER, 1338 ifOperStatus INTEGER, 1339 ifLastChange TimeTicks, 1340 ifInOctets Counter32, 1341 ifInUcastPkts Counter32, 1342 ifInNUcastPkts Counter32, -- deprecated 1343 ifInDiscards Counter32, 1344 ifInErrors Counter32, 1345 ifInUnknownProtos Counter32, 1346 ifOutOctets Counter32, 1347 ifOutUcastPkts Counter32, 1348 ifOutNUcastPkts Counter32, -- deprecated 1349 ifOutDiscards Counter32, 1350 ifOutErrors Counter32, 1351 ifOutQLen Gauge32, -- deprecated 1352 ifSpecific OBJECT IDENTIFIER -- deprecated 1353 } 1355 ifIndex OBJECT-TYPE 1356 SYNTAX InterfaceIndex 1357 MAX-ACCESS read-only 1358 STATUS current 1359 DESCRIPTION 1360 "A unique value, greater than zero, for each interface. It 1361 is recommended that values are assigned contiguously 1362 starting from 1. The value for each interface sub-layer 1363 must remain constant at least from one re-initialization of 1364 the entity's network management system to the next re- 1365 initialization." 1366 ::= { ifEntry 1 } 1368 ifDescr OBJECT-TYPE 1369 SYNTAX DisplayString (SIZE (0..255)) 1370 MAX-ACCESS read-only 1371 STATUS current 1372 DESCRIPTION 1373 "A textual string containing information about the 1374 interface. This string should include the name of the 1375 manufacturer, the product name and the version of the 1376 interface hardware/software." 1377 ::= { ifEntry 2 } 1379 ifType OBJECT-TYPE 1380 SYNTAX IANAifType 1381 MAX-ACCESS read-only 1382 STATUS current 1383 DESCRIPTION 1384 "The type of interface. Additional values for ifType are 1385 assigned by the Internet Assigned Numbers Authority (IANA), 1386 through updating the syntax of the IANAifType textual 1387 convention." 1388 ::= { ifEntry 3 } 1390 ifMtu OBJECT-TYPE 1391 SYNTAX Integer32 1392 MAX-ACCESS read-only 1393 STATUS current 1394 DESCRIPTION 1395 "The size of the largest packet which can be sent/received 1396 on the interface, specified in octets. For interfaces that 1397 are used for transmitting network datagrams, this is the 1398 size of the largest network datagram that can be sent on the 1399 interface." 1400 ::= { ifEntry 4 } 1402 ifSpeed OBJECT-TYPE 1403 SYNTAX Gauge32 1404 MAX-ACCESS read-only 1405 STATUS current 1406 DESCRIPTION 1407 "An estimate of the interface's current bandwidth in bits 1408 per second. For interfaces which do not vary in bandwidth 1409 or for those where no accurate estimation can be made, this 1410 object should contain the nominal bandwidth. If the 1411 bandwidth of the interface is greater than the maximum value 1412 reportable by this object then this object should report its 1413 maximum value (4,294,967,295) and ifHighSpeed must be used 1414 to report the interace's speed. For a sub-layer which has 1415 no concept of bandwidth, this object should be zero." 1417 ::= { ifEntry 5 } 1419 ifPhysAddress OBJECT-TYPE 1420 SYNTAX PhysAddress 1421 MAX-ACCESS read-only 1422 STATUS current 1423 DESCRIPTION 1424 "The interface's address at its protocol sub-layer. For 1425 example, for an 802.x interface, this object normally 1426 contains a MAC address. The interface's media-specific MIB 1427 must define the bit and byte ordering and the format of the 1428 value of this object. For interfaces which do not have such 1429 an address (e.g., a serial line), this object should contain 1430 an octet string of zero length." 1431 ::= { ifEntry 6 } 1433 ifAdminStatus OBJECT-TYPE 1434 SYNTAX INTEGER { 1435 up(1), -- ready to pass packets 1436 down(2), 1437 testing(3) -- in some test mode 1438 } 1439 MAX-ACCESS read-write 1440 STATUS current 1441 DESCRIPTION 1442 "The desired state of the interface. The testing(3) state 1443 indicates that no operational packets can be passed. When a 1444 managed system initializes, all interfaces start with 1445 ifAdminStatus in the down(2) state. As a result of either 1446 explicit management action or per configuration information 1447 retained by the managed system, ifAdminStatus is then 1448 changed to either the up(1) or testing(3) states (or remains 1449 in the down(2) state)." 1450 ::= { ifEntry 7 } 1452 ifOperStatus OBJECT-TYPE 1453 SYNTAX INTEGER { 1454 up(1), -- ready to pass packets 1455 down(2), 1456 testing(3), -- in some test mode 1457 unknown(4), -- status can not be determined 1458 -- for some reason. 1459 dormant(5), 1460 notPresent(6), -- some component is missing 1461 lowerLayerDown(7) -- down due to state of 1462 -- lower-layer interface(s) 1463 } 1464 MAX-ACCESS read-only 1465 STATUS current 1466 DESCRIPTION 1467 "The current operational state of the interface. The 1468 testing(3) state indicates that no operational packets can 1469 be passed. If ifAdminStatus is down(2) then ifOperStatus 1470 should be down(2). If ifAdminStatus is changed to up(1) 1471 then ifOperStatus should change to up(1) if the interface is 1472 ready to transmit and receive network traffic; it should 1473 change to dormant(5) if the interface is waiting for 1474 external actions (such as a serial line waiting for an 1475 incoming connection); it should remain in the down(2) state 1476 if and only if there is a fault that prevents it from going 1477 to the up(1) state; it should remain in the notPresent(6) 1478 state if the interface has missing (typically, hardware) 1479 components." 1480 ::= { ifEntry 8 } 1482 ifLastChange OBJECT-TYPE 1483 SYNTAX TimeTicks 1484 MAX-ACCESS read-only 1485 STATUS current 1486 DESCRIPTION 1487 "The value of sysUpTime at the time the interface entered 1488 its current operational state. If the current state was 1489 entered prior to the last re-initialization of the local 1490 network management subsystem, then this object contains a 1491 zero value." 1492 ::= { ifEntry 9 } 1494 ifInOctets OBJECT-TYPE 1495 SYNTAX Counter32 1496 MAX-ACCESS read-only 1497 STATUS current 1498 DESCRIPTION 1499 "The total number of octets received on the interface, 1500 including framing characters. 1502 Discontinuities in the value of this counter can occur at 1503 re-initialization of the management system, and at other 1504 times as indicated by the value of 1505 ifCounterDiscontinuityTime." 1506 ::= { ifEntry 10 } 1508 ifInUcastPkts OBJECT-TYPE 1509 SYNTAX Counter32 1510 MAX-ACCESS read-only 1511 STATUS current 1512 DESCRIPTION 1513 "The number of packets, delivered by this sub-layer to a 1514 higher (sub-)layer, which were not addressed to a multicast 1515 or broadcast address at this sub-layer. 1517 Discontinuities in the value of this counter can occur at 1518 re-initialization of the management system, and at other 1519 times as indicated by the value of 1520 ifCounterDiscontinuityTime." 1521 ::= { ifEntry 11 } 1523 ifInNUcastPkts OBJECT-TYPE 1524 SYNTAX Counter32 1525 MAX-ACCESS read-only 1526 STATUS deprecated 1527 DESCRIPTION 1528 "The number of packets, delivered by this sub-layer to a 1529 higher (sub-)layer, which were addressed to a multicast or 1530 broadcast address at this sub-layer. 1532 Discontinuities in the value of this counter can occur at 1533 re-initialization of the management system, and at other 1534 times as indicated by the value of 1535 ifCounterDiscontinuityTime. 1537 This object is deprecated in favour of ifInMulticastPkts and 1538 ifInBroadcastPkts." 1539 ::= { ifEntry 12 } 1541 ifInDiscards OBJECT-TYPE 1542 SYNTAX Counter32 1543 MAX-ACCESS read-only 1544 STATUS current 1545 DESCRIPTION 1546 "The number of inbound packets which were chosen to be 1547 discarded even though no errors had been detected to prevent 1548 their being deliverable to a higher-layer protocol. One 1549 possible reason for discarding such a packet could be to 1550 free up buffer space. 1552 Discontinuities in the value of this counter can occur at 1553 re-initialization of the management system, and at other 1554 times as indicated by the value of 1555 ifCounterDiscontinuityTime." 1556 ::= { ifEntry 13 } 1558 ifInErrors OBJECT-TYPE 1559 SYNTAX Counter32 1560 MAX-ACCESS read-only 1561 STATUS current 1562 DESCRIPTION 1563 "For packet-oriented interfaces, the number of inbound 1564 packets that contained errors preventing them from being 1565 deliverable to a higher-layer protocol. For character- 1566 oriented or fixed-length interfaces, the number of inbound 1567 transmission units that contained errors preventing them 1568 from being deliverable to a higher-layer protocol. 1570 Discontinuities in the value of this counter can occur at 1571 re-initialization of the management system, and at other 1572 times as indicated by the value of 1573 ifCounterDiscontinuityTime." 1574 ::= { ifEntry 14 } 1576 ifInUnknownProtos OBJECT-TYPE 1577 SYNTAX Counter32 1578 MAX-ACCESS read-only 1579 STATUS current 1580 DESCRIPTION 1581 "For packet-oriented interfaces, the number of packets 1582 received via the interface which were discarded because of 1583 an unknown or unsupported protocol. For character-oriented 1584 or fixed-length interfaces that support protocol 1585 multiplexing the number of transmission units received via 1586 the interface which were discarded because of an unknown or 1587 unsupported protocol. For any interface that does not 1588 support protocol multiplexing, this counter will always be 1589 0. 1591 Discontinuities in the value of this counter can occur at 1592 re-initialization of the management system, and at other 1593 times as indicated by the value of 1594 ifCounterDiscontinuityTime." 1595 ::= { ifEntry 15 } 1597 ifOutOctets OBJECT-TYPE 1598 SYNTAX Counter32 1599 MAX-ACCESS read-only 1600 STATUS current 1601 DESCRIPTION 1602 "The total number of octets transmitted out of the 1603 interface, including framing characters. 1605 Discontinuities in the value of this counter can occur at 1606 re-initialization of the management system, and at other 1607 times as indicated by the value of 1608 ifCounterDiscontinuityTime." 1609 ::= { ifEntry 16 } 1611 ifOutUcastPkts OBJECT-TYPE 1612 SYNTAX Counter32 1613 MAX-ACCESS read-only 1614 STATUS current 1615 DESCRIPTION 1616 "The total number of packets that higher-level protocols 1617 requested be transmitted, and which were not addressed to a 1618 multicast or broadcast address at this sub-layer, including 1619 those that were discarded or not sent. 1621 Discontinuities in the value of this counter can occur at 1622 re-initialization of the management system, and at other 1623 times as indicated by the value of 1624 ifCounterDiscontinuityTime." 1625 ::= { ifEntry 17 } 1627 ifOutNUcastPkts OBJECT-TYPE 1628 SYNTAX Counter32 1629 MAX-ACCESS read-only 1630 STATUS deprecated 1631 DESCRIPTION 1632 "The total number of packets that higher-level protocols 1633 requested be transmitted, and which were addressed to a 1634 multicast or broadcast address at this sub-layer, including 1635 those that were discarded or not sent. 1637 Discontinuities in the value of this counter can occur at 1638 re-initialization of the management system, and at other 1639 times as indicated by the value of 1640 ifCounterDiscontinuityTime. 1642 This object is deprecated in favour of ifOutMulticastPkts 1643 and ifOutBroadcastPkts." 1644 ::= { ifEntry 18 } 1646 ifOutDiscards OBJECT-TYPE 1647 SYNTAX Counter32 1648 MAX-ACCESS read-only 1649 STATUS current 1650 DESCRIPTION 1651 "The number of outbound packets which were chosen to be 1652 discarded even though no errors had been detected to prevent 1653 their being transmitted. One possible reason for discarding 1654 such a packet could be to free up buffer space. 1656 Discontinuities in the value of this counter can occur at 1657 re-initialization of the management system, and at other 1658 times as indicated by the value of 1659 ifCounterDiscontinuityTime." 1660 ::= { ifEntry 19 } 1662 ifOutErrors OBJECT-TYPE 1663 SYNTAX Counter32 1664 MAX-ACCESS read-only 1665 STATUS current 1666 DESCRIPTION 1667 "For packet-oriented interfaces, the number of outbound 1668 packets that could not be transmitted because of errors. 1669 For character-oriented or fixed-length interfaces, the 1670 number of outbound transmission units that could not be 1671 transmitted because of errors. 1673 Discontinuities in the value of this counter can occur at 1674 re-initialization of the management system, and at other 1675 times as indicated by the value of 1676 ifCounterDiscontinuityTime." 1677 ::= { ifEntry 20 } 1679 ifOutQLen OBJECT-TYPE 1680 SYNTAX Gauge32 1681 MAX-ACCESS read-only 1682 STATUS deprecated 1683 DESCRIPTION 1684 "The length of the output packet queue (in packets)." 1685 ::= { ifEntry 21 } 1687 ifSpecific OBJECT-TYPE 1688 SYNTAX OBJECT IDENTIFIER 1689 MAX-ACCESS read-only 1690 STATUS deprecated 1691 DESCRIPTION 1692 "A reference to MIB definitions specific to the particular 1693 media being used to realize the interface. It is 1694 recommended that this value point to an instance of a MIB 1695 object in the media-specific MIB, i.e., that this object 1696 have the semantics associated with the InstancePointer 1697 textual convention defined in RFC 2579. In fact, it is 1698 recommended that the media-specific MIB specify what value 1699 ifSpecific should/can take for values of ifType. If no MIB 1700 definitions specific to the particular media are available, 1701 the value should be set to the OBJECT IDENTIFIER { 0 0 }." 1702 ::= { ifEntry 22 } 1704 -- 1705 -- Extension to the interface table 1706 -- 1707 -- This table replaces the ifExtnsTable table. 1708 -- 1710 ifXTable OBJECT-TYPE 1711 SYNTAX SEQUENCE OF IfXEntry 1712 MAX-ACCESS not-accessible 1713 STATUS current 1714 DESCRIPTION 1715 "A list of interface entries. The number of entries is 1716 given by the value of ifNumber. This table contains 1717 additional objects for the interface table." 1718 ::= { ifMIBObjects 1 } 1720 ifXEntry OBJECT-TYPE 1721 SYNTAX IfXEntry 1722 MAX-ACCESS not-accessible 1723 STATUS current 1724 DESCRIPTION 1725 "An entry containing additional management information 1726 applicable to a particular interface." 1727 AUGMENTS { ifEntry } 1728 ::= { ifXTable 1 } 1730 IfXEntry ::= 1731 SEQUENCE { 1732 ifName DisplayString, 1733 ifInMulticastPkts Counter32, 1734 ifInBroadcastPkts Counter32, 1735 ifOutMulticastPkts Counter32, 1736 ifOutBroadcastPkts Counter32, 1737 ifHCInOctets Counter64, 1738 ifHCInUcastPkts Counter64, 1739 ifHCInMulticastPkts Counter64, 1740 ifHCInBroadcastPkts Counter64, 1741 ifHCOutOctets Counter64, 1742 ifHCOutUcastPkts Counter64, 1743 ifHCOutMulticastPkts Counter64, 1744 ifHCOutBroadcastPkts Counter64, 1745 ifLinkUpDownTrapEnable INTEGER, 1746 ifHighSpeed Gauge32, 1747 ifPromiscuousMode TruthValue, 1748 ifConnectorPresent TruthValue, 1749 ifAlias DisplayString, 1750 ifCounterDiscontinuityTime TimeStamp 1751 } 1753 ifName OBJECT-TYPE 1754 SYNTAX DisplayString 1755 MAX-ACCESS read-only 1756 STATUS current 1757 DESCRIPTION 1758 "The textual name of the interface. The value of this 1759 object should be the name of the interface as assigned by 1760 the local device and should be suitable for use in commands 1761 entered at the device's `console'. This might be a text 1762 name, such as `le0' or a simple port number, such as `1', 1763 depending on the interface naming syntax of the device. If 1764 several entries in the ifTable together represent a single 1765 interface as named by the device, then each will have the 1766 same value of ifName. Note that for an agent which responds 1767 to SNMP queries concerning an interface on some other 1768 (proxied) device, then the value of ifName for such an 1769 interface is the proxied device's local name for it. 1771 If there is no local name, or this object is otherwise not 1772 applicable, then this object contains a zero-length string." 1773 ::= { ifXEntry 1 } 1775 ifInMulticastPkts OBJECT-TYPE 1776 SYNTAX Counter32 1777 MAX-ACCESS read-only 1778 STATUS current 1779 DESCRIPTION 1780 "The number of packets, delivered by this sub-layer to a 1781 higher (sub-)layer, which were addressed to a multicast 1782 address at this sub-layer. For a MAC layer protocol, this 1783 includes both Group and Functional addresses. 1785 Discontinuities in the value of this counter can occur at 1786 re-initialization of the management system, and at other 1787 times as indicated by the value of 1788 ifCounterDiscontinuityTime." 1789 ::= { ifXEntry 2 } 1791 ifInBroadcastPkts OBJECT-TYPE 1792 SYNTAX Counter32 1793 MAX-ACCESS read-only 1794 STATUS current 1795 DESCRIPTION 1796 "The number of packets, delivered by this sub-layer to a 1797 higher (sub-)layer, which were addressed to a broadcast 1798 address at this sub-layer. 1800 Discontinuities in the value of this counter can occur at 1801 re-initialization of the management system, and at other 1802 times as indicated by the value of 1803 ifCounterDiscontinuityTime." 1804 ::= { ifXEntry 3 } 1806 ifOutMulticastPkts OBJECT-TYPE 1807 SYNTAX Counter32 1808 MAX-ACCESS read-only 1809 STATUS current 1810 DESCRIPTION 1811 "The total number of packets that higher-level protocols 1812 requested be transmitted, and which were addressed to a 1813 multicast address at this sub-layer, including those that 1814 were discarded or not sent. For a MAC layer protocol, this 1815 includes both Group and Functional addresses. 1817 Discontinuities in the value of this counter can occur at 1818 re-initialization of the management system, and at other 1819 times as indicated by the value of 1820 ifCounterDiscontinuityTime." 1821 ::= { ifXEntry 4 } 1823 ifOutBroadcastPkts OBJECT-TYPE 1824 SYNTAX Counter32 1825 MAX-ACCESS read-only 1826 STATUS current 1827 DESCRIPTION 1828 "The total number of packets that higher-level protocols 1829 requested be transmitted, and which were addressed to a 1830 broadcast address at this sub-layer, including those that 1831 were discarded or not sent. 1833 Discontinuities in the value of this counter can occur at 1834 re-initialization of the management system, and at other 1835 times as indicated by the value of 1836 ifCounterDiscontinuityTime." 1837 ::= { ifXEntry 5 } 1839 -- 1840 -- High Capacity Counter objects. These objects are all 1841 -- 64 bit versions of the "basic" ifTable counters. These 1842 -- objects all have the same basic semantics as their 32-bit 1843 -- counterparts, however, their syntax has been extended 1844 -- to 64 bits. 1845 -- 1847 ifHCInOctets OBJECT-TYPE 1848 SYNTAX Counter64 1849 MAX-ACCESS read-only 1850 STATUS current 1851 DESCRIPTION 1852 "The total number of octets received on the interface, 1853 including framing characters. This object is a 64-bit 1854 version of ifInOctets. 1856 Discontinuities in the value of this counter can occur at 1857 re-initialization of the management system, and at other 1858 times as indicated by the value of 1859 ifCounterDiscontinuityTime." 1860 ::= { ifXEntry 6 } 1862 ifHCInUcastPkts OBJECT-TYPE 1863 SYNTAX Counter64 1864 MAX-ACCESS read-only 1865 STATUS current 1866 DESCRIPTION 1867 "The number of packets, delivered by this sub-layer to a 1868 higher (sub-)layer, which were not addressed to a multicast 1869 or broadcast address at this sub-layer. This object is a 1870 64-bit version of ifInUcastPkts. 1872 Discontinuities in the value of this counter can occur at 1873 re-initialization of the management system, and at other 1874 times as indicated by the value of 1875 ifCounterDiscontinuityTime." 1876 ::= { ifXEntry 7 } 1878 ifHCInMulticastPkts OBJECT-TYPE 1879 SYNTAX Counter64 1880 MAX-ACCESS read-only 1881 STATUS current 1882 DESCRIPTION 1883 "The number of packets, delivered by this sub-layer to a 1884 higher (sub-)layer, which were addressed to a multicast 1885 address at this sub-layer. For a MAC layer protocol, this 1886 includes both Group and Functional addresses. This object 1887 is a 64-bit version of ifInMulticastPkts. 1889 Discontinuities in the value of this counter can occur at 1890 re-initialization of the management system, and at other 1891 times as indicated by the value of 1892 ifCounterDiscontinuityTime." 1893 ::= { ifXEntry 8 } 1895 ifHCInBroadcastPkts OBJECT-TYPE 1896 SYNTAX Counter64 1897 MAX-ACCESS read-only 1898 STATUS current 1899 DESCRIPTION 1900 "The number of packets, delivered by this sub-layer to a 1901 higher (sub-)layer, which were addressed to a broadcast 1902 address at this sub-layer. This object is a 64-bit version 1903 of ifInBroadcastPkts. 1905 Discontinuities in the value of this counter can occur at 1906 re-initialization of the management system, and at other 1907 times as indicated by the value of 1908 ifCounterDiscontinuityTime." 1909 ::= { ifXEntry 9 } 1911 ifHCOutOctets OBJECT-TYPE 1912 SYNTAX Counter64 1913 MAX-ACCESS read-only 1914 STATUS current 1915 DESCRIPTION 1916 "The total number of octets transmitted out of the 1917 interface, including framing characters. This object is a 1918 64-bit version of ifOutOctets. 1920 Discontinuities in the value of this counter can occur at 1921 re-initialization of the management system, and at other 1922 times as indicated by the value of 1923 ifCounterDiscontinuityTime." 1924 ::= { ifXEntry 10 } 1926 ifHCOutUcastPkts OBJECT-TYPE 1927 SYNTAX Counter64 1928 MAX-ACCESS read-only 1929 STATUS current 1930 DESCRIPTION 1931 "The total number of packets that higher-level protocols 1932 requested be transmitted, and which were not addressed to a 1933 multicast or broadcast address at this sub-layer, including 1934 those that were discarded or not sent. This object is a 1935 64-bit version of ifOutUcastPkts. 1937 Discontinuities in the value of this counter can occur at 1938 re-initialization of the management system, and at other 1939 times as indicated by the value of 1940 ifCounterDiscontinuityTime." 1941 ::= { ifXEntry 11 } 1943 ifHCOutMulticastPkts OBJECT-TYPE 1944 SYNTAX Counter64 1945 MAX-ACCESS read-only 1946 STATUS current 1947 DESCRIPTION 1948 "The total number of packets that higher-level protocols 1949 requested be transmitted, and which were addressed to a 1950 multicast address at this sub-layer, including those that 1951 were discarded or not sent. For a MAC layer protocol, this 1952 includes both Group and Functional addresses. This object 1953 is a 64-bit version of ifOutMulticastPkts. 1955 Discontinuities in the value of this counter can occur at 1956 re-initialization of the management system, and at other 1957 times as indicated by the value of 1958 ifCounterDiscontinuityTime." 1959 ::= { ifXEntry 12 } 1961 ifHCOutBroadcastPkts OBJECT-TYPE 1962 SYNTAX Counter64 1963 MAX-ACCESS read-only 1964 STATUS current 1965 DESCRIPTION 1966 "The total number of packets that higher-level protocols 1967 requested be transmitted, and which were addressed to a 1968 broadcast address at this sub-layer, including those that 1969 were discarded or not sent. This object is a 64-bit version 1970 of ifOutBroadcastPkts. 1972 Discontinuities in the value of this counter can occur at 1973 re-initialization of the management system, and at other 1974 times as indicated by the value of 1975 ifCounterDiscontinuityTime." 1976 ::= { ifXEntry 13 } 1978 ifLinkUpDownTrapEnable OBJECT-TYPE 1979 SYNTAX INTEGER { enabled(1), disabled(2) } 1980 MAX-ACCESS read-write 1981 STATUS current 1982 DESCRIPTION 1983 "Indicates whether linkUp/linkDown traps should be generated 1984 for this interface. 1986 By default, this object should have the value enabled(1) for 1987 interfaces which do not operate on 'top' of any other 1988 interface (as defined in the ifStackTable), and disabled(2) 1989 otherwise." 1990 ::= { ifXEntry 14 } 1992 ifHighSpeed OBJECT-TYPE 1993 SYNTAX Gauge32 1994 MAX-ACCESS read-only 1995 STATUS current 1996 DESCRIPTION 1997 "An estimate of the interface's current bandwidth in units 1998 of 1,000,000 bits per second. If this object reports a 1999 value of `n' then the speed of the interface is somewhere in 2000 the range of `n-500,000' to `n+499,999'. For interfaces 2001 which do not vary in bandwidth or for those where no 2002 accurate estimation can be made, this object should contain 2003 the nominal bandwidth. For a sub-layer which has no concept 2004 of bandwidth, this object should be zero." 2005 ::= { ifXEntry 15 } 2007 ifPromiscuousMode OBJECT-TYPE 2008 SYNTAX TruthValue 2009 MAX-ACCESS read-write 2010 STATUS current 2011 DESCRIPTION 2012 "This object has a value of false(2) if this interface only 2013 accepts packets/frames that are addressed to this station. 2014 This object has a value of true(1) when the station accepts 2015 all packets/frames transmitted on the media. The value 2016 true(1) is only legal on certain types of media. If legal, 2017 setting this object to a value of true(1) may require the 2018 interface to be reset before becoming effective. 2020 The value of ifPromiscuousMode does not affect the reception 2021 of broadcast and multicast packets/frames by the interface." 2022 ::= { ifXEntry 16 } 2024 ifConnectorPresent OBJECT-TYPE 2025 SYNTAX TruthValue 2026 MAX-ACCESS read-only 2027 STATUS current 2028 DESCRIPTION 2029 "This object has the value 'true(1)' if the interface 2030 sublayer has a physical connector and the value 'false(2)' 2031 otherwise." 2032 ::= { ifXEntry 17 } 2034 ifAlias OBJECT-TYPE 2035 SYNTAX DisplayString (SIZE(0..64)) 2036 MAX-ACCESS read-write 2037 STATUS current 2038 DESCRIPTION 2039 "This object is an 'alias' name for the interface as 2040 specified by a network manager, and provides a non-volatile 2041 'handle' for the interface. 2043 On the first instantiation of an interface, the value of 2044 ifAlias associated with that interface is the zero-length 2045 string. As and when a value is written into an instance of 2046 ifAlias through a network management set operation, then the 2047 agent must retain the supplied value in the ifAlias instance 2048 associated with the same interface for as long as that 2049 interface remains instantiated, including across all re- 2050 initializations/reboots of the network management system, 2051 including those which result in a change of the interface's 2052 ifIndex value. 2054 An example of the value which a network manager might store 2055 in this object for a WAN interface is the (Telco's) circuit 2056 number/identifier of the interface. 2058 Some agents may support write-access only for interfaces 2059 having particular values of ifType. An agent which supports 2060 write access to this object is required to keep the value in 2061 non-volatile storage, but it may limit the length of new 2062 values depending on how much storage is already occupied by 2063 the current values for other interfaces." 2064 ::= { ifXEntry 18 } 2066 ifCounterDiscontinuityTime OBJECT-TYPE 2067 SYNTAX TimeStamp 2068 MAX-ACCESS read-only 2069 STATUS current 2070 DESCRIPTION 2071 "The value of sysUpTime on the most recent occasion at which 2072 any one or more of this interface's counters suffered a 2073 discontinuity. The relevant counters are the specific 2074 instances associated with this interface of any Counter32 or 2075 Counter64 object contained in the ifTable or ifXTable. If 2076 no such discontinuities have occurred since the last re- 2077 initialization of the local management subsystem, then this 2078 object contains a zero value." 2079 ::= { ifXEntry 19 } 2081 -- The Interface Stack Group 2082 -- 2083 -- Implementation of this group is optional, but strongly recommended 2084 -- for all systems 2085 -- 2087 ifStackTable OBJECT-TYPE 2088 SYNTAX SEQUENCE OF IfStackEntry 2089 MAX-ACCESS not-accessible 2090 STATUS current 2091 DESCRIPTION 2092 "The table containing information on the relationships 2093 between the multiple sub-layers of network interfaces. In 2094 particular, it contains information on which sub-layers run 2095 'on top of' which other sub-layers, where each sub-layer 2096 corresponds to a conceptual row in the ifTable. For 2097 example, when the sub-layer with ifIndex value x runs over 2098 the sub-layer with ifIndex value y, then this table 2099 contains: 2101 ifStackStatus.x.y=active 2103 For each ifIndex value, I, which identifies an active 2104 interface, there are always at least two instantiated rows 2105 in this table associated with I. For one of these rows, I 2106 is the value of ifStackHigherLayer; for the other, I is the 2107 value of ifStackLowerLayer. (If I is not involved in 2108 multiplexing, then these are the only two rows associated 2109 with I.) 2111 For example, two rows exist even for an interface which has 2112 no others stacked on top or below it: 2114 ifStackStatus.0.x=active 2115 ifStackStatus.x.0=active " 2116 ::= { ifMIBObjects 2 } 2118 ifStackEntry OBJECT-TYPE 2119 SYNTAX IfStackEntry 2120 MAX-ACCESS not-accessible 2121 STATUS current 2122 DESCRIPTION 2123 "Information on a particular relationship between two sub- 2124 layers, specifying that one sub-layer runs on 'top' of the 2125 other sub-layer. Each sub-layer corresponds to a conceptual 2126 row in the ifTable." 2127 INDEX { ifStackHigherLayer, ifStackLowerLayer } 2128 ::= { ifStackTable 1 } 2130 IfStackEntry ::= 2131 SEQUENCE { 2132 ifStackHigherLayer InterfaceIndexOrZero, 2133 ifStackLowerLayer InterfaceIndexOrZero, 2134 ifStackStatus RowStatus 2135 } 2137 ifStackHigherLayer OBJECT-TYPE 2138 SYNTAX InterfaceIndexOrZero 2139 MAX-ACCESS not-accessible 2140 STATUS current 2141 DESCRIPTION 2142 "The value of ifIndex corresponding to the higher sub-layer 2143 of the relationship, i.e., the sub-layer which runs on 'top' 2144 of the sub-layer identified by the corresponding instance of 2145 ifStackLowerLayer. If there is no higher sub-layer (below 2146 the internetwork layer), then this object has the value 0." 2147 ::= { ifStackEntry 1 } 2149 ifStackLowerLayer OBJECT-TYPE 2150 SYNTAX InterfaceIndexOrZero 2151 MAX-ACCESS not-accessible 2152 STATUS current 2153 DESCRIPTION 2154 "The value of ifIndex corresponding to the lower sub-layer 2155 of the relationship, i.e., the sub-layer which runs 'below' 2156 the sub-layer identified by the corresponding instance of 2157 ifStackHigherLayer. If there is no lower sub-layer, then 2158 this object has the value 0." 2159 ::= { ifStackEntry 2 } 2161 ifStackStatus OBJECT-TYPE 2162 SYNTAX RowStatus 2163 MAX-ACCESS read-create 2164 STATUS current 2165 DESCRIPTION 2166 "The status of the relationship between two sub-layers. 2168 Changing the value of this object from 'active' to 2169 'notInService' or 'destroy' will likely have consequences up 2170 and down the interface stack. Thus, write access to this 2171 object is likely to be inappropriate for some types of 2172 interfaces, and many implementations will choose not to 2173 support write-access for any type of interface." 2174 ::= { ifStackEntry 3 } 2176 ifStackLastChange OBJECT-TYPE 2177 SYNTAX TimeTicks 2178 MAX-ACCESS read-only 2179 STATUS current 2180 DESCRIPTION 2181 "The value of sysUpTime at the time of the last change of 2182 the (whole) interface stack. A change of the interface 2183 stack is defined to be any creation, deletion, or change in 2184 value of any instance of ifStackStatus. If the interface 2185 stack has been unchanged since the last re-initialization of 2186 the local network management subsystem, then this object 2187 contains a zero value." 2188 ::= { ifMIBObjects 6 } 2190 -- Generic Receive Address Table 2191 -- 2192 -- This group of objects is mandatory for all types of 2193 -- interfaces which can receive packets/frames addressed to 2194 -- more than one address. 2195 -- 2196 -- This table replaces the ifExtnsRcvAddr table. The main 2197 -- difference is that this table makes use of the RowStatus 2198 -- textual convention, while ifExtnsRcvAddr did not. 2200 ifRcvAddressTable OBJECT-TYPE 2201 SYNTAX SEQUENCE OF IfRcvAddressEntry 2202 MAX-ACCESS not-accessible 2203 STATUS current 2204 DESCRIPTION 2205 "This table contains an entry for each address (broadcast, 2206 multicast, or uni-cast) for which the system will receive 2207 packets/frames on a particular interface, except as follows: 2209 - for an interface operating in promiscuous mode, entries 2210 are only required for those addresses for which the system 2211 would receive frames were it not operating in promiscuous 2212 mode. 2214 - for 802.5 functional addresses, only one entry is 2215 required, for the address which has the functional address 2216 bit ANDed with the bit mask of all functional addresses for 2217 which the interface will accept frames. 2219 A system is normally able to use any unicast address which 2220 corresponds to an entry in this table as a source address." 2221 ::= { ifMIBObjects 4 } 2223 ifRcvAddressEntry OBJECT-TYPE 2224 SYNTAX IfRcvAddressEntry 2225 MAX-ACCESS not-accessible 2226 STATUS current 2227 DESCRIPTION 2228 "A list of objects identifying an address for which the 2229 system will accept packets/frames on the particular 2230 interface identified by the index value ifIndex." 2231 INDEX { ifIndex, ifRcvAddressAddress } 2232 ::= { ifRcvAddressTable 1 } 2234 IfRcvAddressEntry ::= 2235 SEQUENCE { 2236 ifRcvAddressAddress PhysAddress, 2237 ifRcvAddressStatus RowStatus, 2238 ifRcvAddressType INTEGER 2239 } 2241 ifRcvAddressAddress OBJECT-TYPE 2242 SYNTAX PhysAddress 2243 MAX-ACCESS not-accessible 2244 STATUS current 2245 DESCRIPTION 2246 "An address for which the system will accept packets/frames 2247 on this entry's interface." 2248 ::= { ifRcvAddressEntry 1 } 2250 ifRcvAddressStatus OBJECT-TYPE 2251 SYNTAX RowStatus 2252 MAX-ACCESS read-create 2253 STATUS current 2254 DESCRIPTION 2255 "This object is used to create and delete rows in the 2256 ifRcvAddressTable." 2258 ::= { ifRcvAddressEntry 2 } 2260 ifRcvAddressType OBJECT-TYPE 2261 SYNTAX INTEGER { 2262 other(1), 2263 volatile(2), 2264 nonVolatile(3) 2265 } 2267 MAX-ACCESS read-create 2268 STATUS current 2269 DESCRIPTION 2270 "This object has the value nonVolatile(3) for those entries 2271 in the table which are valid and will not be deleted by the 2272 next restart of the managed system. Entries having the 2273 value volatile(2) are valid and exist, but have not been 2274 saved, so that will not exist after the next restart of the 2275 managed system. Entries having the value other(1) are valid 2276 and exist but are not classified as to whether they will 2277 continue to exist after the next restart." 2279 DEFVAL { volatile } 2280 ::= { ifRcvAddressEntry 3 } 2282 -- definition of interface-related traps. 2284 linkDown NOTIFICATION-TYPE 2285 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2286 STATUS current 2287 DESCRIPTION 2288 "A linkDown trap signifies that the SNMP entity, acting in 2289 an agent role, has detected that the ifOperStatus object for 2290 one of its communication links is about to enter the down 2291 state from some other state (but not from the notPresent 2292 state). This other state is indicated by the included value 2293 of ifOperStatus." 2294 ::= { snmpTraps 3 } 2296 linkUp NOTIFICATION-TYPE 2297 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 2298 STATUS current 2299 DESCRIPTION 2300 "A linkUp trap signifies that the SNMP entity, acting in an 2301 agent role, has detected that the ifOperStatus object for 2302 one of its communication links left the down state and 2303 transitioned into some other state (but not into the 2304 notPresent state). This other state is indicated by the 2305 included value of ifOperStatus." 2306 ::= { snmpTraps 4 } 2308 -- conformance information 2310 ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 } 2312 ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 } 2313 ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 } 2315 -- compliance statements 2317 ifCompliance3 MODULE-COMPLIANCE 2318 STATUS current 2319 DESCRIPTION 2320 "The compliance statement for SNMP entities which have 2321 network interfaces." 2323 MODULE -- this module 2324 MANDATORY-GROUPS { ifGeneralInformationGroup, 2325 linkUpDownNotificationsGroup, 2326 ifCounterDiscontinuityGroup } 2328 -- The groups: 2329 -- ifFixedLengthGroup 2330 -- ifHCFixedLengthGroup 2331 -- ifPacketGroup 2332 -- ifHCPacketGroup 2333 -- ifVHCPacketGroup 2334 -- are mutually exclusive; at most one of these groups is implemented 2335 -- for a particular interface 2337 GROUP ifFixedLengthGroup 2338 DESCRIPTION 2339 "This group is mandatory for those network interfaces which 2340 are character-oriented or transmit data in fixed-length 2341 transmission units, and for which the value of the 2342 corresponding instance of ifSpeed is less than or equal to 2343 20,000,000 bits/second." 2345 GROUP ifHCFixedLengthGroup 2346 DESCRIPTION 2347 "This group is mandatory for those network interfaces which 2348 are character-oriented or transmit data in fixed-length 2349 transmission units, and for which the value of the 2350 corresponding instance of ifSpeed is greater than 20,000,000 2351 bits/second." 2353 GROUP ifPacketGroup 2354 DESCRIPTION 2355 "This group is mandatory for those network interfaces which 2356 are packet-oriented, and for which the value of the 2357 corresponding instance of ifSpeed is less than or equal to 2358 20,000,000 bits/second." 2360 GROUP ifHCPacketGroup 2361 DESCRIPTION 2362 "This group is mandatory only for those network interfaces 2363 which are packet-oriented and for which the value of the 2364 corresponding instance of ifSpeed is greater than 20,000,000 2365 bits/second but less than or equal to 650,000,000 2366 bits/second." 2368 GROUP ifVHCPacketGroup 2369 DESCRIPTION 2370 "This group is mandatory only for those network interfaces 2371 which are packet-oriented and for which the value of the 2372 corresponding instance of ifSpeed is greater than 2373 650,000,000 bits/second." 2375 GROUP ifRcvAddressGroup 2376 DESCRIPTION 2377 "The applicability of this group MUST be defined by the 2378 media-specific MIBs. Media-specific MIBs must define the 2379 exact meaning, use, and semantics of the addresses in this 2380 group." 2382 OBJECT ifLinkUpDownTrapEnable 2383 MIN-ACCESS read-only 2384 DESCRIPTION 2385 "Write access is not required." 2387 OBJECT ifPromiscuousMode 2388 MIN-ACCESS read-only 2389 DESCRIPTION 2390 "Write access is not required." 2392 OBJECT ifAdminStatus 2393 SYNTAX INTEGER { up(1), down(2) } 2394 MIN-ACCESS read-only 2395 DESCRIPTION 2396 "Write access is not required, nor is support for the value 2397 testing(3)." 2399 OBJECT ifAlias 2400 MIN-ACCESS read-only 2401 DESCRIPTION 2402 "Write access is not required." 2404 ::= { ifCompliances 3 } 2406 -- units of conformance 2408 ifGeneralInformationGroup OBJECT-GROUP 2409 OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress, 2410 ifAdminStatus, ifOperStatus, ifLastChange, 2411 ifLinkUpDownTrapEnable, ifConnectorPresent, 2412 ifHighSpeed, ifName, ifNumber, ifAlias, 2413 ifTableLastChange } 2414 STATUS current 2415 DESCRIPTION 2416 "A collection of objects providing information applicable to 2417 all network interfaces." 2418 ::= { ifGroups 10 } 2420 -- the following five groups are mutually exclusive; at most 2421 -- one of these groups is implemented for any interface 2423 ifFixedLengthGroup OBJECT-GROUP 2424 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2425 ifInErrors, ifOutErrors } 2426 STATUS current 2427 DESCRIPTION 2428 "A collection of objects providing information specific to 2429 non-high speed (non-high speed interfaces transmit and 2430 receive at speeds less than or equal to 20,000,000 2431 bits/second) character-oriented or fixed-length-transmission 2432 network interfaces." 2433 ::= { ifGroups 2 } 2435 ifHCFixedLengthGroup OBJECT-GROUP 2436 OBJECTS { ifHCInOctets, ifHCOutOctets, 2437 ifInOctets, ifOutOctets, ifInUnknownProtos, 2438 ifInErrors, ifOutErrors } 2439 STATUS current 2440 DESCRIPTION 2441 "A collection of objects providing information specific to 2442 high speed (greater than 20,000,000 bits/second) character- 2443 oriented or fixed-length-transmission network interfaces." 2444 ::= { ifGroups 3 } 2446 ifPacketGroup OBJECT-GROUP 2447 OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, 2448 ifInErrors, ifOutErrors, 2449 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2450 ifInBroadcastPkts, ifInDiscards, 2451 ifOutUcastPkts, ifOutMulticastPkts, 2452 ifOutBroadcastPkts, ifOutDiscards, 2453 ifPromiscuousMode } 2454 STATUS current 2455 DESCRIPTION 2456 "A collection of objects providing information specific to 2457 non-high speed (non-high speed interfaces transmit and 2458 receive at speeds less than or equal to 20,000,000 2459 bits/second) packet-oriented network interfaces." 2460 ::= { ifGroups 4 } 2462 ifHCPacketGroup OBJECT-GROUP 2463 OBJECTS { ifHCInOctets, ifHCOutOctets, 2464 ifInOctets, ifOutOctets, ifInUnknownProtos, 2465 ifInErrors, ifOutErrors, 2466 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2467 ifInBroadcastPkts, ifInDiscards, 2468 ifOutUcastPkts, ifOutMulticastPkts, 2469 ifOutBroadcastPkts, ifOutDiscards, 2470 ifPromiscuousMode } 2471 STATUS current 2472 DESCRIPTION 2473 "A collection of objects providing information specific to 2474 high speed (greater than 20,000,000 bits/second but less 2475 than or equal to 650,000,000 bits/second) packet-oriented 2476 network interfaces." 2477 ::= { ifGroups 5 } 2479 ifVHCPacketGroup OBJECT-GROUP 2480 OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, 2481 ifHCInBroadcastPkts, ifHCOutUcastPkts, 2482 ifHCOutMulticastPkts, ifHCOutBroadcastPkts, 2483 ifHCInOctets, ifHCOutOctets, 2484 ifInOctets, ifOutOctets, ifInUnknownProtos, 2485 ifInErrors, ifOutErrors, 2486 ifMtu, ifInUcastPkts, ifInMulticastPkts, 2487 ifInBroadcastPkts, ifInDiscards, 2488 ifOutUcastPkts, ifOutMulticastPkts, 2489 ifOutBroadcastPkts, ifOutDiscards, 2490 ifPromiscuousMode } 2491 STATUS current 2492 DESCRIPTION 2493 "A collection of objects providing information specific to 2494 higher speed (greater than 650,000,000 bits/second) packet- 2495 oriented network interfaces." 2497 ::= { ifGroups 6 } 2499 ifRcvAddressGroup OBJECT-GROUP 2500 OBJECTS { ifRcvAddressStatus, ifRcvAddressType } 2501 STATUS current 2502 DESCRIPTION 2503 "A collection of objects providing information on the 2504 multiple addresses which an interface receives." 2505 ::= { ifGroups 7 } 2507 ifStackGroup2 OBJECT-GROUP 2508 OBJECTS { ifStackStatus, ifStackLastChange } 2509 STATUS current 2510 DESCRIPTION 2511 "A collection of objects providing information on the 2512 layering of MIB-II interfaces." 2513 ::= { ifGroups 11 } 2515 ifCounterDiscontinuityGroup OBJECT-GROUP 2516 OBJECTS { ifCounterDiscontinuityTime } 2517 STATUS current 2518 DESCRIPTION 2519 "A collection of objects providing information specific to 2520 interface counter discontinuities." 2521 ::= { ifGroups 13 } 2523 linkUpDownNotificationsGroup NOTIFICATION-GROUP 2524 NOTIFICATIONS { linkUp, linkDown } 2525 STATUS current 2526 DESCRIPTION 2527 "The notifications which indicate specific changes in the 2528 value of ifOperStatus." 2529 ::= { ifGroups 14 } 2531 -- Deprecated Definitions - Objects 2533 -- 2534 -- The Interface Test Table 2535 -- 2536 -- This group of objects is optional. However, a media-specific 2537 -- MIB may make implementation of this group mandatory. 2538 -- 2539 -- This table replaces the ifExtnsTestTable 2540 -- 2542 ifTestTable OBJECT-TYPE 2543 SYNTAX SEQUENCE OF IfTestEntry 2544 MAX-ACCESS not-accessible 2545 STATUS deprecated 2546 DESCRIPTION 2547 "This table contains one entry per interface. It defines 2548 objects which allow a network manager to instruct an agent 2549 to test an interface for various faults. Tests for an 2550 interface are defined in the media-specific MIB for that 2551 interface. After invoking a test, the object ifTestResult 2552 can be read to determine the outcome. If an agent can not 2553 perform the test, ifTestResult is set to so indicate. The 2554 object ifTestCode can be used to provide further test- 2555 specific or interface-specific (or even enterprise-specific) 2556 information concerning the outcome of the test. Only one 2557 test can be in progress on each interface at any one time. 2558 If one test is in progress when another test is invoked, the 2559 second test is rejected. Some agents may reject a test when 2560 a prior test is active on another interface. 2562 Before starting a test, a manager-station must first obtain 2563 'ownership' of the entry in the ifTestTable for the 2564 interface to be tested. This is accomplished with the 2565 ifTestId and ifTestStatus objects as follows: 2567 try_again: 2568 get (ifTestId, ifTestStatus) 2569 while (ifTestStatus != notInUse) 2570 /* 2571 * Loop while a test is running or some other 2572 * manager is configuring a test. 2573 */ 2574 short delay 2575 get (ifTestId, ifTestStatus) 2576 } 2578 /* 2579 * Is not being used right now -- let's compete 2580 * to see who gets it. 2581 */ 2582 lock_value = ifTestId 2584 if ( set(ifTestId = lock_value, ifTestStatus = inUse, 2585 ifTestOwner = 'my-IP-address') == FAILURE) 2586 /* 2587 * Another manager got the ifTestEntry -- go 2588 * try again 2589 */ 2590 goto try_again; 2592 /* 2593 * I have the lock 2594 */ 2595 set up any test parameters. 2597 /* 2598 * This starts the test 2599 */ 2600 set(ifTestType = test_to_run); 2602 wait for test completion by polling ifTestResult 2604 when test completes, agent sets ifTestResult 2605 agent also sets ifTestStatus = 'notInUse' 2607 retrieve any additional test results, and ifTestId 2609 if (ifTestId == lock_value+1) results are valid 2611 A manager station first retrieves the value of the 2612 appropriate ifTestId and ifTestStatus objects, periodically 2613 repeating the retrieval if necessary, until the value of 2614 ifTestStatus is 'notInUse'. The manager station then tries 2615 to set the same ifTestId object to the value it just 2616 retrieved, the same ifTestStatus object to 'inUse', and the 2617 corresponding ifTestOwner object to a value indicating 2618 itself. If the set operation succeeds then the manager has 2619 obtained ownership of the ifTestEntry, and the value of the 2620 ifTestId object is incremented by the agent (per the 2621 semantics of TestAndIncr). Failure of the set operation 2622 indicates that some other manager has obtained ownership of 2623 the ifTestEntry. 2625 Once ownership is obtained, any test parameters can be 2626 setup, and then the test is initiated by setting ifTestType. 2627 On completion of the test, the agent sets ifTestStatus to 2628 'notInUse'. Once this occurs, the manager can retrieve the 2629 results. In the (rare) event that the invocation of tests 2630 by two network managers were to overlap, then there would be 2631 a possibility that the first test's results might be 2632 overwritten by the second test's results prior to the first 2633 results being read. This unlikely circumstance can be 2634 detected by a network manager retrieving ifTestId at the 2635 same time as retrieving the test results, and ensuring that 2636 the results are for the desired request. 2638 If ifTestType is not set within an abnormally long period of 2639 time after ownership is obtained, the agent should time-out 2640 the manager, and reset the value of the ifTestStatus object 2641 back to 'notInUse'. It is suggested that this time-out 2642 period be 5 minutes. 2644 In general, a management station must not retransmit a 2645 request to invoke a test for which it does not receive a 2646 response; instead, it properly inspects an agent's MIB to 2647 determine if the invocation was successful. Only if the 2648 invocation was unsuccessful, is the invocation request 2649 retransmitted. 2651 Some tests may require the interface to be taken off-line in 2652 order to execute them, or may even require the agent to 2653 reboot after completion of the test. In these 2654 circumstances, communication with the management station 2655 invoking the test may be lost until after completion of the 2656 test. An agent is not required to support such tests. 2657 However, if such tests are supported, then the agent should 2658 make every effort to transmit a response to the request 2659 which invoked the test prior to losing communication. When 2660 the agent is restored to normal service, the results of the 2661 test are properly made available in the appropriate objects. 2662 Note that this requires that the ifIndex value assigned to 2663 an interface must be unchanged even if the test causes a 2664 reboot. An agent must reject any test for which it cannot, 2665 perhaps due to resource constraints, make available at least 2666 the minimum amount of information after that test 2667 completes." 2668 ::= { ifMIBObjects 3 } 2670 ifTestEntry OBJECT-TYPE 2671 SYNTAX IfTestEntry 2672 MAX-ACCESS not-accessible 2673 STATUS deprecated 2674 DESCRIPTION 2675 "An entry containing objects for invoking tests on an 2676 interface." 2677 AUGMENTS { ifEntry } 2678 ::= { ifTestTable 1 } 2680 IfTestEntry ::= 2681 SEQUENCE { 2682 ifTestId TestAndIncr, 2683 ifTestStatus INTEGER, 2684 ifTestType AutonomousType, 2685 ifTestResult INTEGER, 2686 ifTestCode OBJECT IDENTIFIER, 2687 ifTestOwner OwnerString 2688 } 2690 ifTestId OBJECT-TYPE 2691 SYNTAX TestAndIncr 2692 MAX-ACCESS read-write 2693 STATUS deprecated 2694 DESCRIPTION 2695 "This object identifies the current invocation of the 2696 interface's test." 2697 ::= { ifTestEntry 1 } 2699 ifTestStatus OBJECT-TYPE 2700 SYNTAX INTEGER { notInUse(1), inUse(2) } 2701 MAX-ACCESS read-write 2702 STATUS deprecated 2703 DESCRIPTION 2704 "This object indicates whether or not some manager currently 2705 has the necessary 'ownership' required to invoke a test on 2706 this interface. A write to this object is only successful 2707 when it changes its value from 'notInUse(1)' to 'inUse(2)'. 2708 After completion of a test, the agent resets the value back 2709 to 'notInUse(1)'." 2711 ::= { ifTestEntry 2 } 2713 ifTestType OBJECT-TYPE 2714 SYNTAX AutonomousType 2715 MAX-ACCESS read-write 2716 STATUS deprecated 2717 DESCRIPTION 2718 "A control variable used to start and stop operator- 2719 initiated interface tests. Most OBJECT IDENTIFIER values 2720 assigned to tests are defined elsewhere, in association with 2721 specific types of interface. However, this document assigns 2722 a value for a full-duplex loopback test, and defines the 2723 special meanings of the subject identifier: 2725 noTest OBJECT IDENTIFIER ::= { 0 0 } 2727 When the value noTest is written to this object, no action 2728 is taken unless a test is in progress, in which case the 2729 test is aborted. Writing any other value to this object is 2730 only valid when no test is currently in progress, in which 2731 case the indicated test is initiated. 2733 When read, this object always returns the most recent value 2734 that ifTestType was set to. If it has not been set since 2735 the last initialization of the network management subsystem 2736 on the agent, a value of noTest is returned." 2737 ::= { ifTestEntry 3 } 2739 ifTestResult OBJECT-TYPE 2740 SYNTAX INTEGER { 2741 none(1), -- no test yet requested 2742 success(2), 2743 inProgress(3), 2744 notSupported(4), 2745 unAbleToRun(5), -- due to state of system 2746 aborted(6), 2747 failed(7) 2748 } 2749 MAX-ACCESS read-only 2750 STATUS deprecated 2751 DESCRIPTION 2752 "This object contains the result of the most recently 2753 requested test, or the value none(1) if no tests have been 2754 requested since the last reset. Note that this facility 2755 provides no provision for saving the results of one test 2756 when starting another, as could be required if used by 2757 multiple managers concurrently." 2758 ::= { ifTestEntry 4 } 2760 ifTestCode OBJECT-TYPE 2761 SYNTAX OBJECT IDENTIFIER 2762 MAX-ACCESS read-only 2763 STATUS deprecated 2764 DESCRIPTION 2765 "This object contains a code which contains more specific 2766 information on the test result, for example an error-code 2767 after a failed test. Error codes and other values this 2768 object may take are specific to the type of interface and/or 2769 test. The value may have the semantics of either the 2770 AutonomousType or InstancePointer textual conventions as 2771 defined in RFC 2579. The identifier: 2773 testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } 2775 is defined for use if no additional result code is 2776 available." 2777 ::= { ifTestEntry 5 } 2779 ifTestOwner OBJECT-TYPE 2780 SYNTAX OwnerString 2781 MAX-ACCESS read-write 2782 STATUS deprecated 2783 DESCRIPTION 2784 "The entity which currently has the 'ownership' required to 2785 invoke a test on this interface." 2786 ::= { ifTestEntry 6 } 2788 -- Deprecated Definitions - Groups 2790 ifGeneralGroup OBJECT-GROUP 2791 OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress, 2792 ifAdminStatus, ifOperStatus, ifLastChange, 2793 ifLinkUpDownTrapEnable, ifConnectorPresent, 2794 ifHighSpeed, ifName } 2795 STATUS deprecated 2796 DESCRIPTION 2797 "A collection of objects deprecated in favour of 2798 ifGeneralInformationGroup." 2799 ::= { ifGroups 1 } 2801 ifTestGroup OBJECT-GROUP 2802 OBJECTS { ifTestId, ifTestStatus, ifTestType, 2803 ifTestResult, ifTestCode, ifTestOwner } 2804 STATUS deprecated 2805 DESCRIPTION 2806 "A collection of objects providing the ability to invoke 2807 tests on an interface." 2808 ::= { ifGroups 8 } 2810 ifStackGroup OBJECT-GROUP 2811 OBJECTS { ifStackStatus } 2812 STATUS deprecated 2813 DESCRIPTION 2814 "The previous collection of objects providing information on 2815 the layering of MIB-II interfaces." 2816 ::= { ifGroups 9 } 2818 ifOldObjectsGroup OBJECT-GROUP 2819 OBJECTS { ifInNUcastPkts, ifOutNUcastPkts, 2820 ifOutQLen, ifSpecific } 2821 STATUS deprecated 2822 DESCRIPTION 2823 "The collection of objects deprecated from the original MIB- 2824 II interfaces group." 2825 ::= { ifGroups 12 } 2827 -- Deprecated Definitions - Compliance 2829 ifCompliance MODULE-COMPLIANCE 2830 STATUS deprecated 2831 DESCRIPTION 2832 "A compliance statement defined in a previous version of 2833 this MIB module, for SNMP entities which have network 2834 interfaces." 2836 MODULE -- this module 2837 MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup } 2839 GROUP ifFixedLengthGroup 2840 DESCRIPTION 2841 "This group is mandatory for all network interfaces which 2842 are character-oriented or transmit data in fixed-length 2843 transmission units." 2845 GROUP ifHCFixedLengthGroup 2846 DESCRIPTION 2847 "This group is mandatory only for those network interfaces 2848 which are character-oriented or transmit data in fixed- 2849 length transmission units, and for which the value of the 2850 corresponding instance of ifSpeed is greater than 20,000,000 2851 bits/second." 2853 GROUP ifPacketGroup 2854 DESCRIPTION 2855 "This group is mandatory for all network interfaces which 2856 are packet-oriented." 2858 GROUP ifHCPacketGroup 2859 DESCRIPTION 2860 "This group is mandatory only for those network interfaces 2861 which are packet-oriented and for which the value of the 2862 corresponding instance of ifSpeed is greater than 2863 650,000,000 bits/second." 2865 GROUP ifTestGroup 2866 DESCRIPTION 2867 "This group is optional. Media-specific MIBs which require 2868 interface tests are strongly encouraged to use this group 2869 for invoking tests and reporting results. A medium specific 2870 MIB which has mandatory tests may make implementation of 2871 this group mandatory." 2873 GROUP ifRcvAddressGroup 2874 DESCRIPTION 2875 "The applicability of this group MUST be defined by the 2876 media-specific MIBs. Media-specific MIBs must define the 2877 exact meaning, use, and semantics of the addresses in this 2878 group." 2880 OBJECT ifLinkUpDownTrapEnable 2881 MIN-ACCESS read-only 2882 DESCRIPTION 2883 "Write access is not required." 2885 OBJECT ifPromiscuousMode 2886 MIN-ACCESS read-only 2887 DESCRIPTION 2888 "Write access is not required." 2890 OBJECT ifStackStatus 2891 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2892 MIN-ACCESS read-only 2893 DESCRIPTION 2894 "Write access is not required, and only one of the six 2895 enumerated values for the RowStatus textual convention need 2896 be supported, specifically: active(1)." 2898 OBJECT ifAdminStatus 2899 SYNTAX INTEGER { up(1), down(2) } 2900 MIN-ACCESS read-only 2901 DESCRIPTION 2902 "Write access is not required, nor is support for the value 2903 testing(3)." 2904 ::= { ifCompliances 1 } 2906 ifCompliance2 MODULE-COMPLIANCE 2907 STATUS deprecated 2908 DESCRIPTION 2909 "A compliance statement defined in a previous version of 2910 this MIB module, for SNMP entities which have network 2911 interfaces." 2913 MODULE -- this module 2914 MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2, 2915 ifCounterDiscontinuityGroup } 2917 GROUP ifFixedLengthGroup 2918 DESCRIPTION 2919 "This group is mandatory for all network interfaces which 2920 are character-oriented or transmit data in fixed-length 2921 transmission units." 2923 GROUP ifHCFixedLengthGroup 2924 DESCRIPTION 2925 "This group is mandatory only for those network interfaces 2926 which are character-oriented or transmit data in fixed- 2927 length transmission units, and for which the value of the 2928 corresponding instance of ifSpeed is greater than 20,000,000 2929 bits/second." 2931 GROUP ifPacketGroup 2932 DESCRIPTION 2933 "This group is mandatory for all network interfaces which 2934 are packet-oriented." 2936 GROUP ifHCPacketGroup 2937 DESCRIPTION 2938 "This group is mandatory only for those network interfaces 2939 which are packet-oriented and for which the value of the 2940 corresponding instance of ifSpeed is greater than 2941 650,000,000 bits/second." 2943 GROUP ifRcvAddressGroup 2944 DESCRIPTION 2945 "The applicability of this group MUST be defined by the 2946 media-specific MIBs. Media-specific MIBs must define the 2947 exact meaning, use, and semantics of the addresses in this 2948 group." 2950 OBJECT ifLinkUpDownTrapEnable 2951 MIN-ACCESS read-only 2952 DESCRIPTION 2953 "Write access is not required." 2955 OBJECT ifPromiscuousMode 2956 MIN-ACCESS read-only 2957 DESCRIPTION 2958 "Write access is not required." 2960 OBJECT ifStackStatus 2961 SYNTAX INTEGER { active(1) } -- subset of RowStatus 2962 MIN-ACCESS read-only 2963 DESCRIPTION 2964 "Write access is not required, and only one of the six 2965 enumerated values for the RowStatus textual convention need 2966 be supported, specifically: active(1)." 2968 OBJECT ifAdminStatus 2969 SYNTAX INTEGER { up(1), down(2) } 2970 MIN-ACCESS read-only 2971 DESCRIPTION 2972 "Write access is not required, nor is support for the value 2973 testing(3)." 2975 OBJECT ifAlias 2976 MIN-ACCESS read-only 2977 DESCRIPTION 2978 "Write access is not required." 2980 ::= { ifCompliances 2 } 2982 END 2983 7. Acknowledgements 2985 This memo has been produced by the IETF's Interfaces MIB working-group. 2987 The original proposal evolved from conversations and discussions with 2988 many people, including at least the following: Fred Baker, Ted Brunner, 2989 Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and Dean Throop. 2991 8. References 2993 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2994 Describing SNMP Management Frameworks", RFC 2571, Cabletron 2995 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 2996 1999. 2998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 2999 Management Information for TCP/IP-based Internets", STD 16, RFC 3000 1155, Performance Systems International, Hughes LAN Systems, May 3001 1990. 3003 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 3004 1212, Performance Systems International, Hughes LAN Systems, March 3005 1991. 3007 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 3008 RFC 1215, Performance Systems International, March 1991. 3010 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. 3011 and S. Waldbusser, "Structure of Management Information Version 2 3012 (SMIv2)", STD 58, RFC 2578, April 1999. 3014 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. 3015 and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 3016 2579, April 1999. 3018 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. 3019 and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 3020 2580, April 1999. 3022 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 3023 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 3024 Systems International, Performance Systems International, MIT 3025 Laboratory for Computer Science, May 1990. 3027 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 3028 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 3029 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 3030 Inc., International Network Services, January 1996. 3032 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 3033 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 3034 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco 3035 Systems, Inc., Dover Beach Consulting, Inc., International Network 3036 Services, January 1996. 3038 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 3039 Processing and Dispatching for the Simple Network Management 3040 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 3041 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 3043 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 3044 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3045 2574, IBM T. J. Watson Research, January 1998. 3047 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 3048 Waldbusser, "Protocol Operations for Version 2 of the Simple 3049 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 3050 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 3051 International Network Services, January 1996. 3053 [14] Levi, D., Meyer, P., and B. Stewart, "SMPv3 Applications", RFC 3054 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 3055 Systems, January 1998. 3057 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 3058 Control Model (VACM) for the Simple Network Management Protocol 3059 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 3060 Cisco Systems, Inc., January 1998. 3062 [16] S. Bradner, "Key words for use in RFCs to Indicate Requirements 3063 Levels", RFC 2119, Harvard University, March 1997. 3065 [17] McCloghrie, K., and M. Rose, "Management Information Base for 3066 Network Management of TCP/IP-based internets - MIB-II", RFC 1213, 3067 Hughes LAN Systems, Performance Systems International, March 1991. 3069 [18] J. Postel, "Internet Protocol", RFC 791, Information Sciences 3070 Institute, USC, September 1981. 3072 [19] K. McCloghrie, "Extensions to the Generic-Interface MIB", RFC 1229, 3073 Hughes LAN Systems, May 1991. 3075 [20] ATM Forum Technical Committee, "LAN Emulation Client Management: 3076 Version 1.0 Specification", af-lane-0044.000, ATM Forum, September 3077 1995. 3079 [21] B. Stewart, "Definitions of Managed Objects for Character Stream 3080 Devices using SMIv2", RFC 1658, Xyplex Inc., July 1994. 3082 [22] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to 3083 Version 3 of the Internet-standard Network Management Framework", 3084 RFC 2570, April 1999. 3086 9. Security Considerations 3088 There are a number of management objects defined in this MIB that have a 3089 MAX-ACCESS clause of read-write and/or read-create. Such objects may be 3090 considered sensitive or vulnerable in some network environments. The 3091 support for SET operations in a non-secure environment without proper 3092 protection can have a negative effect on network operations. 3094 In particular, write-able objects allow an administrator to control the 3095 interfaces and to perform tests on the interfaces, and unauthorized 3096 access to these could cause a denial of service, or in combination with 3097 other (e.g., physical) security breaches, could cause unauthorized 3098 connectivity to a device. 3100 SNMPv1 by itself is not a secure environment. Even if the network 3101 itself is secure (for example by using IPSec), even then, there is no 3102 control as to who on the secure network is allowed to access and GET/SET 3103 (read/change/create/delete) the objects in this MIB. 3105 It is recommended that the implementers consider the security features 3106 as provided by the SNMPv3 framework. Specifically, the use of the User- 3107 based Security Model RFC 2574 [12] and the View- based Access Control 3108 Model RFC 2575 [15] is recommended. 3110 It is then a customer/user responsibility to ensure that the SNMP entity 3111 giving access to an instance of this MIB, is properly configured to give 3112 access to the objects only to those principals (users) that have 3113 legitimate rights to indeed GET or SET (change/create/delete) them. 3115 10. Authors' Addresses 3117 Keith McCloghrie 3118 Cisco Systems, Inc. 3119 170 West Tasman Drive 3120 San Jose, CA 95134-1706 3122 Phone: 408-526-5260 3123 Email: kzm@cisco.com" 3125 Frank Kastenholz 3126 Argon Networks 3127 25 Porter Rd 3128 Littleton Ma 01460 3129 Phone: (508)685-4000 3130 Email: kasten@argon.com 3132 11. Changes from RFC 2233 3134 Added linkUpDownNotificationsGroup. 3136 Changed the status of the definition of OwnerString in this MIB to 3137 be deprecated, because it is only used by ifTestOwner, which is now 3138 deprecated, and because other MIBs should import OwnerString from 3139 RFC 1757 or its successors. 3141 Added ifCompliance3 as a replacement for ifCompliance2 to omit the 3142 ifStackGroup2 group, and add linkUpDownNotificationsGroup. Also, 3143 corrected the omission of ifVHCPacketGroup, and typos in the 3144 DESCRIPTIONs of ifHCPacketGroup and ifFixedLengthGroup. Obsoleted 3145 ifCompliance2. 3147 Modified syntax of ifStackHigherLayer and ifStackLowerLayer to be 3148 InterfaceIndexOrZero. 3150 Added requirement that media-specific MIB designers specify any 3151 special conditions concerning the counting of framing characters in 3152 ifInOctets and ifOutOctets. 3154 Corrected a typo in the DESCRIPTION of the linkUp notification. 3156 Modified the introductory SNMP Network Management Framework 3157 boilerplate text. 3159 12. Notice on Intellectual Property 3161 The IETF takes no position regarding the validity or scope of any 3162 intellectual property or other rights that might be claimed to pertain 3163 to the implementation or use of the technology described in this 3164 document or the extent to which any license under such rights might or 3165 might not be available; neither does it represent that it has made any 3166 effort to identify any such rights. Information on the IETF's 3167 procedures with respect to rights in standards-track and standards- 3168 related documentation can be found in BCP-11. Copies of claims of 3169 rights made available for publication and any assurances of licenses to 3170 be made available, or the result of an attempt made to obtain a general 3171 license or permission for the use of such proprietary rights by 3172 implementors or users of this specification can be obtained from the 3173 IETF Secretariat. 3175 The IETF invites any interested party to bring to its attention any 3176 copyrights, patents or patent applications, or other proprietary rights 3177 which may cover technology that may be required to practice this 3178 standard. Please address the information to the IETF Executive 3179 Director. 3181 13. Full Copyright Statement 3183 Copyright (C) The Internet Society (1999). All Rights Reserved. 3185 This document and translations of it may be copied and furnished to 3186 others, and derivative works that comment on or otherwise explain it or 3187 assist in its implmentation may be prepared, copied, published and 3188 distributed, in whole or in part, without restriction of any kind, 3189 provided that the above copyright notice and this paragraph are included 3190 on all such copies and derivative works. However, this document itself 3191 may not be modified in any way, such as by removing the copyright notice 3192 or references to the Internet Society or other Internet organizations, 3193 except as needed for the purpose of developing Internet standards in 3194 which case the procedures for copyrights defined in the Internet 3195 Standards process must be followed, or as required to translate it into 3196 languages other than English. 3198 The limited permissions granted above are perpetual and will not be 3199 revoked by the Internet Society or its successors or assigns. 3201 This document and the information contained herein is provided on an "AS 3202 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3203 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3204 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3205 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3206 FITNESS FOR A PARTICULAR PURPOSE." 3207 Table of Contents 3209 1 Introduction .................................................... 2 3210 2 The SNMP Network Management Framework ........................... 2 3211 3 Experience with the Interfaces Group ............................ 3 3212 3.1 Clarifications/Revisions ...................................... 4 3213 3.1.1 Interface Sub-Layers ........................................ 4 3214 3.1.2 Guidance on Defining Sub-layers ............................. 7 3215 3.1.3 Virtual Circuits ............................................ 8 3216 3.1.4 Bit, Character, and Fixed-Length Interfaces ................. 9 3217 3.1.5 Interface Numbering ......................................... 11 3218 3.1.6 Counter Size ................................................ 15 3219 3.1.7 Interface Speed ............................................. 17 3220 3.1.8 Multicast/Broadcast Counters ................................ 18 3221 3.1.9 Trap Enable ................................................. 19 3222 3.1.10 Addition of New ifType values .............................. 19 3223 3.1.11 InterfaceIndex Textual Convention .......................... 19 3224 3.1.12 New states for IfOperStatus ................................ 20 3225 3.1.13 IfAdminStatus and IfOperStatus ............................. 21 3226 3.1.14 IfOperStatus in an Interface Stack ......................... 22 3227 3.1.15 Traps ...................................................... 22 3228 3.1.16 ifSpecific ................................................. 24 3229 3.1.17 Creation/Deletion of Interfaces ............................ 24 3230 3.1.18 All Values Must be Known ................................... 25 3231 4 Media-Specific MIB Applicability ................................ 27 3232 5 Overview ........................................................ 28 3233 6 Interfaces Group Definitions .................................... 29 3234 7 Acknowledgements ................................................ 73 3235 8 References ...................................................... 73 3236 9 Security Considerations ......................................... 76 3237 10 Authors' Addresses ............................................. 76 3238 11 Changes from RFC 2233 .......................................... 78 3239 12 Notice on Intellectual Property ................................ 79 3240 13 Full Copyright Statement ....................................... 79