idnits 2.17.1 draft-ietf-entmib-entmib-04.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-26) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 24) being 59 lines 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 223 instances of too long lines in the document, the longest one being 5 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 | 2 Entity MIB 4 20 May 1996 | 6 Keith McCloghrie 7 Cisco Systems Inc. 8 kzm@cisco.com 10 Andy Bierman 11 Cisco Systems Inc. 12 abierman@cisco.com 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference material 24 or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 29 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 Draft Entity MIB May 1996 33 1. Introduction 35 This memo defines an experimental portion of the Management Information 36 Base (MIB) for use with network management protocols in the Internet 37 community. In particular, it describes managed objects used for 38 managing multiple logical and physical entities managed by a single SNMP 39 agent. 41 Draft Entity MIB May 1996 43 2. The SNMP Network Management Framework 45 The SNMP Network Management Framework presently consists of three major 46 components. They are: 48 o the SMI, described in RFC 1902 [1], - the mechanisms used for 49 describing and naming objects for the purpose of management. 51 o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed objects 52 for the Internet suite of protocols. 54 o the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol for 55 accessing managed information. 57 Textual conventions are defined in RFC 1903 [3], and conformance 58 statements are defined in RFC 1905 [5]. 60 The Framework permits new objects to be defined for the purpose of 61 experimentation and evaluation. 63 2.1. Object Definitions 65 Managed objects are accessed via a virtual information store, termed the 66 Management Information Base or MIB. Objects in the MIB are defined 67 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 68 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 69 an administratively assigned name. The object type together with an 70 object instance serves to uniquely identify a specific instantiation of 71 the object. For human convenience, we often use a textual string, 72 termed the descriptor, to refer to the object type. 74 Draft Entity MIB May 1996 76 3. Overview 78 There is a need for a standardized way of representing a single agent 79 which supports multiple instances of one MIB. This is presently true 80 for at least 3 standard MIBs, and is likely to become true for more and 81 more MIBs as time passes. For example: 83 - multiple instances of a bridge supported within a single device 84 having a single agent; 86 - multiple repeaters supported by a single agent; 88 - multiple OSPF backbone areas, each one operating as part of its own 89 Autonomous System, and each identified by the same area-id (e.g., 90 0.0.0.0), supported inside a single router with one agent. 92 The fact that it is a single agent in each of these cases implies there 93 is some relationship which binds all of these entities together. 94 Effectively, there is some "overall" physical entity which houses the 95 sum of the things managed by that one agent, i.e., there are multiple 96 "logical" entities within a single physical entity. Sometimes, the 97 overall physical entity contains multiple (smaller) physical entities 98 and each logical entity is associated with a particular physical entity. 99 Sometimes, the overall physical entity is a "compound" of multiple 100 physical entities (e.g., a stack of stackable hubs). 102 What is needed is a way to determine exactly what logical entities are 103 managed by the agent (either by SNMPv1 or SNMPv2), and thereby to be 104 able to communicate with the agent about a particular logical entity. 105 When different logical entities are associated with different physical 106 entities within the overall physical entity, it is also useful to be 107 able to use this information to distinguish between logical entities. 109 In these situations, there is no need for varbinds for multiple logical 110 entities to be referenced in the same SNMP message (although that might 111 be useful in the future). Rather, it is sufficient, and in some 112 situations preferable, to have the context/community in the message 113 identify the logical entity to which the varbinds apply. 115 3.1. Terms 117 Some new terms are used throughout this document: 119 Draft Entity MIB May 1996 121 - Naming Scope 122 A "naming scope" represents the set of information that may be 123 potentially accessed through a single SNMP operation. All instances 124 within the naming scope share the same unique identifier space. For 125 SNMPv1, a naming scope is identified by the value of the associated 126 'entLogicalCommunity' instance. 128 - Multi-Scoped Object 129 A MIB object, for which identical instance values identify 130 different managed information in different naming scopes, is called 131 a "multi-scoped" MIB object. 133 - Single-Scoped Object 134 A MIB object, for which identical instance values identify the same 135 managed information in different naming scopes, is called a 136 "single-scoped" MIB object. 138 - Logical Entity 139 A managed system contains one or more logical entities, each 140 represented by at most one instantiation of each of a particular 141 set of MIB objects. A set of management functions is associated 142 with each logical entity. Examples of logical entities include 143 routers, bridges, print-servers, etc. 145 - Physical Entity 146 A "physical entity" or "physical component" represents an 147 identifiable physical resource within a managed system. Zero or 148 more logical entities may utilize a physical resource at any given 149 time. It is an implementation-specific manner as to which physical 150 components are represented by an agent in the EntPhysicalTable. 151 Typically, physical resources (e.g. communications ports, 152 backplanes, sensors, daughter-cards, power supplies, the overall 153 chassis) which can be managed via functions associated with one or 154 more logical entities are included in the MIB. 156 - Containment Tree 157 Each physical component may optionally be modeled as 'contained' 158 within another physical component. A "containment-tree" is the 159 conceptual sequence of entPhysicalIndex values which uniquely 160 specifies the exact physical location of a physical component 161 within the managed system. It is generated by 'following and 162 recording' each 'entPhysicalContainedIn' instance 'up the tree 163 towards the root', until a value of zero indicating no further 164 containment is found. 166 Draft Entity MIB May 1996 168 Note that chassis slots, which are capable of accepting one or more - 169 module types from one or more vendors, are modeled as containers in 170 this MIB. The value of entPhysicalContainedIn for a particular 171 'module' entity (entPhysicalClass value of 'module(9)') should be 172 equal to an entPhysicalIndex that represents the parent 'container' 173 entity (associated entPhysicalClass value of ('container(5)'). An 174 agent should represent both empty and full containers in the 175 entPhysicalTable. 177 3.2. Relationship to Community Strings 179 For community-based SNMP, distinguishing between different logical 180 entities is one (but not the only) purpose of the community string [6]. 181 This is accommodated by representing each community string as a logical 182 entity. 184 Note that different logical entities may share the same naming scope 185 (and therefore the same values of entLogicalCommunity). This is 186 possible, providing they have no need for the same instance of a MIB 187 object to represent different managed information. In such a case, 188 individual logical entities can be identified by examining the 189 sysORTable within the same naming scope. 191 3.3. Relationship to Proxy Mechanisms 193 The Entity MIB is designed to allow functional component discovery. The 194 administrative relationships between different logical entities are not 195 visible in any Entity MIB tables. An NMS cannot determine whether MIB 196 instances in different naming scopes are realized locally or remotely 197 (e.g. via some proxy mechanism) by examining any particular Entity MIB 198 objects. 200 The management of administrative framework functions is not an explicit 201 goal of the Entity MIB WG at this time. This new area of functionality 202 may be revisited after some operational experience with the Entity MIB 203 is gained. 205 Note that a network administrator will likely be able to associate 206 community strings with naming scopes with proprietary mechanisms, as a 207 matter of configuration. There are no mechanisms for managing naming 208 scopes defined in this MIB. 210 Draft Entity MIB May 1996 212 3.4. Relationship to a Chassis MIB 214 Some readers may recall that a previous IETF working group attempted to 215 define a Chassis MIB. No consensus was reached by that working group, 216 possibly because its scope was too broad. As such, it is not the 217 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 218 the scope of this MIB to contain all the information which might be 219 necessary to manage a "chassis". On the other hand, the entities 220 represented by an implementation of this MIB might well be contained in 221 a chassis. 223 3.5. Relationship to the Interfaces MIB 225 The Entity MIB contains a mapping table identifying physical components 226 that have 'external values' (e.g. ifIndex) associated with them within a 227 given naming scope. This table can be used to identify the physical 228 location of each interface in the ifTable [7]. Since ifIndex values in 229 different contexts are not related to one another, the interface to 230 physical component associations are relative to the same logical entity 231 within the agent. 233 The Entity MIB also contains an 'entPhysicalName' object, which extends + 234 the semantics of the ifName object from the Interfaces MIB [7] to all + 235 types of physical components. + 237 3.6. Relationship to the Other MIBs 239 The Entity MIB contains a mapping table identifying physical components 240 that have identifiers from other standard MIBs associated with them. 241 For example, this table can be used along with the physical mapping 242 table to identify the physical location of each repeater port in the 243 rptrPortTable, or each interface in the ifTable. 245 3.7. Relationship to Naming Scopes 247 There is some question as to which MIB objects may be returned within a 248 given naming scope. MIB objects which are not multi-scoped within a 249 managed system are likely to ignore context information in 250 implementation. In such a case, it is likely such objects will be 251 returned in all naming scopes (e.g. not just the 'main' naming scope). 253 For example, a community string returned for 'bridge2' may allow access 254 Draft Entity MIB May 1996 256 to all the non-bridge related objects in the 'main' naming scope, as 257 well as a second instance of the Bridge MIB. 259 It is an implementation-specific matter as to the isolation of single- 260 scoped MIB objects by the agent. An agent may wish to limit the objects 261 returned in a particular naming scope to just the multi-scoped objects 262 in that naming scope (e.g. system group and the Bridge MIB). In this 263 case, all single-scoped management information would belong to a common 264 naming scope (e.g. 'main'), which itself may contain some multi-scoped 265 objects (e.g. system group). 267 3.8. Multiple Instances of the Entity MIB 269 It is possible that more than one agent exists in a managed system, and 270 in such cases, multiple instances of the Entity MIB (representing the 271 same managed objects) may be available to an NMS. 273 In order to reduce complexity for agent implementation, multiple 274 instances of the Entity MIB are not required to be equivalent or even 275 consistent. An NMS may be able to 'align' instances returned by 276 different agents by examining the columns of each table, but vendor- 277 specific identifiers and (especially) index values are likely to be 278 different. Each agent may be managing different subsets of the entire 279 chassis as well. 281 An agent implementation of the entLogicalTable is not required to 282 contain information about logical entities managed primarily by other 283 agents. That is, the entLogicalTAddress and entLogicalTDomain objects in 284 the entLogicalTable are provided to support an historical multiplexing 285 mechanism, not to identify other SNMP agents. 287 Note that the Entity MIB is a single-scoped MIB, in the event an agent 288 represents the MIB in different naming scopes. 290 3.9. Re-Configuration of Entities 292 All the MIB objects defined in this MIB have at most a read-only MAX- 293 ACCESS clause, i.e., none are write-able. This is another conscious 294 decision by the authors to limit this MIB's scope. It is possible that 295 this restriction could be lifted after implementation experience, and 296 additional tables (using the AUGMENTS clause) added for configuration 297 and extended entity information. 299 Draft Entity MIB May 1996 301 3.10. MIB Structure 303 The Entity MIB contains four groups: + 305 - entityPhysical group 306 Describes the physical entities managed by a single agent. | 308 - entityLogical group | 309 Describes the logical entities managed by a single agent. | 311 - entityMapping group | 312 Describes the associations between the physical entities, logical | 313 entities, interfaces, and non-interface ports managed by a single | 314 agent. | 316 -entityGeneral group | 317 Describes general system attributes shared by potentially all types | 318 of entities managed by a single agent. | 320 3.10.1. entityPhysical Group | 322 This group contains a single table to identify system components, called | 323 the entPhysicalTable. | 325 The entPhysicalTable contains one row per physical entity, and must | 326 always contains at least one row for an "overall" physical entity. Each 327 row is indexed by an arbitrary, small integer, and contains a 328 description and type of the physical entity. It also optionally 329 contains the index number of another entPhysicalEntry indicating a 330 containment relationship between the two. 332 3.10.2. entityLogical Group 334 This group contains a single table to identify logical entities, called + 335 the entLogicalTable. + 337 The entLogicalTable contains one row per logical entity. Each row is 338 indexed by an arbitrary, small integer and contains a name, description, 339 and type of the logical entity. It also contains information to allow | 340 SNMPv1 or SNMPv2C [9] access to the MIB information for the logical | 341 entity. 343 Draft Entity MIB May 1996 345 3.10.3. entityMapping Group 347 This group contains a three tables to identify associations between + 348 different system components. + 350 The entLPMappingTable contains mappings between entLogicalIndex values 351 (logical entities) and entPhysicalIndex values (the physical components 352 supporting that entity). A logical entity can map to more than one 353 physical component, and more than one logical entity can map to (share) 354 the same physical component. 356 The entAliasMappingTable contains mappings between entLogicalIndex, 357 entPhysicalIndex pairs and 'alias' object identifier values. This 358 allows resources managed with other MIBs (e.g. repeater ports, bridge 359 ports, physical and logical interfaces) to be identified in the physical 360 entity hierarchy. Note that each alias identifier is only relevant in a 361 particular naming scope. 363 The entPhysicalContainsTable contains simple mappings between 364 'entPhysicalContainedIn' values for each container/containee 365 relationship in the managed system. The indexing of this table allows an 366 NMS to quickly discover the 'entPhysicalIndex' values for all children 367 of a given physical entity. 369 3.10.4. entityGeneral Group 371 This group contains general information relating to the other object + 372 groups. + 374 At this time, the entGeneral group contains a single scalar object + 375 (entLastChangeTime), which represents the value of sysUptime when any + 376 part of the system configuration last changed. + 378 3.11. Multiple Agents 380 Even though a primary motivation for this MIB is to represent the 381 multiple logical entities supported by a single agent, it is also 382 possible to use it to represent multiple logical entities supported by 383 multiple agents (in the same "overall" physical entity). Indeed, it is 384 implicit in the SNMP architecture, that the number of agents is 385 Draft Entity MIB May 1996 387 transparent to a network management station. 389 However, there is no agreement at this time as to the degree of 390 cooperation which should be expected for agent implementations. 391 Therefore, multiple agents within the same managed system are free to 392 implement the Entity MIB independently. (Refer the section on "Multiple 393 Instances of the Entity MIB" for more details). 395 Draft Entity MIB May 1996 397 4. Definitions 399 ENTITY-MIB DEFINITIONS ::= BEGIN 401 IMPORTS 402 MODULE-IDENTITY, OBJECT-TYPE, 403 experimental, NOTIFICATION-TYPE 404 FROM SNMPv2-SMI 405 TDomain, TAddress, DisplayString, 406 AutonomousType, TruthValue, RowPointer, TimeStamp | 407 FROM SNMPv2-TC 408 MODULE-COMPLIANCE, OBJECT-GROUP 409 FROM SNMPv2-CONF; 411 entityMIB MODULE-IDENTITY 412 LAST-UPDATED "9605160000Z" | 413 ORGANIZATION "IETF ENTMIB Working Group" 414 CONTACT-INFO 415 " Keith McCloghrie 416 ENTMIB Working Group Chair 417 Cisco Systems Inc. 418 170 West Tasman Drive 419 San Jose, CA 95134 420 408-526-5260 421 kzm@cisco.com 423 Andy Bierman 424 ENTMIB Working Group Editor 425 Cisco Systems Inc. 426 170 West Tasman Drive 427 San Jose, CA 95134 428 408-527-3711 429 abierman@cisco.com" 430 DESCRIPTION 431 "The MIB module for representing multiple logical 432 entities supported by a single SNMP agent." 433 ::= { experimental xx } 435 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 437 -- MIB contains four groups + 438 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } + 439 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } + 440 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } + 441 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } + 442 Draft Entity MIB May 1996 444 -- Textual Conventions + 445 PhysicalIndex ::= TEXTUAL-CONVENTION + 446 STATUS current + 447 DESCRIPTION + 448 "An arbitrary value which uniquely identifies the physical + 449 entity. The value is a small positive integer; index values + 450 for different physical entities are not necessarily + 451 contiguous." + 452 SYNTAX INTEGER (1..2147483647) + 454 Draft Entity MIB May 1996 456 -- The Physical Entity Table 458 entPhysicalTable OBJECT-TYPE 459 SYNTAX SEQUENCE OF EntPhysicalEntry 460 MAX-ACCESS not-accessible 461 STATUS current 462 DESCRIPTION 463 "This table contains one row per physical entity. There is 464 always at least one row for an 'overall' physical entity." 465 ::= { entityPhysical 1 } | 467 entPhysicalEntry OBJECT-TYPE 468 SYNTAX EntPhysicalEntry 469 MAX-ACCESS not-accessible 470 STATUS current 471 DESCRIPTION 472 "Information about a particular physical entity. - 474 Each entry provides objects (entPhysicalDescr, + 475 entPhysicalVendorType, and entPhysicalClass) to help an NMS + 476 identify and characterize the entry, and objects + 477 (entPhysicalContainedIn and entPhysicalParentRelPos) to help + 478 an NMS relate the particular entry to other entries in this + 479 table." + 480 INDEX { entPhysicalIndex } 481 ::= { entPhysicalTable 1 } 483 EntPhysicalEntry ::= SEQUENCE { 484 entPhysicalIndex INTEGER, 485 entPhysicalDescr DisplayString, 486 entPhysicalVendorType AutonomousType, 487 entPhysicalContainedIn INTEGER, 488 entPhysicalClass INTEGER, 489 entPhysicalParentRelPos INTEGER, | 490 entPhysicalName DisplayString | 491 } 493 entPhysicalIndex OBJECT-TYPE 494 SYNTAX PhysicalIndex | 495 MAX-ACCESS not-accessible 496 STATUS current 497 DESCRIPTION 498 "The index for this entry." | 499 ::= { entPhysicalEntry 1 } 501 Draft Entity MIB May 1996 503 entPhysicalDescr OBJECT-TYPE 504 SYNTAX DisplayString 505 MAX-ACCESS read-only 506 STATUS current 507 DESCRIPTION 508 "A textual description of physical entity. This object | 509 should contain a string which identifies the manufacturer's | 510 name for the physical entity, and should be set to a | 511 distinct value for each version or model of the physical | 512 entity. " | 513 ::= { entPhysicalEntry 2 } 515 entPhysicalVendorType OBJECT-TYPE 516 SYNTAX AutonomousType 517 MAX-ACCESS read-only 518 STATUS current 519 DESCRIPTION 520 "An indication of the vendor-specific hardware type of the 521 physical entity. Note that this is different from the 522 definition of MIB-II's sysObjectID. 524 An agent should set this object to a enterprise-specific 525 registration identifier value indicating the specific 526 equipment type in detail. The associated instance of | 527 entPhysicalClass is used | 528 to indicate the general type of hardware device. 530 If no vendor-specific registration identifier exists for 531 this physical entity, or the value is unknown by this agent, 532 then the value { 0 0 } is returned." 533 ::= { entPhysicalEntry 3 } 535 entPhysicalContainedIn OBJECT-TYPE 536 SYNTAX INTEGER (0..2147483647) 537 MAX-ACCESS read-only 538 STATUS current 539 DESCRIPTION 540 "The value of entPhysicalIndex for the physical entity which 541 'contains' this physical entity. A value of zero indicates 542 this physical entity is not contained in any other physical 543 entity. Note that the set of 'containment' relationships 544 define a strict hierarchy; that is, recursion is not 545 allowed." 546 ::= { entPhysicalEntry 4 } 548 Draft Entity MIB May 1996 550 entPhysicalClass OBJECT-TYPE 551 SYNTAX INTEGER { 552 other(1), 553 unknown(2), 554 chassis(3), 555 backplane(4), 556 container(5), -- e.g. slot or daughter-card holder 557 powerSupply(6), 558 fan(7), 559 sensor(8), 560 module(9), -- e.g. plug-in card or daughter-card 561 port(10) 562 } 563 MAX-ACCESS read-only 564 STATUS current 565 DESCRIPTION 566 "An indication of the general hardware type of the physical 567 entity. 569 An agent should set this object to the standard enumeration 570 value which most accurately indicates the general class of 571 the physical entity, or the primary class if there is more 572 than one. 574 If no appropriate standard registration identifier exists 575 for this physical entity, then the value 'other(1)' is 576 returned. If the value is unknown by this agent, then the 577 value 'unknown(2)' is returned." 578 ::= { entPhysicalEntry 5 } 580 entPhysicalParentRelPos OBJECT-TYPE 581 SYNTAX INTEGER (-1..2147483647) 582 MAX-ACCESS read-only 583 STATUS current 584 DESCRIPTION 585 "An indication of the relative position of this 'child' | 586 component among all its 'sibling' components. Sibling | 587 components are defined as entPhysicalEntries which share the | 588 same instance values of each of the entPhysicalContainedIn | 589 and entPhysicalClass objects. | 591 An NMS can use this object to identify the relative ordering + 592 for all sibling components of a particular parent + 593 (identified by the entPhysicalContainedIn instance in each + 594 sibling entry). + 596 Draft Entity MIB May 1996 598 This value should match any external labeling of the 599 physical component if possible. For example, for a module 600 labeled as 'card #3', entPhysicalParentRelPos should have 601 the value '3'. 603 If the physical position of this component does not match 604 any external numbering or clearly visible ordering, then 605 user documentation or other external reference material 606 should be used to determine the parent-relative position. If 607 this is not possible, then the the agent should assign a 608 consistent (but possibly arbitrary) ordering to a given set 609 of 'sibling' components, perhaps based on internal 610 representation of the components. 612 If the agent cannot determine the parent-relative position 613 for some reason, or if the associated value of 614 entPhysicalContainedIn is '0', then the value '-1' is 615 returned. Otherwise a non-negative integer is returned, 616 indicating the parent-relative position of this physical 617 entity. 619 Parent-relative ordering normally starts from '1' and | 620 continues to 'N', | 621 where 'N' represents the highest positioned child entity. | 622 However, if the physical entities (e.g. slots) are labeled | 623 from a starting position of zero, then the first sibling | 624 should be associated with a entPhysicalParentRelPos value of | 625 '0'. | 626 Note that this ordering may be sparse or dense, depending on 627 agent implementation. + 629 The actual values returned are not globally meaningful, as 630 each 'parent' component may use different numbering 631 algorithms. The ordering is only meaningful among siblings 632 of the same parent component. 634 The agent should retain parent-relative position values 635 across reboots, either through algorithmic assignment or use 636 of non-volatile storage." 637 ::= { entPhysicalEntry 6 } 639 entPhysicalName OBJECT-TYPE + 640 SYNTAX DisplayString + 641 MAX-ACCESS read-only + 643 Draft Entity MIB May 1996 645 STATUS current + 646 DESCRIPTION + 647 "The textual name of the physical entity. The value of this + 648 object should be the name of the component as assigned by + 649 the local device and should be suitable for use in commands + 650 entered at the device's `console'. This might be a text + 651 name, such as `console' or a simple component number (e.g. + 652 port or module number), such as `1', depending on the + 653 physical component naming syntax of the device. + 655 If there is no local name, or this object is otherwise not + 656 applicable, then this object contains a zero-length string." + 657 ::= { entPhysicalEntry 7 } + 659 Draft Entity MIB May 1996 661 -- The Logical Entity Table entLogicalTable OBJECT-TYPE 662 SYNTAX SEQUENCE OF EntLogicalEntry 663 MAX-ACCESS not-accessible 664 STATUS current 665 DESCRIPTION 666 "This table contains one row per logical entity." 667 ::= { entityLogical 1 } | 669 entLogicalEntry OBJECT-TYPE 670 SYNTAX EntLogicalEntry 671 MAX-ACCESS not-accessible 672 STATUS current 673 DESCRIPTION 674 "Information about a particular logical entity. Entities 675 may be managed by this agent or other SNMP agents (possibly) 676 in the same chassis." 677 INDEX { entLogicalIndex } 678 ::= { entLogicalTable 1 } 680 EntLogicalEntry ::= SEQUENCE { 681 entLogicalIndex INTEGER, 682 entLogicalDescr DisplayString, 683 entLogicalType AutonomousType, 684 entLogicalCommunity OCTET STRING, 685 entLogicalTAddress TAddress, 686 entLogicalTDomain TDomain 687 } 689 entLogicalIndex OBJECT-TYPE 690 SYNTAX INTEGER (1..2147483647) 691 MAX-ACCESS not-accessible 692 STATUS current 693 DESCRIPTION 694 "The value of this object uniquely identifies the logical 695 entity. The value is a small positive integer; index values 696 for different logical entities are are not necessarily 697 contiguous." 698 ::= { entLogicalEntry 1 } 700 entLogicalDescr OBJECT-TYPE - 701 SYNTAX DisplayString 702 MAX-ACCESS read-only 703 STATUS current 704 DESCRIPTION 705 "A textual description of the logical entity. This object | 707 Draft Entity MIB May 1996 709 should contain a string which identifies the manufacturer's | 710 name for the logical entity, and should be set to a distinct | 711 value for each version of the logical entity. " | 713 ::= { entLogicalEntry 2 } 715 entLogicalType OBJECT-TYPE 716 SYNTAX AutonomousType 717 MAX-ACCESS read-only 718 STATUS current 719 DESCRIPTION 720 "An indication of the type of logical entity. This will 721 typically be the OBJECT IDENTIFIER name of the node in the 722 SMI's naming hierarchy which represents the major MIB 723 module, or the majority of the MIB modules, supported by the 724 logical entity. For example: 725 a logical entity of a regular host/router -> mib-2 726 a logical entity of a 802.1d bridge -> dot1dBridge 727 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 728 If an appropriate node in the SMI's naming hierarchy cannot 729 be identified, the value 'mib-2' should be used." 730 ::= { entLogicalEntry 3 } 732 entLogicalCommunity OBJECT-TYPE 733 SYNTAX OCTET STRING 734 MAX-ACCESS read-only 735 STATUS current 736 DESCRIPTION 737 "An SNMPv1 or SNMPv2C community-string which can be used to 738 access detailed management information for this logical 739 entity. The agent should allow read access with this 740 community string (to an appropriate subset of all managed 741 objects) and may also choose to return a community string 742 based on the privileges of the request used to read this 743 object. Note that an agent may choose to return a community 744 string with read-only privileges, even if this object is 745 accessed with a read-write community string. However, the 746 agent must take care not to return a community string which 747 allows more privileges than the community string used to 748 access this object. 750 A conformant SNMP agent may wish to conserve naming scopes 751 by representing multiple logical entities in a single 'main' 752 naming scope. This is possible when the logical entities 753 represented by the same value of entLogicalCommunity have no 755 Draft Entity MIB May 1996 757 object instances in common. For example, 'bridge1' and 758 'repeater1' may be part of the main naming scope, but at 759 least one additional community string is needed to represent 760 'bridge2' and 'repeater2'. 762 Logical entities 'bridge1' and 'repeater1' would be 763 represented by sysOREntries associated with the 'main' 764 naming scope. 766 For agents not accessible via SNMPv1 or SNMPv2C, the value 767 of this object is the empty-string." 768 ::= { entLogicalEntry 4 } 770 entLogicalTAddress OBJECT-TYPE 771 SYNTAX TAddress 772 MAX-ACCESS read-only 773 STATUS current 774 DESCRIPTION 775 "The transport service address by which the logical entity 776 receives network management traffic, formatted according to 777 the corresponding value of entLogicalTDomain. | 779 For snmpUDPDomain, a TAddress is 6 octets long, the initial | 780 4 octets containing the IP-address in network-byte order and | 781 the last 2 containing the UDP port in network-byte order. | 782 Consult 'Transport Mappings for Version 2 of the Simple | 783 Network Management Protocol' [8] for further information on | 784 snmpUDPDomain." | 785 ::= { entLogicalEntry 5 } 787 entLogicalTDomain OBJECT-TYPE 788 SYNTAX TDomain 789 MAX-ACCESS read-only 790 STATUS current 791 DESCRIPTION 792 "Indicates the kind of transport service by which the 793 logical entity receives network management traffic. 794 Possible values for this object are presently found in the 795 Transport Mappings for SNMPv2 document (RFC 1906 [8])." 796 ::= { entLogicalEntry 6 } 798 Draft Entity MIB May 1996 800 entLPMappingTable OBJECT-TYPE 801 SYNTAX SEQUENCE OF EntLPMappingEntry 802 MAX-ACCESS not-accessible 803 STATUS current 804 DESCRIPTION 805 "This table contains zero or more rows of logical entity to 806 physical equipment associations. For each logical entity 807 known by this agent, there are zero or more mappings to the 808 physical resources which are used to realize that logical 809 entity. 811 An agent should limit the number and nature of entries in 812 this table such that only meaningful and non-redundant 813 information is returned. For example, in a system which 814 contains a single power supply, mappings between logical 815 entities and the power supply are not useful and should not 816 be included. 818 Also, only the most appropriate physical component which is 819 closest to the root of a particular containment tree should 820 be identified in an entLPMapping entry. 822 For example, suppose a bridge is realized on a particular 823 module, and it utilizes all of the ports on that module. A 824 mapping between the bridge and the module would be useful, 825 but additional mappings between the bridge and each of the 826 ports on that module would be redundant (since the 827 entPhysicalContainedIn hierarchy can provide the same 828 information). If, on the other hand, more than one bridge 829 was utilizing ports on this module, then mappings between 830 each bridge and the ports it used would be appropriate. 832 Also, in the case of a single backplane repeater, a mapping 833 for the backplane to the single repeater entity is not 834 necessary." 835 ::= { entityMapping 1 } | 837 entLPMappingEntry OBJECT-TYPE 838 SYNTAX EntLPMappingEntry 839 MAX-ACCESS not-accessible 840 STATUS current 841 DESCRIPTION 842 "Information about a particular logical entity to physical 843 equipment association. Note that the nature of the 844 association is not specifically identified in this entry. It 846 Draft Entity MIB May 1996 848 is expected that sufficient information exists in the MIBs 849 used to manage a particular logical entity to infer how 850 physical component information is utilized." 851 INDEX { entLogicalIndex, entLPPhysicalIndex } 852 ::= { entLPMappingTable 1 } 854 EntLPMappingEntry ::= SEQUENCE { 855 entLPPhysicalIndex INTEGER 856 } 858 entLPPhysicalIndex OBJECT-TYPE 859 SYNTAX PhysicalIndex | 860 MAX-ACCESS read-only 861 STATUS current 862 DESCRIPTION 863 "The value of this object identifies the index value of a | 864 particular entPhysicalEntry associated with the indicated | 865 entLogicalEntity." 866 ::= { entLPMappingEntry 1 } 868 Draft Entity MIB May 1996 870 -- logical entity/component to alias table 871 entAliasMappingTable OBJECT-TYPE 872 SYNTAX SEQUENCE OF EntAliasMappingEntry 873 MAX-ACCESS not-accessible 874 STATUS current 875 DESCRIPTION 876 "This table contains zero or more rows, representing | 877 mappings of logical entity and physical component to | 878 external MIB identifiers. | 879 Each physical port in the system may be associated with a 880 mapping to an external identifier, which itself is 881 associated with a particular logical entity's naming scope. 882 A wildcard mechanism is provided to indicate that an 883 identifier is associated with more than one logical entity." 884 ::= { entityMapping 2 } | 886 entAliasMappingEntry OBJECT-TYPE 887 SYNTAX EntAliasMappingEntry 888 MAX-ACCESS not-accessible 889 STATUS current 890 DESCRIPTION 891 "Information about a particular physical equipment, logical 892 entity to external identifier binding. Each logical 893 entity/physical component pair may be associated with one 894 alias mapping. The logical entity index may also be used as 895 a wildcard (refer to the entAliasLogicalIndexOrZero object 896 DESCRIPTION clause for details.) 898 Note that only entPhysicalIndex values which represent 899 physical ports (i.e. associated entPhysicalClass value is 900 'port(10)') are permitted to exist in this table." 901 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 902 ::= { entAliasMappingTable 1 } 904 EntAliasMappingEntry ::= SEQUENCE { 905 entAliasLogicalIndexOrZero INTEGER, 906 entAliasMappingIdentifier RowPointer 907 } 909 entAliasLogicalIndexOrZero OBJECT-TYPE 910 SYNTAX INTEGER (0..2147483647) 911 MAX-ACCESS not-accessible 912 STATUS current 913 DESCRIPTION 914 "The value of this object uniquely identifies the logical 916 Draft Entity MIB May 1996 918 entity which defines the naming scope for the associated 919 instance of the 'entAliasMappingIdentifier' object. 921 If this object has a non-zero value, then it identifies the 922 logical entity named by the same value of entLogicalIndex. 924 If this object has a value of zero, then the mapping between 925 the physical component and the alias identifier for this 926 entAliasMapping entry is associated with all unspecified 927 logical entities. That is, a value of zero (the default 928 mapping) identifies any logical entity which does not have 929 an explicit entry in this table for a particular 930 entPhysicalIndex/entAliasMappingIdentifier pair. 932 For example, to indicate that a particular interface (e.g. 933 physical component 33) is identified by the same value of 934 ifIndex for all logical entities, the following instance 935 might exist: 937 entAliasMappingIdentifier.33.0 = ifIndex.5 939 In the event an entPhysicalEntry is associated differently 940 for some logical entities (e.g. 4, 5, and 10 below), 941 additional entAliasMapping entries may exist, e.g.: 943 entAliasMappingIdentifier.33.4 = ifIndex.1 944 entAliasMappingIdentifier.33.5 = ifIndex.1 945 entAliasMappingIdentifier.33.10 = ifIndex.12 947 Note that entries with non-zero entAliasLogicalIndexOrZero 948 index values have precedence over any zero-indexed entry." 949 ::= { entAliasMappingEntry 1 } 951 entAliasMappingIdentifier OBJECT-TYPE 952 SYNTAX RowPointer 953 MAX-ACCESS read-only 954 STATUS current 955 DESCRIPTION 956 "The value of this object identifies a particular conceptual 957 row associated with the indicated entPhysicalIndex and 958 entLogicalIndex pair. 960 Since only physical ports are modeled in this table, only 961 entries which represent interfaces or ports are allowed. If 963 Draft Entity MIB May 1996 965 an ifEntry exists on behalf of a particular physical port, 966 then this object should identify the associated 'ifEntry'. 967 For repeater ports, the appropriate row in the 968 'rptrPortGroupTable' should be identified instead. 970 For example, suppose a physical port was represented by 971 entPhysicalEntry.3, entLogicalEntry.15 existed for a 972 repeater, and entLogicalEntry.22 existed for a bridge. Then 973 there might be two related instances of 974 entAliasMappingIdentifier: 975 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 976 entAliasMappingIdentifier.3.22 == ifIndex.17 977 It is possible that other mappings (besides interfaces and 978 repeater ports) may be defined in the future, as required. 979 Bridge ports are identified by examining the Bridge MIB and 980 appropriate ifEntries associated with each 'dot1dBasePort'." 981 ::= { entAliasMappingEntry 2 } 983 Draft Entity MIB May 1996 985 -- physical mapping table 986 entPhysicalContainsTable OBJECT-TYPE 987 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 988 MAX-ACCESS not-accessible 989 STATUS current 990 DESCRIPTION 991 "A table which exposes the container/containee relationships 992 between physical entities. This table provides equivalent 993 information found by constructing the virtual containment 994 tree for a given entPhysicalTable but in a more direct 995 format." 996 ::= { entityMapping 3 } | 998 entPhysicalContainsEntry OBJECT-TYPE 999 SYNTAX EntPhysicalContainsEntry 1000 MAX-ACCESS not-accessible 1001 STATUS current 1002 DESCRIPTION 1003 "A single container/containee relationship." 1004 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1005 ::= { entPhysicalContainsTable 1 } 1007 EntPhysicalContainsEntry ::= SEQUENCE { 1008 entPhysicalChildIndex INTEGER 1009 } 1011 entPhysicalChildIndex OBJECT-TYPE 1012 SYNTAX PhysicalIndex | 1013 MAX-ACCESS read-only 1014 STATUS current 1015 DESCRIPTION 1016 "The value of entPhysicalIndex for the contained physical 1017 entity." 1018 ::= { entPhysicalContainsEntry 1 } 1020 Draft Entity MIB May 1996 1022 -- last change timestamp for the whole MIB 1023 entLastChangeTime OBJECT-TYPE 1024 SYNTAX TimeStamp | 1025 MAX-ACCESS read-only 1026 STATUS current 1027 DESCRIPTION 1028 "The value of sysUpTime at the time any of these events 1029 occur: 1030 * a conceptual row is created or deleted in any 1031 of these tables: 1032 - entPhysicalTable 1033 - entLogicalTable 1034 - entLPMappingTable 1035 - entAliasMappingTable 1036 - entPhysicalContainsTable 1038 * any instance in the following list of objects 1039 changes value: 1040 - entPhysicalDescr 1041 - entPhysicalVendorType 1042 - entPhysicalContainedIn 1043 - entPhysicalClass 1044 - entPhysicalParentRelPos + 1045 - entPhysicalName + 1046 - entLogicalDescr 1047 - entLogicalType 1048 - entLogicalCommunity 1049 - entLogicalTAddress 1050 - entLogicalTDomain 1051 - entAliasMappingIdentifier 1052 " 1053 ::= { entityGeneral 1 } | 1055 Draft Entity MIB May 1996 1057 -- Entity MIB Trap Definitions 1058 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1060 entConfigChange NOTIFICATION-TYPE 1061 STATUS current - 1062 DESCRIPTION 1063 "An entConfigChange trap is sent when the value of 1064 entLastChangeTime changes. It can be utilized by an NMS to 1065 trigger logical/physical entity table maintenance polls. 1066 This trap is throttled by the agent. 1068 An agent must not generate more than | 1069 one entConfigChange 'trap-event' in a five second period, 1070 where a 'trap-event' is the transmission of a single trap 1071 PDU to a list of trap destinations. If additional 1072 configuration changes occur within the five second 1073 'throttling' period, then these events should be discarded 1074 by the agent. An NMS should periodically check the value of 1075 entLastChangeTime to detect any missed entConfigChange 1076 events due to throttling or transmission loss." 1077 ::= { entityMIBTraps 1 } 1079 Draft Entity MIB May 1996 1081 -- conformance information 1082 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1084 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1085 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1087 -- compliance statements 1089 entityCompliance MODULE-COMPLIANCE 1090 STATUS current 1091 DESCRIPTION 1092 "The compliance statement for SNMP entities which implement 1093 the Entity MIB." 1094 MODULE -- this module 1095 MANDATORY-GROUPS { entityPhysicalGroup, | 1096 entityLogicalGroup, | 1097 entityMappingGroup, | 1098 entityGeneralGroup } | 1099 ::= { entityCompliances 1 } 1101 -- MIB groupings 1103 entityPhysicalGroup OBJECT-GROUP + 1104 OBJECTS { + 1105 entPhysicalDescr, + 1106 entPhysicalVendorType, + 1107 entPhysicalContainedIn, + 1108 entPhysicalClass, + 1109 entPhysicalParentRelPos, + 1110 entPhysicalName + 1111 } + 1112 STATUS current + 1113 DESCRIPTION + 1114 "The collection of objects which are used to represent + 1115 physical system components associated with logical entities, + 1116 for which a single agent provides management information." + 1117 ::= { entityGroups 1 } + 1119 entityLogicalGroup OBJECT-GROUP 1120 OBJECTS { 1121 entLogicalDescr, 1122 entLogicalType, 1123 entLogicalCommunity, 1124 entLogicalTAddress, 1125 entLogicalTDomain | 1127 Draft Entity MIB May 1996 1129 } 1130 STATUS current 1131 DESCRIPTION 1132 "The collection of objects which are used to represent the 1133 list of logical entities for which a single agent provides 1134 management information." 1135 ::= { entityGroups 2 } | 1137 entityMappingGroup OBJECT-GROUP 1138 OBJECTS { 1139 entLPPhysicalIndex, - 1140 entAliasLogicalIndexOrZero, 1141 entAliasMappingIdentifier, 1142 entPhysicalChildIndex 1143 } 1144 STATUS current 1145 DESCRIPTION 1146 "The collection of objects which are used to represent the 1147 associations between multiple logical entities, physical | 1148 components, interfaces, and port | 1149 identifiers for which a single agent provides management 1150 information." 1151 ::= { entityGroups 3 } | 1153 entityGeneralGroup OBJECT-GROUP + 1154 OBJECTS { + 1155 entLastChangeTime + 1156 } + 1157 STATUS current + 1158 DESCRIPTION + 1159 "The collection of objects which are used to represent + 1160 general entity information for which a single agent provides + 1161 management information." + 1162 ::= { entityGroups 4 } + 1164 END 1165 Draft Entity MIB May 1996 1167 5. Usage Examples 1169 The following sections iterate the instance values for two example 1170 networking devices. These examples are kept simple to make them more | 1171 understandable. Auxilary components, | 1172 such as fans, sensors, empty slots, and sub-modules are not shown, but 1173 might be modeled in real implementations. 1175 5.1. Router/Bridge 1177 A router containing two slots. Each slot contains a 3 port 1178 router/bridge module. Each port is represented in the ifTable. There 1179 are two logical instances of OSPF running and two logical bridges: 1181 Physical entities -- entPhysicalTable: 1182 1 Field-replaceable physical chassis: 1183 entPhysicalDescr.1 == "Acme Chassis Model 100" 1184 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 1185 entPhysicalContainedIn.1 == 0 1186 entPhysicalClass.1 == chassis(3) 1187 entPhysicalParentRelPos.1 == 0 1188 entPhysicalName.1 == '100-A' + 1190 2 slots within the chassis: 1191 entPhysicalDescr.2 == "Acme Chassis Slot Type AA" | 1192 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 1193 entPhysicalContainedIn.2 == 1 1194 entPhysicalClass.2 == container(5) 1195 entPhysicalParentRelPos.2 == 1 1196 entPhysicalName.2 == 'S1' | 1198 entPhysicalDescr.3 == "Acme Chassis Slot Type AA" | 1199 entPhysicalVendorType.3 == acmeProducts.slotTypes.1 1200 entPhysicalContainedIn.3 == 1 1201 entPhysicalClass.3 == container(5) 1202 entPhysicalParentRelPos.3 == 2 1203 entPhysicalName.3 == 'S2' + 1205 2 Field-replaceable modules: 1206 Slot 1 contains a module with 3 ports: 1207 entPhysicalDescr.4 == "Acme Router-100" | 1208 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 1209 entPhysicalContainedIn.4 == 2 1210 entPhysicalClass.4 == module(9) 1212 Draft Entity MIB May 1996 1214 entPhysicalParentRelPos.4 == 1 1215 entPhysicalName.4 == 'M1' + 1217 entPhysicalDescr.5 == "Acme Ethernet-100 Port Rev G" | 1218 entPhysicalVendorType.5 == acmeProducts.portTypes.2 1219 entPhysicalContainedIn.5 == 4 1220 entPhysicalClass.5 == port(10) 1221 entPhysicalParentRelPos.5 == 1 1222 entPhysicalName.5 == 'P1' + 1224 entPhysicalDescr.6 == "Acme Ethernet-100 Port Rev G" | 1225 entPhysicalVendorType.6 == acmeProducts.portTypes.2 1226 entPhysicalContainedIn.6 == 4 1227 entPhysicalClass.6 == port(10) 1228 entPhysicalParentRelPos.6 == 2 1229 entPhysicalName.6 == 'P2' + 1231 entPhysicalDescr.7 == "Acme Router-100 F-Port: Rev B" | 1232 entPhysicalVendorType.7 == acmeProducts.portTypes.3 1233 entPhysicalContainedIn.7 == 4 1234 entPhysicalClass.7 == port(10) 1235 entPhysicalParentRelPos.7 == 3 1236 entPhysicalName.7 == 'P3' + 1238 Slot 2 contains another 3-port module: 1239 entPhysicalDescr.8 == "Acme Router-100 Comm Module: Rev C"| 1240 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 1241 entPhysicalContainedIn.8 == 3 1242 entPhysicalClass.8 == module(9) 1243 entPhysicalParentRelPos.8 == 1 1244 entPhysicalName.8 == 'M1' + 1246 entPhysicalDescr.9 == "Acme Fddi-100 Port Rev CC" | 1247 entPhysicalVendorType.9 == acmeProducts.portTypes.5 | 1248 entPhysicalContainedIn.9 == 8 1249 entPhysicalClass.9 == port(10) 1250 entPhysicalParentRelPos.9 == 1 1251 entPhysicalName.9 == 'FDDI Primary' + 1253 entPhysicalDescr.10 == "Acme Ethernet-100 Port Rev G" | 1254 entPhysicalVendorType.10 == acmeProducts.portTypes.2 1255 entPhysicalContainedIn.10 == 8 1256 entPhysicalClass.10 == port(10) 1257 entPhysicalParentRelPos.10 == 2 1258 entPhysicalName.10 == 'Ethernet A' + 1260 Draft Entity MIB May 1996 1262 entPhysicalDescr.11 == "Acme Ethernet-100 Port Rev G" | 1263 entPhysicalVendorType.11 == acmeProducts.portTypes.2 1264 entPhysicalContainedIn.11 == 8 1265 entPhysicalClass.11 == port(10) 1266 entPhysicalParentRelPos.11 == 3 1267 entPhysicalName.11 == 'Ethernet B' + 1269 Logical entities -- entLogicalTable 1270 2 OSPF instances: | 1271 entLogicalDescr.1 == "Acme OSPF v1.1" | 1272 entLogicalType.1 == ospf 1273 entLogicalCommunity.1 == "public-ospf1" 1274 entLogicalTAddress.1 == 124.125.126.127:161 1275 entLogicalTDomain.1 == snmpUDPDomain 1277 entLogicalDescr.2 == "Acme OSPF v1.1" | 1278 entLogicalType.2 == ospf 1279 entLogicalCommunity.2 == "public-ospf2" 1280 entLogicalTAddress.2 == 124.125.126.127:161 1281 entLogicalTDomain.2 == snmpUDPDomain 1283 2 logical bridges: 1284 entLogicalDescr.3 == "Acme Bridge v2.1.1" | 1285 entLogicalType.3 == dod1dBridge 1286 entLogicalCommunity.3 == "public-bridge1" 1287 entLogicalTAddress.3 == 124.125.126.127:161 1288 entLogicalTDomain.3 == snmpUDPDomain 1290 entLogicalDescr.4 == "Acme Bridge v2.1.1" | 1291 entLogicalType.4 == dod1dBridge 1292 entLogicalCommunity.4 == "public-bridge2" 1293 entLogicalTAddress.4 == 124.125.126.127:161 1294 entLogicalTDomain.4 == snmpUDPDomain 1296 Logical to Physical Mappings: 1297 1st OSPF instance: uses module 1-port 1 1298 entLPPhysicalIndex.1.5 == 5 1300 2nd OSPF instance: uses module 2-port 1 1301 entLPPhysicalIndex.2.9 == 9 1303 1st bridge group: uses module 1, all ports 1305 [ed. -- Note that these mappings are included in the table since 1306 another logical entity (1st OSPF) utilizes one of the 1308 Draft Entity MIB May 1996 1310 ports. If this were not the case, then a single mapping 1311 to the module (e.g. entLPPhysicalIndex.3.4) would be 1312 present instead. ] 1313 entLPPhysicalIndex.3.5 == 5 1314 entLPPhysicalIndex.3.6 == 6 1315 entLPPhysicalIndex.3.7 == 7 1317 2nd bridge group: uses module 2, all ports 1318 entLPPhysicalIndex.4.9 == 9 1319 entLPPhysicalIndex.4.10 == 10 1320 entLPPhysicalIndex.4.11 == 11 1322 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 1323 Example 1: ifIndex values are global to all logical entities 1324 entAliasMappingIdentifier.5.0 == ifIndex.1 1325 entAliasMappingIdentifier.6.0 == ifIndex.2 1326 entAliasMappingIdentifier.7.0 == ifIndex.3 1327 entAliasMappingIdentifier.9.0 == ifIndex.4 1328 entAliasMappingIdentifier.10.0 == ifIndex.5 1329 entAliasMappingIdentifier.11.0 == ifIndex.6 1331 Example 2: ifIndex values are not shared by all logical entities 1332 entAliasMappingIdentifier.5.0 == ifIndex.1 1333 entAliasMappingIdentifier.5.3 == ifIndex.101 1334 entAliasMappingIdentifier.6.0 == ifIndex.2 1335 entAliasMappingIdentifier.6.3 == ifIndex.102 1336 entAliasMappingIdentifier.7.0 == ifIndex.3 1337 entAliasMappingIdentifier.7.3 == ifIndex.103 1338 entAliasMappingIdentifier.9.0 == ifIndex.4 1339 entAliasMappingIdentifier.9.3 == ifIndex.204 1340 entAliasMappingIdentifier.10.0 == ifIndex.5 1341 entAliasMappingIdentifier.10.3 == ifIndex.205 1342 entAliasMappingIdentifier.11.0 == ifIndex.6 1343 entAliasMappingIdentifier.11.3 == ifIndex.206 1345 Physical Containment Tree -- entPhysicalContainsTable 1346 chassis has two containers: 1347 entPhysicalChildIndex.1.2 = 2 1348 entPhysicalChildIndex.1.3 = 3 1350 container 1 has a module: 1351 entPhysicalChildIndex.2.4 = 4 1353 container 2 has a module: 1354 entPhysicalChildIndex.3.8 = 8 1356 Draft Entity MIB May 1996 1358 module 1 has 3 ports: 1359 entPhysicalChildIndex.4.5 = 5 1360 entPhysicalChildIndex.4.6 = 6 1361 entPhysicalChildIndex.4.7 = 7 1363 module 2 has 3 ports: 1364 entPhysicalChildIndex.8.9 = 9 1365 entPhysicalChildIndex.8.10 = 10 1366 entPhysicalChildIndex.1.11 = 11 1368 5.2. Repeaters 1370 A 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, 1371 and the remaining slots contain ethernet repeater modules. [ed. -- Note 1372 that a replacement for the current Repeater MIB (RFC 1516) is likely to 1373 emerge soon, and it will no longer be necessary to access repeater MIB 1374 data in different naming scopes.] 1376 Physical entities -- entPhysicalTable: 1377 1 Field-replaceable physical chassis: 1378 entPhysicalDescr.1 == "Acme Chassis Model 110" | 1379 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 1380 entPhysicalContainedIn.1 == 0 1381 entPhysicalClass.1 == chassis(3) 1382 entPhysicalParentRelPos.1 == 0 1383 entPhysicalName.1 == '110-B' + 1385 2 Chassis Ethernet Backplanes: 1386 entPhysicalDescr.2 == "Acme Ethernet Backplane Type A" | 1387 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 1388 entPhysicalContainedIn.2 == 1 1389 entPhysicalClass.2 == backplane(4) 1390 entPhysicalParentRelPos.2 == 1 1391 entPhysicalName.2 == 'B1' + 1393 entPhysicalDescr.3 == "Acme Ethernet Backplane Type A" | 1394 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 1395 entPhysicalContainedIn.3 == 1 1396 entPhysicalClass.3 == backplane(4) 1397 entPhysicalParentRelPos.3 == 2 1398 entPhysicalName.3 == 'B2' + 1400 3 slots within the chassis: 1401 entPhysicalDescr.4 == "Acme Hub Slot Type RB" | 1403 Draft Entity MIB May 1996 1405 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 1406 entPhysicalContainedIn.4 == 1 1407 entPhysicalClass.4 == container(5) 1408 entPhysicalParentRelPos.4 == 1 1409 entPhysicalName.4 == 'Slot 1' + 1411 entPhysicalDescr.5 == "Acme Hub Slot Type RB" | 1412 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 1413 entPhysicalContainedIn.5 == 1 1414 entPhysicalClass.5 == container(5) 1415 entPhysicalParentRelPos.5 == 2 1416 entPhysicalName.5 == 'Slot 2' + 1418 entPhysicalDescr.6 == "Acme Hub Slot Type RB" | 1419 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 1420 entPhysicalContainedIn.6 == 1 1421 entPhysicalClass.6 == container(5) 1422 entPhysicalParentRelPos.6 == 3 1423 entPhysicalName.6 == 'Slot 3' + 1425 Slot 1 contains a plug-in module with 4 10-BaseT ports: 1426 entPhysicalDescr.7 == "Acme 10Base-T Module 114 Rev A" | 1427 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 1428 entPhysicalContainedIn.7 == 4 1429 entPhysicalClass.7 == module(9) 1430 entPhysicalParentRelPos.7 == 1 1431 entPhysicalName.7 == 'M1' + 1433 entPhysicalDescr.8 == "Acme 10Base-T Port RB Rev A" | 1434 entPhysicalVendorType.8 == acmeProducts.portTypes.10 1435 entPhysicalContainedIn.8 == 7 1436 entPhysicalClass.8 == port(10) 1437 entPhysicalParentRelPos.8 == 1 1438 entPhysicalName.8 == 'Ethernet-A' + 1440 entPhysicalDescr.9 == "Acme 10Base-T Port RB Rev A" | 1441 entPhysicalVendorType.9 == acmeProducts.portTypes.10 1442 entPhysicalContainedIn.9 == 7 1443 entPhysicalClass.9 == port(10) 1444 entPhysicalParentRelPos.9 == 2 1445 entPhysicalName.9 == 'Ethernet-B' + 1447 entPhysicalDescr.10 == "Acme 10Base-T Port RB Rev B" | 1448 entPhysicalVendorType.10 == acmeProducts.portTypes.10 1449 entPhysicalContainedIn.10 == 7 1451 Draft Entity MIB May 1996 1453 entPhysicalClass.10 == port(10) 1454 entPhysicalParentRelPos.10 == 3 1455 entPhysicalName.10 == 'Ethernet-C' + 1457 entPhysicalDescr.11 == "Acme 10Base-T Port RB Rev B" | 1458 entPhysicalVendorType.11 == acmeProducts.portTypes.10 1459 entPhysicalContainedIn.11 == 7 1460 entPhysicalClass.11 == port(10) 1461 entPhysicalParentRelPos.11 == 4 1462 entPhysicalName.11 == 'Ethernet-D' + 1464 Slot 2 contains another ethernet module with 2 ports. 1465 entPhysicalDescr.12 == "Acme 10Base-T Module Model 4 Rev A" | 1466 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 1467 entPhysicalContainedIn.12 = 5 1468 entPhysicalClass.12 == module(9) 1469 entPhysicalParentRelPos.12 == 1 1470 entPhysicalName.12 == 'M1' + 1472 entPhysicalDescr.13 == "Acme 802.3 AUI Port Rev A" | 1473 entPhysicalVendorType.13 == acmeProducts.portTypes.11 1474 entPhysicalContainedIn.13 == 12 1475 entPhysicalClass.13 == port(10) 1476 entPhysicalParentRelPos.13 == 1 1477 entPhysicalName.13 == 'AUI' + 1479 entPhysicalDescr.14 == "Acme 10Base-T Port RD Rev B" | 1480 entPhysicalVendorType.14 == acmeProducts.portTypes.14 | 1481 entPhysicalContainedIn.14 == 12 1482 entPhysicalClass.14 == port(10) 1483 entPhysicalParentRelPos.14 == 2 1484 entPhysicalName.14 == 'E2' + 1486 Logical entities -- entLogicalTable 1487 Repeater 1--comprised of any ports attached to backplane 1 1488 entLogicalDescr.1 == "Acme repeater v3.1" | 1489 entLogicalType.1 == snmpDot3RptrMgt 1490 entLogicalCommunity.1 "public-repeater1" 1491 entLogicalTAddress.1 == 124.125.126.127:161 1492 entLogicalTDomain.1 == snmpUDPDomain 1494 Repeater 2--comprised of any ports attached to backplane 2: 1495 entLogicalDescr.2 == "Acme repeater v3.1" | 1496 entLogicalType.2 == snmpDot3RptrMgt 1497 entLogicalCommunity.2 == "public-repeater2" 1499 Draft Entity MIB May 1996 1501 entLogicalTAddress.2 == 124.125.126.127:161 1502 entLogicalTDomain.2 == snmpUDPDomain 1504 Logical to Physical Mappings -- entLPMappingTable: 1506 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 1507 [ed. -- Note that a mapping to the module is not included, 1508 since in this example represents a port-switchable hub. 1509 Even though all ports on the module could belong to the 1510 same repeater as a matter of configuration, the LP port 1511 mappings should not be replaced dynamically with a single 1512 mapping for the module (e.g. entLPPhysicalIndex.1.7). 1513 If all ports on the module shared a single backplane connection, 1514 then a single mapping for the module would be more appropriate. ] 1516 entLPPhysicalIndex.1.2 == 2 1517 entLPPhysicalIndex.1.8 == 8 1518 entLPPhysicalIndex.1.9 == 9 1519 entLPPhysicalIndex.1.13 == 13 1521 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 1522 entLPPhysicalIndex.2.3 == 3 1523 entLPPhysicalIndex.2.10 == 10 1524 entLPPhysicalIndex.2.11 == 11 1525 entLPPhysicalIndex.2.14 == 14 1527 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 1528 Repeater Port Identifier values are shared by both repeaters: 1529 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 1530 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 1531 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 1532 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 1533 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 1534 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 1536 Physical Containment Tree -- entPhysicalContainsTable 1537 chassis has two backplanes and three containers: 1538 entPhysicalChildIndex.1.2 = 2 1539 entPhysicalChildIndex.1.3 = 3 1540 entPhysicalChildIndex.1.4 = 4 1541 entPhysicalChildIndex.1.5 = 5 1542 entPhysicalChildIndex.1.6 = 6 1544 container 1 has a module: 1545 entPhysicalChildIndex.4.7 = 7 1547 Draft Entity MIB May 1996 1549 container 2 has a module 1550 entPhysicalChildIndex.5.12 = 12 1551 [ed. - in this example, container 3 is empty.] 1553 module 1 has 4 ports: 1554 entPhysicalChildIndex.7.8 = 8 1555 entPhysicalChildIndex.7.9 = 9 1556 entPhysicalChildIndex.7.10 = 10 1557 entPhysicalChildIndex.7.11 = 11 1559 module 2 has 2 ports: 1560 entPhysicalChildIndex.12.13 = 13 1561 entPhysicalChildIndex.12.14 = 14 1563 Draft Entity MIB May 1996 1565 6. Acknowledgements 1567 This document was produced by the IETF Entity MIB Working Group. 1569 Draft Entity MIB May 1996 1571 7. References 1573 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1574 S. Waldbusser, "Structure of Management Information for version 2 1575 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1576 January 1996. 1578 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 1579 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1580 RFC 1213, Hughes LAN Systems, Performance Systems International, 1581 March 1991. 1583 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1584 S. Waldbusser, "Textual Conventions for version 2 of the Simple 1585 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1587 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1588 S. Waldbusser, "Protocol Operations for version 2 of the Simple 1589 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1591 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1592 S. Waldbusser, "Conformance Statements for version 2 of the Simple 1593 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1595 [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1596 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1597 International, MIT Laboratory for Computer Science, May 1990. 1599 [7] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 1600 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 1602 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1603 S. Waldbusser, "Transport Mappings for version 2 of the Simple 1604 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 1606 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1607 S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 1608 January 1996. 1610 Draft Entity MIB May 1996 1612 8. Security Considerations 1614 Security issues are not discussed in this memo. 1616 9. Authors' Addresses 1618 Keith McCloghrie 1619 Cisco Systems, Inc. 1620 170 West Tasman Drive 1621 San Jose, CA 95134 1622 Phone: 408-526-5260 1623 Email: kzm@cisco.com 1625 Andy Bierman 1626 Cisco Systems, Inc. 1627 170 West Tasman Drive 1628 San Jose, CA 95134 1629 Phone: 408-527-3711 1630 Email: abierman@cisco.com 1632 Draft Entity MIB May 1996 1634 Table of Contents 1636 1 Introduction .................................................... 2 1637 2 The SNMP Network Management Framework ........................... 3 1638 2.1 Object Definitions ............................................ 3 1639 3 Overview ........................................................ 4 1640 3.1 Terms ......................................................... 4 1641 3.2 Relationship to Community Strings ............................. 6 1642 3.3 Relationship to Proxy Mechanisms .............................. 6 1643 3.4 Relationship to a Chassis MIB ................................. 7 1644 3.5 Relationship to the Interfaces MIB ............................ 7 1645 3.6 Relationship to the Other MIBs ................................ 7 1646 3.7 Relationship to Naming Scopes ................................. 7 1647 3.8 Multiple Instances of the Entity MIB .......................... 8 1648 3.9 Re-Configuration of Entities .................................. 8 1649 3.10 MIB Structure ................................................ 9 1650 3.10.1 entityPhysical Group ....................................... 9 1651 3.10.2 entityLogical Group ........................................ 9 1652 3.10.3 entityMapping Group ........................................ 10 1653 3.10.4 entityGeneral Group ........................................ 10 1654 3.11 Multiple Agents .............................................. 10 1655 4 Definitions ..................................................... 12 1656 5 Usage Examples .................................................. 32 1657 5.1 Router/Bridge ................................................. 32 1658 5.2 Repeaters ..................................................... 36 1659 6 Acknowledgements ................................................ 41 1660 7 References ...................................................... 42 1661 8 Security Considerations ......................................... 43 1662 9 Authors' Addresses .............................................. 43