idnits 2.17.1 draft-ietf-entmib-v3-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2833. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 41), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (22 October 2004) is 7123 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) == Missing Reference: 'RFC2574' is mentioned on line 2706, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Missing Reference: 'RFC2575' is mentioned on line 2707, but not defined ** Obsolete undefined reference: RFC 2575 (Obsoleted by RFC 3415) == Unused Reference: 'RFC2026' is defined on line 2727, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) -- Obsolete informational reference (is this intentional?): RFC 1516 (Obsoleted by RFC 2108) -- Obsolete informational reference (is this intentional?): RFC 2037 (Obsoleted by RFC 2737) -- Obsolete informational reference (is this intentional?): RFC 2737 (Obsoleted by RFC 4133) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Entity MIB Working Group Andy Bierman 3 Internet Draft Keith McCloghrie 4 Cisco Systems, Inc. 5 22 October 2004 7 Entity MIB (Version 3) 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This document may not be modified, and derivative works of it may 36 not be created, except to publish it as an RFC and to translate it 37 into languages other than English. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This memo defines a portion of the Management Information Base 46 (MIB) for use with network management protocols in the Internet 47 community. In particular, it describes managed objects used for 48 managing multiple logical and physical entities managed by a single 49 SNMP agent. This document specifies version 3 of the Entity MIB, 50 which obsoletes version 2 (RFC 2737). 52 Table of Contents 54 1 The SNMP Management Framework .............................. 3 55 2 Overview ................................................... 3 56 2.1 Terms .................................................... 4 57 2.2 Relationship to Community Strings ........................ 6 58 2.3 Relationship to SNMP Contexts ............................ 6 59 2.4 Relationship to Proxy Mechanisms ......................... 6 60 2.5 Relationship to a Chassis MIB ............................ 7 61 2.6 Relationship to the Interfaces MIB ....................... 7 62 2.7 Relationship to the Other MIBs ........................... 7 63 2.8 Relationship to Naming Scopes ............................ 8 64 2.9 Multiple Instances of the Entity MIB ..................... 8 65 2.10 Re-Configuration of Entities ............................ 9 66 2.11 Textual Convention Change ............................... 9 67 2.12 MIB Structure ........................................... 9 68 2.12.1 entityPhysical Group .................................. 10 69 2.12.2 entityLogical Group ................................... 11 70 2.12.3 entityMapping Group ................................... 12 71 2.12.4 entityGeneral Group ................................... 12 72 2.12.5 entityNotifications Group ............................. 13 73 2.13 Multiple Agents ......................................... 13 74 2.14 Changes Since RFC 2037 .................................. 13 75 2.14.1 Textual Conventions ................................... 13 76 2.14.2 New entPhysicalTable Objects .......................... 13 77 2.14.3 New entLogicalTable Objects ........................... 14 78 2.14.4 Bugfixes .............................................. 14 79 2.15 Changes Since RFC 2737 .................................. 14 80 2.15.1 Textual Conventions ................................... 14 81 2.15.2 New Objects ........................................... 15 82 2.15.3 Deprecated Objects .................................... 15 83 2.15.4 Bugfixes .............................................. 15 84 3 Definitions ................................................ 16 85 4 Usage Examples ............................................. 48 86 4.1 Router/Bridge ............................................ 48 87 4.2 Repeaters ................................................ 54 88 5 Security Considerations .................................... 62 89 6 IANA Considerations ........................................ 64 90 7 Acknowledgements ........................................... 64 91 8 References ................................................. 64 92 8.1 Normative References ..................................... 64 93 8.2 Informative References ................................... 65 95 1. The SNMP Management Framework 97 For a detailed overview of the documents that describe the current 98 Internet-Standard Management Framework, please refer to section 7 99 of RFC 3410 [RFC3410]. 101 Managed objects are accessed via a virtual information store, 102 termed the Management Information Base or MIB. MIB objects are 103 generally accessed through the Simple Network Management Protocol 104 (SNMP). Objects in the MIB are defined using the mechanisms 105 defined in the Structure of Management Information (SMI). This 106 memo specifies a MIB module that is compliant to the SMIv2, which 107 is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 108 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 110 2. Overview 112 There is a need for a standardized way of representing a single 113 agent which supports multiple instances of one MIB. This is 114 presently true for at least 3 standard MIBs, and is likely to 115 become true for more and more MIBs as time passes. For example: 117 - multiple instances of a bridge supported within a single device 118 having a single agent; 120 - multiple repeaters supported by a single agent; 122 - multiple OSPF backbone areas, each one operating as part of its own 123 Autonomous System, and each identified by the same area-id (e.g., 124 0.0.0.0), supported inside a single router with one agent. 126 The fact that it is a single agent in each of these cases implies 127 there is some relationship which binds all of these entities 128 together. Effectively, there is some "overall" physical entity 129 which houses the sum of the things managed by that one agent, i.e., 130 there are multiple "logical" entities within a single physical 131 entity. Sometimes, the overall physical entity contains multiple 132 (smaller) physical entities and each logical entity is associated 133 with a particular physical entity. Sometimes, the overall physical 134 entity is a "compound" of multiple physical entities (e.g., a stack 135 of stackable hubs). 137 What is needed is a way to determine exactly what logical entities 138 are managed by the agent (with some version of SNMP), and thereby 139 to be able to communicate with the agent about a particular logical 140 entity. When different logical entities are associated with 141 different physical entities within the overall physical entity, it 142 is also useful to be able to use this information to distinguish 143 between logical entities. 145 In these situations, there is no need for varbinds for multiple 146 logical entities to be referenced in the same SNMP message 147 (although that might be useful in the future). Rather, it is 148 sufficient, and in some situations preferable, to have the 149 context/community in the message identify the logical entity to 150 which the varbinds apply. 152 Version 2 of this MIB addresses new requirements that have emerged 153 since the publication of the first Entity MIB (RFC 2037 [RFC2037]). 154 There is a need for a standardized way of providing non-volatile, 155 administratively assigned identifiers for physical components 156 represented with the Entity MIB. There is also a need to align the 157 Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 158 3411 [RFC3411]). Implementation experience has shown that 159 additional physical component attributes are also desirable. 161 Version 3 of this MIB addresses new requirements that have emerged 162 since the publication of the second Entity MIB (RFC 2737 163 [RFC2737]). There is a need for identifying physical entities 164 which are central processing units (CPUs) and a need to provide a 165 textual convention which identifies an entPhysicalIndex value or 166 zero, where the value zero has application-specific semantics. 168 2.1. Terms 170 Some new terms are used throughout this document: 172 - Naming Scope 173 A "naming scope" represents the set of information that may be 174 potentially accessed through a single SNMP operation. All instances 175 within the naming scope share the same unique identifier space. 176 For SNMPv1, a naming scope is identified by the value of the 177 associated 'entLogicalCommunity' instance. For SNMPv3, the term 178 'context' is used instead of 'naming scope'. The complete 179 definition of an SNMP context can be found in section 3.3.1 of RFC 180 3411 [RFC3411]. 182 - Multi-Scoped Object 183 A MIB object, for which identical instance values identify 184 different managed information in different naming scopes, is called 185 a "multi-scoped" MIB object. 187 - Single-Scoped Object 188 A MIB object, for which identical instance values identify the same 189 managed information in different naming scopes, is called a 190 "single-scoped" MIB object. 192 - Logical Entity 193 A managed system contains one or more logical entities, each 194 represented by at most one instantiation of each of a particular 195 set of MIB objects. A set of management functions is associated 196 with each logical entity. Examples of logical entities include 197 routers, bridges, print-servers, etc. 199 - Physical Entity 200 A "physical entity" or "physical component" represents an 201 identifiable physical resource within a managed system. Zero or 202 more logical entities may utilize a physical resource at any given 203 time. It is an implementation-specific manner as to which physical 204 components are represented by an agent in the EntPhysicalTable. 205 Typically, physical resources (e.g., communications ports, 206 backplanes, sensors, daughter-cards, power supplies, the overall 207 chassis) which can be managed via functions associated with one or 208 more logical entities are included in the MIB. 210 - Containment Tree 211 Each physical component may be modeled as 'contained' within 212 another physical component. A "containment-tree" is the conceptual 213 sequence of entPhysicalIndex values which uniquely specifies the 214 exact physical location of a physical component within the managed 215 system. It is generated by 'following and recording' each 216 'entPhysicalContainedIn' instance 'up the tree towards the root', 217 until a value of zero indicating no further containment is found. 219 2.2. Relationship to Community Strings 221 For community-based SNMP, distinguishing between different logical 222 entities is one (but not the only) purpose of the community string 223 (RFC 1157 [RFC1157]). This is accommodated by representing each 224 community string as a logical entity. 226 Note that different logical entities may share the same naming 227 scope (and therefore the same values of entLogicalCommunity). This 228 is possible, providing they have no need for the same instance of a 229 MIB object to represent different managed information. 231 2.3. Relationship to SNMP Contexts 233 Version 2 of the Entity MIB contains support for associating SNMPv3 234 contexts with logical entities. Two new MIB objects, defining an 235 SnmpEngineID and ContextName pair, are used together to identify an 236 SNMP context associated with a logical entity. This context can be 237 used (in conjunction with the entLogicalTAddress and 238 entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of 239 a particular logical entity. 241 2.4. Relationship to Proxy Mechanisms 243 The Entity MIB is designed to allow functional component discovery. 244 The administrative relationships between different logical entities 245 are not visible in any Entity MIB tables. An NMS cannot determine 246 whether MIB instances in different naming scopes are realized 247 locally or remotely (e.g., via some proxy mechanism) by examining 248 any particular Entity MIB objects. 250 The management of administrative framework functions is not an 251 explicit goal of the Entity MIB WG at this time. This new area of 252 functionality may be revisited after some operational experience 253 with the Entity MIB is gained. 255 Note that for community-based versions of SNMP, a network 256 administrator will likely be able to associate community strings 257 with naming scopes with proprietary mechanisms, as a matter of 258 configuration. There are no mechanisms for managing naming scopes 259 defined in this MIB. 261 2.5. Relationship to a Chassis MIB 263 Some readers may recall that a previous IETF working group 264 attempted to define a Chassis MIB. No consensus was reached by 265 that working group, possibly because its scope was too broad. As 266 such, it is not the purpose of this MIB to be a "Chassis MIB 267 replacement", nor is it within the scope of this MIB to contain all 268 the information which might be necessary to manage a "chassis". On 269 the other hand, the entities represented by an implementation of 270 this MIB might well be contained in a chassis. 272 2.6. Relationship to the Interfaces MIB 274 The Entity MIB contains a mapping table identifying physical 275 components that have 'external values' (e.g., ifIndex) associated 276 with them within a given naming scope. This table can be used to 277 identify the physical location of each interface in the ifTable 278 (RFC 2863 [RFC2863]). Since ifIndex values in different contexts 279 are not related to one another, the interface to physical component 280 associations are relative to the same logical entity within the 281 agent. 283 The Entity MIB also contains 'entPhysicalName' and 284 'entPhysicalAlias' objects, which approximate the semantics of the 285 'ifName' and 'ifAlias' objects (respectively) from the Interfaces 286 MIB [RFC2863], for all types of physical components. 288 2.7. Relationship to the Other MIBs 290 The Entity MIB contains a mapping table identifying physical 291 components that have identifiers from other standard MIBs 292 associated with them. For example, this table can be used along 293 with the physical mapping table to identify the physical location 294 of each repeater port in the rptrPortTable, or each interface in 295 the ifTable. 297 2.8. Relationship to Naming Scopes 299 There is some question as to which MIB objects may be returned 300 within a given naming scope. MIB objects which are not multi-scoped 301 within a managed system are likely to ignore context information in 302 implementation. In such a case, it is likely such objects will be 303 returned in all naming scopes (e.g., not just the 'default' naming 304 scope or the SNMPv3 default context). 306 For example, a community string used to access the management 307 information for logical device 'bridge2' may allow access to all 308 the non-bridge related objects in the 'default' naming scope, as 309 well as a second instance of the Bridge MIB (RFC 1493 [RFC1493]). 311 It is an implementation-specific matter as to the isolation of 312 single-scoped MIB objects by the agent. An agent may wish to limit 313 the objects returned in a particular naming scope to just the 314 multi-scoped objects in that naming scope (e.g., system group and 315 the Bridge MIB). In this case, all single-scoped management 316 information would belong to a common naming scope (e.g., 317 'default'), which itself may contain some multi-scoped objects 318 (e.g., system group). 320 2.9. Multiple Instances of the Entity MIB 322 It is possible that more than one agent exists in a managed system, 323 and in such cases, multiple instances of the Entity MIB 324 (representing the same managed objects) may be available to an NMS. 326 In order to reduce complexity for agent implementation, multiple 327 instances of the Entity MIB are not required to be equivalent or 328 even consistent. An NMS may be able to 'align' instances returned 329 by different agents by examining the columns of each table, but 330 vendor-specific identifiers and (especially) index values are 331 likely to be different. Each agent may be managing different 332 subsets of the entire chassis as well. 334 When all of a physically-modular device is represented by a single 335 agent, the entry for which entPhysicalContainedIn has the value 336 zero would likely have 'chassis' as the value of its 337 entPhysicalClass; alternatively, for an agent on a module where the 338 agent represents only the physical entities on that module (not 339 those on other modules), the entry for which entPhysicalContainedIn 340 has the value zero would likely have 'module' as the value of its 341 entPhysicalClass. 343 An agent implementation of the entLogicalTable is not required to 344 contain information about logical entities managed primarily by 345 other agents. That is, the entLogicalTAddress and entLogicalTDomain 346 objects in the entLogicalTable are provided to support an 347 historical multiplexing mechanism, not to identify other SNMP 348 agents. 350 Note that the Entity MIB is a single-scoped MIB, in the event an 351 agent represents the MIB in different naming scopes. 353 2.10. Re-Configuration of Entities 355 Most of the MIB objects defined in this MIB have at most a read- 356 only MAX-ACCESS clause. This is a conscious decision by the 357 working group to limit this MIB's scope. The second version of the 358 Entity MIB allows a network administrator to configure some common 359 attributes of physical components. 361 2.11. Textual Convention Change 363 Version 1 of the Entity MIB contains three MIB objects defined with 364 the (now obsolete) DisplayString textual convention. In version 2 365 of the Entity MIB, the syntax for these objects has been updated to 366 use the (now preferred) SnmpAdminString textual convention. 368 The working group realizes that this change is not strictly 369 supported by SMIv2. In our judgment, the alternative of 370 deprecating the old objects and defining new objects would have a 371 more adverse impact on backward compatibility and interoperability, 372 given the particular semantics of these objects. 374 2.12. MIB Structure 376 The Entity MIB contains five groups of MIB objects: 378 - entityPhysical group 379 Describes the physical entities managed by a single agent. 381 - entityLogical group 382 Describes the logical entities managed by a single agent. 384 - entityMapping group 385 Describes the associations between the physical entities, logical 386 entities, interfaces, and non-interface ports managed by a single 387 agent. 389 - entityGeneral group 390 Describes general system attributes shared by potentially all types 391 of entities managed by a single agent. 393 - entityNotifications group 394 Contains status indication notifications. 396 2.12.1. entityPhysical Group 398 This group contains a single table to identify physical system 399 components, called the entPhysicalTable. 401 The entPhysicalTable contains one row per physical entity, and must 402 always contain at least one row for an "overall" physical entity, 403 which should have an entPhysicalClass value of 'stack(11)', 404 'chassis(3)' or 'module(9)'. 406 Each row is indexed by an arbitrary, small integer, and contains a 407 description and type of the physical entity. It also optionally 408 contains the index number of another entPhysicalEntry indicating a 409 containment relationship between the two. 411 Version 2 of the Entity MIB provides additional MIB objects for 412 each physical entity. Some common read-only attributes have been 413 added, as well as three writable string objects. 415 - entPhysicalAlias 416 This string can be used by an NMS as a non-volatile identifier for 417 the physical component. Maintaining a non-volatile string for every 418 physical component represented in the entPhysicalTable can be 419 costly and unnecessary. An agent may algorithmically generate 420 'entPhysicalAlias' strings for particular entries (e.g., based on 421 the entPhysicalClass value). 423 - entPhysicalAssetID 424 This string is provided to store a user-specific asset identifier 425 for removable physical components. In order to reduce the non- 426 volatile storage needed by a particular agent, a network 427 administrator should only assign asset identifiers to physical 428 entities which are field-replaceable (i.e., not permanently 429 contained within another physical entity). 431 - entPhysicalSerialNum 432 This string is provided to store a vendor-specific serial number 433 string for physical components. This is a writable object in case 434 an agent cannot identify the serial numbers of all installed 435 physical entities, and a network administrator wishes to configure 436 the non-volatile serial number strings manually (via an NMS 437 application). 439 Version 3 of the Entity MIB provides two additional MIB objects for 440 each physical entity: 442 - entPhysicalMfgDate 443 This object contains the date of manufacturing of the managed 444 entity. If the manufacturing date is unknown or not supported the 445 object is not instantiated. 447 - entPhysicalUris 448 This object provides additional identification information about 449 the physical entity. This object may be used to encode for example 450 a URI containing a Common Language Equipment Identifier (CLEI) URI 451 [reference TBD] for the managed physical entity. If no additional 452 identification information is known or supported about the physical 453 entity the object is not instantiated. 455 2.12.2. entityLogical Group 457 This group contains a single table to identify logical entities, 458 called the entLogicalTable. 460 The entLogicalTable contains one row per logical entity. Each row 461 is indexed by an arbitrary, small integer and contains a name, 462 description, and type of the logical entity. It also contains 463 information to allow access to the MIB information for the logical 464 entity. This includes SNMP versions that use a community name (with 465 some form of implied context representation) and SNMP versions that 466 use the SNMP ARCH [RFC3411] method of context identification. 468 If a agent represents multiple logical entities with this MIB, then 469 this group must be implemented for all logical entities known to 470 the agent. 472 If an agent represents a single logical entity, or multiple logical 473 entities within a single naming scope, then implementation of this 474 group may be omitted by the agent. 476 2.12.3. entityMapping Group 478 This group contains three tables to identify associations between 479 different system components. 481 The entLPMappingTable contains mappings between entLogicalIndex 482 values (logical entities) and entPhysicalIndex values (the physical 483 components supporting that entity). A logical entity can map to 484 more than one physical component, and more than one logical entity 485 can map to (share) the same physical component. If an agent 486 represents a single logical entity, or multiple logical entities 487 within a single naming scope, then implementation of this table may 488 be omitted by the agent. Note that this table is deprecated in 489 version 3 of the Entity MIB. 491 The entAliasMappingTable contains mappings between entLogicalIndex, 492 entPhysicalIndex pairs and 'alias' object identifier values. This 493 allows resources managed with other MIBs (e.g., repeater ports, 494 bridge ports, physical and logical interfaces) to be identified in 495 the physical entity hierarchy. Note that each alias identifier is 496 only relevant in a particular naming scope. If an agent represents 497 a single logical entity, or multiple logical entities within a 498 single naming scope, then implementation of this table may be 499 omitted by the agent. 501 The entPhysicalContainsTable contains simple mappings between 502 'entPhysicalContainedIn' values for each container/'containee' 503 relationship in the managed system. The indexing of this table 504 allows an NMS to quickly discover the 'entPhysicalIndex' values for 505 all children of a given physical entity. 507 2.12.4. entityGeneral Group 509 This group contains general information relating to the other 510 object groups. 512 At this time, the entGeneral group contains a single scalar object 513 (entLastChangeTime), which represents the value of sysUptime when 514 any part of the Entity MIB configuration last changed. 516 2.12.5. entityNotifications Group 518 This group contains notification definitions relating to the 519 overall status of the Entity MIB instantiation. 521 2.13. Multiple Agents 523 Even though a primary motivation for this MIB is to represent the 524 multiple logical entities supported by a single agent, it is also 525 possible to use it to represent multiple logical entities supported 526 by multiple agents (in the same "overall" physical entity). 527 Indeed, it is implicit in the SNMP architecture, that the number of 528 agents is transparent to a network management station. 530 However, there is no agreement at this time as to the degree of 531 cooperation which should be expected for agent implementations. 532 Therefore, multiple agents within the same managed system are free 533 to implement the Entity MIB independently. (Refer the section on 534 "Multiple Instances of the Entity MIB" for more details). 536 2.14. Changes Since RFC 2037 538 2.14.1. Textual Conventions 540 The PhysicalClass TC text has been clarified, and a new enumeration 541 to support 'stackable' components has been added. The 542 SnmpEngineIdOrNone TC has been added to support SNMPv3. 544 2.14.2. New entPhysicalTable Objects 546 The entPhysicalHardwareRev, entPhysicalFirmwareRev, and 547 entPhysicalSoftwareRev objects have been added for revision 548 identification. 550 The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, 551 and entPhysicalIsFru objects have been added for better vendor 552 identification for physical components. The entPhysicalSerialNum 553 object can be set by a management station in the event the agent 554 cannot identify this information. 556 The entPhysicalAlias and entPhysicalAssetID objects have been added 557 for better user component identification. These objects are 558 intended to be set by a management station and preserved by the 559 agent across restarts. 561 2.14.3. New entLogicalTable Objects 563 The entLogicalContextEngineID and entLogicalContextName objects 564 have been added to provide an SNMP context for SNMPv3 access on 565 behalf of a logical entity. 567 2.14.4. Bugfixes 569 A bug was fixed in the entLogicalCommunity object. The subrange was 570 incorrect (1..255) and is now (0..255). The description clause has 571 also been clarified. This object is now deprecated. 573 The entLastChangeTime object description has been changed to 574 generalize the events which cause an update to the last change 575 timestamp. 577 The syntax was changed from DisplayString to SnmpAdminString for 578 the entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. 580 2.15. Changes Since RFC 2737 582 2.15.1. Textual Conventions 584 The PhysicalIndexOrZero TC has been added to allow objects to 585 reference an entPhysicalIndex value or zero. The PhysicalClass TC 586 has been extended to support a new enumeration for central 587 processing units. 589 2.15.2. New Objects 591 The entPhysicalMfgDate object has been added to the 592 entPhysicalTable to provide the date of manufacturing of the 593 managed entity. 595 The entPhysicalUris object has been added to the entPhysicalTable 596 to provide additional identification information about the physical 597 entity, such as a Common Language Equipment Identifier (CLEI) URI. 599 2.15.3. Deprecated Objects 601 The entLPMappingTable has been deprecated because no 602 implementations have been found which support this table. The 603 entLPPhysicalIndex has been removed from the entityMappingGroup. 604 This OBJECT-GROUP has been updated (entityMappingGroupRev1) as well 605 as the Entity MIB MODULE-CONFORMANCE statement. 607 2.15.4. Bugfixes 609 The syntax was changed from INTEGER to Integer32 for the 610 entPhysicalParentRelPos, entLogicalIndex, and 611 entAliasLogicalIndexOrZero objects, and from INTEGER to 612 PhysicalIndexOrZero for the entPhysicalContainedIn object. 614 3. Definitions 616 ENTITY-MIB DEFINITIONS ::= BEGIN 618 IMPORTS 619 MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, 620 Integer32 621 FROM SNMPv2-SMI 622 TDomain, TAddress, TEXTUAL-CONVENTION, 623 AutonomousType, RowPointer, TimeStamp, TruthValue, 624 DateAndTime 625 FROM SNMPv2-TC 626 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 627 FROM SNMPv2-CONF 628 SnmpAdminString 629 FROM SNMP-FRAMEWORK-MIB; 631 entityMIB MODULE-IDENTITY 632 LAST-UPDATED "200410220000Z" 633 ORGANIZATION "IETF ENTMIB Working Group" 634 CONTACT-INFO 635 " WG E-mail: entmib@ietf.org 636 Mailing list subscription info: 637 http://www.ietf.org/mailman/listinfo/entmib 639 Andy Bierman 640 Cisco Systems Inc. 641 170 West Tasman Drive 642 San Jose, CA 95134 643 +1 408-527-3711 644 abierman@cisco.com 646 Keith McCloghrie 647 Cisco Systems Inc. 648 170 West Tasman Drive 649 San Jose, CA 95134 650 +1 408-526-5260 651 kzm@cisco.com" 653 DESCRIPTION 654 "The MIB module for representing multiple logical 655 entities supported by a single SNMP agent. 657 Copyright (C) The Internet Society (2004). This 658 version of this MIB module is part of RFC xxxx; see 659 the RFC itself for full legal notices." 660 -- RFC Ed.: replace xxxx with actual RFC number & remove this notice 662 REVISION "200410220000Z" 663 DESCRIPTION 664 "Initial Version of Entity MIB (Version 3). 665 This revision obsoletes RFC 2737. 666 Additions: 667 - cpu(12) enumeration added to PhysicalClass TC 668 - PhysicalIndexOrZero TC 669 - entPhysicalMfgDate object 670 - entPhysicalUris object 671 Changes: 672 - entLPMappingTable deprecated 673 - entPhysicalContainedIn SYNTAX changed from 674 INTEGER to PhysicalIndexOrZero 676 This version published as RFC xxxx." 677 -- RFC Ed.: replace xxxx with actual RFC number & remove this notice 679 REVISION "199912070000Z" 680 DESCRIPTION 681 "Initial Version of Entity MIB (Version 2). 682 This revision obsoletes RFC 2037. 683 This version published as RFC 2737." 685 REVISION "199610310000Z" 686 DESCRIPTION 687 "Initial version (version 1), published as 688 RFC 2037." 689 ::= { mib-2 47 } 691 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 693 -- MIB contains four groups 694 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } 695 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } 696 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } 697 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } 699 -- Textual Conventions 700 PhysicalIndex ::= TEXTUAL-CONVENTION 701 STATUS current 702 DESCRIPTION 703 "An arbitrary value which uniquely identifies the physical 704 entity. The value should be a small positive integer; index 705 values for different physical entities are not necessarily 706 contiguous." 707 SYNTAX Integer32 (1..2147483647) 709 PhysicalIndexOrZero ::= TEXTUAL-CONVENTION 710 STATUS current 711 DESCRIPTION 712 "This textual convention is an extension of the 713 PhysicalIndex convention which defines a greater than zero 714 value used to identify a physical entity. This extension 715 permits the additional value of zero. The semantics of the 716 value zero are object-specific and must therefore be defined 717 as part of the description of any object which uses this 718 syntax. Examples of the usage of this extension are 719 situations where none or all physical entities need to be 720 referenced." 721 SYNTAX Integer32 (0..2147483647) 723 PhysicalClass ::= TEXTUAL-CONVENTION 724 STATUS current 725 DESCRIPTION 726 "An enumerated value which provides an indication of the 727 general hardware type of a particular physical entity. 728 There are no restrictions as to the number of 729 entPhysicalEntries of each entPhysicalClass, which must be 730 instantiated by an agent. 732 The enumeration 'other' is applicable if the physical entity 733 class is known, but does not match any of the supported 734 values. 736 The enumeration 'unknown' is applicable if the physical 737 entity class is unknown to the agent. 739 The enumeration 'chassis' is applicable if the physical 740 entity class is an overall container for networking 741 equipment. Any class of physical entity except a stack may 742 be contained within a chassis, and a chassis may only be 743 contained within a stack. 745 The enumeration 'backplane' is applicable if the physical 746 entity class is some sort of device for aggregating and 747 forwarding networking traffic, such as a shared backplane in 748 a modular ethernet switch. Note that an agent may model a 749 backplane as a single physical entity, which is actually 750 implemented as multiple discrete physical components (within 751 a chassis or stack). 753 The enumeration 'container' is applicable if the physical 754 entity class is capable of containing one or more removable 755 physical entities, possibly of different types. For example, 756 each (empty or full) slot in a chassis will be modeled as a 757 container. Note that all removable physical entities should 758 be modeled within a container entity, such as field- 759 replaceable modules, fans, or power supplies. Note that all 760 known containers should be modeled by the agent, including 761 empty containers. 763 The enumeration 'powerSupply' is applicable if the physical 764 entity class is a power-supplying component. 766 The enumeration 'fan' is applicable if the physical entity 767 class is a fan or other heat-reduction component. 769 The enumeration 'sensor' is applicable if the physical 770 entity class is some sort of sensor, such as a temperature 771 sensor within a router chassis. 773 The enumeration 'module' is applicable if the physical 774 entity class is some sort of self-contained sub-system. If 775 it is removable, then it should be modeled within a 776 container entity, otherwise it should be modeled directly 777 within another physical entity (e.g., a chassis or another 778 module). 780 The enumeration 'port' is applicable if the physical entity 781 class is some sort of networking port, capable of receiving 782 and/or transmitting networking traffic. 784 The enumeration 'stack' is applicable if the physical entity 785 class is some sort of super-container (possibly virtual), 786 intended to group together multiple chassis entities. A 787 stack may be realized by a 'virtual' cable, a real 788 interconnect cable, attached to multiple chassis, or may in 789 fact be comprised of multiple interconnect cables. A stack 790 should not be modeled within any other physical entities, 791 but a stack may be contained within another stack. Only 792 chassis entities should be contained within a stack. 794 The enumeration 'cpu' is applicable if the physical entity 795 class is some sort of central processing unit." 796 SYNTAX INTEGER { 797 other(1), 798 unknown(2), 799 chassis(3), 800 backplane(4), 801 container(5), -- e.g., chassis slot or daughter-card holder 802 powerSupply(6), 803 fan(7), 804 sensor(8), 805 module(9), -- e.g., plug-in card or daughter-card 806 port(10), 807 stack(11), -- e.g., stack of multiple chassis entities 808 cpu(12) 809 } 811 SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION 812 STATUS current 813 DESCRIPTION 814 "A specially formatted SnmpEngineID string for use with the 815 Entity MIB. 817 If an instance of an object of SYNTAX SnmpEngineIdOrNone has 818 a non-zero length, then the object encoding and semantics 819 are defined by the SnmpEngineID textual convention (see STD 820 62, RFC 3411 [RFC3411]). 822 If an instance of an object of SYNTAX SnmpEngineIdOrNone 823 contains a zero-length string, then no appropriate 824 SnmpEngineID is associated with the logical entity (i.e., 825 SNMPv3 not supported)." 826 SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID 828 -- The Physical Entity Table 829 entPhysicalTable OBJECT-TYPE 830 SYNTAX SEQUENCE OF EntPhysicalEntry 831 MAX-ACCESS not-accessible 832 STATUS current 833 DESCRIPTION 834 "This table contains one row per physical entity. There is 835 always at least one row for an 'overall' physical entity." 836 ::= { entityPhysical 1 } 838 entPhysicalEntry OBJECT-TYPE 839 SYNTAX EntPhysicalEntry 840 MAX-ACCESS not-accessible 841 STATUS current 842 DESCRIPTION 843 "Information about a particular physical entity. 845 Each entry provides objects (entPhysicalDescr, 846 entPhysicalVendorType, and entPhysicalClass) to help an NMS 847 identify and characterize the entry, and objects 848 (entPhysicalContainedIn and entPhysicalParentRelPos) to help 849 an NMS relate the particular entry to other entries in this 850 table." 851 INDEX { entPhysicalIndex } 852 ::= { entPhysicalTable 1 } 854 EntPhysicalEntry ::= SEQUENCE { 855 entPhysicalIndex PhysicalIndex, 856 entPhysicalDescr SnmpAdminString, 857 entPhysicalVendorType AutonomousType, 858 entPhysicalContainedIn PhysicalIndexOrZero, 859 entPhysicalClass PhysicalClass, 860 entPhysicalParentRelPos Integer32, 861 entPhysicalName SnmpAdminString, 862 entPhysicalHardwareRev SnmpAdminString, 863 entPhysicalFirmwareRev SnmpAdminString, 864 entPhysicalSoftwareRev SnmpAdminString, 865 entPhysicalSerialNum SnmpAdminString, 866 entPhysicalMfgName SnmpAdminString, 867 entPhysicalModelName SnmpAdminString, 868 entPhysicalAlias SnmpAdminString, 869 entPhysicalAssetID SnmpAdminString, 870 entPhysicalIsFRU TruthValue, 871 entPhysicalMfgDate DateAndTime, 872 entPhysicalUris OCTET STRING 874 } 876 entPhysicalIndex OBJECT-TYPE 877 SYNTAX PhysicalIndex 878 MAX-ACCESS not-accessible 879 STATUS current 880 DESCRIPTION 881 "The index for this entry." 882 ::= { entPhysicalEntry 1 } 884 entPhysicalDescr OBJECT-TYPE 885 SYNTAX SnmpAdminString 886 MAX-ACCESS read-only 887 STATUS current 888 DESCRIPTION 889 "A textual description of physical entity. This object 890 should contain a string which identifies the manufacturer's 891 name for the physical entity, and should be set to a 892 distinct value for each version or model of the physical 893 entity. " 894 ::= { entPhysicalEntry 2 } 896 entPhysicalVendorType OBJECT-TYPE 897 SYNTAX AutonomousType 898 MAX-ACCESS read-only 899 STATUS current 900 DESCRIPTION 901 "An indication of the vendor-specific hardware type of the 902 physical entity. Note that this is different from the 903 definition of MIB-II's sysObjectID. 905 An agent should set this object to a enterprise-specific 906 registration identifier value indicating the specific 907 equipment type in detail. The associated instance of 908 entPhysicalClass is used to indicate the general type of 909 hardware device. 911 If no vendor-specific registration identifier exists for 912 this physical entity, or the value is unknown by this agent, 913 then the value { 0 0 } is returned." 914 ::= { entPhysicalEntry 3 } 916 entPhysicalContainedIn OBJECT-TYPE 917 SYNTAX PhysicalIndexOrZero 918 MAX-ACCESS read-only 919 STATUS current 920 DESCRIPTION 921 "The value of entPhysicalIndex for the physical entity which 922 'contains' this physical entity. A value of zero indicates 923 this physical entity is not contained in any other physical 924 entity. Note that the set of 'containment' relationships 925 define a strict hierarchy; that is, recursion is not 926 allowed. 928 In the event a physical entity is contained by more than one 929 physical entity (e.g., double-wide modules), this object 930 should identify the containing entity with the lowest value 931 of entPhysicalIndex." 932 ::= { entPhysicalEntry 4 } 934 entPhysicalClass OBJECT-TYPE 935 SYNTAX PhysicalClass 936 MAX-ACCESS read-only 937 STATUS current 938 DESCRIPTION 939 "An indication of the general hardware type of the physical 940 entity. 942 An agent should set this object to the standard enumeration 943 value which most accurately indicates the general class of 944 the physical entity, or the primary class if there is more 945 than one. 947 If no appropriate standard registration identifier exists 948 for this physical entity, then the value 'other(1)' is 949 returned. If the value is unknown by this agent, then the 950 value 'unknown(2)' is returned." 951 ::= { entPhysicalEntry 5 } 953 entPhysicalParentRelPos OBJECT-TYPE 954 SYNTAX Integer32 (-1..2147483647) 955 MAX-ACCESS read-only 956 STATUS current 957 DESCRIPTION 958 "An indication of the relative position of this 'child' 959 component among all its 'sibling' components. Sibling 960 components are defined as entPhysicalEntries which share the 961 same instance values of each of the entPhysicalContainedIn 962 and entPhysicalClass objects. 964 An NMS can use this object to identify the relative ordering 965 for all sibling components of a particular parent 966 (identified by the entPhysicalContainedIn instance in each 967 sibling entry). 969 This value should match any external labeling of the 970 physical component if possible. For example, for a container 971 (e.g., card slot) labeled as 'slot #3', 972 entPhysicalParentRelPos should have the value '3'. Note 973 that the entPhysicalEntry for the module plugged in slot 3 974 should have an entPhysicalParentRelPos value of '1'. 976 If the physical position of this component does not match 977 any external numbering or clearly visible ordering, then 978 user documentation or other external reference material 979 should be used to determine the parent-relative position. If 980 this is not possible, then the the agent should assign a 981 consistent (but possibly arbitrary) ordering to a given set 982 of 'sibling' components, perhaps based on internal 983 representation of the components. 985 If the agent cannot determine the parent-relative position 986 for some reason, or if the associated value of 987 entPhysicalContainedIn is '0', then the value '-1' is 988 returned. Otherwise a non-negative integer is returned, 989 indicating the parent-relative position of this physical 990 entity. 992 Parent-relative ordering normally starts from '1' and 993 continues to 'N', where 'N' represents the highest 994 positioned child entity. However, if the physical entities 995 (e.g., slots) are labeled from a starting position of zero, 996 then the first sibling should be associated with a 997 entPhysicalParentRelPos value of '0'. Note that this 998 ordering may be sparse or dense, depending on agent 999 implementation. 1001 The actual values returned are not globally meaningful, as 1002 each 'parent' component may use different numbering 1003 algorithms. The ordering is only meaningful among siblings 1004 of the same parent component. 1006 The agent should retain parent-relative position values 1007 across reboots, either through algorithmic assignment or use 1008 of non-volatile storage." 1009 ::= { entPhysicalEntry 6 } 1011 entPhysicalName OBJECT-TYPE 1012 SYNTAX SnmpAdminString 1013 MAX-ACCESS read-only 1014 STATUS current 1015 DESCRIPTION 1016 "The textual name of the physical entity. The value of this 1017 object should be the name of the component as assigned by 1018 the local device and should be suitable for use in commands 1019 entered at the device's `console'. This might be a text 1020 name, such as `console' or a simple component number (e.g., 1021 port or module number), such as `1', depending on the 1022 physical component naming syntax of the device. 1024 If there is no local name, or this object is otherwise not 1025 applicable, then this object contains a zero-length string. 1027 Note that the value of entPhysicalName for two physical 1028 entities will be the same in the event that the console 1029 interface does not distinguish between them, e.g., slot-1 1030 and the card in slot-1." 1031 ::= { entPhysicalEntry 7 } 1033 entPhysicalHardwareRev OBJECT-TYPE 1034 SYNTAX SnmpAdminString 1035 MAX-ACCESS read-only 1036 STATUS current 1037 DESCRIPTION 1038 "The vendor-specific hardware revision string for the 1039 physical entity. The preferred value is the hardware 1040 revision identifier actually printed on the component itself 1041 (if present). 1043 Note that if revision information is stored internally in a 1044 non-printable (e.g., binary) format, then the agent must 1045 convert such information to a printable format, in an 1046 implementation-specific manner. 1048 If no specific hardware revision string is associated with 1049 the physical component, or this information is unknown to 1050 the agent, then this object will contain a zero-length 1051 string." 1052 ::= { entPhysicalEntry 8 } 1054 entPhysicalFirmwareRev OBJECT-TYPE 1055 SYNTAX SnmpAdminString 1056 MAX-ACCESS read-only 1057 STATUS current 1058 DESCRIPTION 1059 "The vendor-specific firmware revision string for the 1060 physical entity. 1062 Note that if revision information is stored internally in a 1063 non-printable (e.g., binary) format, then the agent must 1064 convert such information to a printable format, in an 1065 implementation-specific manner. 1067 If no specific firmware programs are associated with the 1068 physical component, or this information is unknown to the 1069 agent, then this object will contain a zero-length string." 1070 ::= { entPhysicalEntry 9 } 1072 entPhysicalSoftwareRev OBJECT-TYPE 1073 SYNTAX SnmpAdminString 1074 MAX-ACCESS read-only 1075 STATUS current 1076 DESCRIPTION 1077 "The vendor-specific software revision string for the 1078 physical entity. 1080 Note that if revision information is stored internally in a 1081 non-printable (e.g., binary) format, then the agent must 1082 convert such information to a printable format, in an 1083 implementation-specific manner. 1085 If no specific software programs are associated with the 1086 physical component, or this information is unknown to the 1087 agent, then this object will contain a zero-length string." 1088 ::= { entPhysicalEntry 10 } 1090 entPhysicalSerialNum OBJECT-TYPE 1091 SYNTAX SnmpAdminString (SIZE (0..32)) 1092 MAX-ACCESS read-write 1093 STATUS current 1094 DESCRIPTION 1095 "The vendor-specific serial number string for the physical 1096 entity. The preferred value is the serial number string 1097 actually printed on the component itself (if present). 1099 On the first instantiation of an physical entity, the value 1100 of entPhysicalSerialNum associated with that entity is set 1101 to the correct vendor-assigned serial number, if this 1102 information is available to the agent. If a serial number 1103 is unknown or non-existent, the entPhysicalSerialNum will be 1104 set to a zero-length string instead. 1106 Note that implementations which can correctly identify the 1107 serial numbers of all installed physical entities do not 1108 need to provide write access to the entPhysicalSerialNum 1109 object. Agents which cannot provide non-volatile storage for 1110 the entPhysicalSerialNum strings are not required to 1111 implement write access for this object. 1113 Not every physical component will have a serial number, or 1114 even need one. Physical entities for which the associated 1115 value of the entPhysicalIsFRU object is equal to 'false(2)' 1116 (e.g., the repeater ports within a repeater module), do not 1117 need their own unique serial number. An agent does not have 1118 to provide write access for such entities, and may return a 1119 zero-length string. 1121 If write access is implemented for an instance of 1122 entPhysicalSerialNum, and a value is written into the 1123 instance, the agent must retain the supplied value in the 1124 entPhysicalSerialNum instance associated with the same 1125 physical entity for as long as that entity remains 1126 instantiated. This includes instantiations across all re- 1127 initializations/reboots of the network management system, 1128 including those which result in a change of the physical 1129 entity's entPhysicalIndex value." 1130 ::= { entPhysicalEntry 11 } 1132 entPhysicalMfgName OBJECT-TYPE 1133 SYNTAX SnmpAdminString 1134 MAX-ACCESS read-only 1135 STATUS current 1136 DESCRIPTION 1137 "The name of the manufacturer of this physical component. 1138 The preferred value is the manufacturer name string actually 1139 printed on the component itself (if present). 1141 Note that comparisons between instances of the 1142 entPhysicalModelName, entPhysicalFirmwareRev, 1143 entPhysicalSoftwareRev, and the entPhysicalSerialNum 1144 objects, are only meaningful amongst entPhysicalEntries with 1145 the same value of entPhysicalMfgName. 1147 If the manufacturer name string associated with the physical 1148 component is unknown to the agent, then this object will 1149 contain a zero-length string." 1150 ::= { entPhysicalEntry 12 } 1152 entPhysicalModelName OBJECT-TYPE 1153 SYNTAX SnmpAdminString 1154 MAX-ACCESS read-only 1155 STATUS current 1156 DESCRIPTION 1157 "The vendor-specific model name identifier string associated 1158 with this physical component. The preferred value is the 1159 customer-visible part number, which may be printed on the 1160 component itself. 1162 If the model name string associated with the physical 1163 component is unknown to the agent, then this object will 1164 contain a zero-length string." 1165 ::= { entPhysicalEntry 13 } 1167 entPhysicalAlias OBJECT-TYPE 1168 SYNTAX SnmpAdminString (SIZE (0..32)) 1169 MAX-ACCESS read-write 1170 STATUS current 1171 DESCRIPTION 1172 "This object is an 'alias' name for the physical entity as 1173 specified by a network manager, and provides a non-volatile 1174 'handle' for the physical entity. 1176 On the first instantiation of an physical entity, the value 1177 of entPhysicalAlias associated with that entity is set to 1178 the zero-length string. However, agent may set the value to 1179 a locally unique default value, instead of a zero-length 1180 string. 1182 If write access is implemented for an instance of 1183 entPhysicalAlias, and a value is written into the instance, 1184 the agent must retain the supplied value in the 1185 entPhysicalAlias instance associated with the same physical 1186 entity for as long as that entity remains instantiated. 1187 This includes instantiations across all re- 1188 initializations/reboots of the network management system, 1189 including those which result in a change of the physical 1190 entity's entPhysicalIndex value." 1191 ::= { entPhysicalEntry 14 } 1193 entPhysicalAssetID OBJECT-TYPE 1194 SYNTAX SnmpAdminString (SIZE (0..32)) 1195 MAX-ACCESS read-write 1196 STATUS current 1197 DESCRIPTION 1198 "This object is a user-assigned asset tracking identifier 1199 for the physical entity as specified by a network manager, 1200 and provides non-volatile storage of this information. 1202 On the first instantiation of an physical entity, the value 1203 of entPhysicalAssetID associated with that entity is set to 1204 the zero-length string. 1206 Not every physical component will have a asset tracking 1207 identifier, or even need one. Physical entities for which 1208 the associated value of the entPhysicalIsFRU object is equal 1209 to 'false(2)' (e.g., the repeater ports within a repeater 1210 module), do not need their own unique asset tracking 1211 identifier. An agent does not have to provide write access 1212 for such entities, and may instead return a zero-length 1213 string. 1215 If write access is implemented for an instance of 1216 entPhysicalAssetID, and a value is written into the 1217 instance, the agent must retain the supplied value in the 1218 entPhysicalAssetID instance associated with the same 1219 physical entity for as long as that entity remains 1220 instantiated. This includes instantiations across all re- 1221 initializations/reboots of the network management system, 1222 including those which result in a change of the physical 1223 entity's entPhysicalIndex value. 1225 If no asset tracking information is associated with the 1226 physical component, then this object will contain a zero- 1227 length string." 1228 ::= { entPhysicalEntry 15 } 1230 entPhysicalIsFRU OBJECT-TYPE 1231 SYNTAX TruthValue 1232 MAX-ACCESS read-only 1233 STATUS current 1234 DESCRIPTION 1235 "This object indicates whether or not this physical entity 1236 is considered a 'field replaceable unit' by the vendor. If 1237 this object contains the value 'true(1)' then this 1238 entPhysicalEntry identifies a field replaceable unit. For 1239 all entPhysicalEntries which represent components that are 1240 permanently contained within a field replaceable unit, the 1241 value 'false(2)' should be returned for this object." 1242 ::= { entPhysicalEntry 16 } 1244 entPhysicalMfgDate OBJECT-TYPE 1245 SYNTAX DateAndTime 1246 MAX-ACCESS read-only 1247 STATUS current 1248 DESCRIPTION 1249 "The manufacturing date for the physical entity." 1250 ::= { entPhysicalEntry 17 } 1252 entPhysicalUris OBJECT-TYPE 1253 SYNTAX OCTET STRING 1254 MAX-ACCESS read-write 1255 STATUS current 1256 DESCRIPTION 1257 "This object contains additional identification information 1258 about the physical entity. The object contains URIs and 1259 therefore the syntax of this object must conform to RFC 2396 1260 [RFC2396] section 2. Multiple URIs may be separated by white 1261 space characters." 1262 REFERENCE 1263 "RFC 2396, Uniform Resource Identifiers (URI): Generic 1264 Syntax, section 2, August 1998." 1266 ::= { entPhysicalEntry 18 } 1268 -- The Logical Entity Table 1269 entLogicalTable OBJECT-TYPE 1270 SYNTAX SEQUENCE OF EntLogicalEntry 1271 MAX-ACCESS not-accessible 1272 STATUS current 1273 DESCRIPTION 1274 "This table contains one row per logical entity. For agents 1275 which implement more than one naming scope, at least one 1276 entry must exist. Agents which instantiate all MIB objects 1277 within a single naming scope are not required to implement 1278 this table." 1279 ::= { entityLogical 1 } 1281 entLogicalEntry OBJECT-TYPE 1282 SYNTAX EntLogicalEntry 1283 MAX-ACCESS not-accessible 1284 STATUS current 1285 DESCRIPTION 1286 "Information about a particular logical entity. Entities 1287 may be managed by this agent or other SNMP agents (possibly) 1288 in the same chassis." 1289 INDEX { entLogicalIndex } 1290 ::= { entLogicalTable 1 } 1292 EntLogicalEntry ::= SEQUENCE { 1293 entLogicalIndex Integer32, 1294 entLogicalDescr SnmpAdminString, 1295 entLogicalType AutonomousType, 1296 entLogicalCommunity OCTET STRING, 1297 entLogicalTAddress TAddress, 1298 entLogicalTDomain TDomain, 1299 entLogicalContextEngineID SnmpEngineIdOrNone, 1300 entLogicalContextName SnmpAdminString 1301 } 1303 entLogicalIndex OBJECT-TYPE 1304 SYNTAX Integer32 (1..2147483647) 1305 MAX-ACCESS not-accessible 1306 STATUS current 1307 DESCRIPTION 1308 "The value of this object uniquely identifies the logical 1309 entity. The value should be a small positive integer; index 1310 values for different logical entities are are not 1311 necessarily contiguous." 1312 ::= { entLogicalEntry 1 } 1314 entLogicalDescr OBJECT-TYPE 1315 SYNTAX SnmpAdminString 1316 MAX-ACCESS read-only 1317 STATUS current 1318 DESCRIPTION 1319 "A textual description of the logical entity. This object 1320 should contain a string which identifies the manufacturer's 1321 name for the logical entity, and should be set to a distinct 1322 value for each version of the logical entity. " 1323 ::= { entLogicalEntry 2 } 1325 entLogicalType OBJECT-TYPE 1326 SYNTAX AutonomousType 1327 MAX-ACCESS read-only 1328 STATUS current 1329 DESCRIPTION 1330 "An indication of the type of logical entity. This will 1331 typically be the OBJECT IDENTIFIER name of the node in the 1332 SMI's naming hierarchy which represents the major MIB 1333 module, or the majority of the MIB modules, supported by the 1334 logical entity. For example: 1335 a logical entity of a regular host/router -> mib-2 1336 a logical entity of a 802.1d bridge -> dot1dBridge 1337 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 1338 If an appropriate node in the SMI's naming hierarchy cannot 1339 be identified, the value 'mib-2' should be used." 1340 ::= { entLogicalEntry 3 } 1342 entLogicalCommunity OBJECT-TYPE 1343 SYNTAX OCTET STRING (SIZE (0..255)) 1344 MAX-ACCESS read-only 1345 STATUS deprecated 1346 DESCRIPTION 1347 "An SNMPv1 or SNMPv2C community-string which can be used to 1348 access detailed management information for this logical 1349 entity. The agent should allow read access with this 1350 community string (to an appropriate subset of all managed 1351 objects) and may also return a community string based on the 1352 privileges of the request used to read this object. Note 1353 that an agent may return a community string with read-only 1354 privileges, even if this object is accessed with a read- 1355 write community string. However, the agent must take care 1356 not to return a community string which allows more 1357 privileges than the community string used to access this 1358 object. 1360 A compliant SNMP agent may wish to conserve naming scopes by 1361 representing multiple logical entities in a single 'default' 1362 naming scope. This is possible when the logical entities 1363 represented by the same value of entLogicalCommunity have no 1364 object instances in common. For example, 'bridge1' and 1365 'repeater1' may be part of the main naming scope, but at 1366 least one additional community string is needed to represent 1367 'bridge2' and 'repeater2'. 1369 Logical entities 'bridge1' and 'repeater1' would be 1370 represented by sysOREntries associated with the 'default' 1371 naming scope. 1373 For agents not accessible via SNMPv1 or SNMPv2C, the value 1374 of this object is the empty string. This object may also 1375 contain an empty string if a community string has not yet 1376 been assigned by the agent, or no community string with 1377 suitable access rights can be returned for a particular SNMP 1378 request. 1380 Note that this object is deprecated. Agents which implement 1381 SNMPv3 access should use the entLogicalContextEngineID and 1382 entLogicalContextName objects to identify the context 1383 associated with each logical entity. SNMPv3 agents may 1384 return a zero-length string for this object, or may continue 1385 to return a community string (e.g., tri-lingual agent 1386 support)." 1387 ::= { entLogicalEntry 4 } 1389 entLogicalTAddress OBJECT-TYPE 1390 SYNTAX TAddress 1391 MAX-ACCESS read-only 1392 STATUS current 1393 DESCRIPTION 1394 "The transport service address by which the logical entity 1395 receives network management traffic, formatted according to 1396 the corresponding value of entLogicalTDomain. 1398 For snmpUDPDomain, a TAddress is 6 octets long, the initial 1399 4 octets containing the IP-address in network-byte order and 1400 the last 2 containing the UDP port in network-byte order. 1401 Consult 'Transport Mappings for the Simple Network 1402 Management Protocol' (STD 62, RFC 3417 [RFC3417]) for 1403 further information on snmpUDPDomain." 1404 ::= { entLogicalEntry 5 } 1406 entLogicalTDomain OBJECT-TYPE 1407 SYNTAX TDomain 1408 MAX-ACCESS read-only 1409 STATUS current 1410 DESCRIPTION 1411 "Indicates the kind of transport service by which the 1412 logical entity receives network management traffic. 1413 Possible values for this object are presently found in the 1414 Transport Mappings for Simple Network Management Protocol' 1415 (STD 62, RFC 3417 [RFC3417])." 1416 ::= { entLogicalEntry 6 } 1418 entLogicalContextEngineID OBJECT-TYPE 1419 SYNTAX SnmpEngineIdOrNone 1420 MAX-ACCESS read-only 1421 STATUS current 1422 DESCRIPTION 1423 "The authoritative contextEngineID that can be used to send 1424 an SNMP message concerning information held by this logical 1425 entity, to the address specified by the associated 1426 'entLogicalTAddress/entLogicalTDomain' pair. 1428 This object, together with the associated 1429 entLogicalContextName object, defines the context associated 1430 with a particular logical entity, and allows access to SNMP 1431 engines identified by a contextEngineId and contextName 1432 pair. 1434 If no value has been configured by the agent, a zero-length 1435 string is returned, or the agent may choose not to 1436 instantiate this object at all." 1437 ::= { entLogicalEntry 7 } 1439 entLogicalContextName OBJECT-TYPE 1440 SYNTAX SnmpAdminString 1441 MAX-ACCESS read-only 1442 STATUS current 1443 DESCRIPTION 1444 "The contextName that can be used to send an SNMP message 1445 concerning information held by this logical entity, to the 1446 address specified by the associated 1447 'entLogicalTAddress/entLogicalTDomain' pair. 1449 This object, together with the associated 1450 entLogicalContextEngineID object, defines the context 1451 associated with a particular logical entity, and allows 1452 access to SNMP engines identified by a contextEngineId and 1453 contextName pair. 1455 If no value has been configured by the agent, a zero-length 1456 string is returned, or the agent may choose not to 1457 instantiate this object at all." 1458 ::= { entLogicalEntry 8 } 1460 entLPMappingTable OBJECT-TYPE 1461 SYNTAX SEQUENCE OF EntLPMappingEntry 1462 MAX-ACCESS not-accessible 1463 STATUS deprecated 1464 DESCRIPTION 1465 "This table contains zero or more rows of logical entity to 1466 physical equipment associations. For each logical entity 1467 known by this agent, there are zero or more mappings to the 1468 physical resources which are used to realize that logical 1469 entity. 1471 An agent should limit the number and nature of entries in 1472 this table such that only meaningful and non-redundant 1473 information is returned. For example, in a system which 1474 contains a single power supply, mappings between logical 1475 entities and the power supply are not useful and should not 1476 be included. 1478 Also, only the most appropriate physical component which is 1479 closest to the root of a particular containment tree should 1480 be identified in an entLPMapping entry. 1482 For example, suppose a bridge is realized on a particular 1483 module, and all ports on that module are ports on this 1484 bridge. A mapping between the bridge and the module would be 1485 useful, but additional mappings between the bridge and each 1486 of the ports on that module would be redundant (since the 1487 entPhysicalContainedIn hierarchy can provide the same 1488 information). If, on the other hand, more than one bridge 1489 was utilizing ports on this module, then mappings between 1490 each bridge and the ports it used would be appropriate. 1492 Also, in the case of a single backplane repeater, a mapping 1493 for the backplane to the single repeater entity is not 1494 necessary." 1495 ::= { entityMapping 1 } 1497 entLPMappingEntry OBJECT-TYPE 1498 SYNTAX EntLPMappingEntry 1499 MAX-ACCESS not-accessible 1500 STATUS deprecated 1501 DESCRIPTION 1502 "Information about a particular logical entity to physical 1503 equipment association. Note that the nature of the 1504 association is not specifically identified in this entry. 1505 It is expected that sufficient information exists in the 1506 MIBs used to manage a particular logical entity to infer how 1507 physical component information is utilized." 1508 INDEX { entLogicalIndex, entLPPhysicalIndex } 1509 ::= { entLPMappingTable 1 } 1511 EntLPMappingEntry ::= SEQUENCE { 1512 entLPPhysicalIndex PhysicalIndex 1514 } 1516 entLPPhysicalIndex OBJECT-TYPE 1517 SYNTAX PhysicalIndex 1518 MAX-ACCESS read-only 1519 STATUS deprecated 1520 DESCRIPTION 1521 "The value of this object identifies the index value of a 1522 particular entPhysicalEntry associated with the indicated 1523 entLogicalEntity." 1524 ::= { entLPMappingEntry 1 } 1526 -- logical entity/component to alias table 1527 entAliasMappingTable OBJECT-TYPE 1528 SYNTAX SEQUENCE OF EntAliasMappingEntry 1529 MAX-ACCESS not-accessible 1530 STATUS current 1531 DESCRIPTION 1532 "This table contains zero or more rows, representing 1533 mappings of logical entity and physical component to 1534 external MIB identifiers. Each physical port in the system 1535 may be associated with a mapping to an external identifier, 1536 which itself is associated with a particular logical 1537 entity's naming scope. A 'wildcard' mechanism is provided 1538 to indicate that an identifier is associated with more than 1539 one logical entity." 1540 ::= { entityMapping 2 } 1542 entAliasMappingEntry OBJECT-TYPE 1543 SYNTAX EntAliasMappingEntry 1544 MAX-ACCESS not-accessible 1545 STATUS current 1546 DESCRIPTION 1547 "Information about a particular physical equipment, logical 1548 entity to external identifier binding. Each logical 1549 entity/physical component pair may be associated with one 1550 alias mapping. The logical entity index may also be used as 1551 a 'wildcard' (refer to the entAliasLogicalIndexOrZero object 1552 DESCRIPTION clause for details.) 1554 Note that only entPhysicalIndex values which represent 1555 physical ports (i.e. associated entPhysicalClass value is 1556 'port(10)') are permitted to exist in this table." 1557 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 1558 ::= { entAliasMappingTable 1 } 1560 EntAliasMappingEntry ::= SEQUENCE { 1561 entAliasLogicalIndexOrZero Integer32, 1562 entAliasMappingIdentifier RowPointer 1563 } 1565 entAliasLogicalIndexOrZero OBJECT-TYPE 1566 SYNTAX Integer32 (0..2147483647) 1567 MAX-ACCESS not-accessible 1568 STATUS current 1569 DESCRIPTION 1570 "The value of this object identifies the logical entity 1571 which defines the naming scope for the associated instance 1572 of the 'entAliasMappingIdentifier' object. 1574 If this object has a non-zero value, then it identifies the 1575 logical entity named by the same value of entLogicalIndex. 1577 If this object has a value of zero, then the mapping between 1578 the physical component and the alias identifier for this 1579 entAliasMapping entry is associated with all unspecified 1580 logical entities. That is, a value of zero (the default 1581 mapping) identifies any logical entity which does not have 1582 an explicit entry in this table for a particular 1583 entPhysicalIndex/entAliasMappingIdentifier pair. 1585 For example, to indicate that a particular interface (e.g., 1586 physical component 33) is identified by the same value of 1587 ifIndex for all logical entities, the following instance 1588 might exist: 1590 entAliasMappingIdentifier.33.0 = ifIndex.5 1592 In the event an entPhysicalEntry is associated differently 1593 for some logical entities, additional entAliasMapping 1594 entries may exist, e.g.: 1596 entAliasMappingIdentifier.33.0 = ifIndex.6 1597 entAliasMappingIdentifier.33.4 = ifIndex.1 1598 entAliasMappingIdentifier.33.5 = ifIndex.1 1599 entAliasMappingIdentifier.33.10 = ifIndex.12 1601 Note that entries with non-zero entAliasLogicalIndexOrZero 1602 index values have precedence over any zero-indexed entry. In 1603 this example, all logical entities except 4, 5, and 10, 1604 associate physical entity 33 with ifIndex.6." 1605 ::= { entAliasMappingEntry 1 } 1607 entAliasMappingIdentifier OBJECT-TYPE 1608 SYNTAX RowPointer 1609 MAX-ACCESS read-only 1610 STATUS current 1611 DESCRIPTION 1612 "The value of this object identifies a particular conceptual 1613 row associated with the indicated entPhysicalIndex and 1614 entLogicalIndex pair. 1616 Since only physical ports are modeled in this table, only 1617 entries which represent interfaces or ports are allowed. If 1618 an ifEntry exists on behalf of a particular physical port, 1619 then this object should identify the associated 'ifEntry'. 1620 For repeater ports, the appropriate row in the 1621 'rptrPortGroupTable' should be identified instead. 1623 For example, suppose a physical port was represented by 1624 entPhysicalEntry.3, entLogicalEntry.15 existed for a 1625 repeater, and entLogicalEntry.22 existed for a bridge. Then 1626 there might be two related instances of 1627 entAliasMappingIdentifier: 1628 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 1629 entAliasMappingIdentifier.3.22 == ifIndex.17 1630 It is possible that other mappings (besides interfaces and 1631 repeater ports) may be defined in the future, as required. 1633 Bridge ports are identified by examining the Bridge MIB and 1634 appropriate ifEntries associated with each 'dot1dBasePort', 1635 and are thus not represented in this table." 1636 ::= { entAliasMappingEntry 2 } 1638 -- physical mapping table 1639 entPhysicalContainsTable OBJECT-TYPE 1640 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 1641 MAX-ACCESS not-accessible 1642 STATUS current 1643 DESCRIPTION 1644 "A table which exposes the container/'containee' 1645 relationships between physical entities. This table provides 1646 all the information found by constructing the virtual 1647 containment tree for a given entPhysicalTable, but in a more 1648 direct format. 1650 In the event a physical entity is contained by more than one 1651 other physical entity (e.g., double-wide modules), this 1652 table should include these additional mappings, which cannot 1653 be represented in the entPhysicalTable virtual containment 1654 tree." 1655 ::= { entityMapping 3 } 1657 entPhysicalContainsEntry OBJECT-TYPE 1658 SYNTAX EntPhysicalContainsEntry 1659 MAX-ACCESS not-accessible 1660 STATUS current 1661 DESCRIPTION 1662 "A single container/'containee' relationship." 1663 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1664 ::= { entPhysicalContainsTable 1 } 1666 EntPhysicalContainsEntry ::= SEQUENCE { 1667 entPhysicalChildIndex PhysicalIndex 1668 } 1670 entPhysicalChildIndex OBJECT-TYPE 1671 SYNTAX PhysicalIndex 1672 MAX-ACCESS read-only 1673 STATUS current 1674 DESCRIPTION 1675 "The value of entPhysicalIndex for the contained physical 1676 entity." 1677 ::= { entPhysicalContainsEntry 1 } 1679 -- last change time stamp for the whole MIB 1680 entLastChangeTime OBJECT-TYPE 1681 SYNTAX TimeStamp 1682 MAX-ACCESS read-only 1683 STATUS current 1684 DESCRIPTION 1685 "The value of sysUpTime at the time a conceptual row is 1686 created, modified, or deleted in any of these tables: 1687 - entPhysicalTable 1688 - entLogicalTable 1689 - entLPMappingTable 1690 - entAliasMappingTable 1691 - entPhysicalContainsTable 1692 " 1693 ::= { entityGeneral 1 } 1695 -- Entity MIB Trap Definitions 1696 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1697 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1699 entConfigChange NOTIFICATION-TYPE 1700 STATUS current 1701 DESCRIPTION 1702 "An entConfigChange notification is generated when the value 1703 of entLastChangeTime changes. It can be utilized by an NMS 1704 to trigger logical/physical entity table maintenance polls. 1706 An agent should not generate more than one entConfigChange 1707 'notification-event' in a given time interval (five seconds 1708 is the suggested default). A 'notification-event' is the 1709 transmission of a single trap or inform PDU to a list of 1710 notification destinations. 1712 If additional configuration changes occur within the 1713 throttling period, then notification-events for these 1714 changes should be suppressed by the agent until the current 1715 throttling period expires. At the end of a throttling 1716 period, one notification-event should be generated if any 1717 configuration changes occurred since the start of the 1718 throttling period. In such a case, another throttling period 1719 is started right away. 1721 An NMS should periodically check the value of 1722 entLastChangeTime to detect any missed entConfigChange 1723 notification-events, e.g., due to throttling or transmission 1724 loss." 1725 ::= { entityMIBTrapPrefix 1 } 1727 -- conformance information 1728 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1730 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1731 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1732 -- compliance statements 1733 entityCompliance MODULE-COMPLIANCE 1734 STATUS deprecated 1735 DESCRIPTION 1736 "The compliance statement for SNMP entities which implement 1737 version 1 of the Entity MIB." 1738 MODULE -- this module 1739 MANDATORY-GROUPS { 1740 entityPhysicalGroup, 1741 entityLogicalGroup, 1742 entityMappingGroup, 1743 entityGeneralGroup, 1744 entityNotificationsGroup 1745 } 1746 ::= { entityCompliances 1 } 1748 entity2Compliance MODULE-COMPLIANCE 1749 STATUS deprecated 1750 DESCRIPTION 1751 "The compliance statement for SNMP entities which implement 1752 version 2 of the Entity MIB." 1753 MODULE -- this module 1754 MANDATORY-GROUPS { 1755 entityPhysicalGroup, 1756 entityPhysical2Group, 1757 entityGeneralGroup, 1758 entityNotificationsGroup 1759 } 1760 GROUP entityLogical2Group 1761 DESCRIPTION 1762 "Implementation of this group is not mandatory for agents 1763 which model all MIB object instances within a single naming 1764 scope." 1766 GROUP entityMappingGroup 1767 DESCRIPTION 1768 "Implementation of the entPhysicalContainsTable is mandatory 1769 for all agents. Implementation of the entLPMappingTable and 1770 entAliasMappingTables are not mandatory for agents which 1771 model all MIB object instances within a single naming scope. 1773 Note that the entAliasMappingTable may be useful for all 1774 agents, however implementation of the entityLogicalGroup or 1775 entityLogical2Group is required to support this table." 1777 OBJECT entPhysicalSerialNum 1778 MIN-ACCESS not-accessible 1779 DESCRIPTION 1780 "Read and write access is not required for agents which 1781 cannot identify serial number information for physical 1782 entities, and/or cannot provide non-volatile storage for 1783 NMS-assigned serial numbers. 1785 Write access is not required for agents which can identify 1786 serial number information for physical entities, but cannot 1787 provide non-volatile storage for NMS-assigned serial 1788 numbers. 1790 Write access is not required for physical entities for 1791 physical entities for which the associated value of the 1792 entPhysicalIsFRU object is equal to 'false(2)'." 1794 OBJECT entPhysicalAlias 1795 MIN-ACCESS read-only 1796 DESCRIPTION 1797 "Write access is required only if the associated 1798 entPhysicalClass value is equal to 'chassis(3)'." 1800 OBJECT entPhysicalAssetID 1801 MIN-ACCESS not-accessible 1802 DESCRIPTION 1803 "Read and write access is not required for agents which 1804 cannot provide non-volatile storage for NMS-assigned asset 1805 identifiers. 1807 Write access is not required for physical entities for which 1808 the associated value of entPhysicalIsFRU is equal to 1809 'false(2)'." 1811 OBJECT entPhysicalClass 1812 SYNTAX INTEGER { 1813 other(1), 1814 unknown(2), 1815 chassis(3), 1816 backplane(4), 1817 container(5), 1818 powerSupply(6), 1819 fan(7), 1820 sensor(8), 1821 module(9), 1822 port(10), 1823 stack(11) 1824 } 1825 DESCRIPTION 1826 "Implementation of the 'cpu(12)' enumeration is not 1827 required." 1829 ::= { entityCompliances 2 } 1831 entity3Compliance MODULE-COMPLIANCE 1832 STATUS current 1833 DESCRIPTION 1834 "The compliance statement for SNMP entities which implement 1835 version 3 of the Entity MIB." 1836 MODULE -- this module 1837 MANDATORY-GROUPS { 1838 entityPhysicalGroup, 1839 entityPhysical2Group, 1840 entityPhysical3Group, 1841 entityGeneralGroup, 1842 entityNotificationsGroup 1843 } 1844 GROUP entityLogical2Group 1845 DESCRIPTION 1846 "Implementation of this group is not mandatory for agents 1847 which model all MIB object instances within a single naming 1848 scope." 1850 GROUP entityMappingGroupRev1 1851 DESCRIPTION 1852 "Implementation of the entPhysicalContainsTable is mandatory 1853 for all agents. Implementation of the entAliasMappingTable 1854 is not mandatory for agents which model all MIB object 1855 instances within a single naming scope. 1857 Note that the entAliasMappingTable may be useful for all 1858 agents, however implementation of the entityLogicalGroup or 1859 entityLogical2Group is required to support this table." 1861 OBJECT entPhysicalSerialNum 1862 MIN-ACCESS not-accessible 1863 DESCRIPTION 1864 "Read and write access is not required for agents which 1865 cannot identify serial number information for physical 1866 entities, and/or cannot provide non-volatile storage for 1867 NMS-assigned serial numbers. 1869 Write access is not required for agents which can identify 1870 serial number information for physical entities, but cannot 1871 provide non-volatile storage for NMS-assigned serial 1872 numbers. 1874 Write access is not required for physical entities for 1875 physical entities for which the associated value of the 1876 entPhysicalIsFRU object is equal to 'false(2)'." 1878 OBJECT entPhysicalAlias 1879 MIN-ACCESS read-only 1880 DESCRIPTION 1881 "Write access is required only if the associated 1882 entPhysicalClass value is equal to 'chassis(3)'." 1884 OBJECT entPhysicalAssetID 1885 MIN-ACCESS not-accessible 1886 DESCRIPTION 1887 "Read and write access is not required for agents which 1888 cannot provide non-volatile storage for NMS-assigned asset 1889 identifiers. 1891 Write access is not required for physical entities for which 1892 the associated value of entPhysicalIsFRU is equal to 1893 'false(2)'." 1894 ::= { entityCompliances 3 } 1896 -- MIB groupings 1897 entityPhysicalGroup OBJECT-GROUP 1898 OBJECTS { 1899 entPhysicalDescr, 1900 entPhysicalVendorType, 1901 entPhysicalContainedIn, 1902 entPhysicalClass, 1903 entPhysicalParentRelPos, 1904 entPhysicalName 1905 } 1906 STATUS current 1907 DESCRIPTION 1908 "The collection of objects which are used to represent 1909 physical system components, for which a single agent 1910 provides management information." 1911 ::= { entityGroups 1 } 1913 entityLogicalGroup OBJECT-GROUP 1914 OBJECTS { 1915 entLogicalDescr, 1916 entLogicalType, 1917 entLogicalCommunity, 1918 entLogicalTAddress, 1919 entLogicalTDomain 1920 } 1921 STATUS deprecated 1922 DESCRIPTION 1923 "The collection of objects which are used to represent the 1924 list of logical entities for which a single agent provides 1925 management information." 1926 ::= { entityGroups 2 } 1928 entityMappingGroup OBJECT-GROUP 1929 OBJECTS { 1930 entLPPhysicalIndex, 1931 entAliasMappingIdentifier, 1932 entPhysicalChildIndex 1933 } 1934 STATUS deprecated 1935 DESCRIPTION 1936 "The collection of objects which are used to represent the 1937 associations between multiple logical entities, physical 1938 components, interfaces, and port identifiers for which a 1939 single agent provides management information." 1940 ::= { entityGroups 3 } 1942 entityGeneralGroup OBJECT-GROUP 1943 OBJECTS { 1944 entLastChangeTime 1945 } 1946 STATUS current 1947 DESCRIPTION 1948 "The collection of objects which are used to represent 1949 general entity information for which a single agent provides 1950 management information." 1951 ::= { entityGroups 4 } 1953 entityNotificationsGroup NOTIFICATION-GROUP 1954 NOTIFICATIONS { entConfigChange } 1955 STATUS current 1956 DESCRIPTION 1957 "The collection of notifications used to indicate Entity MIB 1958 data consistency and general status information." 1959 ::= { entityGroups 5 } 1961 entityPhysical2Group OBJECT-GROUP 1962 OBJECTS { 1963 entPhysicalHardwareRev, 1964 entPhysicalFirmwareRev, 1965 entPhysicalSoftwareRev, 1966 entPhysicalSerialNum, 1967 entPhysicalMfgName, 1968 entPhysicalModelName, 1969 entPhysicalAlias, 1970 entPhysicalAssetID, 1971 entPhysicalIsFRU 1972 } 1973 STATUS current 1974 DESCRIPTION 1975 "The collection of objects which are used to represent 1976 physical system components, for which a single agent 1977 provides management information. This group augments the 1978 objects contained in the entityPhysicalGroup." 1979 ::= { entityGroups 6 } 1981 entityLogical2Group OBJECT-GROUP 1982 OBJECTS { 1983 entLogicalDescr, 1984 entLogicalType, 1985 entLogicalTAddress, 1986 entLogicalTDomain, 1987 entLogicalContextEngineID, 1988 entLogicalContextName 1989 } 1990 STATUS current 1991 DESCRIPTION 1992 "The collection of objects which are used to represent the 1993 list of logical entities for which a single SNMP entity 1994 provides management information." 1995 ::= { entityGroups 7 } 1997 entityMappingGroupRev1 OBJECT-GROUP 1998 OBJECTS { 1999 entAliasMappingIdentifier, 2000 entPhysicalChildIndex 2001 } 2002 STATUS current 2003 DESCRIPTION 2004 "The collection of objects which are used to represent the 2005 associations between multiple logical entities, physical 2006 components, interfaces, and port identifiers for which a 2007 single agent provides management information." 2008 ::= { entityGroups 8 } 2010 entityPhysical3Group OBJECT-GROUP 2011 OBJECTS { 2012 entPhysicalMfgDate, 2013 entPhysicalUris 2014 } 2015 STATUS current 2016 DESCRIPTION 2017 "The collection of objects which are used to represent 2018 physical system components, for which a single agent 2019 provides management information. This group augments the 2020 objects contained in the entityPhysicalGroup." 2021 ::= { entityGroups 9 } 2023 END 2024 4. Usage Examples 2026 The following sections iterate the instance values for two example 2027 networking devices. These examples are kept simple to make them 2028 more understandable. Auxiliary components, such as fans, sensors, 2029 empty slots, and sub-modules are not shown, but might be modeled in 2030 real implementations. 2032 4.1. Router/Bridge 2034 A router containing two slots. Each slot contains a 3 port 2035 router/bridge module. Each port is represented in the ifTable. 2036 There are two logical instances of OSPF running and two logical 2037 bridges: 2039 Physical entities -- entPhysicalTable: 2040 1 Field-replaceable physical chassis: 2041 entPhysicalDescr.1 == 'Acme Chassis Model 100' 2042 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 2043 entPhysicalContainedIn.1 == 0 2044 entPhysicalClass.1 == chassis(3) 2045 entPhysicalParentRelPos.1 == 0 2046 entPhysicalName.1 == '100-A' 2047 entPhysicalHardwareRev.1 == 'A(1.00.02)' 2048 entPhysicalSoftwareRev.1 == '' 2049 entPhysicalFirmwareRev.1 == '' 2050 entPhysicalSerialNum.1 == 'C100076544' 2051 entPhysicalMfgName.1 == 'Acme' 2052 entPhysicalModelName.1 == '100' 2053 entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' 2054 entPhysicalAssetID.1 == '0007372293' 2055 entPhysicalIsFRU.1 == true(1) 2057 2 slots within the chassis: 2058 entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' 2059 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 2060 entPhysicalContainedIn.2 == 1 2061 entPhysicalClass.2 == container(5) 2062 entPhysicalParentRelPos.2 == 1 2063 entPhysicalName.2 == 'S1' 2064 entPhysicalHardwareRev.2 == 'B(1.00.01)' 2065 entPhysicalSoftwareRev.2 == '' 2066 entPhysicalFirmwareRev.2 == '' 2067 entPhysicalSerialNum.2 == '' 2068 entPhysicalMfgName.2 == 'Acme' 2069 entPhysicalModelName.2 == 'AA' 2070 entPhysicalAlias.2 == '' 2071 entPhysicalAssetID.2 == '' 2072 entPhysicalIsFRU.2 == false(2) 2074 entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' 2075 entPhysicalVendorType.3 = acmeProducts.slotTypes.1 2076 entPhysicalContainedIn.3 == 1 2077 entPhysicalClass.3 == container(5) 2078 entPhysicalParentRelPos.3 == 2 2079 entPhysicalName.3 == 'S2' 2080 entPhysicalHardwareRev.3 == '1.00.07' 2081 entPhysicalSoftwareRev.3 == '' 2082 entPhysicalFirmwareRev.3 == '' 2083 entPhysicalSerialNum.3 == '' 2084 entPhysicalMfgName.3 == 'Acme' 2085 entPhysicalModelName.3 == 'AA' 2086 entPhysicalAlias.3 == '' 2087 entPhysicalAssetID.3 == '' 2088 entPhysicalIsFRU.3 == false(2) 2090 2 Field-replaceable modules: 2091 Slot 1 contains a module with 3 ports: 2092 entPhysicalDescr.4 == 'Acme Router-100' 2093 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 2094 entPhysicalContainedIn.4 == 2 2095 entPhysicalClass.4 == module(9) 2096 entPhysicalParentRelPos.4 == 1 2097 entPhysicalName.4 == 'M1' 2098 entPhysicalHardwareRev.4 == '1.00.07' 2099 entPhysicalSoftwareRev.4 == '1.4.1' 2100 entPhysicalFirmwareRev.4 == 'A(1.1)' 2101 entPhysicalSerialNum.4 == 'C100087363' 2102 entPhysicalMfgName.4 == 'Acme' 2103 entPhysicalModelName.4 == 'R100-FE' 2104 entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' 2105 entPhysicalAssetID.4 == '0007372462' 2106 entPhysicalIsFRU.4 == true(1) 2108 entPhysicalDescr.5 == 'Acme Ethernet-100 Port' 2109 entPhysicalVendorType.5 == acmeProducts.portTypes.2 2110 entPhysicalContainedIn.5 == 4 2111 entPhysicalClass.5 == port(10) 2112 entPhysicalParentRelPos.5 == 1 2113 entPhysicalName.5 == 'P1' 2114 entPhysicalHardwareRev.5 == 'G(1.02)' 2115 entPhysicalSoftwareRev.5 == '' 2116 entPhysicalFirmwareRev.5 == '1.1' 2117 entPhysicalSerialNum.5 == '' 2118 entPhysicalMfgName.5 == 'Acme' 2119 entPhysicalModelName.5 == 'FE-100' 2120 entPhysicalAlias.5 == '' 2121 entPhysicalAssetID.5 == '' 2122 entPhysicalIsFRU.5 == false(2) 2124 entPhysicalDescr.6 == 'Acme Ethernet-100 Port' 2125 entPhysicalVendorType.6 == acmeProducts.portTypes.2 2126 entPhysicalContainedIn.6 == 4 2127 entPhysicalClass.6 == port(10) 2128 entPhysicalParentRelPos.6 == 2 2129 entPhysicalName.6 == 'P2' 2130 entPhysicalHardwareRev.6 == 'G(1.02)' 2131 entPhysicalSoftwareRev.6 == '' 2132 entPhysicalFirmwareRev.6 == '1.1' 2133 entPhysicalSerialNum.6 == '' 2134 entPhysicalMfgName.6 == 'Acme' 2135 entPhysicalModelName.6 == 'FE-100' 2136 entPhysicalAlias.6 == '' 2137 entPhysicalAssetID.6 == '' 2138 entPhysicalIsFRU.6 == false(2) 2140 entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' 2141 entPhysicalVendorType.7 == acmeProducts.portTypes.3 2142 entPhysicalContainedIn.7 == 4 2143 entPhysicalClass.7 == port(10) 2144 entPhysicalParentRelPos.7 == 3 2145 entPhysicalName.7 == 'P3' 2146 entPhysicalHardwareRev.7 == 'B(1.03)' 2147 entPhysicalSoftwareRev.7 == '2.5.1' 2148 entPhysicalFirmwareRev.7 == '2.5F' 2149 entPhysicalSerialNum.7 == '' 2150 entPhysicalMfgName.7 == 'Acme' 2151 entPhysicalModelName.7 == 'FDDI-100' 2152 entPhysicalAlias.7 == '' 2153 entPhysicalAssetID.7 == '' 2154 entPhysicalIsFRU.7 == false(2) 2156 Slot 2 contains another 3-port module: 2157 entPhysicalDescr.8 == 'Acme Router-100 Comm Module' 2158 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 2159 entPhysicalContainedIn.8 == 3 2160 entPhysicalClass.8 == module(9) 2161 entPhysicalParentRelPos.8 == 1 2162 entPhysicalName.8 == 'M2' 2163 entPhysicalHardwareRev.8 == '2.01.00' 2164 entPhysicalSoftwareRev.8 == '3.0.7' 2165 entPhysicalFirmwareRev.8 == 'A(1.2)' 2166 entPhysicalSerialNum.8 == 'C100098732' 2167 entPhysicalMfgName.8 == 'Acme' 2168 entPhysicalModelName.8 == 'C100' 2169 entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' 2170 entPhysicalAssetID.8 == '0007373982' 2171 entPhysicalIsFRU.8 == true(1) 2173 entPhysicalDescr.9 == 'Acme Fddi-100 Port' 2174 entPhysicalVendorType.9 == acmeProducts.portTypes.5 2175 entPhysicalContainedIn.9 == 8 2176 entPhysicalClass.9 == port(10) 2177 entPhysicalParentRelPos.9 == 1 2178 entPhysicalName.9 == 'FDDI Primary' 2179 entPhysicalHardwareRev.9 == 'CC(1.07)' 2180 entPhysicalSoftwareRev.9 == '2.0.34' 2181 entPhysicalFirmwareRev.9 == '1.1' 2182 entPhysicalSerialNum.9 == '' 2183 entPhysicalMfgName.9 == 'Acme' 2184 entPhysicalModelName.9 == 'FDDI-100' 2185 entPhysicalAlias.9 == '' 2186 entPhysicalAssetID.9 == '' 2187 entPhysicalIsFRU.9 == false(2) 2189 entPhysicalDescr.10 == 'Acme Ethernet-100 Port' 2190 entPhysicalVendorType.10 == acmeProducts.portTypes.2 2191 entPhysicalContainedIn.10 == 8 2192 entPhysicalClass.10 == port(10) 2193 entPhysicalParentRelPos.10 == 2 2194 entPhysicalName.10 == 'Ethernet A' 2195 entPhysicalHardwareRev.10 == 'G(1.04)' 2196 entPhysicalSoftwareRev.10 == '' 2197 entPhysicalFirmwareRev.10 == '1.3' 2198 entPhysicalSerialNum.10 == '' 2199 entPhysicalMfgName.10 == 'Acme' 2200 entPhysicalModelName.10 == 'FE-100' 2201 entPhysicalAlias.10 == '' 2202 entPhysicalAssetID.10 == '' 2203 entPhysicalIsFRU.10 == false(2) 2204 entPhysicalDescr.11 == 'Acme Ethernet-100 Port' 2205 entPhysicalVendorType.11 == acmeProducts.portTypes.2 2206 entPhysicalContainedIn.11 == 8 2207 entPhysicalClass.11 == port(10) 2208 entPhysicalParentRelPos.11 == 3 2209 entPhysicalName.11 == 'Ethernet B' 2210 entPhysicalHardwareRev.11 == 'G(1.04)' 2211 entPhysicalSoftwareRev.11 == '' 2212 entPhysicalFirmwareRev.11 == '1.3' 2213 entPhysicalSerialNum.11 == '' 2214 entPhysicalMfgName.11 == 'Acme' 2215 entPhysicalModelName.11 == 'FE-100' 2216 entPhysicalAlias.11 == '' 2217 entPhysicalAssetID.11 == '' 2218 entPhysicalIsFRU.11 == false(2) 2220 Logical entities -- entLogicalTable; no SNMPv3 support 2221 2 OSPF instances: 2222 entLogicalDescr.1 == 'Acme OSPF v1.1' 2223 entLogicalType.1 == ospf 2224 entLogicalCommunity.1 == 'public-ospf1' 2225 entLogicalTAddress.1 == 124.125.126.127:161 2226 entLogicalTDomain.1 == snmpUDPDomain 2227 entLogicalContextEngineID.1 == '' 2228 entLogicalContextName.1 == '' 2230 entLogicalDescr.2 == 'Acme OSPF v1.1' 2231 entLogicalType.2 == ospf 2232 entLogicalCommunity.2 == 'public-ospf2' 2233 entLogicalTAddress.2 == 124.125.126.127:161 2234 entLogicalTDomain.2 == snmpUDPDomain 2235 entLogicalContextEngineID.2 == '' 2236 entLogicalContextName.2 == '' 2238 2 logical bridges: 2239 entLogicalDescr.3 == 'Acme Bridge v2.1.1' 2240 entLogicalType.3 == dot1dBridge 2241 entLogicalCommunity.3 == 'public-bridge1' 2242 entLogicalTAddress.3 == 124.125.126.127:161 2243 entLogicalTDomain.3 == snmpUDPDomain 2244 entLogicalContextEngineID.3 == '' 2245 entLogicalContextName.3 == '' 2247 entLogicalDescr.4 == 'Acme Bridge v2.1.1' 2248 entLogicalType.4 == dot1dBridge 2249 entLogicalCommunity.4 == 'public-bridge2' 2250 entLogicalTAddress.4 == 124.125.126.127:161 2251 entLogicalTDomain.4 == snmpUDPDomain 2252 entLogicalContextEngineID.4 == '' 2253 entLogicalContextName.4 == '' 2255 Logical to Physical Mappings: 2256 1st OSPF instance: uses module 1-port 1 2257 entLPPhysicalIndex.1.5 == 5 2259 2nd OSPF instance: uses module 2-port 1 2260 entLPPhysicalIndex.2.9 == 9 2262 1st bridge group: uses module 1, all ports 2264 [ed. -- Note that these mappings are included in the table since 2265 another logical entity (1st OSPF) utilizes one of the 2266 ports. If this were not the case, then a single mapping 2267 to the module (e.g., entLPPhysicalIndex.3.4) would be 2268 present instead. ] 2269 entLPPhysicalIndex.3.5 == 5 2270 entLPPhysicalIndex.3.6 == 6 2271 entLPPhysicalIndex.3.7 == 7 2273 2nd bridge group: uses module 2, all ports 2274 entLPPhysicalIndex.4.9 == 9 2275 entLPPhysicalIndex.4.10 == 10 2276 entLPPhysicalIndex.4.11 == 11 2278 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2279 Example 1: ifIndex values are global to all logical entities 2280 entAliasMappingIdentifier.5.0 == ifIndex.1 2281 entAliasMappingIdentifier.6.0 == ifIndex.2 2282 entAliasMappingIdentifier.7.0 == ifIndex.3 2283 entAliasMappingIdentifier.9.0 == ifIndex.4 2284 entAliasMappingIdentifier.10.0 == ifIndex.5 2285 entAliasMappingIdentifier.11.0 == ifIndex.6 2287 Example 2: ifIndex values are not shared by all logical entities 2288 entAliasMappingIdentifier.5.0 == ifIndex.1 2289 entAliasMappingIdentifier.5.3 == ifIndex.101 2290 entAliasMappingIdentifier.6.0 == ifIndex.2 2291 entAliasMappingIdentifier.6.3 == ifIndex.102 2292 entAliasMappingIdentifier.7.0 == ifIndex.3 2293 entAliasMappingIdentifier.7.3 == ifIndex.103 2294 entAliasMappingIdentifier.9.0 == ifIndex.4 2295 entAliasMappingIdentifier.9.3 == ifIndex.204 2296 entAliasMappingIdentifier.10.0 == ifIndex.5 2297 entAliasMappingIdentifier.10.3 == ifIndex.205 2298 entAliasMappingIdentifier.11.0 == ifIndex.6 2299 entAliasMappingIdentifier.11.3 == ifIndex.206 2301 Physical Containment Tree -- entPhysicalContainsTable 2302 chassis has two containers: 2303 entPhysicalChildIndex.1.2 == 2 2304 entPhysicalChildIndex.1.3 == 3 2306 container 1 has a module: 2307 entPhysicalChildIndex.2.4 == 4 2309 container 2 has a module: 2310 entPhysicalChildIndex.3.8 == 8 2312 module 1 has 3 ports: 2313 entPhysicalChildIndex.4.5 == 5 2314 entPhysicalChildIndex.4.6 == 6 2315 entPhysicalChildIndex.4.7 == 7 2317 module 2 has 3 ports: 2318 entPhysicalChildIndex.8.9 == 9 2319 entPhysicalChildIndex.8.10 == 10 2320 entPhysicalChildIndex.1.11 == 11 2322 4.2. Repeaters 2324 A 3-slot Hub with 2 backplane ethernet segments. Slot three is 2325 empty, and the remaining slots contain ethernet repeater modules. 2327 Note that this example assumes an older Repeater MIB 2328 implementation, (RFC 1516 [RFC1516]) rather than the new Repeater 2329 MIB (RFC 2108 [RFC2108]). The new version contains an object 2330 called 'rptrPortRptrId', which should be used to identify repeater 2331 port groupings, rather than with community strings or contexts. 2333 Physical entities -- entPhysicalTable: 2334 1 Field-replaceable physical chassis: 2335 entPhysicalDescr.1 == 'Acme Chassis Model 110' 2336 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 2337 entPhysicalContainedIn.1 == 0 2338 entPhysicalClass.1 == chassis(3) 2339 entPhysicalParentRelPos.1 == 0 2340 entPhysicalName.1 == '110-B' 2341 entPhysicalHardwareRev.1 == 'A(1.02.00)' 2342 entPhysicalSoftwareRev.1 == '' 2343 entPhysicalFirmwareRev.1 == '' 2344 entPhysicalSerialNum.1 == 'C100079294' 2345 entPhysicalMfgName.1 == 'Acme' 2346 entPhysicalModelName.1 == '110' 2347 entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' 2348 entPhysicalAssetID.1 == '0007386327' 2349 entPhysicalIsFRU.1 == true(1) 2351 2 Chassis Ethernet Backplanes: 2352 entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' 2353 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 2354 entPhysicalContainedIn.2 == 1 2355 entPhysicalClass.2 == backplane(4) 2356 entPhysicalParentRelPos.2 == 1 2357 entPhysicalName.2 == 'B1' 2358 entPhysicalHardwareRev.2 == 'A(2.04.01)' 2359 entPhysicalSoftwareRev.2 == '' 2360 entPhysicalFirmwareRev.2 == '' 2361 entPhysicalSerialNum.2 == '' 2362 entPhysicalMfgName.2 == 'Acme' 2363 entPhysicalModelName.2 == 'BK-A' 2364 entPhysicalAlias.2 == '' 2365 entPhysicalAssetID.2 == '' 2366 entPhysicalIsFRU.2 == false(2) 2368 entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' 2369 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 2370 entPhysicalContainedIn.3 == 1 2371 entPhysicalClass.3 == backplane(4) 2372 entPhysicalParentRelPos.3 == 2 2373 entPhysicalName.3 == 'B2' 2374 entPhysicalHardwareRev.3 == 'A(2.04.01)' 2375 entPhysicalSoftwareRev.3 == '' 2376 entPhysicalFirmwareRev.3 == '' 2377 entPhysicalSerialNum.3 == '' 2378 entPhysicalMfgName.3 == 'Acme' 2379 entPhysicalModelName.3 == 'BK-A' 2380 entPhysicalAlias.3 == '' 2381 entPhysicalAssetID.3 == '' 2382 entPhysicalIsFRU.3 == false(2) 2384 3 slots within the chassis: 2385 entPhysicalDescr.4 == 'Acme Hub Slot Type RB' 2386 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 2387 entPhysicalContainedIn.4 == 1 2388 entPhysicalClass.4 == container(5) 2389 entPhysicalParentRelPos.4 == 1 2390 entPhysicalName.4 == 'Slot 1' 2391 entPhysicalHardwareRev.4 == 'B(1.00.03)' 2392 entPhysicalSoftwareRev.4 == '' 2393 entPhysicalFirmwareRev.4 == '' 2394 entPhysicalSerialNum.4 == '' 2395 entPhysicalMfgName.4 == 'Acme' 2396 entPhysicalModelName.4 == 'RB' 2397 entPhysicalAlias.4 == '' 2398 entPhysicalAssetID.4 == '' 2399 entPhysicalIsFRU.4 == false(2) 2401 entPhysicalDescr.5 == 'Acme Hub Slot Type RB' 2402 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 2403 entPhysicalContainedIn.5 == 1 2404 entPhysicalClass.5 == container(5) 2405 entPhysicalParentRelPos.5 == 2 2406 entPhysicalName.5 == 'Slot 2' 2407 entPhysicalHardwareRev.5 == 'B(1.00.03)' 2408 entPhysicalSoftwareRev.5 == '' 2409 entPhysicalFirmwareRev.5 == '' 2410 entPhysicalSerialNum.5 == '' 2411 entPhysicalMfgName.5 == 'Acme' 2412 entPhysicalModelName.5 == 'RB' 2413 entPhysicalAlias.5 == '' 2414 entPhysicalAssetID.5 == '' 2415 entPhysicalIsFRU.5 == false(2) 2417 entPhysicalDescr.6 == 'Acme Hub Slot Type RB' 2418 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 2419 entPhysicalContainedIn.6 == 1 2420 entPhysicalClass.6 == container(5) 2421 entPhysicalParentRelPos.6 == 3 2422 entPhysicalName.6 == 'Slot 3' 2423 entPhysicalHardwareRev.6 == 'B(1.00.03)' 2424 entPhysicalSoftwareRev.6 == '' 2425 entPhysicalFirmwareRev.6 == '' 2426 entPhysicalSerialNum.6 == '' 2427 entPhysicalMfgName.6 == 'Acme' 2428 entPhysicalModelName.6 == 'RB' 2429 entPhysicalAlias.6 == '' 2430 entPhysicalAssetID.6 == '' 2431 entPhysicalIsFRU.6 == false(2) 2433 Slot 1 contains a plug-in module with 4 10-BaseT ports: 2434 entPhysicalDescr.7 == 'Acme 10Base-T Module 114' 2435 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 2436 entPhysicalContainedIn.7 == 4 2437 entPhysicalClass.7 == module(9) 2438 entPhysicalParentRelPos.7 == 1 2439 entPhysicalName.7 == 'M1' 2440 entPhysicalHardwareRev.7 == 'A(1.02.01)' 2441 entPhysicalSoftwareRev.7 == '1.7.2' 2442 entPhysicalFirmwareRev.7 == 'A(1.5)' 2443 entPhysicalSerialNum.7 == 'C100096244' 2444 entPhysicalMfgName.7 == 'Acme' 2445 entPhysicalModelName.7 = '114' 2446 entPhysicalAlias.7 == 'bldg09:floor1:eng' 2447 entPhysicalAssetID.7 == '0007962951' 2448 entPhysicalIsFRU.7 == true(1) 2450 entPhysicalDescr.8 == 'Acme 10Base-T Port RB' 2451 entPhysicalVendorType.8 == acmeProducts.portTypes.10 2452 entPhysicalContainedIn.8 == 7 2453 entPhysicalClass.8 == port(10) 2454 entPhysicalParentRelPos.8 == 1 2455 entPhysicalName.8 == 'Ethernet-A' 2456 entPhysicalHardwareRev.8 == 'A(1.04F)' 2457 entPhysicalSoftwareRev.8 == '' 2458 entPhysicalFirmwareRev.8 == '1.4' 2459 entPhysicalSerialNum.8 == '' 2460 entPhysicalMfgName.8 == 'Acme' 2461 entPhysicalModelName.8 == 'RB' 2462 entPhysicalAlias.8 == '' 2463 entPhysicalAssetID.8 == '' 2464 entPhysicalIsFRU.8 == false(2) 2466 entPhysicalDescr.9 == 'Acme 10Base-T Port RB' 2467 entPhysicalVendorType.9 == acmeProducts.portTypes.10 2468 entPhysicalContainedIn.9 == 7 2469 entPhysicalClass.9 == port(10) 2470 entPhysicalParentRelPos.9 == 2 2471 entPhysicalName.9 == 'Ethernet-B' 2472 entPhysicalHardwareRev.9 == 'A(1.04F)' 2473 entPhysicalSoftwareRev.9 == '' 2474 entPhysicalFirmwareRev.9 == '1.4' 2475 entPhysicalSerialNum.9 == '' 2476 entPhysicalMfgName.9 == 'Acme' 2477 entPhysicalModelName.9 = 'RB' 2478 entPhysicalAlias.9 == '' 2479 entPhysicalAssetID.9 == '' 2480 entPhysicalIsFRU.9 == false(2) 2482 entPhysicalDescr.10 == 'Acme 10Base-T Port RB' 2483 entPhysicalVendorType.10 == acmeProducts.portTypes.10 2484 entPhysicalContainedIn.10 == 7 2485 entPhysicalClass.10 == port(10) 2486 entPhysicalParentRelPos.10 == 3 2487 entPhysicalName.10 == 'Ethernet-C' 2488 entPhysicalHardwareRev.10 == 'B(1.02.07)' 2489 entPhysicalSoftwareRev.10 == '' 2490 entPhysicalFirmwareRev.10 == '1.4' 2491 entPhysicalSerialNum.10 == '' 2492 entPhysicalMfgName.10 == 'Acme' 2493 entPhysicalModelName.10 == 'RB' 2494 entPhysicalAlias.10 == '' 2495 entPhysicalAssetID.10 == '' 2496 entPhysicalIsFRU.10 == false(2) 2498 entPhysicalDescr.11 == 'Acme 10Base-T Port RB' 2499 entPhysicalVendorType.11 == acmeProducts.portTypes.10 2500 entPhysicalContainedIn.11 == 7 2501 entPhysicalClass.11 == port(10) 2502 entPhysicalParentRelPos.11 == 4 2503 entPhysicalName.11 == 'Ethernet-D' 2504 entPhysicalHardwareRev.11 == 'B(1.02.07)' 2505 entPhysicalSoftwareRev.11 == '' 2506 entPhysicalFirmwareRev.11 == '1.4' 2507 entPhysicalSerialNum.11 == '' 2508 entPhysicalMfgName.11 == 'Acme' 2509 entPhysicalModelName.11 == 'RB' 2510 entPhysicalAlias.11 == '' 2511 entPhysicalAssetID.11 == '' 2512 entPhysicalIsFRU.11 == false(2) 2514 Slot 2 contains another ethernet module with 2 ports. 2515 entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' 2516 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 2517 entPhysicalContainedIn.12 = 5 2518 entPhysicalClass.12 == module(9) 2519 entPhysicalParentRelPos.12 == 1 2520 entPhysicalName.12 == 'M2' 2521 entPhysicalHardwareRev.12 == 'A(1.01.07)' 2522 entPhysicalSoftwareRev.12 == '1.8.4' 2523 entPhysicalFirmwareRev.12 == 'A(1.8)' 2524 entPhysicalSerialNum.12 == 'C100102384' 2525 entPhysicalMfgName.12 == 'Acme' 2526 entPhysicalModelName.12 == '4' 2527 entPhysicalAlias.12 == 'bldg09:floor1:devtest' 2528 entPhysicalAssetID.12 == '0007968462' 2529 entPhysicalIsFRU.12 == true(1) 2531 entPhysicalDescr.13 == 'Acme 802.3 AUI Port' 2532 entPhysicalVendorType.13 == acmeProducts.portTypes.11 2533 entPhysicalContainedIn.13 == 12 2534 entPhysicalClass.13 == port(10) 2535 entPhysicalParentRelPos.13 == 1 2536 entPhysicalName.13 == 'AUI' 2537 entPhysicalHardwareRev.13 == 'A(1.06F)' 2538 entPhysicalSoftwareRev.13 == '' 2539 entPhysicalFirmwareRev.13 == '1.5' 2540 entPhysicalSerialNum.13 == '' 2541 entPhysicalMfgName.13 == 'Acme' 2542 entPhysicalModelName.13 == '' 2543 entPhysicalAlias.13 == '' 2544 entPhysicalAssetID.13 == '' 2545 entPhysicalIsFRU.13 == false(2) 2547 entPhysicalDescr.14 == 'Acme 10Base-T Port RD' 2548 entPhysicalVendorType.14 == acmeProducts.portTypes.14 2549 entPhysicalContainedIn.14 == 12 2550 entPhysicalClass.14 == port(10) 2551 entPhysicalParentRelPos.14 == 2 2552 entPhysicalName.14 == 'E2' 2553 entPhysicalHardwareRev.14 == 'B(1.01.02)' 2554 entPhysicalSoftwareRev.14 == '' 2555 entPhysicalFirmwareRev.14 == '2.1' 2556 entPhysicalSerialNum.14 == '' 2557 entPhysicalMfgName.14 == 'Acme' 2558 entPhysicalModelName.14 == '' 2559 entPhysicalAlias.14 == '' 2560 entPhysicalAssetID.14 == '' 2561 entPhysicalIsFRU.14 == false(2) 2563 Logical entities -- entLogicalTable; with SNMPv3 support 2564 Repeater 1--comprised of any ports attached to backplane 1 2565 entLogicalDescr.1 == 'Acme repeater v3.1' 2566 entLogicalType.1 == snmpDot3RptrMgt 2567 entLogicalCommunity.1 'public-repeater1' 2568 entLogicalTAddress.1 == 124.125.126.127:161 2569 entLogicalTDomain.1 == snmpUDPDomain 2570 entLogicalContextEngineID.1 == '80000777017c7d7e7f'H 2571 entLogicalContextName.1 == 'repeater1' 2573 Repeater 2--comprised of any ports attached to backplane 2: 2574 entLogicalDescr.2 == 'Acme repeater v3.1' 2575 entLogicalType.2 == snmpDot3RptrMgt 2576 entLogicalCommunity.2 == 'public-repeater2' 2577 entLogicalTAddress.2 == 124.125.126.127:161 2578 entLogicalTDomain.2 == snmpUDPDomain 2579 entLogicalContextEngineID.2 == '80000777017c7d7e7f'H 2580 entLogicalContextName.2 == 'repeater2' 2582 Logical to Physical Mappings -- entLPMappingTable: 2584 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 2585 [ed. -- Note that a mapping to the module is not included, 2586 since in this example represents a port-switchable hub. 2587 Even though all ports on the module could belong to the 2588 same repeater as a matter of configuration, the LP port 2589 mappings should not be replaced dynamically with a single 2590 mapping for the module (e.g., entLPPhysicalIndex.1.7). 2591 If all ports on the module shared a single backplane connection, 2592 then a single mapping for the module would be more appropriate. ] 2594 entLPPhysicalIndex.1.2 == 2 2595 entLPPhysicalIndex.1.8 == 8 2596 entLPPhysicalIndex.1.9 == 9 2597 entLPPhysicalIndex.1.13 == 13 2599 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 2600 entLPPhysicalIndex.2.3 == 3 2601 entLPPhysicalIndex.2.10 == 10 2602 entLPPhysicalIndex.2.11 == 11 2603 entLPPhysicalIndex.2.14 == 14 2605 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2606 Repeater Port Identifier values are shared by both repeaters: 2607 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 2608 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 2609 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 2610 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 2611 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 2612 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 2614 Physical Containment Tree -- entPhysicalContainsTable 2615 chassis has two backplanes and three containers: 2616 entPhysicalChildIndex.1.2 == 2 2617 entPhysicalChildIndex.1.3 == 3 2618 entPhysicalChildIndex.1.4 == 4 2619 entPhysicalChildIndex.1.5 == 5 2620 entPhysicalChildIndex.1.6 == 6 2622 container 1 has a module: 2623 entPhysicalChildIndex.4.7 == 7 2625 container 2 has a module 2626 entPhysicalChildIndex.5.12 == 12 2627 [ed. - in this example, container 3 is empty.] 2629 module 1 has 4 ports: 2630 entPhysicalChildIndex.7.8 == 8 2631 entPhysicalChildIndex.7.9 == 9 2632 entPhysicalChildIndex.7.10 == 10 2633 entPhysicalChildIndex.7.11 == 11 2635 module 2 has 2 ports: 2636 entPhysicalChildIndex.12.13 == 13 2637 entPhysicalChildIndex.12.14 == 14 2639 5. Security Considerations 2641 There are a number of management objects defined in this MIB that 2642 have a MAX-ACCESS clause of read-write and/or read-create. Such 2643 objects may be considered sensitive or vulnerable in some network 2644 environments. The support for SET operations in a non-secure 2645 environment without proper protection can have a negative effect on 2646 network operations. 2648 There are a number of managed objects in this MIB that may contain 2649 sensitive information. These are: 2651 entPhysicalDescr 2652 entPhysicalVendorType 2653 entPhysicalHardwareRev 2654 entPhysicalFirmwareRev 2655 entPhysicalSoftwareRev 2656 entPhysicalSerialNum 2657 entPhysicalMfgName 2658 entPhysicalModelName 2660 These objects expose information about the physical entities within 2661 a managed system, which may be used to identify the vendor, model, 2662 and version information of each system component. 2664 entPhysicalAssetID 2666 This object can allow asset identifiers for various system 2667 components to be exposed, in the event this MIB object is actually 2668 configured by an NMS application. 2670 entLogicalDescr 2671 entLogicalType 2673 These objects expose the type of logical entities present in the 2674 managed system. 2676 entLogicalCommunity 2678 This object exposes community names associated with particular 2679 logical entities within the system. 2681 entLogicalTAddress 2682 entLogicalTDomain 2683 These objects expose network addresses that can be used to 2684 communicate with an SNMP agent on behalf of particular logical 2685 entities within the system. 2687 entLogicalContextEngineID 2688 entLogicalContextName 2690 These objects identify the authoritative SNMP engine that contains 2691 information on behalf of particular logical entities within the 2692 system. 2694 It is thus important to control even GET access to these objects 2695 and possibly to even encrypt the values of these object when 2696 sending them over the network via SNMP. Not all versions of SNMP 2697 provide features for such a secure environment. 2699 SNMPv1 by itself is not a secure environment. Even if the network 2700 itself is secure (for example by using IPSec), even then, there is 2701 no control as to who on the secure network is allowed to access and 2702 GET/SET (read/change/create/delete) the objects in this MIB. 2704 It is recommended that the implementers consider the security 2705 features as provided by the SNMPv3 framework. Specifically, the 2706 use of the User-based Security Model RFC 2574 [RFC2574] and the 2707 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 2709 It is then a customer/user responsibility to ensure that the SNMP 2710 entity giving access to an instance of this MIB, is properly 2711 configured to give access to the objects only to those principals 2712 (users) that have legitimate rights to indeed GET or SET 2713 (change/create/delete) them. 2715 6. IANA Considerations 2717 This document has no actions for IANA. 2719 7. Acknowledgements 2721 This memo has been produced by the IETF's Entity MIB working group. 2723 8. References 2725 8.1. Normative References 2727 [RFC2026] 2728 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2729 2026, October, 1996. 2731 [RFC2396] 2732 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource 2733 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 2735 [RFC2578] 2736 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2737 and S. Waldbusser, "Structure of Management Information Version 2 2738 (SMIv2)", STD 58, RFC 2578, April 1999. 2740 [RFC2579] 2741 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2742 and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2743 2579, April 1999. 2745 [RFC2580] 2746 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2747 and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2748 2580, April 1999. 2750 [RFC3411] 2751 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2752 Describing Simple Network Management Protocol (SNMP) Management 2753 Frameworks", STD 62, RFC 3411, December 2002. 2755 [RFC3417] 2756 R. Presuhn, Ed., "Transport Mappings for the Simple Network 2757 Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 2759 8.2. Informative References 2761 [RFC1157] 2762 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2763 Management Protocol", STD 15, RFC 1157, May 1990. 2765 [RFC1493] 2766 Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, 2767 "Definitions of Managed Objects for Bridges", RFC 1493, July, 1993. 2769 [RFC1516] 2770 McMaster, D., and K. McCloghrie, "Definitions of Managed Objects 2771 for IEEE 802.3 Repeater Devices", RFC 1516, September, 1993. 2773 [RFC2037] 2774 McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037, 2775 October 1996. 2777 [RFC2108] 2778 de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, 2779 "Definitions of Managed Objects for IEEE 802.3 Repeater Devices 2780 using SMIv2", RFC 2108, February, 1997. 2782 [RFC2863] 2783 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 2784 2863, June, 2000. 2786 [RFC2737] 2787 McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, 2788 December 1999. 2790 [RFC3410] 2791 Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and 2792 Applicability Statements for Internet- Standard Management 2793 Framework", RFC 3410, December 2002. 2795 Authors' Addresses 2797 Andy Bierman 2798 Cisco Systems, Inc. 2799 170 West Tasman Drive 2800 San Jose, CA 95134 USA 2801 Phone: +1 408-527-3711 2802 Email: abierman@cisco.com 2804 Keith McCloghrie 2805 Cisco Systems, Inc. 2806 170 West Tasman Drive 2807 San Jose, CA 95134 USA 2808 Phone: +1 408-526-5260 2809 Email: kzm@cisco.com 2811 Intellectual Property Statement 2813 The IETF takes no position regarding the validity or scope of any 2814 Intellectual Property Rights or other rights that might be claimed 2815 to pertain to the implementation or use of the technology described 2816 in this document or the extent to which any license under such 2817 rights might or might not be available; nor does it represent that 2818 it has made any independent effort to identify any such rights. 2819 Information on the procedures with respect to rights in RFC 2820 documents can be found in BCP 78 and BCP 79. 2822 Copies of IPR disclosures made to the IETF Secretariat and any 2823 assurances of licenses to be made available, or the result of an 2824 attempt made to obtain a general license or permission for the use 2825 of such proprietary rights by implementers or users of this 2826 specification can be obtained from the IETF on-line IPR repository 2827 at http://www.ietf.org/ipr. 2829 The IETF invites any interested party to bring to its attention any 2830 copyrights, patents or patent applications, or other proprietary 2831 rights that may cover technology that may be required to implement 2832 this standard. Please address the information to the IETF at ietf- 2833 ipr@ietf.org. 2835 Disclaimer of Validity 2837 This document and the information contained herein are provided on 2838 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2839 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 2840 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2841 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2842 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2843 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2844 PARTICULAR PURPOSE. 2846 Copyright Statement 2848 Copyright (C) The Internet Society (2004). This document is 2849 subject to the rights, licenses and restrictions contained in BCP 2850 78, and except as set forth therein, the authors retain all their 2851 rights. 2853 Acknowledgment 2855 Funding for the RFC Editor function is currently provided by the 2856 Internet Society.