idnits 2.17.1 draft-ietf-entmib-entmib-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The 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 (18 June 1996) is 10171 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '3') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1904 (ref. '5') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '6') ** Obsolete normative reference: RFC 1573 (ref. '7') (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1906 (ref. '8') (Obsoleted by RFC 3417) ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') Summary: 19 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 3 Entity MIB 5 18 June 1996 7 Keith McCloghrie 8 Cisco Systems Inc. 9 kzm@cisco.com 11 Andy Bierman 12 Cisco Systems Inc. 13 abierman@cisco.com 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 Draft Entity MIB June 1996 34 1. Introduction 36 This memo defines an experimental portion of the Management Information 37 Base (MIB) for use with network management protocols in the Internet 38 community. In particular, it describes managed objects used for 39 managing multiple logical and physical entities managed by a single SNMP 40 agent. 42 Draft Entity MIB June 1996 44 2. The SNMP Network Management Framework 46 The SNMP Network Management Framework presently consists of three major 47 components. They are: 49 o the SMI, described in RFC 1902 [1], - the mechanisms used for 50 describing and naming objects for the purpose of management. 52 o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed objects 53 for the Internet suite of protocols. 55 o the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol for 56 accessing managed information. 58 Textual conventions are defined in RFC 1903 [3], and conformance 59 statements are defined in RFC 1904 [5]. 61 The Framework permits new objects to be defined for the purpose of 62 experimentation and evaluation. 64 This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A 65 semantically identical MIB conforming to the SNMPv1 SMI can be produced 66 through the appropriate translation. 68 2.1. Object Definitions 70 Managed objects are accessed via a virtual information store, termed the 71 Management Information Base or MIB. Objects in the MIB are defined 72 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 73 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 74 an administratively assigned name. The object type together with an 75 object instance serves to uniquely identify a specific instantiation of 76 the object. For human convenience, we often use a textual string, 77 termed the descriptor, to refer to the object type. 79 Draft Entity MIB June 1996 81 3. Overview 83 There is a need for a standardized way of representing a single agent 84 which supports multiple instances of one MIB. This is presently true 85 for at least 3 standard MIBs, and is likely to become true for more and 86 more MIBs as time passes. For example: 88 - multiple instances of a bridge supported within a single device 89 having a single agent; 91 - multiple repeaters supported by a single agent; 93 - multiple OSPF backbone areas, each one operating as part of its own 94 Autonomous System, and each identified by the same area-id (e.g., 95 0.0.0.0), supported inside a single router with one agent. 97 The fact that it is a single agent in each of these cases implies there 98 is some relationship which binds all of these entities together. 99 Effectively, there is some "overall" physical entity which houses the 100 sum of the things managed by that one agent, i.e., there are multiple 101 "logical" entities within a single physical entity. Sometimes, the 102 overall physical entity contains multiple (smaller) physical entities 103 and each logical entity is associated with a particular physical entity. 104 Sometimes, the overall physical entity is a "compound" of multiple 105 physical entities (e.g., a stack of stackable hubs). 107 What is needed is a way to determine exactly what logical entities are 108 managed by the agent (either by SNMPv1 or SNMPv2), and thereby to be 109 able to communicate with the agent about a particular logical entity. 110 When different logical entities are associated with different physical 111 entities within the overall physical entity, it is also useful to be 112 able to use this information to distinguish between logical entities. 114 In these situations, there is no need for varbinds for multiple logical 115 entities to be referenced in the same SNMP message (although that might 116 be useful in the future). Rather, it is sufficient, and in some 117 situations preferable, to have the context/community in the message 118 identify the logical entity to which the varbinds apply. 120 3.1. Terms 122 Some new terms are used throughout this document: 124 Draft Entity MIB June 1996 126 - Naming Scope 127 A "naming scope" represents the set of information that may be 128 potentially accessed through a single SNMP operation. All instances 129 within the naming scope share the same unique identifier space. For 130 SNMPv1, a naming scope is identified by the value of the associated 131 'entLogicalCommunity' instance. 133 - Multi-Scoped Object 134 A MIB object, for which identical instance values identify 135 different managed information in different naming scopes, is called 136 a "multi-scoped" MIB object. 138 - Single-Scoped Object 139 A MIB object, for which identical instance values identify the same 140 managed information in different naming scopes, is called a 141 "single-scoped" MIB object. 143 - Logical Entity 144 A managed system contains one or more logical entities, each 145 represented by at most one instantiation of each of a particular 146 set of MIB objects. A set of management functions is associated 147 with each logical entity. Examples of logical entities include 148 routers, bridges, print-servers, etc. 150 - Physical Entity 151 A "physical entity" or "physical component" represents an 152 identifiable physical resource within a managed system. Zero or 153 more logical entities may utilize a physical resource at any given 154 time. It is an implementation-specific manner as to which physical 155 components are represented by an agent in the EntPhysicalTable. 156 Typically, physical resources (e.g. communications ports, 157 backplanes, sensors, daughter-cards, power supplies, the overall 158 chassis) which can be managed via functions associated with one or 159 more logical entities are included in the MIB. 161 - Containment Tree 162 Each physical component may optionally be modeled as 'contained' 163 within another physical component. A "containment-tree" is the 164 conceptual sequence of entPhysicalIndex values which uniquely 165 specifies the exact physical location of a physical component 166 within the managed system. It is generated by 'following and 167 recording' each 'entPhysicalContainedIn' instance 'up the tree 168 towards the root', until a value of zero indicating no further 169 containment is found. 171 Draft Entity MIB June 1996 173 Note that chassis slots, which are capable of accepting one or more 174 module types from one or more vendors, are modeled as containers in 175 this MIB. The value of entPhysicalContainedIn for a particular 176 'module' entity (entPhysicalClass value of 'module(9)') must be 177 equal to an entPhysicalIndex that represents the parent 'container' 178 entity (associated entPhysicalClass value of ('container(5)'). An 179 agent must represent both empty and full containers in the 180 entPhysicalTable. 182 3.2. Relationship to Community Strings 184 For community-based SNMP, distinguishing between different logical 185 entities is one (but not the only) purpose of the community string [6]. 186 This is accommodated by representing each community string as a logical 187 entity. 189 Note that different logical entities may share the same naming scope 190 (and therefore the same values of entLogicalCommunity). This is 191 possible, providing they have no need for the same instance of a MIB 192 object to represent different managed information. 194 3.3. Relationship to Proxy Mechanisms 196 The Entity MIB is designed to allow functional component discovery. The 197 administrative relationships between different logical entities are not 198 visible in any Entity MIB tables. An NMS cannot determine whether MIB 199 instances in different naming scopes are realized locally or remotely 200 (e.g. via some proxy mechanism) by examining any particular Entity MIB 201 objects. 203 The management of administrative framework functions is not an explicit 204 goal of the Entity MIB WG at this time. This new area of functionality 205 may be revisited after some operational experience with the Entity MIB 206 is gained. 208 Note that a network administrator will likely be able to associate 209 community strings with naming scopes with proprietary mechanisms, as a 210 matter of configuration. There are no mechanisms for managing naming 211 scopes defined in this MIB. 213 Draft Entity MIB June 1996 215 3.4. Relationship to a Chassis MIB 217 Some readers may recall that a previous IETF working group attempted to 218 define a Chassis MIB. No consensus was reached by that working group, 219 possibly because its scope was too broad. As such, it is not the 220 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 221 the scope of this MIB to contain all the information which might be 222 necessary to manage a "chassis". On the other hand, the entities 223 represented by an implementation of this MIB might well be contained in 224 a chassis. 226 3.5. Relationship to the Interfaces MIB 228 The Entity MIB contains a mapping table identifying physical components 229 that have 'external values' (e.g. ifIndex) associated with them within a 230 given naming scope. This table can be used to identify the physical 231 location of each interface in the ifTable [7]. Since ifIndex values in 232 different contexts are not related to one another, the interface to 233 physical component associations are relative to the same logical entity 234 within the agent. 236 The Entity MIB also contains an 'entPhysicalName' object, which 237 approximates the semantics of the ifName object from the Interfaces MIB 238 [7] for all types of physical components. 240 3.6. Relationship to the Other MIBs 242 The Entity MIB contains a mapping table identifying physical components 243 that have identifiers from other standard MIBs associated with them. 244 For example, this table can be used along with the physical mapping 245 table to identify the physical location of each repeater port in the 246 rptrPortTable, or each interface in the ifTable. 248 3.7. Relationship to Naming Scopes 250 There is some question as to which MIB objects may be returned within a 251 given naming scope. MIB objects which are not multi-scoped within a 252 managed system are likely to ignore context information in 253 implementation. In such a case, it is likely such objects will be 254 returned in all naming scopes (e.g. not just the 'main' naming scope). 256 For example, a community string used to access the management 257 Draft Entity MIB June 1996 259 information for logical device 'bridge2' may allow access to all the 260 non-bridge related objects in the 'main' naming scope, as well as a 261 second instance of the Bridge MIB. 263 It is an implementation-specific matter as to the isolation of single- 264 scoped MIB objects by the agent. An agent may wish to limit the objects 265 returned in a particular naming scope to just the multi-scoped objects 266 in that naming scope (e.g. system group and the Bridge MIB). In this 267 case, all single-scoped management information would belong to a common 268 naming scope (e.g. 'main'), which itself may contain some multi-scoped 269 objects (e.g. system group). 271 3.8. Multiple Instances of the Entity MIB 273 It is possible that more than one agent exists in a managed system, and 274 in such cases, multiple instances of the Entity MIB (representing the 275 same managed objects) may be available to an NMS. 277 In order to reduce complexity for agent implementation, multiple 278 instances of the Entity MIB are not required to be equivalent or even 279 consistent. An NMS may be able to 'align' instances returned by 280 different agents by examining the columns of each table, but vendor- 281 specific identifiers and (especially) index values are likely to be 282 different. Each agent may be managing different subsets of the entire 283 chassis as well. 285 When all of a physically-modular device is represented by a single 286 agent, the entry for which entPhysicalContainedIn has the value zero 287 would likely have 'chassis' as the value of its entPhysicalClass; 288 alternatively, for an agent on a module where the agent represents only 289 the physical entities on that module (not those on other modules), the 290 entry for which entPhysicalContainedIn has the value zero would likely 291 have 'module' as the value of its entPhysicalClass. 293 An agent implementation of the entLogicalTable is not required to 294 contain information about logical entities managed primarily by other 295 agents. That is, the entLogicalTAddress and entLogicalTDomain objects in 296 the entLogicalTable are provided to support an historical multiplexing 297 mechanism, not to identify other SNMP agents. 299 Note that the Entity MIB is a single-scoped MIB, in the event an agent 300 represents the MIB in different naming scopes. 302 Draft Entity MIB June 1996 304 3.9. Re-Configuration of Entities 306 All the MIB objects defined in this MIB have at most a read-only MAX- 307 ACCESS clause, i.e., none are write-able. This is a conscious decision 308 by the working group to limit this MIB's scope. It is possible that 309 this restriction could be lifted after implementation experience, by 310 means of additional tables (using the AUGMENTS clause) for configuration 311 and extended entity information. 313 3.10. MIB Structure 315 The Entity MIB contains five conformance groups: 317 - entityPhysical group 318 Describes the physical entities managed by a single agent. 320 - entityLogical group 321 Describes the logical entities managed by a single agent. 323 - entityMapping group 324 Describes the associations between the physical entities, logical 325 entities, interfaces, and non-interface ports managed by a single 326 agent. 328 -entityGeneral group 329 Describes general system attributes shared by potentially all types 330 of entities managed by a single agent. 332 -entityNotifications group 333 Contains status indication notifications. 335 3.10.1. entityPhysical Group 337 This group contains a single table to identify physical system 338 components, called the entPhysicalTable. 340 The entPhysicalTable contains one row per physical entity, and must 341 always contains at least one row for an "overall" physical entity. Each 342 row is indexed by an arbitrary, small integer, and contains a 343 description and type of the physical entity. It also optionally 344 contains the index number of another entPhysicalEntry indicating a 345 containment relationship between the two. 347 Draft Entity MIB June 1996 349 3.10.2. entityLogical Group 351 This group contains a single table to identify logical entities, called 352 the entLogicalTable. 354 The entLogicalTable contains one row per logical entity. Each row is 355 indexed by an arbitrary, small integer and contains a name, description, 356 and type of the logical entity. It also contains information to allow 357 SNMPv1 or SNMPv2C [9] access to the MIB information for the logical 358 entity. 360 3.10.3. entityMapping Group 362 This group contains a three tables to identify associations between 363 different system components. 365 The entLPMappingTable contains mappings between entLogicalIndex values 366 (logical entities) and entPhysicalIndex values (the physical components 367 supporting that entity). A logical entity can map to more than one 368 physical component, and more than one logical entity can map to (share) 369 the same physical component. 371 The entAliasMappingTable contains mappings between entLogicalIndex, 372 entPhysicalIndex pairs and 'alias' object identifier values. This 373 allows resources managed with other MIBs (e.g. repeater ports, bridge 374 ports, physical and logical interfaces) to be identified in the physical 375 entity hierarchy. Note that each alias identifier is only relevant in a 376 particular naming scope. 378 The entPhysicalContainsTable contains simple mappings between 379 'entPhysicalContainedIn' values for each container/containee 380 relationship in the managed system. The indexing of this table allows an 381 NMS to quickly discover the 'entPhysicalIndex' values for all children 382 of a given physical entity. 384 3.10.4. entityGeneral Group 386 This group contains general information relating to the other object 387 groups. 389 Draft Entity MIB June 1996 391 At this time, the entGeneral group contains a single scalar object 392 (entLastChangeTime), which represents the value of sysUptime when any 393 part of the system configuration last changed. 395 3.10.5. entityNotifications Group 397 This group contains notification definitions relating to the overall 398 status of the Entity MIB instantiation. 400 3.11. Multiple Agents 402 Even though a primary motivation for this MIB is to represent the 403 multiple logical entities supported by a single agent, it is also 404 possible to use it to represent multiple logical entities supported by 405 multiple agents (in the same "overall" physical entity). Indeed, it is 406 implicit in the SNMP architecture, that the number of agents is 407 transparent to a network management station. 409 However, there is no agreement at this time as to the degree of 410 cooperation which should be expected for agent implementations. 411 Therefore, multiple agents within the same managed system are free to 412 implement the Entity MIB independently. (Refer the section on "Multiple 413 Instances of the Entity MIB" for more details). 415 Draft Entity MIB June 1996 417 4. Definitions 419 ENTITY-MIB DEFINITIONS ::= BEGIN 421 IMPORTS 422 MODULE-IDENTITY, OBJECT-TYPE, 423 experimental, NOTIFICATION-TYPE 424 FROM SNMPv2-SMI 425 TDomain, TAddress, DisplayString, TEXTUAL-CONVENTION, 426 AutonomousType, RowPointer, TimeStamp 427 FROM SNMPv2-TC 428 MODULE-COMPLIANCE, OBJECT-GROUP 429 FROM SNMPv2-CONF; 431 entityMIB MODULE-IDENTITY 432 LAST-UPDATED "9605160000Z" 433 ORGANIZATION "IETF ENTMIB Working Group" 434 CONTACT-INFO 435 " WG E-mail: entmib@cisco.com 436 Subscribe: majordomo@cisco.com 437 msg body: subscribe entmib 439 Keith McCloghrie 440 ENTMIB Working Group Chair 441 Cisco Systems Inc. 442 170 West Tasman Drive 443 San Jose, CA 95134 444 408-526-5260 445 kzm@cisco.com 447 Andy Bierman 448 ENTMIB Working Group Editor 449 Cisco Systems Inc. 450 170 West Tasman Drive 451 San Jose, CA 95134 452 408-527-3711 453 abierman@cisco.com" 454 DESCRIPTION 455 "The MIB module for representing multiple logical 456 entities supported by a single SNMP agent." 457 ::= { experimental xx } 459 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 461 -- MIB contains four groups 462 Draft Entity MIB June 1996 464 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } 465 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } 466 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } 467 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } 469 -- Textual Conventions 470 PhysicalIndex ::= TEXTUAL-CONVENTION 471 STATUS current 472 DESCRIPTION 473 "An arbitrary value which uniquely identifies the physical 474 entity. The value is a small positive integer; index values 475 for different physical entities are not necessarily 476 contiguous." 477 SYNTAX INTEGER (1..2147483647) 479 PhysicalClass ::= TEXTUAL-CONVENTION 480 STATUS current 481 DESCRIPTION 482 "An enumerated value which provides an indication of the 483 general hardware type of a particular physical entity." 484 SYNTAX INTEGER { 485 other(1), 486 unknown(2), 487 chassis(3), 488 backplane(4), 489 container(5), -- e.g. slot or daughter-card holder 490 powerSupply(6), 491 fan(7), 492 sensor(8), 493 module(9), -- e.g. plug-in card or daughter-card 494 port(10) 495 } 497 Draft Entity MIB June 1996 499 -- The Physical Entity Table 501 entPhysicalTable OBJECT-TYPE 502 SYNTAX SEQUENCE OF EntPhysicalEntry 503 MAX-ACCESS not-accessible 504 STATUS current 505 DESCRIPTION 506 "This table contains one row per physical entity. There is 507 always at least one row for an 'overall' physical entity." 508 ::= { entityPhysical 1 } 510 entPhysicalEntry OBJECT-TYPE 511 SYNTAX EntPhysicalEntry 512 MAX-ACCESS not-accessible 513 STATUS current 514 DESCRIPTION 515 "Information about a particular physical entity. 517 Each entry provides objects (entPhysicalDescr, 518 entPhysicalVendorType, and entPhysicalClass) to help an NMS 519 identify and characterize the entry, and objects 520 (entPhysicalContainedIn and entPhysicalParentRelPos) to help 521 an NMS relate the particular entry to other entries in this 522 table." 523 INDEX { entPhysicalIndex } 524 ::= { entPhysicalTable 1 } 526 EntPhysicalEntry ::= SEQUENCE { 527 entPhysicalIndex PhysicalIndex, 528 entPhysicalDescr DisplayString, 529 entPhysicalVendorType AutonomousType, 530 entPhysicalContainedIn INTEGER, 531 entPhysicalClass PhysicalClass, 532 entPhysicalParentRelPos INTEGER, 533 entPhysicalName DisplayString 534 } 536 entPhysicalIndex OBJECT-TYPE 537 SYNTAX PhysicalIndex 538 MAX-ACCESS not-accessible 539 STATUS current 540 DESCRIPTION 541 "The index for this entry." 542 ::= { entPhysicalEntry 1 } 544 Draft Entity MIB June 1996 546 entPhysicalDescr OBJECT-TYPE 547 SYNTAX DisplayString 548 MAX-ACCESS read-only 549 STATUS current 550 DESCRIPTION 551 "A textual description of physical entity. This object 552 should contain a string which identifies the manufacturer's 553 name for the physical entity, and should be set to a 554 distinct value for each version or model of the physical 555 entity. " 556 ::= { entPhysicalEntry 2 } 558 entPhysicalVendorType OBJECT-TYPE 559 SYNTAX AutonomousType 560 MAX-ACCESS read-only 561 STATUS current 562 DESCRIPTION 563 "An indication of the vendor-specific hardware type of the 564 physical entity. Note that this is different from the 565 definition of MIB-II's sysObjectID. 567 An agent should set this object to a enterprise-specific 568 registration identifier value indicating the specific 569 equipment type in detail. The associated instance of 570 entPhysicalClass is used to indicate the general type of 571 hardware device. 573 If no vendor-specific registration identifier exists for 574 this physical entity, or the value is unknown by this agent, 575 then the value { 0 0 } is returned." 576 ::= { entPhysicalEntry 3 } 578 entPhysicalContainedIn OBJECT-TYPE 579 SYNTAX INTEGER (0..2147483647) 580 MAX-ACCESS read-only 581 STATUS current 582 DESCRIPTION 583 "The value of entPhysicalIndex for the physical entity which 584 'contains' this physical entity. A value of zero indicates 585 this physical entity is not contained in any other physical 586 entity. Note that the set of 'containment' relationships 587 define a strict hierarchy; that is, recursion is not 588 allowed." 589 ::= { entPhysicalEntry 4 } 591 Draft Entity MIB June 1996 593 entPhysicalClass OBJECT-TYPE 594 SYNTAX PhysicalClass 595 MAX-ACCESS read-only 596 STATUS current 597 DESCRIPTION 598 "An indication of the general hardware type of the physical 599 entity. 601 An agent should set this object to the standard enumeration 602 value which most accurately indicates the general class of 603 the physical entity, or the primary class if there is more 604 than one. 606 If no appropriate standard registration identifier exists 607 for this physical entity, then the value 'other(1)' is 608 returned. If the value is unknown by this agent, then the 609 value 'unknown(2)' is returned." 610 ::= { entPhysicalEntry 5 } 612 entPhysicalParentRelPos OBJECT-TYPE 613 SYNTAX INTEGER (-1..2147483647) 614 MAX-ACCESS read-only 615 STATUS current 616 DESCRIPTION 617 "An indication of the relative position of this 'child' 618 component among all its 'sibling' components. Sibling 619 components are defined as entPhysicalEntries which share the 620 same instance values of each of the entPhysicalContainedIn 621 and entPhysicalClass objects. 623 An NMS can use this object to identify the relative ordering 624 for all sibling components of a particular parent 625 (identified by the entPhysicalContainedIn instance in each 626 sibling entry). 628 This value should match any external labeling of the 629 physical component if possible. For example, for a module 630 labeled as 'card #3', entPhysicalParentRelPos should have 631 the value '3'. 633 If the physical position of this component does not match 634 any external numbering or clearly visible ordering, then 635 user documentation or other external reference material 636 should be used to determine the parent-relative position. If 637 this is not possible, then the the agent should assign a 639 Draft Entity MIB June 1996 641 consistent (but possibly arbitrary) ordering to a given set 642 of 'sibling' components, perhaps based on internal 643 representation of the components. 645 If the agent cannot determine the parent-relative position 646 for some reason, or if the associated value of 647 entPhysicalContainedIn is '0', then the value '-1' is 648 returned. Otherwise a non-negative integer is returned, 649 indicating the parent-relative position of this physical 650 entity. 652 Parent-relative ordering normally starts from '1' and 653 continues to 'N', where 'N' represents the highest 654 positioned child entity. However, if the physical entities 655 (e.g. slots) are labeled from a starting position of zero, 656 then the first sibling should be associated with a 657 entPhysicalParentRelPos value of '0'. Note that this 658 ordering may be sparse or dense, depending on agent 659 implementation. 661 The actual values returned are not globally meaningful, as 662 each 'parent' component may use different numbering 663 algorithms. The ordering is only meaningful among siblings 664 of the same parent component. 666 The agent should retain parent-relative position values 667 across reboots, either through algorithmic assignment or use 668 of non-volatile storage." 669 ::= { entPhysicalEntry 6 } 671 entPhysicalName OBJECT-TYPE 672 SYNTAX DisplayString 673 MAX-ACCESS read-only 674 STATUS current 675 DESCRIPTION 676 "The textual name of the physical entity. The value of this 677 object should be the name of the component as assigned by 678 the local device and should be suitable for use in commands 679 entered at the device's `console'. This might be a text 680 name, such as `console' or a simple component number (e.g. 681 port or module number), such as `1', depending on the 682 physical component naming syntax of the device. 684 If there is no local name, or this object is otherwise not 686 Draft Entity MIB June 1996 688 applicable, then this object contains a zero-length string. 690 Note that the value of entPhysicalName for two physical 691 entities will be the same in the event that the console 692 interface does not distinguish between them, e.g., slot-1 693 and the card in slot-1." 694 ::= { entPhysicalEntry 7 } 696 Draft Entity MIB June 1996 698 -- The Logical Entity Table 699 entLogicalTable OBJECT-TYPE 700 SYNTAX SEQUENCE OF EntLogicalEntry 701 MAX-ACCESS not-accessible 702 STATUS current 703 DESCRIPTION 704 "This table contains one row per logical entity. At least 705 one entry must exist." 706 ::= { entityLogical 1 } 708 entLogicalEntry OBJECT-TYPE 709 SYNTAX EntLogicalEntry 710 MAX-ACCESS not-accessible 711 STATUS current 712 DESCRIPTION 713 "Information about a particular logical entity. Entities 714 may be managed by this agent or other SNMP agents (possibly) 715 in the same chassis." 716 INDEX { entLogicalIndex } 717 ::= { entLogicalTable 1 } 719 EntLogicalEntry ::= SEQUENCE { 720 entLogicalIndex INTEGER, 721 entLogicalDescr DisplayString, 722 entLogicalType AutonomousType, 723 entLogicalCommunity OCTET STRING, 724 entLogicalTAddress TAddress, 725 entLogicalTDomain TDomain 726 } 728 entLogicalIndex OBJECT-TYPE 729 SYNTAX INTEGER (1..2147483647) 730 MAX-ACCESS not-accessible 731 STATUS current 732 DESCRIPTION 733 "The value of this object uniquely identifies the logical 734 entity. The value is a small positive integer; index values 735 for different logical entities are are not necessarily 736 contiguous." 737 ::= { entLogicalEntry 1 } 739 entLogicalDescr OBJECT-TYPE 740 SYNTAX DisplayString 741 MAX-ACCESS read-only 742 STATUS current 744 Draft Entity MIB June 1996 746 DESCRIPTION 747 "A textual description of the logical entity. This object 748 should contain a string which identifies the manufacturer's 749 name for the logical entity, and should be set to a distinct 750 value for each version of the logical entity. " 751 ::= { entLogicalEntry 2 } 753 entLogicalType OBJECT-TYPE 754 SYNTAX AutonomousType 755 MAX-ACCESS read-only 756 STATUS current 757 DESCRIPTION 758 "An indication of the type of logical entity. This will 759 typically be the OBJECT IDENTIFIER name of the node in the 760 SMI's naming hierarchy which represents the major MIB 761 module, or the majority of the MIB modules, supported by the 762 logical entity. For example: 763 a logical entity of a regular host/router -> mib-2 764 a logical entity of a 802.1d bridge -> dot1dBridge 765 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 766 If an appropriate node in the SMI's naming hierarchy cannot 767 be identified, the value 'mib-2' should be used." 768 ::= { entLogicalEntry 3 } 770 entLogicalCommunity OBJECT-TYPE 771 SYNTAX OCTET STRING (SIZE (1..255)) 772 MAX-ACCESS read-only 773 STATUS current 774 DESCRIPTION 775 "An SNMPv1 or SNMPv2C community-string which can be used to 776 access detailed management information for this logical 777 entity. The agent should allow read access with this 778 community string (to an appropriate subset of all managed 779 objects) and may also choose to return a community string 780 based on the privileges of the request used to read this 781 object. Note that an agent may choose to return a community 782 string with read-only privileges, even if this object is 783 accessed with a read-write community string. However, the 784 agent must take care not to return a community string which 785 allows more privileges than the community string used to 786 access this object. 788 A compliant SNMP agent may wish to conserve naming scopes by 789 representing multiple logical entities in a single 'main' 790 naming scope. This is possible when the logical entities 792 Draft Entity MIB June 1996 794 represented by the same value of entLogicalCommunity have no 795 object instances in common. For example, 'bridge1' and 796 'repeater1' may be part of the main naming scope, but at 797 least one additional community string is needed to represent 798 'bridge2' and 'repeater2'. 800 Logical entities 'bridge1' and 'repeater1' would be 801 represented by sysOREntries associated with the 'main' 802 naming scope. 804 For agents not accessible via SNMPv1 or SNMPv2C, the value 805 of this object is the empty-string." 806 ::= { entLogicalEntry 4 } 808 entLogicalTAddress OBJECT-TYPE 809 SYNTAX TAddress 810 MAX-ACCESS read-only 811 STATUS current 812 DESCRIPTION 813 "The transport service address by which the logical entity 814 receives network management traffic, formatted according to 815 the corresponding value of entLogicalTDomain. 817 For snmpUDPDomain, a TAddress is 6 octets long, the initial 818 4 octets containing the IP-address in network-byte order and 819 the last 2 containing the UDP port in network-byte order. 820 Consult 'Transport Mappings for Version 2 of the Simple 821 Network Management Protocol' (RFC 1906 [8]) for further 822 information on snmpUDPDomain." 823 ::= { entLogicalEntry 5 } 825 entLogicalTDomain OBJECT-TYPE 826 SYNTAX TDomain 827 MAX-ACCESS read-only 828 STATUS current 829 DESCRIPTION 830 "Indicates the kind of transport service by which the 831 logical entity receives network management traffic. 832 Possible values for this object are presently found in the 833 Transport Mappings for SNMPv2 document (RFC 1906 [8])." 834 ::= { entLogicalEntry 6 } 836 Draft Entity MIB June 1996 838 entLPMappingTable OBJECT-TYPE 839 SYNTAX SEQUENCE OF EntLPMappingEntry 840 MAX-ACCESS not-accessible 841 STATUS current 842 DESCRIPTION 843 "This table contains zero or more rows of logical entity to 844 physical equipment associations. For each logical entity 845 known by this agent, there are zero or more mappings to the 846 physical resources which are used to realize that logical 847 entity. 849 An agent should limit the number and nature of entries in 850 this table such that only meaningful and non-redundant 851 information is returned. For example, in a system which 852 contains a single power supply, mappings between logical 853 entities and the power supply are not useful and should not 854 be included. 856 Also, only the most appropriate physical component which is 857 closest to the root of a particular containment tree should 858 be identified in an entLPMapping entry. 860 For example, suppose a bridge is realized on a particular 861 module, and all ports on that module are ports on this 862 bridge. A mapping between the bridge and the module would be 863 useful, but additional mappings between the bridge and each 864 of the ports on that module would be redundant (since the 865 entPhysicalContainedIn hierarchy can provide the same 866 information). If, on the other hand, more than one bridge 867 was utilizing ports on this module, then mappings between 868 each bridge and the ports it used would be appropriate. 870 Also, in the case of a single backplane repeater, a mapping 871 for the backplane to the single repeater entity is not 872 necessary." 873 ::= { entityMapping 1 } 875 entLPMappingEntry OBJECT-TYPE 876 SYNTAX EntLPMappingEntry 877 MAX-ACCESS not-accessible 878 STATUS current 879 DESCRIPTION 880 "Information about a particular logical entity to physical 881 equipment association. Note that the nature of the 882 association is not specifically identified in this entry. It 884 Draft Entity MIB June 1996 886 is expected that sufficient information exists in the MIBs 887 used to manage a particular logical entity to infer how 888 physical component information is utilized." 889 INDEX { entLogicalIndex, entLPPhysicalIndex } 890 ::= { entLPMappingTable 1 } 892 EntLPMappingEntry ::= SEQUENCE { 893 entLPPhysicalIndex PhysicalIndex 894 } 896 entLPPhysicalIndex OBJECT-TYPE 897 SYNTAX PhysicalIndex 898 MAX-ACCESS read-only 899 STATUS current 900 DESCRIPTION 901 "The value of this object identifies the index value of a 902 particular entPhysicalEntry associated with the indicated 903 entLogicalEntity." 904 ::= { entLPMappingEntry 1 } 906 Draft Entity MIB June 1996 908 -- logical entity/component to alias table 909 entAliasMappingTable OBJECT-TYPE 910 SYNTAX SEQUENCE OF EntAliasMappingEntry 911 MAX-ACCESS not-accessible 912 STATUS current 913 DESCRIPTION 914 "This table contains zero or more rows, representing 915 mappings of logical entity and physical component to 916 external MIB identifiers. Each physical port in the system 917 may be associated with a mapping to an external identifier, 918 which itself is associated with a particular logical 919 entity's naming scope. A 'wildcard' mechanism is provided to 920 indicate that an identifier is associated with more than one 921 logical entity." 922 ::= { entityMapping 2 } 924 entAliasMappingEntry OBJECT-TYPE 925 SYNTAX EntAliasMappingEntry 926 MAX-ACCESS not-accessible 927 STATUS current 928 DESCRIPTION 929 "Information about a particular physical equipment, logical 930 entity to external identifier binding. Each logical 931 entity/physical component pair may be associated with one 932 alias mapping. The logical entity index may also be used as 933 a 'wildcard' (refer to the entAliasLogicalIndexOrZero object 934 DESCRIPTION clause for details.) 936 Note that only entPhysicalIndex values which represent 937 physical ports (i.e. associated entPhysicalClass value is 938 'port(10)') are permitted to exist in this table." 939 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 940 ::= { entAliasMappingTable 1 } 942 EntAliasMappingEntry ::= SEQUENCE { 943 entAliasLogicalIndexOrZero INTEGER, 944 entAliasMappingIdentifier RowPointer 945 } 947 entAliasLogicalIndexOrZero OBJECT-TYPE 948 SYNTAX INTEGER (0..2147483647) 949 MAX-ACCESS not-accessible 950 STATUS current 951 DESCRIPTION 952 "The value of this object uniquely identifies the logical 954 Draft Entity MIB June 1996 956 entity which defines the naming scope for the associated 957 instance of the 'entAliasMappingIdentifier' object. 959 If this object has a non-zero value, then it identifies the 960 logical entity named by the same value of entLogicalIndex. 962 If this object has a value of zero, then the mapping between 963 the physical component and the alias identifier for this 964 entAliasMapping entry is associated with all unspecified 965 logical entities. That is, a value of zero (the default 966 mapping) identifies any logical entity which does not have 967 an explicit entry in this table for a particular 968 entPhysicalIndex/entAliasMappingIdentifier pair. 970 For example, to indicate that a particular interface (e.g. 971 physical component 33) is identified by the same value of 972 ifIndex for all logical entities, the following instance 973 might exist: 975 entAliasMappingIdentifier.33.0 = ifIndex.5 977 In the event an entPhysicalEntry is associated differently 978 for some logical entities, additional entAliasMapping 979 entries may exist, e.g.: 981 entAliasMappingIdentifier.33.0 = ifIndex.6 982 entAliasMappingIdentifier.33.4 = ifIndex.1 983 entAliasMappingIdentifier.33.5 = ifIndex.1 984 entAliasMappingIdentifier.33.10 = ifIndex.12 986 Note that entries with non-zero entAliasLogicalIndexOrZero 987 index values have precedence over any zero-indexed entry. In 988 this example, all logical entities except 4, 5, and 10, 989 associate physical entity 33 with ifIndex.6." 990 ::= { entAliasMappingEntry 1 } 992 entAliasMappingIdentifier OBJECT-TYPE 993 SYNTAX RowPointer 994 MAX-ACCESS read-only 995 STATUS current 996 DESCRIPTION 997 "The value of this object identifies a particular conceptual 998 row associated with the indicated entPhysicalIndex and 999 entLogicalIndex pair. 1001 Draft Entity MIB June 1996 1003 Since only physical ports are modeled in this table, only 1004 entries which represent interfaces or ports are allowed. If 1005 an ifEntry exists on behalf of a particular physical port, 1006 then this object should identify the associated 'ifEntry'. 1007 For repeater ports, the appropriate row in the 1008 'rptrPortGroupTable' should be identified instead. 1010 For example, suppose a physical port was represented by 1011 entPhysicalEntry.3, entLogicalEntry.15 existed for a 1012 repeater, and entLogicalEntry.22 existed for a bridge. Then 1013 there might be two related instances of 1014 entAliasMappingIdentifier: 1015 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 1016 entAliasMappingIdentifier.3.22 == ifIndex.17 1017 It is possible that other mappings (besides interfaces and 1018 repeater ports) may be defined in the future, as required. 1020 Bridge ports are identified by examining the Bridge MIB and 1021 appropriate ifEntries associated with each 'dot1dBasePort', 1022 and are thus not represented in this table." 1023 ::= { entAliasMappingEntry 2 } 1025 Draft Entity MIB June 1996 1027 -- physical mapping table 1028 entPhysicalContainsTable OBJECT-TYPE 1029 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 1030 MAX-ACCESS not-accessible 1031 STATUS current 1032 DESCRIPTION 1033 "A table which exposes the container/containee relationships 1034 between physical entities. This table provides equivalent 1035 information found by constructing the virtual containment 1036 tree for a given entPhysicalTable but in a more direct 1037 format." 1038 ::= { entityMapping 3 } 1040 entPhysicalContainsEntry OBJECT-TYPE 1041 SYNTAX EntPhysicalContainsEntry 1042 MAX-ACCESS not-accessible 1043 STATUS current 1044 DESCRIPTION 1045 "A single container/containee relationship." 1046 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1047 ::= { entPhysicalContainsTable 1 } 1049 EntPhysicalContainsEntry ::= SEQUENCE { 1050 entPhysicalChildIndex PhysicalIndex 1051 } 1053 entPhysicalChildIndex OBJECT-TYPE 1054 SYNTAX PhysicalIndex 1055 MAX-ACCESS read-only 1056 STATUS current 1057 DESCRIPTION 1058 "The value of entPhysicalIndex for the contained physical 1059 entity." 1060 ::= { entPhysicalContainsEntry 1 } 1062 Draft Entity MIB June 1996 1064 -- last change time stamp for the whole MIB 1065 entLastChangeTime OBJECT-TYPE 1066 SYNTAX TimeStamp 1067 MAX-ACCESS read-only 1068 STATUS current 1069 DESCRIPTION 1070 "The value of sysUpTime at the time any of these events 1071 occur: 1072 * a conceptual row is created or deleted in any 1073 of these tables: 1074 - entPhysicalTable 1075 - entLogicalTable 1076 - entLPMappingTable 1077 - entAliasMappingTable 1078 - entPhysicalContainsTable 1080 * any instance in the following list of objects 1081 changes value: 1082 - entPhysicalDescr 1083 - entPhysicalVendorType 1084 - entPhysicalContainedIn 1085 - entPhysicalClass 1086 - entPhysicalParentRelPos 1087 - entPhysicalName 1088 - entLogicalDescr 1089 - entLogicalType 1090 - entLogicalCommunity 1091 - entLogicalTAddress 1092 - entLogicalTDomain 1093 - entAliasMappingIdentifier " 1094 ::= { entityGeneral 1 } 1096 Draft Entity MIB June 1996 1098 -- Entity MIB Trap Definitions 1099 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1100 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1102 entConfigChange NOTIFICATION-TYPE 1103 STATUS current 1104 DESCRIPTION 1105 "An entConfigChange trap is sent when the value of 1106 entLastChangeTime changes. It can be utilized by an NMS to 1107 trigger logical/physical entity table maintenance polls. 1109 An agent must not generate more than one entConfigChange 1110 'trap-event' in a five second period, where a 'trap-event' 1111 is the transmission of a single trap PDU to a list of trap 1112 destinations. If additional configuration changes occur 1113 within the five second 'throttling' period, then these 1114 trap-events should be suppressed by the agent. An NMS should 1115 periodically check the value of entLastChangeTime to detect 1116 any missed entConfigChange trap-events, e.g. due to 1117 throttling or transmission loss." 1118 ::= { entityMIBTrapPrefix 1 } 1120 Draft Entity MIB June 1996 1122 -- conformance information 1123 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1125 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1126 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1128 -- compliance statements 1130 entityCompliance MODULE-COMPLIANCE 1131 STATUS current 1132 DESCRIPTION 1133 "The compliance statement for SNMP entities which implement 1134 the Entity MIB." 1135 MODULE -- this module 1136 MANDATORY-GROUPS { entityPhysicalGroup, 1137 entityLogicalGroup, 1138 entityMappingGroup, 1139 entityGeneralGroup, 1140 entityNotificationsGroup } 1141 ::= { entityCompliances 1 } 1143 -- MIB groupings 1145 entityPhysicalGroup OBJECT-GROUP 1146 OBJECTS { 1147 entPhysicalDescr, 1148 entPhysicalVendorType, 1149 entPhysicalContainedIn, 1150 entPhysicalClass, 1151 entPhysicalParentRelPos, 1152 entPhysicalName 1153 } 1154 STATUS current 1155 DESCRIPTION 1156 "The collection of objects which are used to represent 1157 physical system components, for which a single agent 1158 provides management information." 1159 ::= { entityGroups 1 } 1161 entityLogicalGroup OBJECT-GROUP 1162 OBJECTS { 1163 entLogicalDescr, 1164 entLogicalType, 1165 entLogicalCommunity, 1166 entLogicalTAddress, 1168 Draft Entity MIB June 1996 1170 entLogicalTDomain 1171 } 1172 STATUS current 1173 DESCRIPTION 1174 "The collection of objects which are used to represent the 1175 list of logical entities for which a single agent provides 1176 management information." 1177 ::= { entityGroups 2 } 1179 entityMappingGroup OBJECT-GROUP 1180 OBJECTS { 1181 entLPPhysicalIndex, 1182 entAliasMappingIdentifier, 1183 entPhysicalChildIndex 1184 } 1185 STATUS current 1186 DESCRIPTION 1187 "The collection of objects which are used to represent the 1188 associations between multiple logical entities, physical 1189 components, interfaces, and port identifiers for which a 1190 single agent provides management information." 1191 ::= { entityGroups 3 } 1193 entityGeneralGroup OBJECT-GROUP 1194 OBJECTS { 1195 entLastChangeTime 1196 } 1197 STATUS current 1198 DESCRIPTION 1199 "The collection of objects which are used to represent 1200 general entity information for which a single agent provides 1201 management information." 1202 ::= { entityGroups 4 } 1204 entityNotificationsGroup NOTIFICATION-GROUP 1205 NOTIFICATIONS { entConfigChange } 1206 STATUS current 1207 DESCRIPTION 1208 "The collection of notifications used to indicate Entity MIB 1209 data consistency and general status information." 1210 ::= { entityGroups 5 } 1212 END 1213 Draft Entity MIB June 1996 1215 5. Usage Examples 1217 The following sections iterate the instance values for two example 1218 networking devices. These examples are kept simple to make them more 1219 understandable. Auxiliary components, such as fans, sensors, empty 1220 slots, and sub-modules are not shown, but might be modeled in real 1221 implementations. 1223 5.1. Router/Bridge 1225 A router containing two slots. Each slot contains a 3 port 1226 router/bridge module. Each port is represented in the ifTable. There 1227 are two logical instances of OSPF running and two logical bridges: 1229 Physical entities -- entPhysicalTable: 1230 1 Field-replaceable physical chassis: 1231 entPhysicalDescr.1 == "Acme Chassis Model 100" 1232 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 1233 entPhysicalContainedIn.1 == 0 1234 entPhysicalClass.1 == chassis(3) 1235 entPhysicalParentRelPos.1 == 0 1236 entPhysicalName.1 == '100-A' 1238 2 slots within the chassis: 1239 entPhysicalDescr.2 == "Acme Chassis Slot Type AA" 1240 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 1241 entPhysicalContainedIn.2 == 1 1242 entPhysicalClass.2 == container(5) 1243 entPhysicalParentRelPos.2 == 1 1244 entPhysicalName.2 == 'S1' 1246 entPhysicalDescr.3 == "Acme Chassis Slot Type AA" 1247 entPhysicalVendorType.3 == acmeProducts.slotTypes.1 1248 entPhysicalContainedIn.3 == 1 1249 entPhysicalClass.3 == container(5) 1250 entPhysicalParentRelPos.3 == 2 1251 entPhysicalName.3 == 'S2' 1253 2 Field-replaceable modules: 1254 Slot 1 contains a module with 3 ports: 1255 entPhysicalDescr.4 == "Acme Router-100" 1256 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 1257 entPhysicalContainedIn.4 == 2 1258 entPhysicalClass.4 == module(9) 1260 Draft Entity MIB June 1996 1262 entPhysicalParentRelPos.4 == 1 1263 entPhysicalName.4 == 'M1' 1265 entPhysicalDescr.5 == "Acme Ethernet-100 Port Rev G" 1266 entPhysicalVendorType.5 == acmeProducts.portTypes.2 1267 entPhysicalContainedIn.5 == 4 1268 entPhysicalClass.5 == port(10) 1269 entPhysicalParentRelPos.5 == 1 1270 entPhysicalName.5 == 'P1' 1272 entPhysicalDescr.6 == "Acme Ethernet-100 Port Rev G" 1273 entPhysicalVendorType.6 == acmeProducts.portTypes.2 1274 entPhysicalContainedIn.6 == 4 1275 entPhysicalClass.6 == port(10) 1276 entPhysicalParentRelPos.6 == 2 1277 entPhysicalName.6 == 'P2' 1279 entPhysicalDescr.7 == "Acme Router-100 F-Port: Rev B" 1280 entPhysicalVendorType.7 == acmeProducts.portTypes.3 1281 entPhysicalContainedIn.7 == 4 1282 entPhysicalClass.7 == port(10) 1283 entPhysicalParentRelPos.7 == 3 1284 entPhysicalName.7 == 'P3' 1286 Slot 2 contains another 3-port module: 1287 entPhysicalDescr.8 == "Acme Router-100 Comm Module: Rev C" 1288 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 1289 entPhysicalContainedIn.8 == 3 1290 entPhysicalClass.8 == module(9) 1291 entPhysicalParentRelPos.8 == 1 1292 entPhysicalName.8 == 'M1' 1294 entPhysicalDescr.9 == "Acme Fddi-100 Port Rev CC" 1295 entPhysicalVendorType.9 == acmeProducts.portTypes.5 1296 entPhysicalContainedIn.9 == 8 1297 entPhysicalClass.9 == port(10) 1298 entPhysicalParentRelPos.9 == 1 1299 entPhysicalName.9 == 'FDDI Primary' 1301 entPhysicalDescr.10 == "Acme Ethernet-100 Port Rev G" 1302 entPhysicalVendorType.10 == acmeProducts.portTypes.2 1303 entPhysicalContainedIn.10 == 8 1304 entPhysicalClass.10 == port(10) 1305 entPhysicalParentRelPos.10 == 2 1306 entPhysicalName.10 == 'Ethernet A' 1308 Draft Entity MIB June 1996 1310 entPhysicalDescr.11 == "Acme Ethernet-100 Port Rev G" 1311 entPhysicalVendorType.11 == acmeProducts.portTypes.2 1312 entPhysicalContainedIn.11 == 8 1313 entPhysicalClass.11 == port(10) 1314 entPhysicalParentRelPos.11 == 3 1315 entPhysicalName.11 == 'Ethernet B' 1317 Logical entities -- entLogicalTable 1318 2 OSPF instances: 1319 entLogicalDescr.1 == "Acme OSPF v1.1" 1320 entLogicalType.1 == ospf 1321 entLogicalCommunity.1 == "public-ospf1" 1322 entLogicalTAddress.1 == 124.125.126.127:161 1323 entLogicalTDomain.1 == snmpUDPDomain 1325 entLogicalDescr.2 == "Acme OSPF v1.1" 1326 entLogicalType.2 == ospf 1327 entLogicalCommunity.2 == "public-ospf2" 1328 entLogicalTAddress.2 == 124.125.126.127:161 1329 entLogicalTDomain.2 == snmpUDPDomain 1331 2 logical bridges: 1332 entLogicalDescr.3 == "Acme Bridge v2.1.1" 1333 entLogicalType.3 == dod1dBridge 1334 entLogicalCommunity.3 == "public-bridge1" 1335 entLogicalTAddress.3 == 124.125.126.127:161 1336 entLogicalTDomain.3 == snmpUDPDomain 1338 entLogicalDescr.4 == "Acme Bridge v2.1.1" 1339 entLogicalType.4 == dod1dBridge 1340 entLogicalCommunity.4 == "public-bridge2" 1341 entLogicalTAddress.4 == 124.125.126.127:161 1342 entLogicalTDomain.4 == snmpUDPDomain 1344 Logical to Physical Mappings: 1345 1st OSPF instance: uses module 1-port 1 1346 entLPPhysicalIndex.1.5 == 5 1348 2nd OSPF instance: uses module 2-port 1 1349 entLPPhysicalIndex.2.9 == 9 1351 1st bridge group: uses module 1, all ports 1353 [ed. -- Note that these mappings are included in the table since 1354 another logical entity (1st OSPF) utilizes one of the 1356 Draft Entity MIB June 1996 1358 ports. If this were not the case, then a single mapping 1359 to the module (e.g. entLPPhysicalIndex.3.4) would be 1360 present instead. ] 1361 entLPPhysicalIndex.3.5 == 5 1362 entLPPhysicalIndex.3.6 == 6 1363 entLPPhysicalIndex.3.7 == 7 1365 2nd bridge group: uses module 2, all ports 1366 entLPPhysicalIndex.4.9 == 9 1367 entLPPhysicalIndex.4.10 == 10 1368 entLPPhysicalIndex.4.11 == 11 1370 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 1371 Example 1: ifIndex values are global to all logical entities 1372 entAliasMappingIdentifier.5.0 == ifIndex.1 1373 entAliasMappingIdentifier.6.0 == ifIndex.2 1374 entAliasMappingIdentifier.7.0 == ifIndex.3 1375 entAliasMappingIdentifier.9.0 == ifIndex.4 1376 entAliasMappingIdentifier.10.0 == ifIndex.5 1377 entAliasMappingIdentifier.11.0 == ifIndex.6 1379 Example 2: ifIndex values are not shared by all logical entities 1380 entAliasMappingIdentifier.5.0 == ifIndex.1 1381 entAliasMappingIdentifier.5.3 == ifIndex.101 1382 entAliasMappingIdentifier.6.0 == ifIndex.2 1383 entAliasMappingIdentifier.6.3 == ifIndex.102 1384 entAliasMappingIdentifier.7.0 == ifIndex.3 1385 entAliasMappingIdentifier.7.3 == ifIndex.103 1386 entAliasMappingIdentifier.9.0 == ifIndex.4 1387 entAliasMappingIdentifier.9.3 == ifIndex.204 1388 entAliasMappingIdentifier.10.0 == ifIndex.5 1389 entAliasMappingIdentifier.10.3 == ifIndex.205 1390 entAliasMappingIdentifier.11.0 == ifIndex.6 1391 entAliasMappingIdentifier.11.3 == ifIndex.206 1393 Physical Containment Tree -- entPhysicalContainsTable 1394 chassis has two containers: 1395 entPhysicalChildIndex.1.2 = 2 1396 entPhysicalChildIndex.1.3 = 3 1398 container 1 has a module: 1399 entPhysicalChildIndex.2.4 = 4 1401 container 2 has a module: 1402 entPhysicalChildIndex.3.8 = 8 1404 Draft Entity MIB June 1996 1406 module 1 has 3 ports: 1407 entPhysicalChildIndex.4.5 = 5 1408 entPhysicalChildIndex.4.6 = 6 1409 entPhysicalChildIndex.4.7 = 7 1411 module 2 has 3 ports: 1412 entPhysicalChildIndex.8.9 = 9 1413 entPhysicalChildIndex.8.10 = 10 1414 entPhysicalChildIndex.1.11 = 11 1416 5.2. Repeaters 1418 A 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, 1419 and the remaining slots contain ethernet repeater modules. [ed. -- Note 1420 that a replacement for the current Repeater MIB (RFC 1516) is likely to 1421 emerge soon, and it will no longer be necessary to access repeater MIB 1422 data in different naming scopes.] 1424 Physical entities -- entPhysicalTable: 1425 1 Field-replaceable physical chassis: 1426 entPhysicalDescr.1 == "Acme Chassis Model 110" 1427 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 1428 entPhysicalContainedIn.1 == 0 1429 entPhysicalClass.1 == chassis(3) 1430 entPhysicalParentRelPos.1 == 0 1431 entPhysicalName.1 == '110-B' 1433 2 Chassis Ethernet Backplanes: 1434 entPhysicalDescr.2 == "Acme Ethernet Backplane Type A" 1435 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 1436 entPhysicalContainedIn.2 == 1 1437 entPhysicalClass.2 == backplane(4) 1438 entPhysicalParentRelPos.2 == 1 1439 entPhysicalName.2 == 'B1' 1441 entPhysicalDescr.3 == "Acme Ethernet Backplane Type A" 1442 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 1443 entPhysicalContainedIn.3 == 1 1444 entPhysicalClass.3 == backplane(4) 1445 entPhysicalParentRelPos.3 == 2 1446 entPhysicalName.3 == 'B2' 1448 3 slots within the chassis: 1449 entPhysicalDescr.4 == "Acme Hub Slot Type RB" 1451 Draft Entity MIB June 1996 1453 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 1454 entPhysicalContainedIn.4 == 1 1455 entPhysicalClass.4 == container(5) 1456 entPhysicalParentRelPos.4 == 1 1457 entPhysicalName.4 == 'Slot 1' 1459 entPhysicalDescr.5 == "Acme Hub Slot Type RB" 1460 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 1461 entPhysicalContainedIn.5 == 1 1462 entPhysicalClass.5 == container(5) 1463 entPhysicalParentRelPos.5 == 2 1464 entPhysicalName.5 == 'Slot 2' 1466 entPhysicalDescr.6 == "Acme Hub Slot Type RB" 1467 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 1468 entPhysicalContainedIn.6 == 1 1469 entPhysicalClass.6 == container(5) 1470 entPhysicalParentRelPos.6 == 3 1471 entPhysicalName.6 == 'Slot 3' 1473 Slot 1 contains a plug-in module with 4 10-BaseT ports: 1474 entPhysicalDescr.7 == "Acme 10Base-T Module 114 Rev A" 1475 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 1476 entPhysicalContainedIn.7 == 4 1477 entPhysicalClass.7 == module(9) 1478 entPhysicalParentRelPos.7 == 1 1479 entPhysicalName.7 == 'M1' 1481 entPhysicalDescr.8 == "Acme 10Base-T Port RB Rev A" 1482 entPhysicalVendorType.8 == acmeProducts.portTypes.10 1483 entPhysicalContainedIn.8 == 7 1484 entPhysicalClass.8 == port(10) 1485 entPhysicalParentRelPos.8 == 1 1486 entPhysicalName.8 == 'Ethernet-A' 1488 entPhysicalDescr.9 == "Acme 10Base-T Port RB Rev A" 1489 entPhysicalVendorType.9 == acmeProducts.portTypes.10 1490 entPhysicalContainedIn.9 == 7 1491 entPhysicalClass.9 == port(10) 1492 entPhysicalParentRelPos.9 == 2 1493 entPhysicalName.9 == 'Ethernet-B' 1495 entPhysicalDescr.10 == "Acme 10Base-T Port RB Rev B" 1496 entPhysicalVendorType.10 == acmeProducts.portTypes.10 1497 entPhysicalContainedIn.10 == 7 1499 Draft Entity MIB June 1996 1501 entPhysicalClass.10 == port(10) 1502 entPhysicalParentRelPos.10 == 3 1503 entPhysicalName.10 == 'Ethernet-C' 1505 entPhysicalDescr.11 == "Acme 10Base-T Port RB Rev B" 1506 entPhysicalVendorType.11 == acmeProducts.portTypes.10 1507 entPhysicalContainedIn.11 == 7 1508 entPhysicalClass.11 == port(10) 1509 entPhysicalParentRelPos.11 == 4 1510 entPhysicalName.11 == 'Ethernet-D' 1512 Slot 2 contains another ethernet module with 2 ports. 1513 entPhysicalDescr.12 == "Acme 10Base-T Module Model 4 Rev A" 1514 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 1515 entPhysicalContainedIn.12 = 5 1516 entPhysicalClass.12 == module(9) 1517 entPhysicalParentRelPos.12 == 1 1518 entPhysicalName.12 == 'M1' 1520 entPhysicalDescr.13 == "Acme 802.3 AUI Port Rev A" 1521 entPhysicalVendorType.13 == acmeProducts.portTypes.11 1522 entPhysicalContainedIn.13 == 12 1523 entPhysicalClass.13 == port(10) 1524 entPhysicalParentRelPos.13 == 1 1525 entPhysicalName.13 == 'AUI' 1527 entPhysicalDescr.14 == "Acme 10Base-T Port RD Rev B" 1528 entPhysicalVendorType.14 == acmeProducts.portTypes.14 1529 entPhysicalContainedIn.14 == 12 1530 entPhysicalClass.14 == port(10) 1531 entPhysicalParentRelPos.14 == 2 1532 entPhysicalName.14 == 'E2' 1534 Logical entities -- entLogicalTable 1535 Repeater 1--comprised of any ports attached to backplane 1 1536 entLogicalDescr.1 == "Acme repeater v3.1" 1537 entLogicalType.1 == snmpDot3RptrMgt 1538 entLogicalCommunity.1 "public-repeater1" 1539 entLogicalTAddress.1 == 124.125.126.127:161 1540 entLogicalTDomain.1 == snmpUDPDomain 1542 Repeater 2--comprised of any ports attached to backplane 2: 1543 entLogicalDescr.2 == "Acme repeater v3.1" 1544 entLogicalType.2 == snmpDot3RptrMgt 1545 entLogicalCommunity.2 == "public-repeater2" 1547 Draft Entity MIB June 1996 1549 entLogicalTAddress.2 == 124.125.126.127:161 1550 entLogicalTDomain.2 == snmpUDPDomain 1552 Logical to Physical Mappings -- entLPMappingTable: 1554 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 1555 [ed. -- Note that a mapping to the module is not included, 1556 since in this example represents a port-switchable hub. 1557 Even though all ports on the module could belong to the 1558 same repeater as a matter of configuration, the LP port 1559 mappings should not be replaced dynamically with a single 1560 mapping for the module (e.g. entLPPhysicalIndex.1.7). 1561 If all ports on the module shared a single backplane connection, 1562 then a single mapping for the module would be more appropriate. ] 1564 entLPPhysicalIndex.1.2 == 2 1565 entLPPhysicalIndex.1.8 == 8 1566 entLPPhysicalIndex.1.9 == 9 1567 entLPPhysicalIndex.1.13 == 13 1569 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 1570 entLPPhysicalIndex.2.3 == 3 1571 entLPPhysicalIndex.2.10 == 10 1572 entLPPhysicalIndex.2.11 == 11 1573 entLPPhysicalIndex.2.14 == 14 1575 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 1576 Repeater Port Identifier values are shared by both repeaters: 1577 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 1578 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 1579 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 1580 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 1581 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 1582 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 1584 Physical Containment Tree -- entPhysicalContainsTable 1585 chassis has two backplanes and three containers: 1586 entPhysicalChildIndex.1.2 = 2 1587 entPhysicalChildIndex.1.3 = 3 1588 entPhysicalChildIndex.1.4 = 4 1589 entPhysicalChildIndex.1.5 = 5 1590 entPhysicalChildIndex.1.6 = 6 1592 container 1 has a module: 1593 entPhysicalChildIndex.4.7 = 7 1595 Draft Entity MIB June 1996 1597 container 2 has a module 1598 entPhysicalChildIndex.5.12 = 12 1599 [ed. - in this example, container 3 is empty.] 1601 module 1 has 4 ports: 1602 entPhysicalChildIndex.7.8 = 8 1603 entPhysicalChildIndex.7.9 = 9 1604 entPhysicalChildIndex.7.10 = 10 1605 entPhysicalChildIndex.7.11 = 11 1607 module 2 has 2 ports: 1608 entPhysicalChildIndex.12.13 = 13 1609 entPhysicalChildIndex.12.14 = 14 1611 Draft Entity MIB June 1996 1613 6. Acknowledgements 1615 This document was produced by the IETF Entity MIB Working Group. 1617 Draft Entity MIB June 1996 1619 7. References 1621 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1622 S. Waldbusser, "Structure of Management Information for version 2 1623 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1624 January 1996. 1626 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 1627 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1628 RFC 1213, Hughes LAN Systems, Performance Systems International, 1629 March 1991. 1631 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1632 S. Waldbusser, "Textual Conventions for version 2 of the Simple 1633 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1635 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1636 S. Waldbusser, "Protocol Operations for version 2 of the Simple 1637 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1639 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1640 S. Waldbusser, "Conformance Statements for version 2 of the Simple 1641 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1643 [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1644 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1645 International, MIT Laboratory for Computer Science, May 1990. 1647 [7] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 1648 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 1650 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1651 S. Waldbusser, "Transport Mappings for version 2 of the Simple 1652 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 1654 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1655 S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 1656 January 1996. 1658 Draft Entity MIB June 1996 1660 8. Security Considerations 1662 Security issues are not discussed in this memo. 1664 9. Authors' Addresses 1666 Keith McCloghrie 1667 Cisco Systems, Inc. 1668 170 West Tasman Drive 1669 San Jose, CA 95134 1670 Phone: 408-526-5260 1671 Email: kzm@cisco.com 1673 Andy Bierman 1674 Cisco Systems, Inc. 1675 170 West Tasman Drive 1676 San Jose, CA 95134 1677 Phone: 408-527-3711 1678 Email: abierman@cisco.com 1680 Draft Entity MIB June 1996 1682 Table of Contents 1684 1 Introduction .................................................... 2 1685 2 The SNMP Network Management Framework ........................... 3 1686 2.1 Object Definitions ............................................ 3 1687 3 Overview ........................................................ 4 1688 3.1 Terms ......................................................... 4 1689 3.2 Relationship to Community Strings ............................. 6 1690 3.3 Relationship to Proxy Mechanisms .............................. 6 1691 3.4 Relationship to a Chassis MIB ................................. 7 1692 3.5 Relationship to the Interfaces MIB ............................ 7 1693 3.6 Relationship to the Other MIBs ................................ 7 1694 3.7 Relationship to Naming Scopes ................................. 7 1695 3.8 Multiple Instances of the Entity MIB .......................... 8 1696 3.9 Re-Configuration of Entities .................................. 9 1697 3.10 MIB Structure ................................................ 9 1698 3.10.1 entityPhysical Group ....................................... 9 1699 3.10.2 entityLogical Group ........................................ 10 1700 3.10.3 entityMapping Group ........................................ 10 1701 3.10.4 entityGeneral Group ........................................ 10 1702 3.10.5 entityNotifications Group .................................. 11 1703 3.11 Multiple Agents .............................................. 11 1704 4 Definitions ..................................................... 12 1705 5 Usage Examples .................................................. 32 1706 5.1 Router/Bridge ................................................. 32 1707 5.2 Repeaters ..................................................... 36 1708 6 Acknowledgements ................................................ 41 1709 7 References ...................................................... 42 1710 8 Security Considerations ......................................... 43 1711 9 Authors' Addresses .............................................. 43