idnits 2.17.1 draft-ietf-entmib-entmib-03.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-25) 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 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 (12 April 1996) is 10240 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: 18 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 12 April 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 April 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 April 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 1905 [5]. 61 The Framework permits new objects to be defined for the purpose of 62 experimentation and evaluation. 64 2.1. Object Definitions 66 Managed objects are accessed via a virtual information store, termed the 67 Management Information Base or MIB. Objects in the MIB are defined 68 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 69 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 70 an administratively assigned name. The object type together with an 71 object instance serves to uniquely identify a specific instantiation of 72 the object. For human convenience, we often use a textual string, 73 termed the descriptor, to refer to the object type. 75 Draft Entity MIB April 1996 77 3. Overview 79 There is a need for a standardized way of representing a single agent 80 which supports multiple instances of one MIB. This is presently true 81 for at least 3 standard MIBs, and is likely to become true for more and 82 more MIBs as time passes. For example: 84 - multiple instances of a bridge supported within a single device 85 having a single agent; 87 - multiple repeaters supported by a single agent; 89 - multiple OSPF backbone areas, each one operating as part of its own 90 Autonomous System, and each identified by the same area-id (e.g., 91 0.0.0.0), supported inside a single router with one agent. 93 The fact that it is a single agent in each of these cases implies there 94 is some relationship which binds all of these entities together. 95 Effectively, there is some "overall" physical entity which houses the 96 sum of the things managed by that one agent, i.e., there are multiple 97 "logical" entities within a single physical entity. Sometimes, the 98 overall physical entity contains multiple (smaller) physical entities 99 and each logical entity is associated with a particular physical entity. 100 Sometimes, the overall physical entity is a "compound" of multiple 101 physical entities (e.g., a stack of stackable hubs). 103 What is needed is a way to determine exactly what logical entities are 104 managed by the agent (either by SNMPv1 or SNMPv2), and thereby to be 105 able to communicate with the agent about a particular logical entity. 106 When different logical entities are associated with different physical 107 entities within the overall physical entity, it is also useful to be 108 able to use this information to distinguish between logical entities. 110 In these situations, there is no need for varbinds for multiple logical 111 entities to be referenced in the same SNMP message (although that might 112 be useful in the future). Rather, it is sufficient, and in some 113 situations preferable, to have the context/community in the message 114 identify the logical entity to which the varbinds apply. 116 3.1. Terms 118 Some new terms are used throughout this document: 120 Draft Entity MIB April 1996 122 - Naming Scope 123 A "naming scope" represents the set of information that may be 124 potentially accessed through a single SNMP operation. All instances 125 within the naming scope share the same unique identifier space. For 126 SNMPv1, a naming scope is identified by the value of the associated 127 'entLogicalCommunity' instance. 129 - Multi-Scoped Object 130 A MIB object, for which identical instance values identify 131 different managed information in different naming scopes, is called 132 a "multi-scoped" MIB object. 134 - Single-Scoped Object 135 A MIB object, for which identical instance values identify the same 136 managed information in different naming scopes, is called a 137 "single-scoped" MIB object. 139 - Logical Entity 140 A managed system contains one or more logical entities, each 141 represented by at most one instantiation of each of a particular 142 set of MIB objects. A set of management functions is associated 143 with each logical entity. Examples of logical entities include 144 routers, bridges, print-servers, etc. 146 - Physical Entity 147 A "physical entity" or "physical component" represents an 148 identifiable physical resource within a managed system. Zero or 149 more logical entities may utilize a physical resource at any given 150 time. It is an implementation-specific manner as to which physical 151 components are represented by an agent in the EntPhysicalTable. 152 Typically, physical resources (e.g. communications ports, 153 backplanes, sensors, daughter-cards, power supplies, the overall 154 chassis) which can be managed via functions associated with one or 155 more logical entities are included in the MIB. 157 - Containment Tree 158 Each physical component may optionally be modeled as 'contained' 159 within another physical component. A "containment-tree" is the 160 conceptual sequence of entPhysicalIndex values which uniquely 161 specifies the exact physical location of a physical component 162 within the managed system. It is generated by 'following and 163 recording' each 'entPhysicalContainedIn' instance 'up the tree 164 towards the root', until a value of zero indicating no further 165 containment is found. 167 Draft Entity MIB April 1996 169 It is required that physical containment-trees retain their 170 identity across reboots. Specifically, two identical hardware 171 configurations should produce the same set of containment-trees for 172 every corresponding entry in the entPhysicalTable (i.e. the same 173 set of entPhysicalEntries with the same entPhysicalIndex values. 174 This requirement exists only if the agent is warmstarting, not 175 coldstarting. If the hardware configuration changes in any way, 176 then the index values retained across the reboot do not have to be 177 used. 179 Note that chassis slots, which are capable of accepting one or more 180 module types from one or more vendors, are modeled as containers in 181 this MIB. The value of entPhysicalContainedIn for a particular 182 'module' entity (entPhysicalClass value of 'module(9)') should be 183 equal to an entPhysicalIndex that represents the parent 'container' 184 entity (associated entPhysicalClass value of ('container(5)'). An 185 agent should represent both empty and full containers in the 186 entPhysicalTable. 188 3.2. Relationship to Community Strings 190 For community-based SNMP, distinguishing between different logical 191 entities is one (but not the only) purpose of the community string [6]. 192 This is accommodated by representing each community string as a logical 193 entity. 195 Note that different logical entities may share the same naming scope 196 (and therefore the same values of entLogicalCommunity). This is 197 possible, providing they have no need for the same instance of a MIB 198 object to represent different managed information. In such a case, 199 individual logical entities can be identified by examining the 200 sysORTable within the same naming scope. 202 3.3. Relationship to Proxy Mechanisms 204 The Entity MIB is designed to allow functional component discovery. The 205 administrative relationships between different logical entities are not 206 visible in any Entity MIB tables. An NMS cannot determine whether MIB 207 instances in different naming scopes are realized locally or remotely 208 (e.g. via some proxy mechanism) by examining any particular Entity MIB 209 objects. 211 The management of administrative framework functions is not an explicit 212 Draft Entity MIB April 1996 214 goal of the Entity MIB WG at this time. This new area of functionality 215 may be revisited after some operational experience with the Entity MIB 216 is gained. 218 Note that a network administrator will likely be able to associate 219 community strings with naming scopes with proprietary mechanisms, as a 220 matter of configuration. There are no mechanisms for managing naming 221 scopes defined in this MIB. 223 3.4. Relationship to a Chassis MIB 225 Some readers may recall that a previous IETF working group attempted to 226 define a Chassis MIB. No consensus was reached by that working group, 227 possibly because its scope was too broad. As such, it is not the 228 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 229 the scope of this MIB to contain all the information which might be 230 necessary to manage a "chassis". On the other hand, the entities 231 represented by an implementation of this MIB might well be contained in 232 a chassis. 234 3.5. Relationship to the Interfaces MIB 236 The Entity MIB contains a mapping table identifying physical components 237 that have 'external values' (e.g. ifIndex) associated with them within a 238 given naming scope. This table can be used to identify the physical 239 location of each interface in the ifTable [7]. Since ifIndex values in 240 different contexts are not related to one another, the interface to 241 physical component associations are relative to the same logical entity 242 within the agent. 244 3.6. Relationship to the Other MIBs 246 The Entity MIB contains a mapping table identifying physical components 247 that have identifiers from other standard MIBs associated with them. 248 For example, this table can be used along with the physical mapping 249 table to identify the physical location of each repeater port in the 250 rptrPortTable, or each interface in the ifTable. 252 Draft Entity MIB April 1996 254 3.7. Relationship to Naming Scopes 256 There is some question as to which MIB objects may be returned within a 257 given naming scope. MIB objects which are not multi-scoped within a 258 managed system are likely to ignore context information in 259 implementation. In such a case, it is likely such objects will be 260 returned in all naming scopes (e.g. not just the 'main' naming scope). 262 For example, a community string returned for 'bridge2' may allow access 263 to all the non-bridge related objects in the 'main' naming scope, as 264 well as a second instance of the Bridge MIB. 266 It is an implementation-specific matter as to the isolation of single- 267 scoped MIB objects by the agent. An agent may wish to limit the objects 268 returned in a particular naming scope to just the multi-scoped objects 269 in that naming scope (e.g. system group and the Bridge MIB). In this 270 case, all single-scoped management information would belong to a common 271 naming scope (e.g. 'main'), which itself may contain some multi-scoped 272 objects (e.g. system group). 274 3.8. Multiple Instances of the Entity MIB 276 It is possible that more than one agent exists in a managed system, and 277 in such cases, multiple instances of the Entity MIB (representing the 278 same managed objects) may be available to an NMS. 280 In order to reduce complexity for agent implementation, multiple 281 instances of the Entity MIB are not required to be equivalent or even 282 consistent. An NMS may be able to 'align' instances returned by 283 different agents by examining the columns of each table, but vendor- 284 specific identifiers and (especially) index values are likely to be 285 different. Each agent may be managing different subsets of the entire 286 chassis as well. 288 An agent implementation of the entLogicalTable is not required to 289 contain information about logical entities managed primarily by other 290 agents. That is, the entLogicalTAddress and entLogicalTDomain objects in 291 the entLogicalTable are provided to support an historical multiplexing 292 mechanism, not to identify other SNMP agents. 294 Note that the Entity MIB is a single-scoped MIB, in the event an agent 295 represents the MIB in different naming scopes. 297 Draft Entity MIB April 1996 299 3.9. Re-Configuration of Entities 301 All the MIB objects defined in this MIB have at most a read-only MAX- 302 ACCESS clause, i.e., none are write-able. This is another conscious 303 decision by the authors to limit this MIB's scope. It is possible that 304 this restriction could be lifted after implementation experience, and 305 additional tables (using the AUGMENTS clause) added for configuration 306 and extended entity information. 308 3.10. MIB Structure 310 This MIB contains five tables: the entPhysicalTable and the 311 entLogicalTable each provide a list of entities. The entLPMappingTable 312 provides mappings between logical and physical entities. The 313 entAliasMappingTable provides mappings between physical components and 314 associated identifiers from other MIBs. These mappings may be defined 315 for all logical entities, or individual logical entities. The 316 entPhysicalContainsTable provides efficient discovery of the containment 317 relationships of all physical entities (also derivable from 318 'entPhysicalContainedIn' values). 320 The entPhysicalTable contains one row per physical entity, and should 321 always contains at least one row for an "overall" physical entity. Each 322 row is indexed by an arbitrary, small integer, and contains a 323 description and type of the physical entity. It also optionally 324 contains the index number of another entPhysicalEntry indicating a 325 containment relationship between the two. 327 The entLogicalTable contains one row per logical entity. Each row is 328 indexed by an arbitrary, small integer and contains a name, description, 329 and type of the logical entity. It also contains information to allow 330 SNMPv1 or (SNMPv2C [9]) access to the MIB information for the logical 331 entity. 333 The entLPMappingTable contains mappings between entLogicalIndex values 334 (logical entities) and entPhysicalIndex values (the physical components 335 supporting that entity). A logical entity can map to more than one 336 physical component, and more than one logical entity can map to (share) 337 the same physical component. 339 Draft Entity MIB April 1996 341 The entAliasMappingTable contains mappings between entLogicalIndex, 342 entPhysicalIndex pairs and 'alias' object identifier values. This 343 allows resources managed with other MIBs (e.g. repeater ports, bridge 344 ports, physical and logical interfaces) to be identified in the physical 345 entity hierarchy. Note that each alias identifier is only relevant in a 346 particular naming scope. 348 The entPhysicalContainsTable contains simple mappings between 349 'entPhysicalContainedIn' values for each container/containee 350 relationship in the managed system. The indexing of this table allows an 351 NMS to quickly discover the 'entPhysicalIndex' values for all children 352 of a given physical entity. 354 3.11. Multiple Agents 356 Even though a primary motivation for this MIB is to represent the 357 multiple logical entities supported by a single agent, it is also 358 possible to use it to represent multiple logical entities supported by 359 multiple agents (in the same "overall" physical entity). Indeed, it is 360 implicit in the SNMP architecture, that the number of agents is 361 transparent to a network management station. 363 However, there is no agreement at this time as to the degree of 364 cooperation which should be expected for agent implementations. 365 Therefore, multiple agents within the same managed system are free to 366 implement the Entity MIB independently. (Refer the section on "Multiple 367 Instances of the Entity MIB" for more details). 369 Draft Entity MIB April 1996 371 4. Definitions 373 ENTITY-MIB DEFINITIONS ::= BEGIN 375 IMPORTS 376 MODULE-IDENTITY, OBJECT-TYPE, 377 experimental, NOTIFICATION-TYPE 378 FROM SNMPv2-SMI 379 TDomain, TAddress, DisplayString, 380 AutonomousType, TruthValue, RowPointer 381 FROM SNMPv2-TC 382 MODULE-COMPLIANCE, OBJECT-GROUP 383 FROM SNMPv2-CONF; 385 entityMIB MODULE-IDENTITY 386 LAST-UPDATED "9604100000Z" 387 ORGANIZATION "IETF ENTMIB Working Group" 388 CONTACT-INFO 389 " Keith McCloghrie 390 ENTMIB Working Group Chair 391 Cisco Systems Inc. 392 170 West Tasman Drive 393 San Jose, CA 95134 394 408-526-5260 395 kzm@cisco.com 397 Andy Bierman 398 ENTMIB Working Group Editor 399 Cisco Systems Inc. 400 170 West Tasman Drive 401 San Jose, CA 95134 402 408-527-3711 403 abierman@cisco.com" 404 DESCRIPTION 405 "The MIB module for representing multiple logical 406 entities supported by a single SNMP agent." 407 ::= { experimental xx } 409 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 410 Draft Entity MIB April 1996 412 -- The Physical Entity Table 414 entPhysicalTable OBJECT-TYPE 415 SYNTAX SEQUENCE OF EntPhysicalEntry 416 MAX-ACCESS not-accessible 417 STATUS current 418 DESCRIPTION 419 "This table contains one row per physical entity. There is 420 always at least one row for an 'overall' physical entity." 421 ::= { entityMIBObjects 1 } 423 entPhysicalEntry OBJECT-TYPE 424 SYNTAX EntPhysicalEntry 425 MAX-ACCESS not-accessible 426 STATUS current 427 DESCRIPTION 428 "Information about a particular physical entity. An agent 429 is expected to represent physical components in as much 430 detail as possible." 432 INDEX { entPhysicalIndex } 433 ::= { entPhysicalTable 1 } 435 EntPhysicalEntry ::= SEQUENCE { 436 entPhysicalIndex INTEGER, 437 entPhysicalDescr DisplayString, 438 entPhysicalVendorType AutonomousType, 439 entPhysicalContainedIn INTEGER, 440 entPhysicalClass INTEGER, 441 entPhysicalParentRelPos INTEGER 442 } 444 entPhysicalIndex OBJECT-TYPE 445 SYNTAX INTEGER (1..2147483647) 446 MAX-ACCESS not-accessible 447 STATUS current 448 DESCRIPTION 449 "The value of this object uniquely identifies the physical 450 entity. The value is a small positive integer; index values 451 for different physical entities are not necessarily 452 contiguous." 453 ::= { entPhysicalEntry 1 } 455 entPhysicalDescr OBJECT-TYPE 456 SYNTAX DisplayString 458 Draft Entity MIB April 1996 460 MAX-ACCESS read-only 461 STATUS current 462 DESCRIPTION 463 "A textual description of physical entity." 464 ::= { entPhysicalEntry 2 } 466 entPhysicalVendorType OBJECT-TYPE 467 SYNTAX AutonomousType 468 MAX-ACCESS read-only 469 STATUS current 470 DESCRIPTION 471 "An indication of the vendor-specific hardware type of the 472 physical entity. Note that this is different from the 473 definition of MIB-II's sysObjectID. 475 An agent should set this object to a enterprise-specific 476 registration identifier value indicating the specific 477 equipment type in detail. The associated instance of 478 entPhysicalClass should be used to indicate the general type 479 of hardware device. 481 If no vendor-specific registration identifier exists for 482 this physical entity, or the value is unknown by this agent, 483 then the value { 0 0 } is returned." 484 ::= { entPhysicalEntry 3 } 486 entPhysicalContainedIn OBJECT-TYPE 487 SYNTAX INTEGER (0..2147483647) 488 MAX-ACCESS read-only 489 STATUS current 490 DESCRIPTION 491 "The value of entPhysicalIndex for the physical entity which 492 'contains' this physical entity. A value of zero indicates 493 this physical entity is not contained in any other physical 494 entity. Note that the set of 'containment' relationships 495 define a strict hierarchy; that is, recursion is not 496 allowed." 497 ::= { entPhysicalEntry 4 } 499 entPhysicalClass OBJECT-TYPE 500 SYNTAX INTEGER { 501 other(1), 502 unknown(2), 503 chassis(3), 504 backplane(4), 506 Draft Entity MIB April 1996 508 container(5), -- e.g. slot or daughter-card holder 509 powerSupply(6), 510 fan(7), 511 sensor(8), 512 module(9), -- e.g. plug-in card or daughter-card 513 port(10) 514 } 515 MAX-ACCESS read-only 516 STATUS current 517 DESCRIPTION 518 "An indication of the general hardware type of the physical 519 entity. 521 An agent should set this object to the standard enumeration 522 value which most accurately indicates the general class of 523 the physical entity, or the primary class if there is more 524 than one. 526 If no appropriate standard registration identifier exists 527 for this physical entity, then the value 'other(1)' is 528 returned. If the value is unknown by this agent, then the 529 value 'unknown(2)' is returned." 530 ::= { entPhysicalEntry 5 } 532 entPhysicalParentRelPos OBJECT-TYPE 533 SYNTAX INTEGER (-1..2147483647) 534 MAX-ACCESS read-only 535 STATUS current 536 DESCRIPTION 537 "An indication of the position of this 'child' component 538 among all its 'sibling' components. The numbering is 539 relative to the 'parent' component. A component's parent is 540 identified by the associated instance of the 541 entPhysicalContainedIn object. An NMS may use this value to 542 compare against other entPhysicalEntries with the same 543 parent. 545 This value should match any external labeling of the 546 physical component if possible. For example, for a module 547 labeled as 'card #3', entPhysicalParentRelPos should have 548 the value '3'. 550 If the physical position of this component does not match 551 any external numbering or clearly visible ordering, then 552 user documentation or other external reference material 554 Draft Entity MIB April 1996 556 should be used to determine the parent-relative position. If 557 this is not possible, then the the agent should assign a 558 consistent (but possibly arbitrary) ordering to a given set 559 of 'sibling' components, perhaps based on internal 560 representation of the components. 562 If the agent cannot determine the parent-relative position 563 for some reason, or if the associated value of 564 entPhysicalContainedIn is '0', then the value '-1' is 565 returned. Otherwise a non-negative integer is returned, 566 indicating the parent-relative position of this physical 567 entity. 569 Parent-relative ordering normally starts from '1' and 570 continue to 'N', where 'N' represents the highest positioned 571 child entity. However, if slots are labeled from a starting 572 position of zero, then the first sibling should be 573 associated with a entPhysicalParentRelPos value of '0'. 574 Note that this ordering may be sparse or dense, depending on 575 agent implementation. The actual values returned are not 576 globally meaningful, as each 'parent' component may use 577 different numbering algorithms. The ordering is only 578 meaningful among siblings of the same parent component. 580 The agent should retain parent-relative position values 581 across reboots, either through algorithmic assignment or use 582 of non-volatile storage." 583 ::= { entPhysicalEntry 6 } 585 Draft Entity MIB April 1996 587 -- The Logical Entity Table 588 entLogicalTable OBJECT-TYPE 589 SYNTAX SEQUENCE OF EntLogicalEntry 590 MAX-ACCESS not-accessible 591 STATUS current 592 DESCRIPTION 593 "This table contains one row per logical entity." 594 ::= { entityMIBObjects 2 } 596 entLogicalEntry OBJECT-TYPE 597 SYNTAX EntLogicalEntry 598 MAX-ACCESS not-accessible 599 STATUS current 600 DESCRIPTION 601 "Information about a particular logical entity. Entities 602 may be managed by this agent or other SNMP agents (possibly) 603 in the same chassis." 604 INDEX { entLogicalIndex } 605 ::= { entLogicalTable 1 } 607 EntLogicalEntry ::= SEQUENCE { 608 entLogicalIndex INTEGER, 609 entLogicalDescr DisplayString, 610 entLogicalType AutonomousType, 611 entLogicalCommunity OCTET STRING, 612 entLogicalTAddress TAddress, 613 entLogicalTDomain TDomain 614 } 616 entLogicalIndex OBJECT-TYPE 617 SYNTAX INTEGER (1..2147483647) 618 MAX-ACCESS not-accessible 619 STATUS current 620 DESCRIPTION 621 "The value of this object uniquely identifies the logical 622 entity. The value is a small positive integer; index values 623 for different logical entities are are not necessarily 624 contiguous." 625 ::= { entLogicalEntry 1 } 627 Draft Entity MIB April 1996 629 entLogicalDescr OBJECT-TYPE 630 SYNTAX DisplayString 631 MAX-ACCESS read-only 632 STATUS current 633 DESCRIPTION 634 "A textual description of the logical entity." 635 ::= { entLogicalEntry 2 } 637 entLogicalType OBJECT-TYPE 638 SYNTAX AutonomousType 639 MAX-ACCESS read-only 640 STATUS current 641 DESCRIPTION 642 "An indication of the type of logical entity. This will 643 typically be the OBJECT IDENTIFIER name of the node in the 644 SMI's naming hierarchy which represents the major MIB 645 module, or the majority of the MIB modules, supported by the 646 logical entity. For example: 647 a logical entity of a regular host/router -> mib-2 648 a logical entity of a 802.1d bridge -> dot1dBridge 649 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 650 If an appropriate node in the SMI's naming hierarchy cannot 651 be identified, the value 'mib-2' should be used." 652 ::= { entLogicalEntry 3 } 654 entLogicalCommunity OBJECT-TYPE 655 SYNTAX OCTET STRING 656 MAX-ACCESS read-only 657 STATUS current 658 DESCRIPTION 659 "An SNMPv1 or SNMPv2C community-string which can be used to 660 access detailed management information for this logical 661 entity. The agent should allow read access with this 662 community string (to an appropriate subset of all managed 663 objects) and may also choose to return a community string 664 based on the privileges of the request used to read this 665 object. Note that an agent may choose to return a community 666 string with read-only privileges, even if this object is 667 accessed with a read-write community string. However, the 668 agent must take care not to return a community string which 669 allows more privileges than the community string used to 670 access this object. 672 A conformant SNMP agent may wish to conserve naming scopes 673 by representing multiple logical entities in a single 'main' 675 Draft Entity MIB April 1996 677 naming scope. This is possible when the logical entities 678 represented by the same value of entLogicalCommunity have no 679 object instances in common. For example, 'bridge1' and 680 'repeater1' may be part of the main naming scope, but at 681 least one additional community string is needed to represent 682 'bridge2' and 'repeater2'. 684 Logical entities 'bridge1' and 'repeater1' would be 685 represented by sysOREntries associated with the 'main' 686 naming scope. 688 For agents not accessible via SNMPv1 or SNMPv2C, the value 689 of this object is the empty-string." 690 ::= { entLogicalEntry 4 } 692 entLogicalTAddress OBJECT-TYPE 693 SYNTAX TAddress 694 MAX-ACCESS read-only 695 STATUS current 696 DESCRIPTION 697 "The transport service address by which the logical entity 698 receives network management traffic, formatted according to 699 the corresponding value of entLogicalTDomain. For 700 snmpUDPDomain, entLogicalTAddress is formatted as a 4-octet 701 IP Address concatenated with a 2-octet UDP port number." 702 ::= { entLogicalEntry 5 } 704 entLogicalTDomain OBJECT-TYPE 705 SYNTAX TDomain 706 MAX-ACCESS read-only 707 STATUS current 708 DESCRIPTION 709 "Indicates the kind of transport service by which the 710 logical entity receives network management traffic. 711 Possible values for this object are presently found in the 712 Transport Mappings for SNMPv2 document (RFC 1906 [8])." 713 ::= { entLogicalEntry 6 } 715 Draft Entity MIB April 1996 717 entLPMappingTable OBJECT-TYPE 718 SYNTAX SEQUENCE OF EntLPMappingEntry 719 MAX-ACCESS not-accessible 720 STATUS current 721 DESCRIPTION 722 "This table contains zero or more rows of logical entity to 723 physical equipment associations. For each logical entity 724 known by this agent, there are zero or more mappings to the 725 physical resources which are used to realize that logical 726 entity. 728 An agent should limit the number and nature of entries in 729 this table such that only meaningful and non-redundant 730 information is returned. For example, in a system which 731 contains a single power supply, mappings between logical 732 entities and the power supply are not useful and should not 733 be included. 735 Also, only the most appropriate physical component which is 736 closest to the root of a particular containment tree should 737 be identified in an entLPMapping entry. 739 For example, suppose a bridge is realized on a particular 740 module, and it utilizes all of the ports on that module. A 741 mapping between the bridge and the module would be useful, 742 but additional mappings between the bridge and each of the 743 ports on that module would be redundant (since the 744 entPhysicalContainedIn hierarchy can provide the same 745 information). If, on the other hand, more than one bridge 746 was utilizing ports on this module, then mappings between 747 each bridge and the ports it used would be appropriate. 749 Also, in the case of a single backplane repeater, a mapping 750 for the backplane to the single repeater entity is not 751 necessary." 752 ::= { entityMIBObjects 3 } 754 entLPMappingEntry OBJECT-TYPE 755 SYNTAX EntLPMappingEntry 756 MAX-ACCESS not-accessible 757 STATUS current 758 DESCRIPTION 759 "Information about a particular logical entity to physical 760 equipment association. Note that the nature of the 761 association is not specifically identified in this entry. It 763 Draft Entity MIB April 1996 765 is expected that sufficient information exists in the MIBs 766 used to manage a particular logical entity to infer how 767 physical component information is utilized." 768 INDEX { entLogicalIndex, entLPPhysicalIndex } 769 ::= { entLPMappingTable 1 } 771 EntLPMappingEntry ::= SEQUENCE { 772 entLPPhysicalIndex INTEGER 773 } 775 entLPPhysicalIndex OBJECT-TYPE 776 SYNTAX INTEGER (1..2147483647) 777 MAX-ACCESS read-only 778 STATUS current 779 DESCRIPTION 780 "The value of this object identifies a particular 781 entPhysicalEntry associated with the indicated 782 entLogicalEntity." 783 ::= { entLPMappingEntry 1 } 785 Draft Entity MIB April 1996 787 -- logical entity/component to alias table 788 entAliasMappingTable OBJECT-TYPE 789 SYNTAX SEQUENCE OF EntAliasMappingEntry 790 MAX-ACCESS not-accessible 791 STATUS current 792 DESCRIPTION 793 "This table contains zero or more rows of logical entity, 794 and physical component to external MIB identifiers. Each 795 physical port in the system may be associated with a mapping 796 to an external identifier, which itself is associated with a 797 particular logical entity's naming scope. A wildcard 798 mechanism is provided to indicate that an identifier is 799 associated with more than one logical entity." 800 ::= { entityMIBObjects 4 } 802 entAliasMappingEntry OBJECT-TYPE 803 SYNTAX EntAliasMappingEntry 804 MAX-ACCESS not-accessible 805 STATUS current 806 DESCRIPTION 807 "Information about a particular physical equipment, logical 808 entity to external identifier binding. Each logical 809 entity/physical component pair may be associated with one 810 alias mapping. The logical entity index may also be used as 811 a wildcard (refer to the entAliasLogicalIndexOrZero object 812 DESCRIPTION clause for details.) 814 Note that only entPhysicalIndex values which represent 815 physical ports (i.e. associated entPhysicalClass value is 816 'port(10)') are permitted to exist in this table." 817 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 818 ::= { entAliasMappingTable 1 } 820 EntAliasMappingEntry ::= SEQUENCE { 821 entAliasLogicalIndexOrZero INTEGER, 822 entAliasMappingIdentifier RowPointer 823 } 825 entAliasLogicalIndexOrZero OBJECT-TYPE 826 SYNTAX INTEGER (0..2147483647) 827 MAX-ACCESS not-accessible 828 STATUS current 829 DESCRIPTION 830 "The value of this object uniquely identifies the logical 831 entity which defines the naming scope for the associated 833 Draft Entity MIB April 1996 835 instance of the 'entAliasMappingIdentifier' object. 837 If this object has a non-zero value, then it identifies the 838 logical entity named by the same value of entLogicalIndex. 840 If this object has a value of zero, then the mapping between 841 the physical component and the alias identifier for this 842 entAliasMapping entry is associated with all unspecified 843 logical entities. That is, a value of zero (the default 844 mapping) identifies any logical entity which does not have 845 an explicit entry in this table for a particular 846 entPhysicalIndex/entAliasMappingIdentifier pair. 848 For example, to indicate that a particular interface (e.g. 849 physical component 33) is identified by the same value of 850 ifIndex for all logical entities, the following instance 851 might exist: 853 entAliasMappingIdentifier.33.0 = ifIndex.5 855 In the event an entPhysicalEntry is associated differently 856 for some logical entities (e.g. 4, 5, and 10 below), 857 additional entAliasMapping entries may exist, e.g.: 859 entAliasMappingIdentifier.33.4 = ifIndex.1 860 entAliasMappingIdentifier.33.5 = ifIndex.1 861 entAliasMappingIdentifier.33.10 = ifIndex.12 863 Note that entries with non-zero entAliasLogicalIndexOrZero 864 index values have precedence over any zero-indexed entry." 865 ::= { entAliasMappingEntry 1 } 867 entAliasMappingIdentifier OBJECT-TYPE 868 SYNTAX RowPointer 869 MAX-ACCESS read-only 870 STATUS current 871 DESCRIPTION 872 "The value of this object identifies a particular conceptual 873 row associated with the indicated entPhysicalIndex and 874 entLogicalIndex pair. 876 Since only physical ports are modeled in this table, only 877 entries which represent interfaces or ports are allowed. If 878 an ifEntry exists on behalf of a particular physical port, 880 Draft Entity MIB April 1996 882 then this object should identify the associated 'ifEntry'. 883 For repeater ports, the appropriate row in the 884 'rptrPortGroupTable' should be identified instead. 886 For example, suppose a physical port was represented by 887 entPhysicalEntry.3, entLogicalEntry.15 existed for a 888 repeater, and entLogicalEntry.22 existed for a bridge. Then 889 there might be two related instances of 890 entAliasMappingIdentifier: 891 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 892 entAliasMappingIdentifier.3.22 == ifIndex.17 893 It is possible that other mappings (besides interfaces and 894 repeater ports) may be defined in the future, as required. 895 Bridge ports are identified by examining the Bridge MIB and 896 appropriate ifEntries associated with each 'dot1dBasePort'." 897 ::= { entAliasMappingEntry 2 } 899 Draft Entity MIB April 1996 901 -- physical mapping table 902 entPhysicalContainsTable OBJECT-TYPE 903 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 904 MAX-ACCESS not-accessible 905 STATUS current 906 DESCRIPTION 907 "A table which exposes the container/containee relationships 908 between physical entities. This table provides equivalent 909 information found by constructing the virtual containment 910 tree for a given entPhysicalTable but in a more direct 911 format." 912 ::= { entityMIBObjects 5 } 914 entPhysicalContainsEntry OBJECT-TYPE 915 SYNTAX EntPhysicalContainsEntry 916 MAX-ACCESS not-accessible 917 STATUS current 918 DESCRIPTION 919 "A single container/containee relationship." 920 INDEX { entPhysicalIndex, entPhysicalChildIndex } 921 ::= { entPhysicalContainsTable 1 } 923 EntPhysicalContainsEntry ::= SEQUENCE { 924 entPhysicalChildIndex INTEGER 925 } 927 entPhysicalChildIndex OBJECT-TYPE 928 SYNTAX INTEGER (1..2147483647) 929 MAX-ACCESS read-only 930 STATUS current 931 DESCRIPTION 932 "The value of entPhysicalIndex for the contained physical 933 entity." 934 ::= { entPhysicalContainsEntry 1 } 936 Draft Entity MIB April 1996 938 -- last change timestamp for the whole MIB 939 entLastChangeTime OBJECT-TYPE 940 SYNTAX Timestamp 941 MAX-ACCESS read-only 942 STATUS current 943 DESCRIPTION 944 "The value of sysUpTime at the time any of these events 945 occur: 946 * a conceptual row is created or deleted in any 947 of these tables: 948 - entPhysicalTable 949 - entLogicalTable 950 - entLPMappingTable 951 - entAliasMappingTable 952 - entPhysicalContainsTable 954 * any instance in the following list of objects 955 changes value: 956 - entPhysicalDescr 957 - entPhysicalVendorType 958 - entPhysicalContainedIn 959 - entPhysicalClass 960 - entLogicalDescr 961 - entLogicalType 962 - entLogicalCommunity 963 - entLogicalTAddress 964 - entLogicalTDomain 965 - entAliasMappingIdentifier 966 " 967 ::= { entityMIBObjects 6 } 969 Draft Entity MIB April 1996 971 -- Entity MIB Trap Definitions 972 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 974 entConfigChange NOTIFICATION-TYPE 975 OBJECTS { 976 entLastChangeTime 977 } 978 STATUS current 979 DESCRIPTION 980 "An entConfigChange trap is sent when the value of 981 entLastChangeTime changes. It can be utilized by an NMS to 982 trigger logical/physical entity table maintenance polls. 983 This trap is throttled by the agent. 985 The value of entLastChangeTime at the time the 986 entConfigChange event is detected by the agent is encoded as 987 a var-bind in the trap. This will normally be the same value 988 as the sysUpTime instance included in the trap, but may not 989 be if trap generation is delayed at all within the agent. 991 An agent must take care not to generate more than one 992 entConfigChange 'trap-event' in a five second period, where 993 a 'trap-event' is the transmission of a single trap PDU to a 994 list of trap destinations. If additional configuration 995 changes occur within the five second 'throttling' period, 996 then these events should be discarded by the agent. An NMS 997 should periodically check the value of entLastChangeTime to 998 detect any missed entConfigChange events due to throttling 999 or transmission loss." 1000 ::= { entityMIBTraps 1 } 1002 Draft Entity MIB April 1996 1004 -- conformance information 1005 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1007 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1008 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1010 -- compliance statements 1012 entityCompliance MODULE-COMPLIANCE 1013 STATUS current 1014 DESCRIPTION 1015 "The compliance statement for SNMP entities which implement 1016 the Entity MIB." 1017 MODULE -- this module 1018 MANDATORY-GROUPS { entityLogicalGroup } 1019 ::= { entityCompliances 1 } 1021 -- MIB groupings 1022 entityLogicalGroup OBJECT-GROUP 1023 OBJECTS { 1024 entLogicalDescr, 1025 entLogicalType, 1026 entLogicalCommunity, 1027 entLogicalTAddress, 1028 entLogicalTDomain, 1029 entLastChangeTime 1030 } 1031 STATUS current 1032 DESCRIPTION 1033 "The collection of objects which are used to represent the 1034 list of logical entities for which a single agent provides 1035 management information." 1036 ::= { entityGroups 1 } 1038 entityMappingGroup OBJECT-GROUP 1039 OBJECTS { 1040 entPhysicalDescr, 1041 entPhysicalVendorType, 1042 entPhysicalContainedIn, 1043 entPhysicalClass, 1044 entPhysicalParentRelPos, 1045 entLPPhysicalIndex, 1046 entAliasLogicalIndexOrZero, 1047 entAliasMappingIdentifier, 1048 entPhysicalChildIndex 1050 Draft Entity MIB April 1996 1052 } 1053 STATUS current 1054 DESCRIPTION 1055 "The collection of objects which are used to represent the 1056 associations between multiple physical components, 1057 interfaces, and port identifiers for which a single agent 1058 provides management information." 1059 ::= { entityGroups 2 } 1061 END 1063 Draft Entity MIB April 1996 1065 5. Usage Examples 1067 The following sections iterate the instance values for two example 1068 networking devices. These examples are kept simple to make them more 1069 understandable. Auxillary components, such as fans, sensors, empty 1070 slots, and sub-modules are not shown, but might be modeled in real 1071 implementations. 1073 5.1. Router/Bridge 1075 A router containing two slots. Each slot contains a 3 port 1076 router/bridge module. Each port is represented in the ifTable. There 1077 are two logical instances of OSPF running and two logical bridges: 1079 Physical entities -- entPhysicalTable: 1080 1 Field-replaceable physical chassis: 1081 entPhysicalDescr.1 == "Acme Chassis Model 100" 1082 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 1083 entPhysicalContainedIn.1 == 0 1084 entPhysicalClass.1 == chassis(3) 1085 entPhysicalParentRelPos.1 == 0 1087 2 slots within the chassis: 1088 entPhysicalDescr.2 == "Acme Router Chassis Slot 1" 1089 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 1090 entPhysicalContainedIn.2 == 1 1091 entPhysicalClass.2 == container(5) 1092 entPhysicalParentRelPos.2 == 1 1094 entPhysicalDescr.3 == "Acme Router Chassis Slot 2" 1095 entPhysicalVendorType.3 == acmeProducts.slotTypes.1 1096 entPhysicalContainedIn.3 == 1 1097 entPhysicalClass.3 == container(5) 1098 entPhysicalParentRelPos.3 == 2 1100 2 Field-replaceable modules: 1101 Slot 1 contains a module with 3 ports: 1102 entPhysicalDescr.4 == "Acme Router Module Model 10" 1103 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 1104 entPhysicalContainedIn.4 == 2 1105 entPhysicalClass.4 == module(9) 1106 entPhysicalParentRelPos.4 == 1 1108 entPhysicalDescr.5 == "Acme Router Ethernet Port 1" 1110 Draft Entity MIB April 1996 1112 entPhysicalVendorType.5 == acmeProducts.portTypes.2 1113 entPhysicalContainedIn.5 == 4 1114 entPhysicalClass.5 == port(10) 1115 entPhysicalParentRelPos.5 == 1 1117 entPhysicalDescr.6 == "Acme Router Ethernet Port 2" 1118 entPhysicalVendorType.6 == acmeProducts.portTypes.2 1119 entPhysicalContainedIn.6 == 4 1120 entPhysicalClass.6 == port(10) 1121 entPhysicalParentRelPos.6 == 2 1123 entPhysicalDescr.7 == "Acme Router Fddi Port 3" 1124 entPhysicalVendorType.7 == acmeProducts.portTypes.3 1125 entPhysicalContainedIn.7 == 4 1126 entPhysicalClass.7 == port(10) 1127 entPhysicalParentRelPos.7 == 3 1129 Slot 2 contains another 3-port module: 1130 entPhysicalDescr.8 == "Acme Router Module Model 11" 1131 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 1132 entPhysicalContainedIn.8 == 3 1133 entPhysicalClass.8 == module(9) 1134 entPhysicalParentRelPos.8 == 1 1136 entPhysicalDescr.9 == "Acme Router Fddi Port 1" 1137 entPhysicalVendorType.9 == acmeProducts.portTypes.3 1138 entPhysicalContainedIn.9 == 8 1139 entPhysicalClass.9 == port(10) 1140 entPhysicalParentRelPos.9 == 1 1142 entPhysicalDescr.10 == "Acme Router Ethernet Port 2" 1143 entPhysicalVendorType.10 == acmeProducts.portTypes.2 1144 entPhysicalContainedIn.10 == 8 1145 entPhysicalClass.10 == port(10) 1146 entPhysicalParentRelPos.10 == 2 1148 entPhysicalDescr.11 == "Acme Router Ethernet Port 3" 1149 entPhysicalVendorType.11 == acmeProducts.portTypes.2 1150 entPhysicalContainedIn.11 == 8 1151 entPhysicalClass.11 == port(10) 1152 entPhysicalParentRelPos.11 == 3 1154 Logical entities -- entLogicalTable 1155 2 OSPF instances: 1156 entLogicalDescr.1 == "ospf-1" 1158 Draft Entity MIB April 1996 1160 entLogicalType.1 == ospf 1161 entLogicalCommunity.1 == "public-ospf1" 1162 entLogicalTAddress.1 == 124.125.126.127:161 1163 entLogicalTDomain.1 == snmpUDPDomain 1165 entLogicalDescr.2 == "ospf-2" 1166 entLogicalType.2 == ospf 1167 entLogicalCommunity.2 == "public-ospf2" 1168 entLogicalTAddress.2 == 124.125.126.127:161 1169 entLogicalTDomain.2 == snmpUDPDomain 1171 2 logical bridges: 1172 entLogicalDescr.3 == "bridge1" 1173 entLogicalType.3 == dod1dBridge 1174 entLogicalCommunity.3 == "public-bridge1" 1175 entLogicalTAddress.3 == 124.125.126.127:161 1176 entLogicalTDomain.3 == snmpUDPDomain 1178 entLogicalDescr.4 == "bridge2" 1179 entLogicalType.4 == dod1dBridge 1180 entLogicalCommunity.4 == "public-bridge2" 1181 entLogicalTAddress.4 == 124.125.126.127:161 1182 entLogicalTDomain.4 == snmpUDPDomain 1184 Logical to Physical Mappings: 1185 1st OSPF instance: uses module 1-port 1 1186 entLPPhysicalIndex.1.5 == 5 1188 2nd OSPF instance: uses module 2-port 1 1189 entLPPhysicalIndex.2.9 == 9 1191 1st bridge group: uses module 1, all ports 1193 [ed. -- Note that these mappings are included in the table since 1194 another logical entity (1st OSPF) utilizes one of the 1195 ports. If this were not the case, then a single mapping 1196 to the module (e.g. entLPPhysicalIndex.3.4) would be 1197 present instead. ] 1198 entLPPhysicalIndex.3.5 == 5 1199 entLPPhysicalIndex.3.6 == 6 1200 entLPPhysicalIndex.3.7 == 7 1202 2nd bridge group: uses module 2, all ports 1203 entLPPhysicalIndex.4.9 == 9 1204 entLPPhysicalIndex.4.10 == 10 1206 Draft Entity MIB April 1996 1208 entLPPhysicalIndex.4.11 == 11 1210 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 1211 Example 1: ifIndex values are global to all logical entities 1212 entAliasMappingIdentifier.5.0 == ifIndex.1 1213 entAliasMappingIdentifier.6.0 == ifIndex.2 1214 entAliasMappingIdentifier.7.0 == ifIndex.3 1215 entAliasMappingIdentifier.9.0 == ifIndex.4 1216 entAliasMappingIdentifier.10.0 == ifIndex.5 1217 entAliasMappingIdentifier.11.0 == ifIndex.6 1219 Example 2: ifIndex values are not shared by all logical entities 1220 entAliasMappingIdentifier.5.0 == ifIndex.1 1221 entAliasMappingIdentifier.5.3 == ifIndex.101 1222 entAliasMappingIdentifier.6.0 == ifIndex.2 1223 entAliasMappingIdentifier.6.3 == ifIndex.102 1224 entAliasMappingIdentifier.7.0 == ifIndex.3 1225 entAliasMappingIdentifier.7.3 == ifIndex.103 1226 entAliasMappingIdentifier.9.0 == ifIndex.4 1227 entAliasMappingIdentifier.9.3 == ifIndex.204 1228 entAliasMappingIdentifier.10.0 == ifIndex.5 1229 entAliasMappingIdentifier.10.3 == ifIndex.205 1230 entAliasMappingIdentifier.11.0 == ifIndex.6 1231 entAliasMappingIdentifier.11.3 == ifIndex.206 1233 Physical Containment Tree -- entPhysicalContainsTable 1234 chassis has two containers: 1235 entPhysicalChildIndex.1.2 = 2 1236 entPhysicalChildIndex.1.3 = 3 1238 container 1 has a module: 1239 entPhysicalChildIndex.2.4 = 4 1241 container 2 has a module: 1242 entPhysicalChildIndex.3.8 = 8 1244 module 1 has 3 ports: 1245 entPhysicalChildIndex.4.5 = 5 1246 entPhysicalChildIndex.4.6 = 6 1247 entPhysicalChildIndex.4.7 = 7 1249 module 2 has 3 ports: 1250 entPhysicalChildIndex.8.9 = 9 1251 entPhysicalChildIndex.8.10 = 10 1252 entPhysicalChildIndex.1.11 = 11 1254 Draft Entity MIB April 1996 1256 5.2. Repeaters 1258 A 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, 1259 and the remaining slots contain ethernet repeater modules. [ed. -- Note 1260 that a replacement for the current Repeater MIB (RFC 1516) is likely to 1261 emerge soon, and it will no longer be necessary to access repeater MIB 1262 data in different naming scopes.] 1264 Physical entities -- entPhysicalTable: 1265 1 Field-replaceable physical chassis: 1266 entPhysicalDescr.1 == "Acme Repeater Chassis Model 110" 1267 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 1268 entPhysicalContainedIn.1 == 0 1269 entPhysicalClass.1 == chassis(3) 1270 entPhysicalParentRelPos.1 == 0 1272 2 Chassis Ethernet Backplanes: 1273 entPhysicalDescr.2 == "Ethernet Backplane 1" 1274 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 1275 entPhysicalContainedIn.2 == 1 1276 entPhysicalClass.2 == backplane(4) 1277 entPhysicalParentRelPos.2 == 1 1279 entPhysicalDescr.3 == "Ethernet Backplane 2" 1280 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 1281 entPhysicalContainedIn.3 == 1 1282 entPhysicalClass.3 == backplane(4) 1283 entPhysicalParentRelPos.3 == 2 1285 3 slots within the chassis: 1286 entPhysicalDescr.4 == "Acme Hub Slot 1" 1287 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 1288 entPhysicalContainedIn.4 == 1 1289 entPhysicalClass.4 == container(5) 1290 entPhysicalParentRelPos.4 == 1 1292 entPhysicalDescr.5 == "Acme Hub Slot 2" 1293 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 1294 entPhysicalContainedIn.5 == 1 1295 entPhysicalClass.5 == container(5) 1296 entPhysicalParentRelPos.5 == 2 1298 entPhysicalDescr.6 == "Acme Hub Slot 3" 1299 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 1300 entPhysicalContainedIn.6 == 1 1302 Draft Entity MIB April 1996 1304 entPhysicalClass.6 == container(5) 1305 entPhysicalParentRelPos.6 == 3 1307 Slot 1 contains a plug-in module with 4 10-BaseT ports: 1308 entPhysicalDescr.7 == "10Base-T Module Model 14" 1309 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 1310 entPhysicalContainedIn.7 == 4 1311 entPhysicalClass.7 == module(9) 1312 entPhysicalParentRelPos.7 == 1 1314 entPhysicalDescr.8 == "10Base-T Port 1" 1315 entPhysicalVendorType.8 == acmeProducts.portTypes.10 1316 entPhysicalContainedIn.8 == 7 1317 entPhysicalClass.8 == port(10) 1318 entPhysicalParentRelPos.8 == 1 1320 entPhysicalDescr.9 == "10Base-T Port 2" 1321 entPhysicalVendorType.9 == acmeProducts.portTypes.10 1322 entPhysicalContainedIn.9 == 7 1323 entPhysicalClass.9 == port(10) 1324 entPhysicalParentRelPos.9 == 2 1326 entPhysicalDescr.10 == "10Base-T Port 3" 1327 entPhysicalVendorType.10 == acmeProducts.portTypes.10 1328 entPhysicalContainedIn.10 == 7 1329 entPhysicalClass.10 == port(10) 1330 entPhysicalParentRelPos.10 == 3 1332 entPhysicalDescr.11 == "10Base-T Port 4" 1333 entPhysicalVendorType.11 == acmeProducts.portTypes.10 1334 entPhysicalContainedIn.11 == 7 1335 entPhysicalClass.11 == port(10) 1336 entPhysicalParentRelPos.11 == 4 1338 Slot 2 contains another ethernet module with 2 ports. 1339 entPhysicalDescr.12 == "Acme 10Base-T Module Model 4" 1340 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 1341 entPhysicalContainedIn.12 = 5 1342 entPhysicalClass.12 == module(9) 1343 entPhysicalParentRelPos.12 == 1 1345 entPhysicalDescr.13 == "802.3 AUI Port 1" 1346 entPhysicalVendorType.13 == acmeProducts.portTypes.11 1347 entPhysicalContainedIn.13 == 12 1348 entPhysicalClass.13 == port(10) 1350 Draft Entity MIB April 1996 1352 entPhysicalParentRelPos.13 == 1 1354 entPhysicalDescr.14 == "10Base-T Port 2" 1355 entPhysicalVendorType.14 == acmeProducts.portTypes.10 1356 entPhysicalContainedIn.14 == 12 1357 entPhysicalClass.14 == port(10) 1358 entPhysicalParentRelPos.14 == 2 1360 Logical entities -- entLogicalTable 1361 Repeater 1--comprised of any ports attached to backplane 1 1362 entLogicalDescr.1 == "repeater1" 1363 entLogicalType.1 == snmpDot3RptrMgt 1364 entLogicalCommunity.1 "public-repeater1" 1365 entLogicalTAddress.1 == 124.125.126.127:161 1366 entLogicalTDomain.1 == snmpUDPDomain 1368 Repeater 2--comprised of any ports attached to backplane 2: 1369 entLogicalDescr.2 == "repeater2" 1370 entLogicalType.2 == snmpDot3RptrMgt 1371 entLogicalCommunity.2 == "public-repeater2" 1372 entLogicalTAddress.2 == 124.125.126.127:161 1373 entLogicalTDomain.2 == snmpUDPDomain 1375 Logical to Physical Mappings -- entLPMappingTable: 1377 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 1378 [ed. -- Note that a mapping to the module is not included, 1379 since in this example represents a port-switchable hub. 1380 Even though all ports on the module could belong to the 1381 same repeater as a matter of configuration, the LP port 1382 mappings should not be replaced dynamically with a single 1383 mapping for the module (e.g. entLPPhysicalIndex.1.7). 1384 If all ports on the module shared a single backplane connection, 1385 then a single mapping for the module would be more appropriate. ] 1387 entLPPhysicalIndex.1.2 == 2 1388 entLPPhysicalIndex.1.8 == 8 1389 entLPPhysicalIndex.1.9 == 9 1390 entLPPhysicalIndex.1.13 == 13 1392 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 1393 entLPPhysicalIndex.2.3 == 3 1394 entLPPhysicalIndex.2.10 == 10 1395 entLPPhysicalIndex.2.11 == 11 1396 entLPPhysicalIndex.2.14 == 14 1398 Draft Entity MIB April 1996 1400 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 1401 Repeater Port Identifier values are shared by both repeaters: 1402 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 1403 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 1404 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 1405 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 1406 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 1407 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 1409 Physical Containment Tree -- entPhysicalContainsTable 1410 chassis has two backplanes and three containers: 1411 entPhysicalChildIndex.1.2 = 2 1412 entPhysicalChildIndex.1.3 = 3 1413 entPhysicalChildIndex.1.4 = 4 1414 entPhysicalChildIndex.1.5 = 5 1415 entPhysicalChildIndex.1.6 = 6 1417 container 1 has a module: 1418 entPhysicalChildIndex.4.7 = 7 1420 container 2 has a module 1421 entPhysicalChildIndex.5.12 = 12 1422 [ed. - in this example, container 3 is empty.] 1424 module 1 has 4 ports: 1425 entPhysicalChildIndex.7.8 = 8 1426 entPhysicalChildIndex.7.9 = 9 1427 entPhysicalChildIndex.7.10 = 10 1428 entPhysicalChildIndex.7.11 = 11 1430 module 2 has 2 ports: 1431 entPhysicalChildIndex.12.13 = 13 1432 entPhysicalChildIndex.12.14 = 14 1434 Draft Entity MIB April 1996 1436 6. Acknowledgements 1438 This document was produced by the IETF Entity MIB Working Group. 1440 Draft Entity MIB April 1996 1442 7. References 1444 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1445 S. Waldbusser, "Structure of Management Information for version 2 1446 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1447 January 1996. 1449 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 1450 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1451 RFC 1213, Hughes LAN Systems, Performance Systems International, 1452 March 1991. 1454 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1455 S. Waldbusser, "Textual Conventions for version 2 of the Simple 1456 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1458 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1459 S. Waldbusser, "Protocol Operations for version 2 of the Simple 1460 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1462 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1463 S. Waldbusser, "Conformance Statements for version 2 of the Simple 1464 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1466 [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1467 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1468 International, MIT Laboratory for Computer Science, May 1990. 1470 [7] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 1471 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 1473 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1474 S. Waldbusser, "Transport Mappings for version 2 of the Simple 1475 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 1477 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1478 S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 1479 January 1996. 1481 Draft Entity MIB April 1996 1483 8. Security Considerations 1485 Security issues are not discussed in this memo. 1487 9. Authors' Addresses 1489 Keith McCloghrie 1490 Cisco Systems, Inc. 1491 170 West Tasman Drive 1492 San Jose, CA 95134 1493 Phone: 408-526-5260 1494 Email: kzm@cisco.com 1496 Andy Bierman 1497 Cisco Systems, Inc. 1498 170 West Tasman Drive 1499 San Jose, CA 95134 1500 Phone: 408-527-3711 1501 Email: abierman@cisco.com 1503 Draft Entity MIB April 1996 1505 Table of Contents 1507 1 Introduction .................................................... 2 1508 2 The SNMP Network Management Framework ........................... 3 1509 2.1 Object Definitions ............................................ 3 1510 3 Overview ........................................................ 4 1511 3.1 Terms ......................................................... 4 1512 3.2 Relationship to Community Strings ............................. 6 1513 3.3 Relationship to Proxy Mechanisms .............................. 6 1514 3.4 Relationship to a Chassis MIB ................................. 7 1515 3.5 Relationship to the Interfaces MIB ............................ 7 1516 3.6 Relationship to the Other MIBs ................................ 7 1517 3.7 Relationship to Naming Scopes ................................. 8 1518 3.8 Multiple Instances of the Entity MIB .......................... 8 1519 3.9 Re-Configuration of Entities .................................. 9 1520 3.10 MIB Structure ................................................ 9 1521 3.11 Multiple Agents .............................................. 10 1522 4 Definitions ..................................................... 11 1523 5 Usage Examples .................................................. 29 1524 5.1 Router/Bridge ................................................. 29 1525 5.2 Repeaters ..................................................... 33 1526 6 Acknowledgements ................................................ 37 1527 7 References ...................................................... 38 1528 8 Security Considerations ......................................... 39 1529 9 Authors' Addresses .............................................. 39