idnits 2.17.1 draft-ietf-entmib-v2-00.txt: ** The Abstract section seems to be numbered 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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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 4 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (05 August 1998) is 9389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** 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 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) ** Obsolete normative reference: RFC 2037 (ref. '16') (Obsoleted by RFC 2737) ** Obsolete normative reference: RFC 2233 (ref. '17') (Obsoleted by RFC 2863) Summary: 26 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Entity MIB Working Group Keith McCloghrie 3 Internet Draft Cisco Systems, Inc. 4 Andy Bierman 5 Cisco Systems, Inc. 6 05 August 1998 8 Entity MIB using SMIv2 (Version 2) 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 27 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 28 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. Please send comments to the 31 Entity MIB Working Group, . 33 1. Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 2. Abstract 39 This memo defines an experimental portion of the Management Information 40 Base (MIB) for use with network management protocols in the Internet 41 community. In particular, it describes managed objects used for 42 managing multiple logical and physical entities managed by a single SNMP 43 agent. 45 3. The SNMP Network Management Framework 47 The SNMP Management Framework presently consists of five major 48 components: 50 - An overall architecture, described in RFC 2271 [1]. 52 - Mechanisms for describing and naming objects and events for the 53 purpose of management. The first version of this Structure of 54 Management Information (SMI) is called SMIv1 and described in RFC 55 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called 56 SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. 58 - Message protocols for transferring management information. The 59 first version of the SNMP message protocol is called SNMPv1 and 60 described in RFC 1157 [8]. A second version of the SNMP message 61 protocol, which is not an Internet standards track protocol, is 62 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 63 The third version of the message protocol is called SNMPv3 and 64 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 66 - Protocol operations for accessing management information. The first 67 set of protocol operations and associated PDU formats is described 68 in RFC 1157 [8]. A second set of protocol operations and associated 69 PDU formats is described in RFC 1905 [13]. 71 - A set of fundamental applications described in RFC 2273 [14] and 72 the view-based access control mechanism described in RFC 2275 [15]. 74 Managed objects are accessed via a virtual information store, termed the 75 Management Information Base or MIB. Objects in the MIB are defined 76 using the mechanisms defined in the SMI. 78 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 79 conforming to the SMIv1 can be produced through the appropriate 80 translations. The resulting translated MIB must be semantically 81 equivalent, except where objects or events are omitted because no 82 information in SMIv2 will be converted into textual descriptions in 83 SMIv1 during the translation process. However, this loss of machine 84 readable information is not considered to change the semantics of the 85 MIB. 87 4. Overview 89 There is a need for a standardized way of representing a single agent 90 which supports multiple instances of one MIB. This is presently true 91 for at least 3 standard MIBs, and is likely to become true for more and 92 more MIBs as time passes. For example: 94 - multiple instances of a bridge supported within a single device 95 having ssa single agent; 97 - multiple repeaters supported by a single agent; 99 - multiple OSPF backbone areas, each one operating as part of its own 100 Autonomous System, and each identified by the same area-id (e.g., 101 0.0.0.0), supported inside a single router with one agent. 103 The fact that it is a single agent in each of these cases implies there 104 is some relationship which binds all of these entities together. 105 Effectively, there is some "overall" physical entity which houses the 106 sum of the things managed by that one agent, i.e., there are multiple 107 "logical" entities within a single physical entity. Sometimes, the 108 overall physical entity contains multiple (smaller) physical entities 109 and each logical entity is associated with a particular physical entity. 110 Sometimes, the overall physical entity is a "compound" of multiple 111 physical entities (e.g., a stack of stackable hubs). 113 What is needed is a way to determine exactly what logical entities are 114 managed by the agent (either by SNMPv1, SNMPv2C, or SNMPv3), and thereby 115 to be able to communicate with the agent about a particular logical 116 entity. When different logical entities are associated with different 117 physical entities within the overall physical entity, it is also useful 118 to be able to use this information to distinguish between logical 119 entities. 121 In these situations, there is no need for varbinds for multiple logical 122 entities to be referenced in the same SNMP message (although that might 123 be useful in the future). Rather, it is sufficient, and in some 124 situations preferable, to have the context/community in the message 125 identify the logical entity to which the varbinds apply. 127 Version 2 of this MIB addresses new requirements that have emerged since 128 the publication of the first Entity MIB (RFC 2037 [16]). There is a 129 need for a standardized way of providing non-volatile, administratively 130 assigned identifiers for physical components represented with the Entity 131 MIB. There is also a need to align the Entity MIB with the SNMPv3 132 administrative framework [1]. Implementation experience has shown that 133 additional physical component attributes are also needed. 135 4.1. Terms 137 Some new terms are used throughout this document: 139 - Naming Scope 140 A "naming scope" represents the set of information that may be 141 potentially accessed through a single SNMP operation. All instances 142 within the naming scope share the same unique identifier space. For 143 SNMPv1, a naming scope is identified by the value of the associated 144 'entLogicalCommunity' instance. For SNMPv3, the term 'context' is 145 used instead of 'naming scope'. The complete definition of an SNMP 146 context can be found in section 3.3.1 of RFC 2271 [1]. 148 - Multi-Scoped Object 149 A MIB object, for which identical instance values identify 150 different managed information in different naming scopes, is called 151 a "multi-scoped" MIB object. 153 - Single-Scoped Object 154 A MIB object, for which identical instance values identify the same 155 managed information in different naming scopes, is called a 156 "single-scoped" MIB object. 158 - Logical Entity 159 A managed system contains one or more logical entities, each 160 represented by at most one instantiation of each of a particular 161 set of MIB objects. A set of management functions is associated 162 with each logical entity. Examples of logical entities include 163 routers, bridges, print-servers, etc. 165 - Physical Entity 166 A "physical entity" or "physical component" represents an 167 identifiable physical resource within a managed system. Zero or 168 more logical entities may utilize a physical resource at any given 169 time. It is an implementation-specific manner as to which physical 170 components are represented by an agent in the EntPhysicalTable. 172 Typically, physical resources (e.g. communications ports, 173 backplanes, sensors, daughter-cards, power supplies, the overall 174 chassis) which can be managed via functions associated with one or 175 more logical entities are included in the MIB. 177 - Containment Tree 178 Each physical component may optionally be modeled as 'contained' 179 within another physical component. A "containment-tree" is the 180 conceptual sequence of entPhysicalIndex values which uniquely 181 specifies the exact physical location of a physical component 182 within the managed system. It is generated by 'following and 183 recording' each 'entPhysicalContainedIn' instance 'up the tree 184 towards the root', until a value of zero indicating no further 185 containment is found. 187 Note that chassis slots, which are capable of accepting one or more 188 module types from one or more vendors, are modeled as containers in 189 this MIB. The value of entPhysicalContainedIn for a particular 190 'module' entity (entPhysicalClass value of 'module(9)') must be 191 equal to an entPhysicalIndex that represents the parent 'container' 192 entity (associated entPhysicalClass value of ('container(5)'). An 193 agent must represent both empty and full containers in the 194 entPhysicalTable. 196 4.2. Relationship to Community Strings 198 For community-based SNMP, distinguishing between different logical 199 entities is one (but not the only) purpose of the community string [8]. 200 This is accommodated by representing each community string as a logical 201 entity. 203 Note that different logical entities may share the same naming scope 204 (and therefore the same values of entLogicalCommunity). This is 205 possible, providing they have no need for the same instance of a MIB 206 object to represent different managed information. 208 4.3. Relationship to SNMP Contexts 210 Version 2 of the Entity MIB contains support for associating SNMPv3 211 contexts with logical entities. Two new MIB objects, defining an 212 SnmpEngineID and ContextName pair, are used together to identify an SNMP 213 context associated with a logical entity. This context can be used, (in 214 conjunction with the entLogicalTAddress and entLogicalTDomain MIB 215 objects) to send SNMPv3 messages on behalf of a particular logical 216 entity. 218 4.4. Relationship to Proxy Mechanisms 220 The Entity MIB is designed to allow functional component discovery. The 221 administrative relationships between different logical entities are not 222 visible in any Entity MIB tables. An NMS cannot determine whether MIB 223 instances in different naming scopes are realized locally or remotely 224 (e.g. via some proxy mechanism) by examining any particular Entity MIB 225 objects. 227 The management of administrative framework functions is not an explicit 228 goal of the Entity MIB WG at this time. This new area of functionality 229 may be revisited after some operational experience with the Entity MIB 230 is gained. 232 Note that a network administrator will likely be able to associate 233 community strings with naming scopes with proprietary mechanisms, as a 234 matter of configuration. There are no mechanisms for managing naming 235 scopes defined in this MIB. 237 4.5. Relationship to a Chassis MIB 239 Some readers may recall that a previous IETF working group attempted to 240 define a Chassis MIB. No consensus was reached by that working group, 241 possibly because its scope was too broad. As such, it is not the 242 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 243 the scope of this MIB to contain all the information which might be 244 necessary to manage a "chassis". On the other hand, the entities 245 represented by an implementation of this MIB might well be contained in 246 a chassis. 248 4.6. Relationship to the Interfaces MIB 250 The Entity MIB contains a mapping table identifying physical components 251 that have 'external values' (e.g. ifIndex) associated with them within a 252 given naming scope. This table can be used to identify the physical 253 location of each interface in the ifTable [17]. Since ifIndex values in 254 different contexts are not related to one another, the interface to 255 physical component associations are relative to the same logical entity 256 within the agent. 258 The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias' 259 objects, which approximate the semantics of the 'ifName' and 'ifAlias' 260 objects (respectively) from the Interfaces MIB [17], for all types of 261 physical components. 263 4.7. Relationship to the Other MIBs 265 The Entity MIB contains a mapping table identifying physical components 266 that have identifiers from other standard MIBs associated with them. 267 For example, this table can be used along with the physical mapping 268 table to identify the physical location of each repeater port in the 269 rptrPortTable, or each interface in the ifTable. 271 4.8. Relationship to Naming Scopes 273 There is some question as to which MIB objects may be returned within a 274 given naming scope. MIB objects which are not multi-scoped within a 275 managed system are likely to ignore context information in 276 implementation. In such a case, it is likely such objects will be 277 returned in all naming scopes (e.g. not just the 'main' naming scope). 279 For example, a community string used to access the management 280 information for logical device 'bridge2' may allow access to all the 281 non-bridge related objects in the 'main' naming scope, as well as a 282 second instance of the Bridge MIB. 284 It is an implementation-specific matter as to the isolation of single- 285 scoped MIB objects by the agent. An agent may wish to limit the objects 286 returned in a particular naming scope to just the multi-scoped objects 287 in that naming scope (e.g. system group and the Bridge MIB). In this 288 case, all single-scoped management information would belong to a common 289 naming scope (e.g. 'main'), which itself may contain some multi-scoped 290 objects (e.g. system group). 292 4.9. Multiple Instances of the Entity MIB 294 It is possible that more than one agent exists in a managed system, and 295 in such cases, multiple instances of the Entity MIB (representing the 296 same managed objects) may be available to an NMS. 298 In order to reduce complexity for agent implementation, multiple 299 instances of the Entity MIB are not required to be equivalent or even 300 consistent. An NMS may be able to 'align' instances returned by 301 different agents by examining the columns of each table, but vendor- 302 specific identifiers and (especially) index values are likely to be 303 different. Each agent may be managing different subsets of the entire 304 chassis as well. 306 When all of a physically-modular device is represented by a single 307 agent, the entry for which entPhysicalContainedIn has the value zero 308 would likely have 'chassis' as the value of its entPhysicalClass; 309 alternatively, for an agent on a module where the agent represents only 310 the physical entities on that module (not those on other modules), the 311 entry for which entPhysicalContainedIn has the value zero would likely 312 have 'module' as the value of its entPhysicalClass. 314 An agent implementation of the entLogicalTable is not required to 315 contain information about logical entities managed primarily by other 316 agents. That is, the entLogicalTAddress and entLogicalTDomain objects in 317 the entLogicalTable are provided to support an historical multiplexing 318 mechanism, not to identify other SNMP agents. 320 Note that the Entity MIB is a single-scoped MIB, in the event an agent 321 represents the MIB in different naming scopes. 323 4.10. Re-Configuration of Entities 325 Most of the MIB objects defined in this MIB have at most a read-only 326 MAX-ACCESS clause, i.e., none are write-able. This is a conscious 327 decision by the working group to limit this MIB's scope. The second 328 version of the Entity MIB allows an network administrator to configure 329 some common attributes of physical components. 331 4.11. MIB Structure 333 The Entity MIB contains five groups of MIB objects: 335 - entityPhysical group 336 Describes the physical entities managed by a single agent. 338 - entityLogical group 339 Describes the logical entities managed by a single agent. 341 - entityMapping group 342 Describes the associations between the physical entities, logical 343 entities, interfaces, and non-interface ports managed by a single 344 agent. 346 - entityGeneral group 347 Describes general system attributes shared by potentially all types 348 of entities managed by a single agent. 350 - entityNotifications group 351 Contains status indication notifications. 353 4.11.1. entityPhysical Group 355 This group contains a single table to identify physical system 356 components, called the entPhysicalTable. 358 The entPhysicalTable contains one row per physical entity, and must 359 always contains at least one row for an "overall" physical entity. Each 360 row is indexed by an arbitrary, small integer, and contains a 361 description and type of the physical entity. It also optionally 362 contains the index number of another entPhysicalEntry indicating a 363 containment relationship between the two. 365 Version 2 of the Entity MIB provides additional MIB objects for each 366 physical entity. Some common read-only attributes have been added, as 367 well as three writable string objects. 369 - entPhysicalAlias 370 This string can be used by an NMS as a non-volatile identifier for 371 the physical component. Maintaining a non-volatile string for every 372 physical component represented in the entPhysicalTable can be 373 costly and unnecessary. An agent may choose to algorithmically 374 generate 'entPhysicalAlias' strings for particular entries (e.g., 375 based on the entPhysicalClass value). 377 - entPhysicalAssetID 378 This string is provided to store a user-specific asset identifier 379 for removeable physical components. In order to reduce the non- 380 volatile storage needed by a particular agent, a network 381 administrator should only assign asset identifiers to physical 382 entities which are field-replaceable (i.e., not permanently 383 contained within another physical entity). 385 - entPhysicalSerialNum 386 This string is provided to store a vendor-specific serial number 387 string for physical components. This is a writeable object in case 388 an agent cannot identify the serial numbers of all installed 389 physical entities, and a network administrator wishes to configure 390 the non-volatile serial number strings manually (via an NMS 391 application). 393 4.11.2. entityLogical Group 395 This group contains a single table to identify logical entities, called 396 the entLogicalTable. 398 The entLogicalTable contains one row per logical entity. Each row is 399 indexed by an arbitrary, small integer and contains a name, description, 400 and type of the logical entity. It also contains information to allow 401 SNMPv1 [6], SNMPv2C [9], or SNMPv3 [1] access to the MIB information 402 for the logical entity. 404 4.11.3. entityMapping Group 406 This group contains a three tables to identify associations between 407 different system components. 409 The entLPMappingTable contains mappings between entLogicalIndex values 410 (logical entities) and entPhysicalIndex values (the physical components 411 supporting that entity). A logical entity can map to more than one 412 physical component, and more than one logical entity can map to (share) 413 the same physical component. 415 The entAliasMappingTable contains mappings between entLogicalIndex, 416 entPhysicalIndex pairs and 'alias' object identifier values. This 417 allows resources managed with other MIBs (e.g. repeater ports, bridge 418 ports, physical and logical interfaces) to be identified in the physical 419 entity hierarchy. Note that each alias identifier is only relevant in a 420 particular naming scope. 422 The entPhysicalContainsTable contains simple mappings between 423 'entPhysicalContainedIn' values for each container/'containee' 424 relationship in the managed system. The indexing of this table allows an 425 NMS to quickly discover the 'entPhysicalIndex' values for all children 426 of a given physical entity. 428 4.11.4. entityGeneral Group 430 This group contains general information relating to the other object 431 groups. 433 At this time, the entGeneral group contains a single scalar object 434 (entLastChangeTime), which represents the value of sysUptime when any 435 part of the system configuration last changed. 437 4.11.5. entityNotifications Group 439 This group contains notification definitions relating to the overall 440 status of the Entity MIB instantiation. 442 4.12. Multiple Agents 444 Even though a primary motivation for this MIB is to represent the 445 multiple logical entities supported by a single agent, it is also 446 possible to use it to represent multiple logical entities supported by 447 multiple agents (in the same "overall" physical entity). Indeed, it is 448 implicit in the SNMP architecture, that the number of agents is 449 transparent to a network management station. 451 However, there is no agreement at this time as to the degree of 452 cooperation which should be expected for agent implementations. 453 Therefore, multiple agents within the same managed system are free to 454 implement the Entity MIB independently. (Refer the section on "Multiple 455 Instances of the Entity MIB" for more details). 457 4.13. Change Log 459 The following changes have been made since publication of the original 460 Entity MIB [16]. 462 4.13.1. Version 00 464 - Clarified description of the PhysicalClass textual convention. 465 Added a new enumeration. 467 - Added RevisionString and SnmpEngineIdOrZero textual conventions to 468 support new entPhysicalTable and entLogicalTable objects 470 - Fixed bug in entPhysicalParentRelPos DESCRIPTION clause 472 - Added entPhysicalHardwareRev, FirmwareRev, and SoftwareRev objects 473 for revision identification 475 - Added entPhysicalMfgName and entPhysicalModelName objects for 476 better component identification 478 - Added entPhysicalAlias read-write string to identify specific 479 components across reboots. 481 - Added entPhysicalAssetID and entPhysicalSerialNum read-write 482 strings to allow user identification of specific components across 483 reboots. 485 - Fixed a bug in the entLogicalCommunity object. The subrange was 486 incorrect (1..255) and is now (0..255). The description clause has 487 also been clarified. This object is now deprecated. 489 - Added entLogicalContextEngineID and entLogicalContextName objects 490 to provide an SNMP context for SNMPv3 access on behalf of a logical 491 entity. 493 - Changed entLastChangeTime object description to generalize the 494 events which cause an update to the last change timestamp. 496 5. Definitions 498 ENTITY-MIB DEFINITIONS ::= BEGIN 500 IMPORTS 501 MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE 502 FROM SNMPv2-SMI 503 TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION, 504 AutonomousType, RowPointer, TimeStamp 505 FROM SNMPv2-TC 506 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 507 FROM SNMPv2-CONF 508 SnmpAdminString 509 FROM SNMP-FRAMEWORK-MIB; 511 entityMIB MODULE-IDENTITY 512 LAST-UPDATED "9808050000Z" 513 ORGANIZATION "IETF ENTMIB Working Group" 514 CONTACT-INFO 515 " WG E-mail: entmib@cisco.com 516 Subscribe: majordomo@cisco.com 517 msg body: subscribe entmib 519 Keith McCloghrie 520 ENTMIB Working Group Chair 521 Cisco Systems Inc. 522 170 West Tasman Drive 523 San Jose, CA 95134 524 408-526-5260 525 kzm@cisco.com 526 Andy Bierman 527 ENTMIB Working Group Editor 528 Cisco Systems Inc. 529 170 West Tasman Drive 530 San Jose, CA 95134 531 408-527-3711 532 abierman@cisco.com" 533 DESCRIPTION 534 "The MIB module for representing multiple logical 535 entities supported by a single SNMP agent." 536 ::= { mib-2 47 } 538 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 540 -- MIB contains four groups 541 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } 542 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } 543 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } 544 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } 546 -- Textual Conventions 547 PhysicalIndex ::= TEXTUAL-CONVENTION 548 STATUS current 549 DESCRIPTION 550 "An arbitrary value which uniquely identifies the physical 551 entity. The value is a small positive integer; index values 552 for different physical entities are not necessarily 553 contiguous." 554 SYNTAX INTEGER (1..2147483647) 556 PhysicalClass ::= TEXTUAL-CONVENTION 557 STATUS current 558 DESCRIPTION 559 "An enumerated value which provides an indication of the 560 general hardware type of a particular physical entity. 561 There are no restrictions as to the number of 562 entPhysicalEntries of each entPhysicalClass, which must be 563 instantiated by an agent. 565 The enumeration 'other' is applicable if the physical entity 566 class is known, but does not match any of the supported 567 values. 569 The enumeration 'unknown' is applicable if the physical 570 entity class is unknown to the agent. 572 The enumeration 'chassis' is applicable if the physical 573 entity class is an overall container for networking 574 equipment. Any class of physical entity except a stack may 575 be contained within a chassis, and a chasis may only be 576 contained within a stack. (The phrase 'within class X' 577 indicates an entPhysicalEntry with a entPhysicalContainedIn 578 value identical to the entPhysicalIndex for a particular 579 physical entity, of entPhysicalClass 'X'.) 581 The enumeration 'backplane' is applicable if the physical 582 entity class is some sort of device for aggregating and 583 forwarding networking traffic, such as a shared backplane in 584 a modular ethernet switch. 586 The enumeration 'container' is applicable if the physical 587 entity class is capable of containing one or more removable 588 physical entities, possibly of different types. For example, 589 each (empty or full) slot in a chassis will be modeled as a 590 container. Note that all removeable physical entities should 591 be modeled within a container entity, such as field- 592 replaceable modules, fans, power supplies, etc. 594 The enumeration 'powerSupply' is applicable if the physical 595 entity class is a power-supplying component. 597 The enumeration 'fan' is applicable if the physical entity 598 class is a fan or other heat-reduction component. 600 The enumeration 'sensor' is applicable if the physical 601 entity class is some sort of sensor, such as a temperature 602 sensor within a router chassis. 604 The enumeration 'module' is applicable if the physical 605 entity class is some sort of self-contained sub-system. If 606 it is removeable, then it should be modeled within a 607 container entity, otherwise it may be modeled directly 608 within another physical entity (e.g., a chassis or another 609 module). 611 The enumeration 'port' is applicable if the physical entity 612 class is some sort of networking port, capable of receiving 613 and/or transmitting networking traffic. 615 The enumeration 'stack' is applicable if the physical entity 616 class is some sort of super-container (possibly virtual), 617 intended to group together multiple chassis entities. A 618 stack may be a virtual cable, or be a real interconnect 619 cable, attached to multiple chassis, or may in fact be 620 comprised of multiple interconnect cables. A stack may not 621 be modeled within any other entity class, and only chassis 622 entities may be contained within a stack." 623 SYNTAX INTEGER { 624 other(1), 625 unknown(2), 626 chassis(3), 627 backplane(4), 628 container(5), -- e.g., slot or daughter-card holder 629 powerSupply(6), 630 fan(7), 631 sensor(8), 632 module(9), -- e.g., plug-in card or daughter-card 633 port(10), 634 stack(11) -- e.g., stack of multiple chassis entities 635 } 637 RevisionString ::= TEXTUAL-CONVENTION 638 STATUS current 639 DESCRIPTION 640 "A specially formatted SnmpAdminString which contains one or 641 more revision identifier strings. This string has the 642 encoding rules as those defined in the SnmpAdminString 643 textual convention (see RFC 2271 [1]), with some additional 644 restrictions. 646 The actual semantics and contents of an individual revision 647 string are vendor-specific, and not defined by this TC. 649 Some encoding rules to improve readability are defined: 651 If more than one revision applies to a particular 652 physical entity, a field separator must be present 653 between each revision string. The same field separator 654 must be used throughout the string, and only a single 655 instance of the field separator is allowed between 656 revision strings. Leading and trailing field separators 657 are not allowed. 659 No one mandatory field separator value is defined, but 660 the value must be one of following sequences: 662 Name '[]' (Decimal) 663 ------------------------------------- 664 space (SP) ' ' (32) 665 comma ',' (44) 666 semicolon ';' (59) 667 colon ':' (58) 668 newline CR LF (13 10) 669 field sep. FS (28) 671 If a revision string contains binary numbers (in its 672 native encoding), then such numbers must be converted 673 to a printable format before they can be returned in a 674 RevisionString-based MIB object. 676 A hexadecimal prefix (e.g., '0x') is not explicitly 677 defined, and is not mandatory. 679 Each binary octet is first separated into two binary 680 nibbles. The higher-valued 4 bits are printed as the 681 leftmost character, and the lower-valued 4 bits are 682 printed as the rightmost character. 684 Each binary nibble is converted to a printable 685 character using the following table: 687 Binary Value ASCII (Decimal) Value 688 ---------------------------------------- 689 0 - 9 '0' (48) - '9' (57) 690 10 'A' (65) or 'a' (97) 691 11 'B' (66) or 'b' (98) 692 12 'C' (67) or 'c' (99) 693 13 'D' (68) or 'd' (100) 694 14 'E' (69) or 'e' (101) 695 15 'F' (70) or 'f' (102) 697 For example, a printable hexidecimal string 698 representing the decimal value 100 would be printed as 699 an ASCII string containing the two octet sequence '64' 700 (decimal 54 52). 702 If no suitable revision string exists for a particular 703 physical entity, then a RevisionString-based MIB object may 704 contain a zero-length octet string." 706 SYNTAX OCTET STRING (SIZE(0..255)) -- SnmpAdminString 708 SnmpEngineIdOrZero ::= TEXTUAL-CONVENTION 709 STATUS current 710 DESCRIPTION 711 "A specially formatted SnmpEngineID string for use with the 712 Entity MIB. 714 If an instance of an object of SYNTAX SnmpEngineIdOrZero has 715 a non-zero length, then the object encoding and semantics 716 are defined by the SnmpEngineID textual convention (see RFC 717 2271 [1]). 719 If an instance of an object of SYNTAX SnmpEngineIdOrZero 720 contains a zero-length string, then no appropriate 721 SnmpEngineID is associated with the logical entity (e.g., 722 SNMPv3 not supported), or no such string may be returned to 723 the caller (e.g., insufficient access rights)." 724 SYNTAX OCTET STRING (SIZE(0..32)) -- null string or SnmpEngineID 726 -- The Physical Entity Table 728 entPhysicalTable OBJECT-TYPE 729 SYNTAX SEQUENCE OF EntPhysicalEntry 730 MAX-ACCESS not-accessible 731 STATUS current 732 DESCRIPTION 733 "This table contains one row per physical entity. There is 734 always at least one row for an 'overall' physical entity." 735 ::= { entityPhysical 1 } 737 entPhysicalEntry OBJECT-TYPE 738 SYNTAX EntPhysicalEntry 739 MAX-ACCESS not-accessible 740 STATUS current 741 DESCRIPTION 742 "Information about a particular physical entity. 744 Each entry provides objects (entPhysicalDescr, 745 entPhysicalVendorType, and entPhysicalClass) to help an NMS 746 identify and characterize the entry, and objects 747 (entPhysicalContainedIn and entPhysicalParentRelPos) to help 748 an NMS relate the particular entry to other entries in this 749 table." 750 INDEX { entPhysicalIndex } 751 ::= { entPhysicalTable 1 } 753 EntPhysicalEntry ::= SEQUENCE { 754 entPhysicalIndex PhysicalIndex, 755 entPhysicalDescr DisplayString, 756 entPhysicalVendorType AutonomousType, 757 entPhysicalContainedIn INTEGER, 758 entPhysicalClass PhysicalClass, 759 entPhysicalParentRelPos INTEGER, 760 entPhysicalName DisplayString, 761 entPhysicalHardwareRev RevisionString, 762 entPhysicalFirmwareRev RevisionString, 763 entPhysicalSoftwareRev RevisionString, 764 entPhysicalSerialNum SnmpAdminString, 765 entPhysicalMfgName SnmpAdminString, 766 entPhysicalModelName SnmpAdminString, 767 entPhysicalAlias SnmpAdminString, 768 entPhysicalAssetID SnmpAdminString 769 } 771 entPhysicalIndex OBJECT-TYPE 772 SYNTAX PhysicalIndex 773 MAX-ACCESS not-accessible 774 STATUS current 775 DESCRIPTION 776 "The index for this entry." 777 ::= { entPhysicalEntry 1 } 779 entPhysicalDescr OBJECT-TYPE 780 SYNTAX DisplayString 781 MAX-ACCESS read-only 782 STATUS current 783 DESCRIPTION 784 "A textual description of physical entity. This object 785 should contain a string which identifies the manufacturer's 786 name for the physical entity, and should be set to a 787 distinct value for each version or model of the physical 788 entity. " 789 ::= { entPhysicalEntry 2 } 791 entPhysicalVendorType OBJECT-TYPE 792 SYNTAX AutonomousType 793 MAX-ACCESS read-only 794 STATUS current 795 DESCRIPTION 796 "An indication of the vendor-specific hardware type of the 797 physical entity. Note that this is different from the 798 definition of MIB-II's sysObjectID. 800 An agent should set this object to a enterprise-specific 801 registration identifier value indicating the specific 802 equipment type in detail. The associated instance of 803 entPhysicalClass is used to indicate the general type of 804 hardware device. 806 If no vendor-specific registration identifier exists for 807 this physical entity, or the value is unknown by this agent, 808 then the value { 0 0 } is returned." 809 ::= { entPhysicalEntry 3 } 811 entPhysicalContainedIn OBJECT-TYPE 812 SYNTAX INTEGER (0..2147483647) 813 MAX-ACCESS read-only 814 STATUS current 815 DESCRIPTION 816 "The value of entPhysicalIndex for the physical entity which 817 'contains' this physical entity. A value of zero indicates 818 this physical entity is not contained in any other physical 819 entity. Note that the set of 'containment' relationships 820 define a strict hierarchy; that is, recursion is not 821 allowed." 822 ::= { entPhysicalEntry 4 } 824 entPhysicalClass OBJECT-TYPE 825 SYNTAX PhysicalClass 826 MAX-ACCESS read-only 827 STATUS current 828 DESCRIPTION 829 "An indication of the general hardware type of the physical 830 entity. 832 An agent should set this object to the standard enumeration 833 value which most accurately indicates the general class of 834 the physical entity, or the primary class if there is more 835 than one. 837 If no appropriate standard registration identifier exists 838 for this physical entity, then the value 'other(1)' is 839 returned. If the value is unknown by this agent, then the 840 value 'unknown(2)' is returned." 841 ::= { entPhysicalEntry 5 } 843 entPhysicalParentRelPos OBJECT-TYPE 844 SYNTAX INTEGER (-1..2147483647) 845 MAX-ACCESS read-only 846 STATUS current 847 DESCRIPTION 848 "An indication of the relative position of this 'child' 849 component among all its 'sibling' components. Sibling 850 components are defined as entPhysicalEntries which share the 851 same instance values of each of the entPhysicalContainedIn 852 and entPhysicalClass objects. 854 An NMS can use this object to identify the relative ordering 855 for all sibling components of a particular parent 856 (identified by the entPhysicalContainedIn instance in each 857 sibling entry). 859 This value should match any external labeling of the 860 physical component if possible. For example, for a container 861 (e.g., card slot) labeled as 'slot #3', 862 entPhysicalParentRelPos should have the value '3'. Note 863 that the entPhysicalEntry for the module plugged in slot 3 864 should have an entPhysicalParentRelPos value of '1'. 866 If the physical position of this component does not match 867 any external numbering or clearly visible ordering, then 868 user documentation or other external reference material 869 should be used to determine the parent-relative position. If 870 this is not possible, then the the agent should assign a 871 consistent (but possibly arbitrary) ordering to a given set 872 of 'sibling' components, perhaps based on internal 873 representation of the components. 875 If the agent cannot determine the parent-relative position 876 for some reason, or if the associated value of 877 entPhysicalContainedIn is '0', then the value '-1' is 878 returned. Otherwise a non-negative integer is returned, 879 indicating the parent-relative position of this physical 880 entity. 882 Parent-relative ordering normally starts from '1' and 883 continues to 'N', where 'N' represents the highest 884 positioned child entity. However, if the physical entities 885 (e.g. slots) are labeled from a starting position of zero, 886 then the first sibling should be associated with a 887 entPhysicalParentRelPos value of '0'. Note that this 888 ordering may be sparse or dense, depending on agent 889 implementation. 891 The actual values returned are not globally meaningful, as 892 each 'parent' component may use different numbering 893 algorithms. The ordering is only meaningful among siblings 894 of the same parent component. 896 The agent should retain parent-relative position values 897 across reboots, either through algorithmic assignment or use 898 of non-volatile storage." 899 ::= { entPhysicalEntry 6 } 901 entPhysicalName OBJECT-TYPE 902 SYNTAX DisplayString 903 MAX-ACCESS read-only 904 STATUS current 905 DESCRIPTION 906 "The textual name of the physical entity. The value of this 907 object should be the name of the component as assigned by 908 the local device and should be suitable for use in commands 909 entered at the device's `console'. This might be a text 910 name, such as `console' or a simple component number (e.g. 911 port or module number), such as `1', depending on the 912 physical component naming syntax of the device. 914 If there is no local name, or this object is otherwise not 915 applicable, then this object contains a zero-length string. 917 Note that the value of entPhysicalName for two physical 918 entities will be the same in the event that the console 919 interface does not distinguish between them, e.g., slot-1 920 and the card in slot-1." 921 ::= { entPhysicalEntry 7 } 923 entPhysicalHardwareRev OBJECT-TYPE 924 SYNTAX RevisionString 925 MAX-ACCESS read-only 926 STATUS current 927 DESCRIPTION 928 "The vendor-specific hardware revision string for the 929 physical entity. The preferred value is the hardware 930 revision identifier actually printed on the component itself 931 (if present). 933 If no specific hardware revision string is associated with 934 the physical component, or this information is unknown to 935 the agent, then this object will contain a zero-length 936 string." 937 ::= { entPhysicalEntry 8 } 939 entPhysicalFirmwareRev OBJECT-TYPE 940 SYNTAX RevisionString 941 MAX-ACCESS read-only 942 STATUS current 943 DESCRIPTION 944 "The vendor-specific firmware revision string for the 945 physical entity. 947 If no specific firmware programs are associated with the 948 physical component, or this information is unknown to the 949 agent, then this object will contain a zero-length string." 950 ::= { entPhysicalEntry 9 } 952 entPhysicalSoftwareRev OBJECT-TYPE 953 SYNTAX RevisionString 954 MAX-ACCESS read-only 955 STATUS current 956 DESCRIPTION 957 "The vendor-specific software revision string for the 958 physical entity. 960 If no specific software programs are associated with the 961 physical component, or this information is unknown to the 962 agent, then this object will contain a zero-length string." 963 ::= { entPhysicalEntry 10 } 965 entPhysicalSerialNum OBJECT-TYPE 966 SYNTAX SnmpAdminString 967 MAX-ACCESS read-write 968 STATUS current 969 DESCRIPTION 970 "The vendor-specific serial number string for the physical 971 entity. The preferred value is the serial number string 972 actually printed on the component itself (if present). 974 On the first instantiation of an physical entity, the value 975 of entPhysicalSerialNum associated with that entity is set 976 to the correct vendor-assigned serial number, if this 977 information is available to the agent. If a serial number is 978 unknown or non-existent, the entPhysicalSerialNum will be 979 set to a zero-length string instead. 981 Note that implementations which can correctly identify the 982 serial numbers of all installed physical entities do not 983 need to provide write access to the entPhysicalSerialNum 984 object. Agents which cannot provide non-volatile storage for 985 the entPhysicalSerialNum strings are not required to 986 implement write access for this object. 988 Not every physical component will have a serial number, or 989 even need one. Physical entities which are permanently 990 'contained in' another physical entity (e.g., the repeater 991 ports within a repeater module) do not need their own unique 992 serial number. An agent does not have to provide write 993 access for such entities. 995 If write access is implemented for an instance of 996 entPhysicalSerialNum, and a value is written into the 997 instance, the agent must retain the supplied value in the 998 entPhysicalSerialNum instance associated with the same 999 physical entity for as long as that entity remains 1000 instantiated. This includes instantiations across all re- 1001 initializations/reboots of the network management system, 1002 including those which result in a change of the physical 1003 entity's entPhysicalIndex value." 1004 ::= { entPhysicalEntry 11 } 1006 entPhysicalMfgName OBJECT-TYPE 1007 SYNTAX SnmpAdminString 1008 MAX-ACCESS read-only 1009 STATUS current 1010 DESCRIPTION 1011 "The name of the manufacturer of this physical component. 1012 The preferred value is the manufacturer name string actually 1013 printed on the component itself (if present). 1015 If the manufacturer name string associated with the physical 1016 component is unknown to the agent, then this object will 1017 contain a zero-length string." 1018 ::= { entPhysicalEntry 12 } 1020 entPhysicalModelName OBJECT-TYPE 1021 SYNTAX SnmpAdminString 1022 MAX-ACCESS read-only 1023 STATUS current 1024 DESCRIPTION 1025 "The vendor-specific model name identifier string associated 1026 with this physical component. The preferred value is the 1027 model name string actually printed on the component itself 1028 (if present). 1030 If the model name string is associated with the physical 1031 component is unknown to the agent, then this object will 1032 contain a zero-length string." 1033 ::= { entPhysicalEntry 13 } 1035 entPhysicalAlias OBJECT-TYPE 1036 SYNTAX SnmpAdminString (SIZE (0..32)) 1037 MAX-ACCESS read-write 1038 STATUS current 1039 DESCRIPTION 1040 "This object is an 'alias' name for the physical entity as 1041 specified by a network manager, and provides a non-volatile 1042 'handle' for the physical entity. 1044 On the first instantiation of an physical entity, the value 1045 of entPhysicalAlias associated with that entity is set to 1046 the zero-length string. However, agent may choose to set the 1047 value to a locally unique default value, instead of a zero- 1048 length string. 1050 If write access is implemented for an instance of 1051 entPhysicalAlias, and a value is written into the instance, 1052 the agent must retain the supplied value in the 1053 entPhysicalAlias instance associated with the same physical 1054 entity for as long as that entity remains instantiated. This 1055 includes instantiations across all re- 1056 initializations/reboots of the network management system, 1057 including those which result in a change of the physical 1058 entity's entPhysicalIndex value." 1059 ::= { entPhysicalEntry 14 } 1061 entPhysicalAssetID OBJECT-TYPE 1062 SYNTAX SnmpAdminString 1063 MAX-ACCESS read-write 1064 STATUS current 1065 DESCRIPTION 1066 "This object is a user-assigned asset tracking identifier 1067 for the physical entity as specified by a network manager, 1068 and provides non-volatile storage of this information. 1070 On the first instantiation of an physical entity, the value 1071 of entPhysicalAssetID associated with that entity is set to 1072 the zero-length string. 1074 Not every physical component will have a asset tracking 1075 identifier, or even need one. Physical entities which are 1076 permanently 'contained in' another physical entity (e.g., 1077 the repeater ports within a repeater module) do not need 1078 their own unique asset tracking identifier. An agent does 1079 not have to provide write access for such entities, and may 1080 instead return a zero-length string. 1082 If write access is implemented for an instance of 1083 entPhysicalAssetID, and a value is written into the 1084 instance, the agent must retain the supplied value in the 1085 entPhysicalAssetID instance associated with the same 1086 physical entity for as long as that entity remains 1087 instantiated. This includes instantiations across all re- 1088 initializations/reboots of the network management system, 1089 including those which result in a change of the physical 1090 entity's entPhysicalIndex value. 1092 If no asset tracking information is associated with the 1093 physical component, then this object will contain a zero- 1094 length string." 1095 ::= { entPhysicalEntry 15 } 1097 -- The Logical Entity Table 1098 entLogicalTable OBJECT-TYPE 1099 SYNTAX SEQUENCE OF EntLogicalEntry 1100 MAX-ACCESS not-accessible 1101 STATUS current 1102 DESCRIPTION 1103 "This table contains one row per logical entity. At least 1104 one entry must exist." 1105 ::= { entityLogical 1 } 1107 entLogicalEntry OBJECT-TYPE 1108 SYNTAX EntLogicalEntry 1109 MAX-ACCESS not-accessible 1110 STATUS current 1111 DESCRIPTION 1112 "Information about a particular logical entity. Entities 1113 may be managed by this agent or other SNMP agents (possibly) 1114 in the same chassis." 1115 INDEX { entLogicalIndex } 1116 ::= { entLogicalTable 1 } 1118 EntLogicalEntry ::= SEQUENCE { 1119 entLogicalIndex INTEGER, 1120 entLogicalDescr DisplayString, 1121 entLogicalType AutonomousType, 1122 entLogicalCommunity OCTET STRING, 1123 entLogicalTAddress TAddress, 1124 entLogicalTDomain TDomain, 1125 entLogicalContextEngineID SnmpEngineIdOrZero, 1126 entLogicalContextName SnmpAdminString 1127 } 1129 entLogicalIndex OBJECT-TYPE 1130 SYNTAX INTEGER (1..2147483647) 1131 MAX-ACCESS not-accessible 1132 STATUS current 1133 DESCRIPTION 1134 "The value of this object uniquely identifies the logical 1135 entity. The value is a small positive integer; index values 1136 for different logical entities are are not necessarily 1137 contiguous." 1138 ::= { entLogicalEntry 1 } 1140 entLogicalDescr OBJECT-TYPE 1141 SYNTAX DisplayString 1142 MAX-ACCESS read-only 1143 STATUS current 1144 DESCRIPTION 1145 "A textual description of the logical entity. This object 1146 should contain a string which identifies the manufacturer's 1147 name for the logical entity, and should be set to a distinct 1148 value for each version of the logical entity. " 1149 ::= { entLogicalEntry 2 } 1151 entLogicalType OBJECT-TYPE 1152 SYNTAX AutonomousType 1153 MAX-ACCESS read-only 1154 STATUS current 1155 DESCRIPTION 1156 "An indication of the type of logical entity. This will 1157 typically be the OBJECT IDENTIFIER name of the node in the 1158 SMI's naming hierarchy which represents the major MIB 1159 module, or the majority of the MIB modules, supported by the 1160 logical entity. For example: 1161 a logical entity of a regular host/router -> mib-2 1162 a logical entity of a 802.1d bridge -> dot1dBridge 1163 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 1164 If an appropriate node in the SMI's naming hierarchy cannot 1165 be identified, the value 'mib-2' should be used." 1166 ::= { entLogicalEntry 3 } 1168 entLogicalCommunity OBJECT-TYPE 1169 SYNTAX OCTET STRING (SIZE (0..255)) 1170 MAX-ACCESS read-only 1171 STATUS deprecated 1172 DESCRIPTION 1173 "An SNMPv1 or SNMPv2C community-string which can be used to 1174 access detailed management information for this logical 1175 entity. The agent should allow read access with this 1176 community string (to an appropriate subset of all managed 1177 objects) and may also choose to return a community string 1178 based on the privileges of the request used to read this 1179 object. Note that an agent may choose to return a community 1180 string with read-only privileges, even if this object is 1181 accessed with a read-write community string. However, the 1182 agent must take care not to return a community string which 1183 allows more privileges than the community string used to 1184 access this object. 1186 A compliant SNMP agent may wish to conserve naming scopes by 1187 representing multiple logical entities in a single 'main' 1188 naming scope. This is possible when the logical entities 1189 represented by the same value of entLogicalCommunity have no 1190 object instances in common. For example, 'bridge1' and 1191 'repeater1' may be part of the main naming scope, but at 1192 least one additional community string is needed to represent 1193 'bridge2' and 'repeater2'. 1195 Logical entities 'bridge1' and 'repeater1' would be 1196 represented by sysOREntries associated with the 'main' 1197 naming scope. 1199 For agents not accessible via SNMPv1 or SNMPv2C, the value 1200 of this object is the empty-string. This object may also 1201 contain an empty string if a community string has not yet 1202 been assigned by the agent, or no community string with 1203 suitable access rights can be returned for a particular SNMP 1204 request. 1206 Note that this object is deprecated. Agents which implement 1207 SNMPv3 access should use the entLogicalContextEngineID and 1208 entLogicalContextName objects to identify the context 1209 associated with each logical entity. SNMPv3 agents may 1210 return a zero-length string for this object, or may continue 1211 to return a community string (e.g., tri-lingual agent 1212 support)." 1213 ::= { entLogicalEntry 4 } 1215 entLogicalTAddress OBJECT-TYPE 1216 SYNTAX TAddress 1217 MAX-ACCESS read-only 1218 STATUS current 1219 DESCRIPTION 1220 "The transport service address by which the logical entity 1221 receives network management traffic, formatted according to 1222 the corresponding value of entLogicalTDomain. 1224 For snmpUDPDomain, a TAddress is 6 octets long, the initial 1225 4 octets containing the IP-address in network-byte order and 1226 the last 2 containing the UDP port in network-byte order. 1227 Consult 'Transport Mappings for Version 2 of the Simple 1228 Network Management Protocol' (RFC 1906 [8]) for further 1229 information on snmpUDPDomain." 1230 ::= { entLogicalEntry 5 } 1232 entLogicalTDomain OBJECT-TYPE 1233 SYNTAX TDomain 1234 MAX-ACCESS read-only 1235 STATUS current 1236 DESCRIPTION 1237 "Indicates the kind of transport service by which the 1238 logical entity receives network management traffic. 1239 Possible values for this object are presently found in the 1240 Transport Mappings for SNMPv2 document (RFC 1906 [8])." 1241 ::= { entLogicalEntry 6 } 1243 entLogicalContextEngineID OBJECT-TYPE 1244 SYNTAX SnmpEngineIdOrZero 1245 MAX-ACCESS read-only 1246 STATUS current 1247 DESCRIPTION 1248 "The authoritative contextEngineID that can be used to send 1249 an SNMPv3 message concerning information held by this 1250 logical entity, to the address specified by the associated 1251 'entLogicalTAddress/entLogicalTDomain' pair. 1253 This object, together with the associated 1254 entLogicalContextName object, defines the context associated 1255 with a particular logical entity. 1257 If SNMPv3 access is not available, no value has been 1258 configured by the agent, or access control does not permit a 1259 SNMP Engine ID to be returned for a particular request, a 1260 zero-length string is returned." 1261 ::= { entLogicalEntry 7 } 1263 entLogicalContextName OBJECT-TYPE 1264 SYNTAX SnmpAdminString 1265 MAX-ACCESS read-only 1266 STATUS current 1267 DESCRIPTION 1268 "The contextName that can be used to send an SNMPv3 message 1269 concerning information held by this logical entity, to the 1270 address specified by the associated 1271 'entLogicalTAddress/entLogicalTDomain' pair. 1273 This object, together with the associated 1274 entLogicalContextEngineID object, defines the context 1275 associated with a particular logical entity. 1277 If SNMPv3 access is not available, no value has been 1278 configured by the agent, or access control does not permit a 1279 context name to be returned for a particular request, a 1280 zero-length string is returned." 1281 ::= { entLogicalEntry 8 } 1283 entLPMappingTable OBJECT-TYPE 1284 SYNTAX SEQUENCE OF EntLPMappingEntry 1285 MAX-ACCESS not-accessible 1286 STATUS current 1287 DESCRIPTION 1288 "This table contains zero or more rows of logical entity to 1289 physical equipment associations. For each logical entity 1290 known by this agent, there are zero or more mappings to the 1291 physical resources which are used to realize that logical 1292 entity. 1294 An agent should limit the number and nature of entries in 1295 this table such that only meaningful and non-redundant 1296 information is returned. For example, in a system which 1297 contains a single power supply, mappings between logical 1298 entities and the power supply are not useful and should not 1299 be included. 1301 Also, only the most appropriate physical component which is 1302 closest to the root of a particular containment tree should 1303 be identified in an entLPMapping entry. 1305 For example, suppose a bridge is realized on a particular 1306 module, and all ports on that module are ports on this 1307 bridge. A mapping between the bridge and the module would be 1308 useful, but additional mappings between the bridge and each 1309 of the ports on that module would be redundant (since the 1310 entPhysicalContainedIn hierarchy can provide the same 1311 information). If, on the other hand, more than one bridge 1312 was utilizing ports on this module, then mappings between 1313 each bridge and the ports it used would be appropriate. 1315 Also, in the case of a single backplane repeater, a mapping 1316 for the backplane to the single repeater entity is not 1317 necessary." 1318 ::= { entityMapping 1 } 1320 entLPMappingEntry OBJECT-TYPE 1321 SYNTAX EntLPMappingEntry 1322 MAX-ACCESS not-accessible 1323 STATUS current 1324 DESCRIPTION 1325 "Information about a particular logical entity to physical 1326 equipment association. Note that the nature of the 1327 association is not specifically identified in this entry. It 1328 is expected that sufficient information exists in the MIBs 1329 used to manage a particular logical entity to infer how 1330 physical component information is utilized." 1331 INDEX { entLogicalIndex, entLPPhysicalIndex } 1332 ::= { entLPMappingTable 1 } 1334 EntLPMappingEntry ::= SEQUENCE { 1335 entLPPhysicalIndex PhysicalIndex 1336 } 1338 entLPPhysicalIndex OBJECT-TYPE 1339 SYNTAX PhysicalIndex 1340 MAX-ACCESS read-only 1341 STATUS current 1342 DESCRIPTION 1343 "The value of this object identifies the index value of a 1344 particular entPhysicalEntry associated with the indicated 1345 entLogicalEntity." 1346 ::= { entLPMappingEntry 1 } 1348 -- logical entity/component to alias table 1349 entAliasMappingTable OBJECT-TYPE 1350 SYNTAX SEQUENCE OF EntAliasMappingEntry 1351 MAX-ACCESS not-accessible 1352 STATUS current 1353 DESCRIPTION 1354 "This table contains zero or more rows, representing 1355 mappings of logical entity and physical component to 1356 external MIB identifiers. Each physical port in the system 1357 may be associated with a mapping to an external identifier, 1358 which itself is associated with a particular logical 1359 entity's naming scope. A 'wildcard' mechanism is provided to 1360 indicate that an identifier is associated with more than one 1361 logical entity." 1362 ::= { entityMapping 2 } 1364 entAliasMappingEntry OBJECT-TYPE 1365 SYNTAX EntAliasMappingEntry 1366 MAX-ACCESS not-accessible 1367 STATUS current 1368 DESCRIPTION 1369 "Information about a particular physical equipment, logical 1370 entity to external identifier binding. Each logical 1371 entity/physical component pair may be associated with one 1372 alias mapping. The logical entity index may also be used as 1373 a 'wildcard' (refer to the entAliasLogicalIndexOrZero object 1374 DESCRIPTION clause for details.) 1376 Note that only entPhysicalIndex values which represent 1377 physical ports (i.e. associated entPhysicalClass value is 1378 'port(10)') are permitted to exist in this table." 1380 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 1381 ::= { entAliasMappingTable 1 } 1383 EntAliasMappingEntry ::= SEQUENCE { 1384 entAliasLogicalIndexOrZero INTEGER, 1385 entAliasMappingIdentifier RowPointer 1386 } 1388 entAliasLogicalIndexOrZero OBJECT-TYPE 1389 SYNTAX INTEGER (0..2147483647) 1390 MAX-ACCESS not-accessible 1391 STATUS current 1392 DESCRIPTION 1393 "The value of this object uniquely identifies the logical 1394 entity which defines the naming scope for the associated 1395 instance of the 'entAliasMappingIdentifier' object. 1397 If this object has a non-zero value, then it identifies the 1398 logical entity named by the same value of entLogicalIndex. 1400 If this object has a value of zero, then the mapping between 1401 the physical component and the alias identifier for this 1402 entAliasMapping entry is associated with all unspecified 1403 logical entities. That is, a value of zero (the default 1404 mapping) identifies any logical entity which does not have 1405 an explicit entry in this table for a particular 1406 entPhysicalIndex/entAliasMappingIdentifier pair. 1408 For example, to indicate that a particular interface (e.g. 1409 physical component 33) is identified by the same value of 1410 ifIndex for all logical entities, the following instance 1411 might exist: 1413 entAliasMappingIdentifier.33.0 = ifIndex.5 1415 In the event an entPhysicalEntry is associated differently 1416 for some logical entities, additional entAliasMapping 1417 entries may exist, e.g.: 1419 entAliasMappingIdentifier.33.0 = ifIndex.6 1420 entAliasMappingIdentifier.33.4 = ifIndex.1 1421 entAliasMappingIdentifier.33.5 = ifIndex.1 1422 entAliasMappingIdentifier.33.10 = ifIndex.12 1424 Note that entries with non-zero entAliasLogicalIndexOrZero 1425 index values have precedence over any zero-indexed entry. In 1426 this example, all logical entities except 4, 5, and 10, 1427 associate physical entity 33 with ifIndex.6." 1428 ::= { entAliasMappingEntry 1 } 1430 entAliasMappingIdentifier OBJECT-TYPE 1431 SYNTAX RowPointer 1432 MAX-ACCESS read-only 1433 STATUS current 1434 DESCRIPTION 1435 "The value of this object identifies a particular conceptual 1436 row associated with the indicated entPhysicalIndex and 1437 entLogicalIndex pair. 1439 Since only physical ports are modeled in this table, only 1440 entries which represent interfaces or ports are allowed. If 1441 an ifEntry exists on behalf of a particular physical port, 1442 then this object should identify the associated 'ifEntry'. 1443 For repeater ports, the appropriate row in the 1444 'rptrPortGroupTable' should be identified instead. 1446 For example, suppose a physical port was represented by 1447 entPhysicalEntry.3, entLogicalEntry.15 existed for a 1448 repeater, and entLogicalEntry.22 existed for a bridge. Then 1449 there might be two related instances of 1450 entAliasMappingIdentifier: 1451 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 1452 entAliasMappingIdentifier.3.22 == ifIndex.17 1453 It is possible that other mappings (besides interfaces and 1454 repeater ports) may be defined in the future, as required. 1456 Bridge ports are identified by examining the Bridge MIB and 1457 appropriate ifEntries associated with each 'dot1dBasePort', 1458 and are thus not represented in this table." 1459 ::= { entAliasMappingEntry 2 } 1461 -- physical mapping table 1462 entPhysicalContainsTable OBJECT-TYPE 1463 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 1464 MAX-ACCESS not-accessible 1465 STATUS current 1466 DESCRIPTION 1467 "A table which exposes the container/containee relationships 1468 between physical entities. This table provides equivalent 1469 information found by constructing the virtual containment 1470 tree for a given entPhysicalTable but in a more direct 1471 format." 1472 ::= { entityMapping 3 } 1474 entPhysicalContainsEntry OBJECT-TYPE 1475 SYNTAX EntPhysicalContainsEntry 1476 MAX-ACCESS not-accessible 1477 STATUS current 1478 DESCRIPTION 1479 "A single container/containee relationship." 1480 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1481 ::= { entPhysicalContainsTable 1 } 1483 EntPhysicalContainsEntry ::= SEQUENCE { 1484 entPhysicalChildIndex PhysicalIndex 1485 } 1487 entPhysicalChildIndex OBJECT-TYPE 1488 SYNTAX PhysicalIndex 1489 MAX-ACCESS read-only 1490 STATUS current 1491 DESCRIPTION 1492 "The value of entPhysicalIndex for the contained physical 1493 entity." 1494 ::= { entPhysicalContainsEntry 1 } 1496 -- last change time stamp for the whole MIB 1497 entLastChangeTime OBJECT-TYPE 1498 SYNTAX TimeStamp 1499 MAX-ACCESS read-only 1500 STATUS current 1501 DESCRIPTION 1502 "The value of sysUpTime at the time a conceptual row is 1503 created, modified, or deleted in any of these tables: 1504 - entPhysicalTable 1505 - entLogicalTable 1506 - entLPMappingTable 1507 - entAliasMappingTable 1508 - entPhysicalContainsTable 1509 " 1510 ::= { entityGeneral 1 } 1512 -- Entity MIB Trap Definitions 1513 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1514 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1516 entConfigChange NOTIFICATION-TYPE 1517 STATUS current 1518 DESCRIPTION 1519 "An entConfigChange trap is sent when the value of 1520 entLastChangeTime changes. It can be utilized by an NMS to 1521 trigger logical/physical entity table maintenance polls. 1523 An agent must not generate more than one entConfigChange 1524 'trap-event' in a five second period, where a 'trap-event' 1525 is the transmission of a single trap PDU to a list of trap 1526 destinations. If additional configuration changes occur 1527 within the five second 'throttling' period, then these 1528 trap-events should be suppressed by the agent. An NMS should 1529 periodically check the value of entLastChangeTime to detect 1530 any missed entConfigChange trap-events, e.g. due to 1531 throttling or transmission loss." 1532 ::= { entityMIBTrapPrefix 1 } 1534 -- conformance information 1535 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1537 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1538 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1540 -- compliance statements 1542 entityCompliance MODULE-COMPLIANCE 1543 STATUS current 1544 DESCRIPTION 1545 "The compliance statement for SNMP entities which implement 1546 the Entity MIB." 1547 MODULE -- this module 1548 MANDATORY-GROUPS { entityPhysicalGroup, 1549 entityLogicalGroup, 1550 entityMappingGroup, 1551 entityGeneralGroup, 1552 entityNotificationsGroup } 1553 ::= { entityCompliances 1 } 1555 entity2Compliance MODULE-COMPLIANCE 1556 STATUS current 1557 DESCRIPTION 1558 "The compliance statement for SNMP entities which implement 1559 version 2 of the Entity MIB." 1560 MODULE -- this module 1561 MANDATORY-GROUPS { entityPhysicalGroup, 1562 entityPhysical2Group, 1563 entityLogicalGroup, 1564 entityLogical2Group, 1565 entityMappingGroup, 1566 entityGeneralGroup, 1567 entityNotificationsGroup } 1569 OBJECT entPhysicalSerialNum 1570 MIN-ACCESS not-accessible 1571 DESCRIPTION 1572 "Read and write access is not required for agents which 1573 cannot identify serial number information for physical 1574 entities, and cannot provide non-volatile storage for NMS- 1575 assigned serial numbers. 1577 Write access is not required for agents which can identify 1578 serial number information for physical entities, but cannot 1579 provide non-volatile storage for NMS-assigned serial 1580 numbers. 1582 Write access is not required for physical entities which are 1583 permanently contained within another physical entity." 1585 OBJECT entPhysicalAlias 1586 MIN-ACCESS read-only 1587 DESCRIPTION 1588 "Write access is required only if the associated 1589 entPhysicalClass value is equal to 'chassis(3)'." 1591 OBJECT entPhysicalAssetID 1592 MIN-ACCESS not-accessible 1593 DESCRIPTION 1594 "Read and write access is not required for agents which 1595 cannot provide non-volatile storage for NMS-assigned asset 1596 identifiers. 1598 Write access is not required for physical entities which are 1599 permanently contained within another physical entity." 1600 ::= { entityCompliances 2 } 1602 -- MIB groupings 1604 entityPhysicalGroup OBJECT-GROUP 1605 OBJECTS { 1606 entPhysicalDescr, 1607 entPhysicalVendorType, 1608 entPhysicalContainedIn, 1609 entPhysicalClass, 1610 entPhysicalParentRelPos, 1611 entPhysicalName 1612 } 1613 STATUS current 1614 DESCRIPTION 1615 "The collection of objects which are used to represent 1616 physical system components, for which a single agent 1617 provides management information." 1618 ::= { entityGroups 1 } 1620 entityLogicalGroup OBJECT-GROUP 1621 OBJECTS { 1622 entLogicalDescr, 1623 entLogicalType, 1624 -- entLogicalCommunity, 1625 entLogicalTAddress, 1626 entLogicalTDomain, 1627 entLogicalContextEngineID, 1628 entLogicalContextName 1629 } 1630 STATUS current 1631 DESCRIPTION 1632 "The collection of objects which are used to represent the 1633 list of logical entities for which a single agent provides 1634 management information." 1635 ::= { entityGroups 2 } 1637 entityMappingGroup OBJECT-GROUP 1638 OBJECTS { 1639 entLPPhysicalIndex, 1640 entAliasMappingIdentifier, 1641 entPhysicalChildIndex 1642 } 1643 STATUS current 1644 DESCRIPTION 1645 "The collection of objects which are used to represent the 1646 associations between multiple logical entities, physical 1647 components, interfaces, and port identifiers for which a 1648 single agent provides management information." 1649 ::= { entityGroups 3 } 1651 entityGeneralGroup OBJECT-GROUP 1652 OBJECTS { 1653 entLastChangeTime 1654 } 1655 STATUS current 1656 DESCRIPTION 1657 "The collection of objects which are used to represent 1658 general entity information for which a single agent provides 1659 management information." 1660 ::= { entityGroups 4 } 1662 entityNotificationsGroup NOTIFICATION-GROUP 1663 NOTIFICATIONS { entConfigChange } 1664 STATUS current 1665 DESCRIPTION 1666 "The collection of notifications used to indicate Entity MIB 1667 data consistency and general status information." 1668 ::= { entityGroups 5 } 1670 entityPhysical2Group OBJECT-GROUP 1671 OBJECTS { 1672 entPhysicalHardwareRev, 1673 entPhysicalFirmwareRev, 1674 entPhysicalSoftwareRev, 1675 entPhysicalSerialNum, 1676 entPhysicalMfgName, 1677 entPhysicalModelName, 1678 entPhysicalAlias, 1679 entPhysicalAssetID 1680 } 1681 STATUS current 1682 DESCRIPTION 1683 "The collection of objects which are used to represent 1684 physical system components, for which a single agent 1685 provides management information. These objects are 1686 mandatory for agents conforming to version 2 of the Entity 1687 MIB." 1688 ::= { entityGroups 6 } 1690 entityLogical2Group OBJECT-GROUP 1691 OBJECTS { 1692 entLogicalContextEngineID, 1693 entLogicalContextName 1694 } 1695 STATUS current 1696 DESCRIPTION 1697 "The collection of objects which are used to represent the 1698 list of logical entities for which a single agent provides 1699 management information. These objects are mandatory for 1700 agents conforming to version 2 of the Entity MIB." 1701 ::= { entityGroups 7 } 1703 END 1704 6. Usage Examples 1706 The following sections iterate the instance values for two example 1707 networking devices. These examples are kept simple to make them more 1708 understandable. Auxiliary components, such as fans, sensors, empty 1709 slots, and sub-modules are not shown, but might be modeled in real 1710 implementations. 1712 6.1. Router/Bridge 1714 A router containing two slots. Each slot contains a 3 port 1715 router/bridge module. Each port is represented in the ifTable. There 1716 are two logical instances of OSPF running and two logical bridges: 1718 Physical entities -- entPhysicalTable: 1719 1 Field-replaceable physical chassis: 1720 entPhysicalDescr.1 == "Acme Chassis Model 100" 1721 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 1722 entPhysicalContainedIn.1 == 0 1723 entPhysicalClass.1 == chassis(3) 1724 entPhysicalParentRelPos.1 == 0 1725 entPhysicalName.1 == '100-A' 1727 2 slots within the chassis: 1728 entPhysicalDescr.2 == "Acme Chassis Slot Type AA" 1729 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 1730 entPhysicalContainedIn.2 == 1 1731 entPhysicalClass.2 == container(5) 1732 entPhysicalParentRelPos.2 == 1 1733 entPhysicalName.2 == 'S1' 1735 entPhysicalDescr.3 == "Acme Chassis Slot Type AA" 1736 entPhysicalVendorType.3 == acmeProducts.slotTypes.1 1737 entPhysicalContainedIn.3 == 1 1738 entPhysicalClass.3 == container(5) 1739 entPhysicalParentRelPos.3 == 2 1740 entPhysicalName.3 == 'S2' 1742 2 Field-replaceable modules: 1743 Slot 1 contains a module with 3 ports: 1744 entPhysicalDescr.4 == "Acme Router-100" 1745 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 1746 entPhysicalContainedIn.4 == 2 1747 entPhysicalClass.4 == module(9) 1748 entPhysicalParentRelPos.4 == 1 1749 entPhysicalName.4 == 'M1' 1751 entPhysicalDescr.5 == "Acme Ethernet-100 Port Rev G" 1752 entPhysicalVendorType.5 == acmeProducts.portTypes.2 1753 entPhysicalContainedIn.5 == 4 1754 entPhysicalClass.5 == port(10) 1755 entPhysicalParentRelPos.5 == 1 1756 entPhysicalName.5 == 'P1' 1758 entPhysicalDescr.6 == "Acme Ethernet-100 Port Rev G" 1759 entPhysicalVendorType.6 == acmeProducts.portTypes.2 1760 entPhysicalContainedIn.6 == 4 1761 entPhysicalClass.6 == port(10) 1762 entPhysicalParentRelPos.6 == 2 1763 entPhysicalName.6 == 'P2' 1765 entPhysicalDescr.7 == "Acme Router-100 F-Port: Rev B" 1766 entPhysicalVendorType.7 == acmeProducts.portTypes.3 1767 entPhysicalContainedIn.7 == 4 1768 entPhysicalClass.7 == port(10) 1769 entPhysicalParentRelPos.7 == 3 1770 entPhysicalName.7 == 'P3' 1772 Slot 2 contains another 3-port module: 1773 entPhysicalDescr.8 == "Acme Router-100 Comm Module: Rev C" 1774 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 1775 entPhysicalContainedIn.8 == 3 1776 entPhysicalClass.8 == module(9) 1777 entPhysicalParentRelPos.8 == 1 1778 entPhysicalName.8 == 'M2' 1780 entPhysicalDescr.9 == "Acme Fddi-100 Port Rev CC" 1781 entPhysicalVendorType.9 == acmeProducts.portTypes.5 1782 entPhysicalContainedIn.9 == 8 1783 entPhysicalClass.9 == port(10) 1784 entPhysicalParentRelPos.9 == 1 1785 entPhysicalName.9 == 'FDDI Primary' 1787 entPhysicalDescr.10 == "Acme Ethernet-100 Port Rev G" 1788 entPhysicalVendorType.10 == acmeProducts.portTypes.2 1789 entPhysicalContainedIn.10 == 8 1790 entPhysicalClass.10 == port(10) 1791 entPhysicalParentRelPos.10 == 2 1792 entPhysicalName.10 == 'Ethernet A' 1793 entPhysicalDescr.11 == "Acme Ethernet-100 Port Rev G" 1794 entPhysicalVendorType.11 == acmeProducts.portTypes.2 1795 entPhysicalContainedIn.11 == 8 1796 entPhysicalClass.11 == port(10) 1797 entPhysicalParentRelPos.11 == 3 1798 entPhysicalName.11 == 'Ethernet B' 1800 Logical entities -- entLogicalTable 1801 2 OSPF instances: 1802 entLogicalDescr.1 == "Acme OSPF v1.1" 1803 entLogicalType.1 == ospf 1804 entLogicalCommunity.1 == "public-ospf1" 1805 entLogicalTAddress.1 == 124.125.126.127:161 1806 entLogicalTDomain.1 == snmpUDPDomain 1808 entLogicalDescr.2 == "Acme OSPF v1.1" 1809 entLogicalType.2 == ospf 1810 entLogicalCommunity.2 == "public-ospf2" 1811 entLogicalTAddress.2 == 124.125.126.127:161 1812 entLogicalTDomain.2 == snmpUDPDomain 1814 2 logical bridges: 1815 entLogicalDescr.3 == "Acme Bridge v2.1.1" 1816 entLogicalType.3 == dod1dBridge 1817 entLogicalCommunity.3 == "public-bridge1" 1818 entLogicalTAddress.3 == 124.125.126.127:161 1819 entLogicalTDomain.3 == snmpUDPDomain 1821 entLogicalDescr.4 == "Acme Bridge v2.1.1" 1822 entLogicalType.4 == dod1dBridge 1823 entLogicalCommunity.4 == "public-bridge2" 1824 entLogicalTAddress.4 == 124.125.126.127:161 1825 entLogicalTDomain.4 == snmpUDPDomain 1827 Logical to Physical Mappings: 1828 1st OSPF instance: uses module 1-port 1 1829 entLPPhysicalIndex.1.5 == 5 1831 2nd OSPF instance: uses module 2-port 1 1832 entLPPhysicalIndex.2.9 == 9 1834 1st bridge group: uses module 1, all ports 1836 [ed. -- Note that these mappings are included in the table since 1837 another logical entity (1st OSPF) utilizes one of the 1838 ports. If this were not the case, then a single mapping 1839 to the module (e.g. entLPPhysicalIndex.3.4) would be 1840 present instead. ] 1841 entLPPhysicalIndex.3.5 == 5 1842 entLPPhysicalIndex.3.6 == 6 1843 entLPPhysicalIndex.3.7 == 7 1845 2nd bridge group: uses module 2, all ports 1846 entLPPhysicalIndex.4.9 == 9 1847 entLPPhysicalIndex.4.10 == 10 1848 entLPPhysicalIndex.4.11 == 11 1850 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 1851 Example 1: ifIndex values are global to all logical entities 1852 entAliasMappingIdentifier.5.0 == ifIndex.1 1853 entAliasMappingIdentifier.6.0 == ifIndex.2 1854 entAliasMappingIdentifier.7.0 == ifIndex.3 1855 entAliasMappingIdentifier.9.0 == ifIndex.4 1856 entAliasMappingIdentifier.10.0 == ifIndex.5 1857 entAliasMappingIdentifier.11.0 == ifIndex.6 1859 Example 2: ifIndex values are not shared by all logical entities 1860 entAliasMappingIdentifier.5.0 == ifIndex.1 1861 entAliasMappingIdentifier.5.3 == ifIndex.101 1862 entAliasMappingIdentifier.6.0 == ifIndex.2 1863 entAliasMappingIdentifier.6.3 == ifIndex.102 1864 entAliasMappingIdentifier.7.0 == ifIndex.3 1865 entAliasMappingIdentifier.7.3 == ifIndex.103 1866 entAliasMappingIdentifier.9.0 == ifIndex.4 1867 entAliasMappingIdentifier.9.3 == ifIndex.204 1868 entAliasMappingIdentifier.10.0 == ifIndex.5 1869 entAliasMappingIdentifier.10.3 == ifIndex.205 1870 entAliasMappingIdentifier.11.0 == ifIndex.6 1871 entAliasMappingIdentifier.11.3 == ifIndex.206 1873 Physical Containment Tree -- entPhysicalContainsTable 1874 chassis has two containers: 1875 entPhysicalChildIndex.1.2 = 2 1876 entPhysicalChildIndex.1.3 = 3 1878 container 1 has a module: 1879 entPhysicalChildIndex.2.4 = 4 1881 container 2 has a module: 1882 entPhysicalChildIndex.3.8 = 8 1884 module 1 has 3 ports: 1885 entPhysicalChildIndex.4.5 = 5 1886 entPhysicalChildIndex.4.6 = 6 1887 entPhysicalChildIndex.4.7 = 7 1889 module 2 has 3 ports: 1890 entPhysicalChildIndex.8.9 = 9 1891 entPhysicalChildIndex.8.10 = 10 1892 entPhysicalChildIndex.1.11 = 11 1894 6.2. Repeaters 1896 A 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, 1897 and the remaining slots contain ethernet repeater modules. [ed. -- Note 1898 that a replacement for the current Repeater MIB (RFC 1516) is likely to 1899 emerge soon, and it will no longer be necessary to access repeater MIB 1900 data in different naming scopes.] 1902 Physical entities -- entPhysicalTable: 1903 1 Field-replaceable physical chassis: 1904 entPhysicalDescr.1 == "Acme Chassis Model 110" 1905 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 1906 entPhysicalContainedIn.1 == 0 1907 entPhysicalClass.1 == chassis(3) 1908 entPhysicalParentRelPos.1 == 0 1909 entPhysicalName.1 == '110-B' 1911 2 Chassis Ethernet Backplanes: 1912 entPhysicalDescr.2 == "Acme Ethernet Backplane Type A" 1913 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 1914 entPhysicalContainedIn.2 == 1 1915 entPhysicalClass.2 == backplane(4) 1916 entPhysicalParentRelPos.2 == 1 1917 entPhysicalName.2 == 'B1' 1919 entPhysicalDescr.3 == "Acme Ethernet Backplane Type A" 1920 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 1921 entPhysicalContainedIn.3 == 1 1922 entPhysicalClass.3 == backplane(4) 1923 entPhysicalParentRelPos.3 == 2 1924 entPhysicalName.3 == 'B2' 1926 3 slots within the chassis: 1927 entPhysicalDescr.4 == "Acme Hub Slot Type RB" 1928 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 1929 entPhysicalContainedIn.4 == 1 1930 entPhysicalClass.4 == container(5) 1931 entPhysicalParentRelPos.4 == 1 1932 entPhysicalName.4 == 'Slot 1' 1934 entPhysicalDescr.5 == "Acme Hub Slot Type RB" 1935 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 1936 entPhysicalContainedIn.5 == 1 1937 entPhysicalClass.5 == container(5) 1938 entPhysicalParentRelPos.5 == 2 1939 entPhysicalName.5 == 'Slot 2' 1941 entPhysicalDescr.6 == "Acme Hub Slot Type RB" 1942 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 1943 entPhysicalContainedIn.6 == 1 1944 entPhysicalClass.6 == container(5) 1945 entPhysicalParentRelPos.6 == 3 1946 entPhysicalName.6 == 'Slot 3' 1948 Slot 1 contains a plug-in module with 4 10-BaseT ports: 1949 entPhysicalDescr.7 == "Acme 10Base-T Module 114 Rev A" 1950 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 1951 entPhysicalContainedIn.7 == 4 1952 entPhysicalClass.7 == module(9) 1953 entPhysicalParentRelPos.7 == 1 1954 entPhysicalName.7 == 'M1' 1956 entPhysicalDescr.8 == "Acme 10Base-T Port RB Rev A" 1957 entPhysicalVendorType.8 == acmeProducts.portTypes.10 1958 entPhysicalContainedIn.8 == 7 1959 entPhysicalClass.8 == port(10) 1960 entPhysicalParentRelPos.8 == 1 1961 entPhysicalName.8 == 'Ethernet-A' 1963 entPhysicalDescr.9 == "Acme 10Base-T Port RB Rev A" 1964 entPhysicalVendorType.9 == acmeProducts.portTypes.10 1965 entPhysicalContainedIn.9 == 7 1966 entPhysicalClass.9 == port(10) 1967 entPhysicalParentRelPos.9 == 2 1968 entPhysicalName.9 == 'Ethernet-B' 1970 entPhysicalDescr.10 == "Acme 10Base-T Port RB Rev B" 1971 entPhysicalVendorType.10 == acmeProducts.portTypes.10 1972 entPhysicalContainedIn.10 == 7 1973 entPhysicalClass.10 == port(10) 1974 entPhysicalParentRelPos.10 == 3 1975 entPhysicalName.10 == 'Ethernet-C' 1977 entPhysicalDescr.11 == "Acme 10Base-T Port RB Rev B" 1978 entPhysicalVendorType.11 == acmeProducts.portTypes.10 1979 entPhysicalContainedIn.11 == 7 1980 entPhysicalClass.11 == port(10) 1981 entPhysicalParentRelPos.11 == 4 1982 entPhysicalName.11 == 'Ethernet-D' 1984 Slot 2 contains another ethernet module with 2 ports. 1985 entPhysicalDescr.12 == "Acme 10Base-T Module Model 4 Rev A" 1986 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 1987 entPhysicalContainedIn.12 = 5 1988 entPhysicalClass.12 == module(9) 1989 entPhysicalParentRelPos.12 == 1 1990 entPhysicalName.12 == 'M2' 1992 entPhysicalDescr.13 == "Acme 802.3 AUI Port Rev A" 1993 entPhysicalVendorType.13 == acmeProducts.portTypes.11 1994 entPhysicalContainedIn.13 == 12 1995 entPhysicalClass.13 == port(10) 1996 entPhysicalParentRelPos.13 == 1 1997 entPhysicalName.13 == 'AUI' 1999 entPhysicalDescr.14 == "Acme 10Base-T Port RD Rev B" 2000 entPhysicalVendorType.14 == acmeProducts.portTypes.14 2001 entPhysicalContainedIn.14 == 12 2002 entPhysicalClass.14 == port(10) 2003 entPhysicalParentRelPos.14 == 2 2004 entPhysicalName.14 == 'E2' 2006 Logical entities -- entLogicalTable 2007 Repeater 1--comprised of any ports attached to backplane 1 2008 entLogicalDescr.1 == "Acme repeater v3.1" 2009 entLogicalType.1 == snmpDot3RptrMgt 2010 entLogicalCommunity.1 "public-repeater1" 2011 entLogicalTAddress.1 == 124.125.126.127:161 2012 entLogicalTDomain.1 == snmpUDPDomain 2014 Repeater 2--comprised of any ports attached to backplane 2: 2015 entLogicalDescr.2 == "Acme repeater v3.1" 2016 entLogicalType.2 == snmpDot3RptrMgt 2017 entLogicalCommunity.2 == "public-repeater2" 2018 entLogicalTAddress.2 == 124.125.126.127:161 2019 entLogicalTDomain.2 == snmpUDPDomain 2021 Logical to Physical Mappings -- entLPMappingTable: 2023 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 2024 [ed. -- Note that a mapping to the module is not included, 2025 since in this example represents a port-switchable hub. 2026 Even though all ports on the module could belong to the 2027 same repeater as a matter of configuration, the LP port 2028 mappings should not be replaced dynamically with a single 2029 mapping for the module (e.g. entLPPhysicalIndex.1.7). 2030 If all ports on the module shared a single backplane connection, 2031 then a single mapping for the module would be more appropriate. ] 2033 entLPPhysicalIndex.1.2 == 2 2034 entLPPhysicalIndex.1.8 == 8 2035 entLPPhysicalIndex.1.9 == 9 2036 entLPPhysicalIndex.1.13 == 13 2038 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 2039 entLPPhysicalIndex.2.3 == 3 2040 entLPPhysicalIndex.2.10 == 10 2041 entLPPhysicalIndex.2.11 == 11 2042 entLPPhysicalIndex.2.14 == 14 2044 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2045 Repeater Port Identifier values are shared by both repeaters: 2046 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 2047 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 2048 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 2049 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 2050 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 2051 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 2053 Physical Containment Tree -- entPhysicalContainsTable 2054 chassis has two backplanes and three containers: 2055 entPhysicalChildIndex.1.2 = 2 2056 entPhysicalChildIndex.1.3 = 3 2057 entPhysicalChildIndex.1.4 = 4 2058 entPhysicalChildIndex.1.5 = 5 2059 entPhysicalChildIndex.1.6 = 6 2061 container 1 has a module: 2062 entPhysicalChildIndex.4.7 = 7 2064 container 2 has a module 2065 entPhysicalChildIndex.5.12 = 12 2066 [ed. - in this example, container 3 is empty.] 2068 module 1 has 4 ports: 2069 entPhysicalChildIndex.7.8 = 8 2070 entPhysicalChildIndex.7.9 = 9 2071 entPhysicalChildIndex.7.10 = 10 2072 entPhysicalChildIndex.7.11 = 11 2074 module 2 has 2 ports: 2075 entPhysicalChildIndex.12.13 = 13 2076 entPhysicalChildIndex.12.14 = 14 2078 7. Acknowledgements 2080 This memo has been produced by the IETF's Entity MIB working-group. 2082 8. References 2084 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2085 Describing SNMP Management Frameworks", RFC 2271, Cabletron 2086 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 2087 January 1998 2089 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 2090 Management Information for TCP/IP-based Internets", RFC 1155, 2091 Performance Systems International, Hughes LAN Systems, May 1990 2093 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 2094 Performance Systems International, Hughes LAN Systems, March 1991 2096 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 2097 RFC 1215, Performance Systems International, March 1991 2099 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2100 Waldbusser, "Structure of Management Information for Version 2 of 2101 the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP 2102 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2103 International Network Services, January 1996. 2105 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2106 Waldbusser, "Textual Conventions for Version 2 of the Simple 2107 Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, 2108 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2109 International Network Services, January 1996. 2111 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2112 Waldbusser, "Conformance Statements for Version 2 of the Simple 2113 Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, 2114 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2115 International Network Services, January 1996. 2117 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2118 Management Protocol", RFC 1157, SNMP Research, Performance Systems 2119 International, Performance Systems International, MIT Laboratory 2120 for Computer Science, May 1990. 2122 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2123 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 2124 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 2125 Inc., International Network Services, January 1996. 2127 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2128 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 2129 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco 2130 Systems, Inc., Dover Beach Consulting, Inc., International Network 2131 Services, January 1996. 2133 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2134 Processing and Dispatching for the Simple Network Management 2135 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 2136 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 2138 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 2139 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2140 2274, IBM T. J. Watson Research, January 1998. 2142 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2143 Waldbusser, "Protocol Operations for Version 2 of the Simple 2144 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 2145 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2146 International Network Services, January 1996. 2148 [14] Levi, D., Meyer, P., and B. Stewart, MPv3 Applications", RFC 2273, 2149 SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, 2150 January 1998. 2152 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 2153 Control Model (VACM) for the Simple Network Management Protocol 2154 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 2155 Cisco Systems, Inc., January 1998. 2157 [16] McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, 2158 Cisco Systems, October 1996. 2160 [17] McCloghrie, K., Kastenholz, F., "The Interfaces Group MIB Using 2161 SMIv2", RFC 2233, Cisco Systems, FTP Software, November, 1997. 2163 9. Security Considerations 2165 In order to implement this MIB, an agent must make certain management 2166 information available about various logical and physical entities within 2167 a managed system, which may be considered sensitive in some network 2168 environments. 2170 Therefore, a network administrator may wish to employ instance-level 2171 access control, and configure the Entity MIB access (e.g., community 2172 strings in SNMPv1 and SNMPv2C), such that certain instances within this 2173 MIB (e.g., entLogicalCommunity, or entire entLogicalEntries, 2174 entPhysicalEntries, and associated mapping table entries), are excluded 2175 from particular MIB views. SNMPv3 agents may also wish to employ 2176 instance-level access control, in order to exclude certain instances 2177 within this MIB (e.g., entLogicalContextEngineID and 2178 entLogicalContextName) from particular MIB views. 2180 10. Authors' Addresses 2182 Keith McCloghrie 2183 Cisco Systems, Inc. 2184 170 West Tasman Drive 2185 San Jose, CA 95134 2186 Phone: 408-526-5260 2187 Email: kzm@cisco.com 2189 Andy Bierman 2190 Cisco Systems, Inc. 2191 170 West Tasman Drive 2192 San Jose, CA 95134 2193 Phone: 408-527-3711 2194 Email: abierman@cisco.com 2196 11. Full Copyright Statement 2198 Copyright (C) The Internet Society (1998). All Rights Reserved. 2200 This document and translations of it may be copied and furnished to 2201 others, and derivative works that comment on or otherwise explain it or 2202 assist in its implementation may be prepared, copied, published and 2203 distributed, in whole or in part, without restriction of any kind, 2204 provided that the above copyright notice and this paragraph are included 2205 on all such copies and derivative works. However, this document itself 2206 may not be modified in any way, such as by removing the copyright notice 2207 or references to the Internet Society or other Internet organizations, 2208 except as needed for the purpose of developing Internet standards in 2209 which case the procedures for copyrights defined in the Internet 2210 Standards process must be followed, or as required to translate it into 2211 languages other than English. 2213 The limited permissions granted above are perpetual and will not be 2214 revoked by the Internet Society or its successors or assigns. 2216 This document and the information contained herein is provided on an "AS 2217 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2218 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2219 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2220 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2221 FITNESS FOR A PARTICULAR PURPOSE." 2222 Table of Contents 2224 1 Copyright Notice ................................................ 1 2225 2 Abstract ........................................................ 2 2226 3 The SNMP Network Management Framework ........................... 2 2227 4 Overview ........................................................ 3 2228 4.1 Terms ......................................................... 4 2229 4.2 Relationship to Community Strings ............................. 5 2230 4.3 Relationship to SNMP Contexts ................................. 5 2231 4.4 Relationship to Proxy Mechanisms .............................. 6 2232 4.5 Relationship to a Chassis MIB ................................. 6 2233 4.6 Relationship to the Interfaces MIB ............................ 6 2234 4.7 Relationship to the Other MIBs ................................ 7 2235 4.8 Relationship to Naming Scopes ................................. 7 2236 4.9 Multiple Instances of the Entity MIB .......................... 7 2237 4.10 Re-Configuration of Entities ................................. 8 2238 4.11 MIB Structure ................................................ 8 2239 4.11.1 entityPhysical Group ....................................... 9 2240 4.11.2 entityLogical Group ........................................ 10 2241 4.11.3 entityMapping Group ........................................ 10 2242 4.11.4 entityGeneral Group ........................................ 10 2243 4.11.5 entityNotifications Group .................................. 11 2244 4.12 Multiple Agents .............................................. 11 2245 4.13 Change Log ................................................... 11 2246 4.13.1 Version 00 ................................................. 11 2247 5 Definitions ..................................................... 12 2248 6 Usage Examples .................................................. 40 2249 6.1 Router/Bridge ................................................. 40 2250 6.2 Repeaters ..................................................... 44 2251 7 Acknowledgements ................................................ 49 2252 8 References ...................................................... 49 2253 9 Security Considerations ......................................... 51 2254 10 Authors' Addresses ............................................. 51 2255 11 Full Copyright Statement ....................................... 52