idnits 2.17.1 draft-ietf-entmib-entmib-02.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-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 8 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: ---------------------------------------------------------------------------- == Line 429 has weird spacing: '...in card or da...' -- 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 (January 22, 1996) is 10314 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) == Unused Reference: '3' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1257, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1262, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1270, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1442 (ref. '1') (Obsoleted by RFC 1902) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '3') ** Obsolete normative reference: RFC 1448 (ref. '4') (Obsoleted by RFC 1905) ** Downref: Normative reference to an Historic RFC: RFC 1447 (ref. '5') ** 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 1449 (ref. '8') (Obsoleted by RFC 1906) Summary: 18 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft Entity MIB January 22, 1996 4 5 Entity MIB 7 22 January 1996 9 Keith McCloghrie 10 Cisco Systems Inc. 11 kzm@cisco.com 13 Andy Bierman 14 Bierman Consulting 15 abierman@west.net 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 Draft Entity MIB January 22, 1996 36 1. Introduction 38 This memo defines an experimental portion of the Management Information 39 Base (MIB) for use with network management protocols in the Internet 40 community. In particular, it describes managed objects used for 41 managing multiple logical entities managed by a single SNMPv1 agent. 43 Draft Entity MIB January 22, 1996 45 2. The SNMPv1 Network Management Framework 47 The SNMPv1 Network Management Framework presently consists of two major 48 components. They are: 50 o RFC 1442 [1] which defines the SMI, the mechanisms used for 51 describing and naming objects for the purpose of management. 53 o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed 54 objects for the Internet suite of protocols. 56 The Framework permits new objects to be defined for the purpose of 57 experimentation and evaluation. 59 2.1. Object Definitions 61 Managed objects are accessed via a virtual information store, termed the 62 Management Information Base or MIB. Objects in the MIB are defined 63 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 64 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 65 an administratively assigned name. The object type together with an 66 object instance serves to uniquely identify a specific instantiation of 67 the object. For human convenience, we often use a textual string, 68 termed the descriptor, to refer to the object type. 70 Draft Entity MIB January 22, 1996 72 3. Overview 74 There is a need for a standardized way of representing a single agent 75 which supports multiple instances of one MIB. This is presently true 76 for at least 3 standard MIBs, and is likely to become true for more and 77 more MIBs as time passes. For example: 79 - multiple instances of a bridge supported within a single device 80 having a single agent; 82 - multiple repeaters supported by a single agent; 84 - multiple OSPF backbone areas, each one operating as part of its own 85 Autonomous System, and each identified by the same area-id (e.g., 86 0.0.0.0), supported inside a single router with one agent. 88 The fact that it is a single agent in each of these cases implies there 89 is some relationship which binds all of these entities together. 90 Effectively, there is some "overall" physical entity which houses the 91 sum of the things managed by that one agent, i.e., there are multiple 92 "logical" entities within a single physical entity. Sometimes, the 93 overall physical entity contains multiple (smaller) physical entities 94 and each logical entity is associated with a particular physical entity. 95 Sometimes, the overall physical entity is a "compound" of multiple 96 physical entities (e.g., a stack of stackable hubs). 98 What is needed is a way to determine exactly what logical entities are 99 managed by the agent (either by SNMPv1 or SNMPv2), and thereby to be 100 able to communicate with the agent about a particular logical entity. 101 When different logical entities are associated with different physical 102 entities within the overall physical entity, it is also useful to be 103 able to use this information to distinguish between logical entities. 105 In these situations, there is no need for varbinds for multiple logical 106 entities to be referenced in the same SNMPv1 message (although that 107 might be useful in the future). Rather, it is sufficient, and in some 108 situations preferable, to have the context/community in the message 109 identify the logical entity to which the varbinds apply. 111 3.1. Terms 113 Some new terms are used throughout this document: 115 Draft Entity MIB January 22, 1996 117 - Naming Scope 118 A "naming scope" represents the set of information that may be 119 potentially accessed through a single SNMPv1 operation. All 120 instances within the naming scope share the same unique identifier 121 space. For SNMPv1, a naming scope is identified by the value of the 122 associated 'entLogicalCommunity' instance. 124 - Logical Entity 125 A managed system contains one or more logical entities, each 126 represented by at most one instantiation of each of a particular 127 set of MIB objects. A set of management functions is associated 128 with each logical entity. Examples of logical entities include 129 routers, bridges, print-servers, etc. 131 - Physical Entity 132 A "physical entity" or "physical component" represents an 133 identifiable physical resource within a managed system. Zero or 134 more logical entities may utilize a physical resource at any given 135 time. It is an implementation-specific manner as to which physical 136 components are represented by an agent in the EntPhysicalTable. 137 Typically, physical resources (e.g. communications ports, 138 backplanes, sensors, daughter-cards, power supplies, the overall 139 chassis) which can be managed via functions associated with one or 140 more logical entities are included in the MIB. 142 - Containment Tree 143 Each physical component may optionally be modeled as 'contained' 144 within another physical component. A "containment-tree" is the 145 conceptual sequence of entPhysicalIndex values which uniquely 146 specifies the exact physical location of a physical component 147 within the managed system. It is generated by 'following and 148 recording' each 'entPhysicalContainedIn' instance 'up the tree 149 towards the root', until a value of zero indicating no further 150 containment is found. 152 It is required that physical containment-trees retain their 153 identity across reboots. Specifically, two identical hardware 154 configurations should produce the same set of containment-trees for 155 every corresponding entry in the entPhysicalTable (i.e. the same 156 set of entPhysicalEntries with the same entPhysicalIndex values, 158 Note that chassis slots, which are capable of accepting one or more 159 module types from one or more vendors, are modeled as containers in 160 this MIB. The value of entPhysicalContainedIn for a particular 161 'module' entity (entPhysicalClass value of 'module(9)') should be 163 Draft Entity MIB January 22, 1996 165 equal to an entPhysicalIndex that represents the parent 'container' 166 entity (associated entPhysicalClass value of ('container(5)'). An 167 agent should represent both empty and full containers in the 168 entPhysicalTable. 170 3.2. Relationship to Community Strings 172 For SNMPv1, distinguishing between different logical entities is one 173 (but not the only) purpose of the community string [6]. This is 174 accommodated by representing each community string as a logical entity. 176 Note that different logical entities may 'share' the same naming scope 177 (and therefore the same values of entLogicalCommunity). In such a case, 178 individual logical entities can be identified by examining the 179 sysORTable within the same naming scope. 181 3.3. Relationship to Proxy Mechanisms 183 The Entity MIB is designed to allow functional component discovery. The 184 administrative relationships between different logical entities are not 185 visible in any Entity MIB tables. 187 The management of administrative framework functions is not an explicit 188 goal of the Entity MIB WG at this time. This new area of functionality 189 may be revisited after some operational experience with the Entity MIB 190 is gained. 192 3.4. Relationship to a Chassis MIB 194 Some readers may recall that a previous IETF working group attempted to 195 define a Chassis MIB. No consensus was reached by that working group, 196 possibly because its scope was too broad. As such, it is not the 197 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 198 the scope of this MIB to contain all the information which might be 199 necessary to manage a "chassis". On the other hand, the entities 200 represented by an implementation of this MIB might well be contained in 201 a chassis. 203 Draft Entity MIB January 22, 1996 205 3.5. Relationship to the Interfaces MIB 207 The Entity MIB contains a mapping table identifying physical components 208 that have 'external values' (e.g. ifIndex) associated with them within a 209 given naming scope. This table can be used to identify the physical 210 location of each interface in the ifTable. Since ifIndex values in 211 different contexts are not related to one another, the interface to 212 physical component associations are relative to a specific logical 213 entity within the agent. 215 3.6. Relationship to the Other MIBs 217 The Entity MIB contains a mapping table identifying physical components 218 that have identifiers from other standard MIBs associated with them. 219 For example, this table can be used along with the physical mapping 220 table to identify the physical location of each repeater port in the 221 rptrPortTable, each bridge port in the dot1dBasePortTable, or each 222 ifIndex in the ifTable. 224 3.7. Re-Configuration of Entities 226 All the MIB objects defined in this MIB have at most a read-only MAX- 227 ACCESS clause, i.e., none are write-able. This is another conscious 228 decision by the authors to limit this MIB's scope. It is possible that 229 this restriction could be lifted after implementation experience. 231 3.8. MIB Structure 233 This MIB contains five tables: the entPhysicalTable and the 234 entLogicalTable each provide a list of entities. The entLPMappingTable 235 provides mappings between logical and physical entities. The 236 entAliasMappingTable provides mappings between physical components and 237 associated identifiers from other MIBs. For example, a physical repeater 238 port may be associated with an instance of 'rptrPortGroupIndex.1.5', or 239 'ifIndex.12', or both. The entPhysicalContainsTable provides efficient 240 discovery of the containment relationships of all physical entities 241 (also derivable from 'entPhysicalContainedIn' values). 243 The entPhysicalTable contains one row per physical entity, and should 244 always contains at least one row for an "overall" physical entity. Each 245 Draft Entity MIB January 22, 1996 247 row is indexed by an arbitrary, small integer, and contains a 248 description and type of the physical entity. It also optionally 249 contains the index number of another entPhysicalEntry indicating a 250 containment relationship between the two. 252 The entLogicalTable contains one row per logical entity. Each row is 253 indexed by an arbitrary, small integer and contains a name, description, 254 and type of the logical entity. It also contains information to allow 255 SNMPv1 access to the MIB information for the logical entity. 257 The entLPMappingTable contains mappings between entLogicalIndex values 258 (logical entities) and entPhysicalIndex values (the physical components 259 supporting that entity). A logical entity can map to more than one 260 physical component, and more than one logical entity can map to (share) 261 the same physical component. 263 The entAliasMappingTable contains mappings between entLogicalIndex, 264 entPhysicalIndex pairs and 'alias' object identifier values. This 265 allows resources managed with other MIBs (e.g. repeater ports, bridge 266 ports, physical and logical interfaces) to be identified in the physical 267 entity hierarchy. Note that each alias identifier is only relevant in a 268 particular naming scope. 270 The entPhysicalContainsTable contains simple mappings between 271 'entPhysicalContainedIn' values for each container/containee 272 relationship in the managed system. The indexing of this table allows an 273 NMS to quickly discover the 'entPhysicalIndex' values for all children 274 of a given physical entity. 276 3.9. Multiple Agents 278 Even though a primary motivation for this MIB is to represent the 279 multiple logical entities supported by a single agent, it is also 280 possible to use it to represent multiple logical entities supported by 281 multiple agents (in the same "overall" physical entity). Indeed, it is 282 implicit in the SNMPv1 architecture, that the number of agents is 283 transparent to a network management station. 285 Draft Entity MIB January 22, 1996 287 4. Definitions 289 ENTITY-MIB DEFINITIONS ::= BEGIN 291 IMPORTS 292 MODULE-IDENTITY, OBJECT-TYPE, 293 experimental, NOTIFICATION-TYPE 294 FROM SNMPv2-SMI 295 DisplayString, AutonomousType, TruthValue 296 FROM SNMPv2-TC 297 TAddress 298 FROM SNMPv2-PARTY-MIB 299 MODULE-COMPLIANCE, OBJECT-GROUP 300 FROM SNMPv2-CONF; 302 entityMIB MODULE-IDENTITY 303 LAST-UPDATED "9601200000Z" 304 ORGANIZATION "IETF ENTMIB Working Group" 305 CONTACT-INFO 306 " Keith McCloghrie 307 Cisco Systems Inc. 308 170 West Tasman Drive 309 San Jose, CA 95134 310 408-526-5260 311 kzm@cisco.com 313 Andy Bierman 314 Bierman Consulting 315 1200 Sagamore Lane 316 Ventura, CA 93001 317 805-648-2028 318 abierman@west.net" 319 DESCRIPTION 320 "The MIB module for representing multiple logical 321 entities supported by a single SNMP agent." 322 ::= { experimental xx } 324 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 325 Draft Entity MIB January 22, 1996 327 -- The Physical Entity Table 329 entPhysicalTable OBJECT-TYPE 330 SYNTAX SEQUENCE OF EntPhysicalEntry 331 MAX-ACCESS not-accessible 332 STATUS current 333 DESCRIPTION 334 "This table contains one row per physical entity. There is 335 always at least one row for an 'overall' physical entity." 336 ::= { entityMIBObjects 1 } 338 entPhysicalEntry OBJECT-TYPE 339 SYNTAX EntPhysicalEntry 340 MAX-ACCESS not-accessible 341 STATUS current 342 DESCRIPTION 343 "Information about a particular physical entity. An agent 344 is expected to represent physical components in as much 345 detail as possible. If more than one agent within a chassis 346 implements the Entity MIB, the information retrieved from 347 each agent must be consistent, but not necessarily 348 identical." 349 INDEX { entPhysicalIndex } 350 ::= { entPhysicalTable 1 } 352 EntPhysicalEntry ::= SEQUENCE { 353 entPhysicalIndex INTEGER, 354 entPhysicalDescr DisplayString, 355 entPhysicalVendorType AutonomousType, 356 entPhysicalContainedIn INTEGER, 357 entPhysicalClass INTEGER, 358 entPhysicalParentRelPos INTEGER 359 } 361 entPhysicalIndex OBJECT-TYPE 362 SYNTAX INTEGER (1..2147483647) 363 MAX-ACCESS not-accessible 364 STATUS current 365 DESCRIPTION 366 "The value of this object uniquely identifies the physical 367 entity. The value is a small positive integer; index values 368 for different physical entities are not necessarily 369 contiguous." 370 ::= { entPhysicalEntry 1 } 372 Draft Entity MIB January 22, 1996 374 entPhysicalDescr OBJECT-TYPE 375 SYNTAX DisplayString 376 MAX-ACCESS read-only 377 STATUS current 378 DESCRIPTION 379 "A textual description of physical entity." 380 ::= { entPhysicalEntry 2 } 382 entPhysicalVendorType OBJECT-TYPE 383 SYNTAX AutonomousType 384 MAX-ACCESS read-only 385 STATUS current 386 DESCRIPTION 387 "An indication of the vendor-specific hardware type of the 388 physical entity. Note that this is different from the 389 definition of MIB-II's sysObjectID. 391 An agent should set this object to a enterprise-specific 392 registration identifier value indicating the specific 393 equipment type in detail. The associated instance of 394 entPhysicalClass should be used to indicate the general type 395 of hardware device. 397 If no vendor-specific registration identifier exists for 398 this physical entity, then the value { 0 0 } is returned. If 399 the value is unknown by this agent, then the special value 400 'entPClassUnknown' is returned." 401 ::= { entPhysicalEntry 3 } 403 entPhysicalContainedIn OBJECT-TYPE 404 SYNTAX INTEGER (0..2147483647) 405 MAX-ACCESS read-only 406 STATUS current 407 DESCRIPTION 408 "The value of entPhysicalIndex for the physical entity which 409 'contains' this physical entity. A value of zero indicates 410 this physical entity is not contained in any other physical 411 entity. Note that the set of 'containment' relationships 412 define a strict hierarchy; that is, recursion is not 413 allowed." 414 ::= { entPhysicalEntry 4 } 416 entPhysicalClass OBJECT-TYPE 417 SYNTAX INTEGER { 418 other(1), 420 Draft Entity MIB January 22, 1996 422 unknown(2), 423 chassis(3), 424 backplane(4), 425 container(5), -- slot or daughter-card holder 426 powerSupply(6), 427 fan(7), 428 sensor(8), 429 module(9), -- plug-in card or daughter-card 430 port(10) 431 } 432 MAX-ACCESS read-only 433 STATUS current 434 DESCRIPTION 435 "An indication of the general hardware type of the physical 436 entity. 438 An agent should set this object to the standard enumeration 439 value which most accurately indicates the general class of 440 the physical entity, or the primary class if there is more 441 than one. 443 If no appropriate standard registration identifier exists 444 for this physical entity, then the value 'other(1)' is 445 returned. If the value is unknown by this agent, then the 446 value 'unknown(2)' is returned." 447 ::= { entPhysicalEntry 5 } 449 entPhysicalParentRelPos OBJECT-TYPE 450 SYNTAX INTEGER (0..2147483647) 451 MAX-ACCESS read-only 452 STATUS current 453 DESCRIPTION 454 "An indication of the position of this 'child' component 455 among all its 'sibling' components. The numbering is 456 relative to the 'parent' component. A component's parent is 457 identified by the associated instance of the 458 entPhysicalContainedIn object. An NMS may use this value to 459 compare against other entPhysicalEntries with the same 460 parent (same value of entPhysicalContainedIn). 462 This value should match any external labeling of the 463 physical component if possible. For example, an 464 entPhysicalEntry representing entPhysicalParentRelPos value 465 of '10'. The entPhysicalContainedIn instance should equal 466 the entPhysicalIndex for the parent (module 3). The 468 Draft Entity MIB January 22, 1996 470 entPhysicalParentRelPos instance associated with the parent 471 should be equal to '3'. 473 If the physical position of this component does not match 474 any external labeling, then user documentation or other 475 external reference material should be used to determine the 476 parent-relative position. If this is not possible, then the 477 the agent should assign an arbitrary ordering to a given set 478 of 'sibling' components, perhaps based on internal 479 representation of the components. 481 If the agent cannot determine the parent-relative position 482 for some reason, or if the associated value of 483 entPhysicalContainedIn is '0', then the value '0' is 484 returned. Otherwise a positive integer is returned, 485 indicating the parent-relative position of this physical 486 entity. 488 Parent-relative ordering should start from '1' and continue 489 to 'N', where 'N' represents the highest positioned child 490 entity. Note that this ordering may be sparse or dense, 491 depending on agent implementation. The actual values 492 returned are not globally meaningful, as each 'parent' 493 component may use different numbering algorithms. The 494 ordering is only meaningful among siblings of the same 495 parent component. 497 The agent should retain parent-relative position values 498 across reboots, either through algorithmic assignment or use 499 of non-volatile storage." 500 ::= { entPhysicalEntry 6 } 502 Draft Entity MIB January 22, 1996 504 -- The Logical Entity Table 505 entLogicalTable OBJECT-TYPE 506 SYNTAX SEQUENCE OF EntLogicalEntry 507 MAX-ACCESS not-accessible 508 STATUS current 509 DESCRIPTION 510 "This table contains one row per logical entity." 511 ::= { entityMIBObjects 2 } 513 entLogicalEntry OBJECT-TYPE 514 SYNTAX EntLogicalEntry 515 MAX-ACCESS not-accessible 516 STATUS current 517 DESCRIPTION 518 "Information about a particular logical entity. Entities 519 may be managed by this agent or other SNMP agents (possibly) 520 in the same chassis." 521 INDEX { entLogicalIndex } 522 ::= { entLogicalTable 1 } 524 EntLogicalEntry ::= SEQUENCE { 525 entLogicalIndex INTEGER, 526 entLogicalDescr DisplayString, 527 entLogicalType AutonomousType, 528 entLogicalCommunity OCTET STRING, 529 entLogicalTAddress TAddress, 530 entLogicalTDomain OBJECT IDENTIFIER 531 } 533 entLogicalIndex OBJECT-TYPE 534 SYNTAX INTEGER (1..2147483647) 535 MAX-ACCESS not-accessible 536 STATUS current 537 DESCRIPTION 538 "The value of this object uniquely identifies the logical 539 entity. The value is a small positive integer; index values 540 for different logical entities are are not necessarily 541 contiguous." 542 ::= { entLogicalEntry 1 } 544 Draft Entity MIB January 22, 1996 546 entLogicalDescr OBJECT-TYPE 547 SYNTAX DisplayString 548 MAX-ACCESS read-only 549 STATUS current 550 DESCRIPTION 551 "A textual description of logical entity." 552 ::= { entLogicalEntry 2 } 554 entLogicalType OBJECT-TYPE 555 SYNTAX AutonomousType 556 MAX-ACCESS read-only 557 STATUS current 558 DESCRIPTION 559 "An indication of the type of logical entity. This will 560 typically be the OBJECT IDENTIFIER name of the node in the 561 SMI's naming hierarchy which represents the major MIB 562 module, or the majority of the MIB modules, supported by the 563 logical entity. For example: 564 a logical entity of a regular host/router -> mib-2 565 a logical entity of a 802.1d bridge -> dot1dBridge 566 a logical entity of a 802.3 repeater -> 567 snmpDot3RptrMgmt" 568 ::= { entLogicalEntry 3 } 570 entLogicalCommunity OBJECT-TYPE 571 SYNTAX OCTET STRING 572 MAX-ACCESS read-only 573 STATUS current 574 DESCRIPTION 575 "A SNMPv1 community-string which can be used to access 576 detailed management information for this logical entity. 577 The agent should allow read access with this community 578 string (to an appropriate subset of all managed objects) and 579 may also choose to return a community string based on the 580 privileges of the request used to read this object (e.g. 581 only return a string having read-write privileges when 582 accessed with read-write privileges). 584 A conformant SNMP agent may wish to conserve naming scopes 585 by representing multiple logical entities in a single 'main' 586 naming scope. This is possible when the logical entities 587 represented by the same value of entLogicalCommunity have no 588 object instances in common. For example, 'bridge1' and 589 'repeater1' may be part of the main naming scope, but two 590 additional community strings are needed to represent 592 Draft Entity MIB January 22, 1996 594 'bridge2' and 'repeater2'. 596 Logical entities 'bridge1' and 'repeater1' would be 597 represented by sysOREntries associated with the 'main' 598 naming scope. 600 For agents not accessible via SNMPv1, the value of this 601 object is the empty-string." 602 ::= { entLogicalEntry 4 } 604 entLogicalTAddress OBJECT-TYPE 605 SYNTAX TAddress 606 MAX-ACCESS read-only 607 STATUS current 608 DESCRIPTION 609 "The transport service address by which the logical entity 610 receives network management traffic, formatted according to 611 the corresponding value of entLogicalTDomain. For 612 snmpUDPDomain, entLogicalTAddress is formatted as a 4-octet 613 IP Address concatenated with a 2-octet UDP port number." 614 ::= { entLogicalEntry 5 } 616 entLogicalTDomain OBJECT-TYPE 617 SYNTAX OBJECT IDENTIFIER 618 MAX-ACCESS read-only 619 STATUS current 620 DESCRIPTION 621 "Indicates the kind of transport service by which the 622 logical entity receives network management traffic. 623 Possible values for this object are presently found in the 624 Transport Mappings for SNMPv2 document (RFC 1449 [8]). [ed 625 -- RFC 1449 is now historic]" 626 ::= { entLogicalEntry 6 } 628 Draft Entity MIB January 22, 1996 630 -- entLPMappingTable: for each entity index, there are N 631 -- rows, each representing a physical component 632 -- that is associated with the indicated entity 633 -- 634 -- entity to component table 635 entLPMappingTable OBJECT-TYPE 636 SYNTAX SEQUENCE OF EntLPMappingEntry 637 MAX-ACCESS not-accessible 638 STATUS current 639 DESCRIPTION 640 "This table contains zero or more rows of logical entity to 641 physical equipment associations." 642 ::= { entityMIBObjects 3 } 644 entLPMappingEntry OBJECT-TYPE 645 SYNTAX EntLPMappingEntry 646 MAX-ACCESS not-accessible 647 STATUS current 648 DESCRIPTION 649 "Information about a particular logical entity to physical 650 equipment binding." 651 INDEX { entLogicalIndex, entLPPhysicalIndex } 652 ::= { entLPMappingTable 1 } 654 EntLPMappingEntry ::= SEQUENCE { 655 entLPPhysicalIndex INTEGER 656 } 658 entLPPhysicalIndex OBJECT-TYPE 659 SYNTAX INTEGER (1..2147483647) 660 MAX-ACCESS read-only 661 STATUS current 662 DESCRIPTION 663 "The value of this object identifies a particular 664 entPhysicalEntry associated with the indicated 665 entLogicalEntity." 666 ::= { entLPMappingEntry 1 } 668 Draft Entity MIB January 22, 1996 670 -- logical entity/component to alias table 671 entAliasMappingTable OBJECT-TYPE 672 SYNTAX SEQUENCE OF EntAliasMappingEntry 673 MAX-ACCESS not-accessible 674 STATUS current 675 DESCRIPTION 676 "This table contains zero or more rows of logical entity, 677 and physical component to external identifier associations." 678 ::= { entityMIBObjects 4 } 680 entAliasMappingEntry OBJECT-TYPE 681 SYNTAX EntAliasMappingEntry 682 MAX-ACCESS not-accessible 683 STATUS current 684 DESCRIPTION 685 "Information about a particular physical equipment, logical 686 entity to external identifier binding. Note that the same 687 logical entity/ physical component pair may have an 688 arbitrary number of external identifier (alias) bindings." 689 INDEX { entLogicalIndex, entPhysicalIndex, entAliasMappingIndex } 690 ::= { entAliasMappingTable 1 } 692 EntAliasMappingEntry ::= SEQUENCE { 693 entAliasMappingIndex INTEGER, 694 entAliasIdentifier OBJECT IDENTIFIER 695 } 697 entAliasMappingIndex OBJECT-TYPE 698 SYNTAX INTEGER (1..2147483647) 699 MAX-ACCESS not-accessible 700 STATUS current 701 DESCRIPTION 702 "The value of this object uniquely identifies the particular 703 binding for a specific logical entity on a particular 704 physical component. The value is a small positive integer; 705 index values for different entAlias mappings are not 706 necessarily contiguous." 707 ::= { entAliasMappingEntry 1 } 709 entAliasIdentifier OBJECT-TYPE 710 SYNTAX OBJECT IDENTIFIER 711 MAX-ACCESS read-only 712 STATUS current 713 DESCRIPTION 714 "The value of this object identifies a particular MIB 716 Draft Entity MIB January 22, 1996 718 instance associated with the indicated entPhysicalEntry and 719 entLogicalEntry pair. 721 For example, suppose a physical port was represented by 722 entPhysicalEntry.3, and entLogicalEntry.1 existed for a 723 repeater, entLogicalEntry.2 existed for a bridge, and the 724 bridge port was also represented in the ifTable. Then there 725 might be three related instances of entAliasIdentifier: 726 entAliasIdentifier.3.1.1 == rptrPortGroupIndex.5.2 727 entAliasIdentifier.3.2.1 == dot1dBasePort.2 728 entAliasIdentifier.3.2.2 == ifIndex.2 " 729 ::= { entAliasMappingEntry 2 } 731 Draft Entity MIB January 22, 1996 733 -- physical mapping table 734 entPhysicalContainsTable OBJECT-TYPE 735 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 736 MAX-ACCESS not-accessible 737 STATUS current 738 DESCRIPTION 739 "A table which exposes the container/containee relationships 740 between physical entities." 741 ::= { entityMIBObjects 5 } 743 entPhysicalContainsEntry OBJECT-TYPE 744 SYNTAX EntPhysicalContainsEntry 745 MAX-ACCESS not-accessible 746 STATUS current 747 DESCRIPTION 748 "A single container/containee relationship." 749 INDEX { entPhysicalIndex, entPhysicalChildIndex } 750 ::= { entPhysicalContainsTable 1 } 752 EntPhysicalContainsEntry ::= SEQUENCE { 753 entPhysicalChildIndex INTEGER 754 } 756 entPhysicalChildIndex OBJECT-TYPE 757 SYNTAX INTEGER (1..2147483647) 758 MAX-ACCESS read-only 759 STATUS current 760 DESCRIPTION 761 "The value of entPhysicalIndex for the contained physical 762 entity." 763 ::= { entPhysicalContainsEntry 1 } 765 Draft Entity MIB January 22, 1996 767 -- last change timestamp for the whole MIB 768 entLastChangeTime OBJECT-TYPE 769 SYNTAX Timestamp 770 MAX-ACCESS read-only 771 STATUS current 772 DESCRIPTION 773 "The value of sysUpTime at the time any of these events 774 occur: 775 * a conceptual row is created or deleted in any of these tables: 776 - entPhysicalTable 777 - entLogicalTable 778 - entLPMappingTable 779 - entAliasMappingTable 780 - entPhysicalContainsTable 782 * any instance in the following list of objects changes value: 783 - entPhysicalDescr 784 - entPhysicalVendorType 785 - entPhysicalContainedIn 786 - entPhysicalClass 787 - entLogicalDescr 788 - entLogicalType 789 - entLogicalCommunity 790 - entLogicalTAddress 791 - entLogicalTDomain 792 - entAliasIdentifier 793 " 794 ::= { entityMIBObjects 6 } 796 Draft Entity MIB January 22, 1996 798 -- Entity MIB Trap Definitions 799 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 801 entConfigChange NOTIFICATION-TYPE 802 OBJECTS { 803 entLastChangeTime 804 } 805 STATUS current 806 DESCRIPTION 807 "An entConfigChange trap is sent when the value of 808 entLastChangeTime changes. It can be utilized by an NMS to 809 trigger logical/physical entity table maintenance polls. 810 This trap is throttled by the agent. 812 The value of entLastChangeTime at the time the 813 entConfigChange event is detected by the agent is encoded as 814 a var-bind in the trap. This should be the same value as the 815 sysUpTime instance included in the trap, but may not be if 816 trap generation is delayed at all within the agent. 818 An agent must take care not to generate more than one 819 entConfigChange 'trap-event' in a five second period, where 820 a 'trap-event' is the transmission of a single trap PDU to a 821 list of trap destinations. If additional configuration 822 changes occur within the five second 'throttling' period, 823 then these events should be discarded by the agent. An NMS 824 should periodically check the value of entLastChangeTime to 825 detect any missed entConfigChange events due to throttling. 826 ::= { entityMIBTraps 1 } 828 Draft Entity MIB January 22, 1996 830 -- conformance information 831 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 833 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 834 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 836 -- compliance statements 838 entityCompliance MODULE-COMPLIANCE 839 STATUS current 840 DESCRIPTION 841 "The compliance statement for SNMPv2 entities 842 which implement the Entity MIB." 843 MODULE -- this module 844 MANDATORY-GROUPS { entityGroup } 845 ::= { entityCompliances 1 } 847 -- units of conformance 849 entityGroup OBJECT-GROUP 850 OBJECTS { entPhysicalDescr, 851 entPhysicalVendorType, 852 entPhysicalContainedIn, 853 entPhysicalClass, 854 entPhysicalParentRelPos, 855 entLogicalDescr, 856 entLogicalType, 857 entLogicalCommunity, 858 entLogicalTAddress, 859 entLogicalTDomain, 860 entLPPhysicalIndex, 861 entAliasIdentifier, 862 entPhysicalChildIndex, 863 entLastChangeTime, 864 entConfigChange 865 } 866 STATUS current 867 DESCRIPTION 868 "The collection of objects which are used to 869 represent the multiple logical entities, 870 physical components, interfaces, and port 871 alias identifiers for which a single agent 872 provides MIB information." 873 ::= { entityGroups 1 } 875 Draft Entity MIB January 22, 1996 877 END 878 Draft Entity MIB January 22, 1996 880 5. Usage Examples 882 The following sections iterate the instance values for two example 883 networking devices. These examples are kept simple to make them more 884 understandable. Auxillary components, such as fans, sensors, empty 885 slots, and sub-modules are not shown, but should be modeled in real 886 implementations. 888 5.1. Router/Bridge 890 An SNMPv1 router containing two slots. Each slot contains a 3 port 891 router/bridge module. Each port is represented in the ifTable. There 892 are two logical instances of OSPF running and two logical bridges: 894 Physical entities -- entPhysicalTable: 895 1 Field-replaceable physical chassis: 896 entPhysicalDescr.1 == "Acme Chassis Model 100" 897 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 898 entPhysicalContainedIn.1 == 0 899 entPhysicalClass.1 == chassis(3) 900 entPhysicalParentRelPos.1 == 0 902 2 slots within the chassis: 903 entPhysicalDescr.2 == "Acme Router Chassis Slot 1" 904 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 905 entPhysicalContainedIn.2 == 1 906 entPhysicalClass.2 == container(5) 907 entPhysicalParentRelPos.2 == 1 909 entPhysicalDescr.3 == "Acme Router Chassis Slot 2" 910 entPhysicalVendorType.3 == acmeProducts.slotTypes.1 911 entPhysicalContainedIn.3 == 1 912 entPhysicalClass.3 == container(5) 913 entPhysicalParentRelPos.3 == 2 915 2 Field-replaceable modules: 916 Slot 1 contains a module with 3 ports: 917 entPhysicalDescr.4 == "Acme Router Module Model 10" 918 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 919 entPhysicalContainedIn.4 == 2 920 entPhysicalClass.4 == module(9) 921 entPhysicalParentRelPos.4 == 1 923 entPhysicalDescr.5 == "Acme Router Ethernet Port 1" 925 Draft Entity MIB January 22, 1996 927 entPhysicalVendorType.5 == acmeProducts.portTypes.2 928 entPhysicalContainedIn.5 == 4 929 entPhysicalClass.5 == port(10) 930 entPhysicalParentRelPos.5 == 1 932 entPhysicalDescr.6 == "Acme Router Ethernet Port 2" 933 entPhysicalVendorType.6 == acmeProducts.portTypes.2 934 entPhysicalContainedIn.6 == 4 935 entPhysicalClass.6 == port(10) 936 entPhysicalParentRelPos.6 == 2 938 entPhysicalDescr.7 == "Acme Router Fddi Port 3" 939 entPhysicalVendorType.7 == acmeProducts.portTypes.3 940 entPhysicalContainedIn.7 == 4 941 entPhysicalClass.7 == port(10) 942 entPhysicalParentRelPos.7 == 3 944 Slot 2 contains another 3-port module: 945 entPhysicalDescr.8 == "Acme Router Module Model 11" 946 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 947 entPhysicalContainedIn.8 == 3 948 entPhysicalClass.8 == module(9) 949 entPhysicalParentRelPos.8 == 1 951 entPhysicalDescr.9 == "Acme Router Fddi Port 1" 952 entPhysicalVendorType.9 == acmeProducts.portTypes.3 953 entPhysicalContainedIn.9 == 8 954 entPhysicalClass.9 == port(10) 955 entPhysicalParentRelPos.9 == 1 957 entPhysicalDescr.10 == "Acme Router Ethernet Port 2" 958 entPhysicalVendorType.10 == acmeProducts.portTypes.2 959 entPhysicalContainedIn.10 == 8 960 entPhysicalClass.10 == port(10) 961 entPhysicalParentRelPos.10 == 2 963 entPhysicalDescr.11 == "Acme Router Ethernet Port 3" 964 entPhysicalVendorType.11 == acmeProducts.portTypes.2 965 entPhysicalContainedIn.11 == 8 966 entPhysicalClass.11 == port(10) 967 entPhysicalParentRelPos.11 == 3 969 Logical entities -- entLogicalTable 970 2 OSPF instances: 971 entLogicalDescr.1 == "ospf-1" 973 Draft Entity MIB January 22, 1996 975 entLogicalType.1 == ospf 976 entLogicalCommunity.1 == "public-ospf1" 977 entLogicalTAddress.1 == 124.125.126.127:161 978 entLogicalTDomain.1 == snmpUDPDomain 980 entLogicalDescr.2 == "ospf-2" 981 entLogicalType.2 == ospf 982 entLogicalCommunity.2 == "public-ospf2" 983 entLogicalTAddress.2 == 124.125.126.127:161 984 entLogicalTDomain.2 == snmpUDPDomain 986 2 logical bridges: 987 entLogicalDescr.3 == "bridge1" 988 entLogicalType.3 == dod1dBridge 989 entLogicalCommunity.3 == "public-bridge1" 990 entLogicalTAddress.3 == 124.125.126.127:161 991 entLogicalTDomain.3 == snmpUDPDomain 993 entLogicalDescr.4 == "bridge2" 994 entLogicalType.4 == dod1dBridge 995 entLogicalCommunity.4 == "public-bridge2" 996 entLogicalTAddress.4 == 124.125.126.127:161 997 entLogicalTDomain.4 == snmpUDPDomain 999 Logical to Physical Mappings: 1000 1st OSPF instance: uses module 1-port 1 1001 entLPPhysicalIndex.1.5 == 5 1003 2nd OSPF instance: uses module 2-port 1 1004 entLPPhysicalIndex.2.9 == 9 1006 1st bridge group: uses module 1, all ports 1007 entLPPhysicalIndex.3.5 == 5 1008 entLPPhysicalIndex.3.6 == 6 1009 entLPPhysicalIndex.3.7 == 7 1011 2nd bridge group: uses module 2, all ports 1012 entLPPhysicalIndex.4.9 == 9 1013 entLPPhysicalIndex.4.10 == 10 1014 entLPPhysicalIndex.4.11 == 11 1016 Logical to Physical to Alias Mappings -- entAliasMappingTable: 1017 Bridge 1 uses Ports 1..3 on Slot 1 1018 entAliasIdentifier.3.5.1 == dot1dBasePort.1 1019 entAliasIdentifier.3.5.2 == ifIndex.1 1021 Draft Entity MIB January 22, 1996 1023 entAliasIdentifier.3.6.1 == dot1dBasePort.2 1024 entAliasIdentifier.3.6.2 == ifIndex.2 1025 entAliasIdentifier.3.7.1 == dot1dBasePort.3 1026 entAliasIdentifier.3.7.2 == ifIndex.3 1028 Bridge 2 uses Ports 1..3 on Slot 2; uses same Bridge MIB and ifIndex 1029 values as Bridge 1, but in a different context, and representing 1030 different physical ports: 1031 entAliasIdentifier.4.9.1 == dot1dBasePort.1 1032 entAliasIdentifier.4.9.2 == ifIndex.1 1033 entAliasIdentifier.4.10.1 == dot1dBasePort.2 1034 entAliasIdentifier.4.10.2 == ifIndex.2 1035 entAliasIdentifier.4.11.1 == dot1dBasePort.3 1036 entAliasIdentifier.4.11.2 == ifIndex.3 1038 Physical Containment Tree -- entPhysicalContainsTable 1039 chassis has two containers: 1040 entPhysicalChildIndex.1.2 = 2 1041 entPhysicalChildIndex.1.3 = 3 1043 container 1 has a module: 1044 entPhysicalChildIndex.2.4 = 4 1046 container 2 has a module 1047 entPhysicalChildIndex.3.8 = 8 1049 module 1 has some ports: 1050 entPhysicalChildIndex.4.5 = 5 1051 entPhysicalChildIndex.4.6 = 6 1052 entPhysicalChildIndex.4.7 = 7 1054 module 2 has some ports: 1055 entPhysicalChildIndex.8.9 = 9 1056 entPhysicalChildIndex.8.10 = 10 1057 entPhysicalChildIndex.1.11 = 11 1059 5.2. Repeaters 1061 An SNMPv1 only, 3-slot Hub with 2 backplane ethernet segments. Slot 1062 three is empty, and the remaining slots contain ethernet repeater 1063 modules. 1065 Physical entities -- entPhysicalTable: 1066 1 Field-replaceable physical chassis: 1068 Draft Entity MIB January 22, 1996 1070 entPhysicalDescr.1 == "Acme Repeater Chassis Model 110" 1071 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 1072 entPhysicalContainedIn.1 == 0 1073 entPhysicalClass.1 == chassis(3) 1074 entPhysicalParentRelPos.1 == 0 1076 2 Chassis Ethernet Backplanes: 1077 entPhysicalDescr.2 == "Ethernet Backplane 1" 1078 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 1079 entPhysicalContainedIn.2 == 1 1080 entPhysicalClass.2 == backplane(4) 1081 entPhysicalParentRelPos.2 == 1 1083 entPhysicalDescr.3 == "Ethernet Backplane 2" 1084 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 1085 entPhysicalContainedIn.3 == 1 1086 entPhysicalClass.3 == backplane(4) 1087 entPhysicalParentRelPos.3 == 2 1089 3 slots within the chassis: 1090 entPhysicalDescr.4 == "Acme Hub Slot 1" 1091 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 1092 entPhysicalContainedIn.4 == 1 1093 entPhysicalClass.4 == container(5) 1094 entPhysicalParentRelPos.4 == 1 1096 entPhysicalDescr.5 == "Acme Hub Slot 2" 1097 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 1098 entPhysicalContainedIn.5 == 1 1099 entPhysicalClass.5 == container(5) 1100 entPhysicalParentRelPos.5 == 2 1102 entPhysicalDescr.6 == "Acme Hub Slot 3" 1103 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 1104 entPhysicalContainedIn.6 == 1 1105 entPhysicalClass.6 == container(5) 1106 entPhysicalParentRelPos.6 == 3 1108 Slot 1 contains a plug-in module with 4 10-BaseT ports: 1109 entPhysicalDescr.7 == "10Base-T Module Model 14" 1110 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 1111 entPhysicalContainedIn.7 == 4 1112 entPhysicalClass.7 == module(9) 1113 entPhysicalParentRelPos.7 == 1 1115 Draft Entity MIB January 22, 1996 1117 entPhysicalDescr.8 == "10Base-T Port 1" 1118 entPhysicalVendorType.8 == acmeProducts.portTypes.10 1119 entPhysicalContainedIn.8 == 7 1120 entPhysicalClass.8 == port(10) 1121 entPhysicalParentRelPos.8 == 1 1123 entPhysicalDescr.9 == "10Base-T Port 2" 1124 entPhysicalVendorType.9 == acmeProducts.portTypes.10 1125 entPhysicalContainedIn.9 == 7 1126 entPhysicalClass.9 == port(10) 1127 entPhysicalParentRelPos.9 == 2 1129 entPhysicalDescr.10 == "10Base-T Port 3" 1130 entPhysicalVendorType.10 == acmeProducts.portTypes.10 1131 entPhysicalContainedIn.10 == 7 1132 entPhysicalClass.10 == port(10) 1133 entPhysicalParentRelPos.10 == 3 1135 entPhysicalDescr.11 == "10Base-T Port 4" 1136 entPhysicalVendorType.11 == acmeProducts.portTypes.10 1137 entPhysicalContainedIn.11 == 7 1138 entPhysicalClass.11 == port(10) 1139 entPhysicalParentRelPos.11 == 4 1141 Slot 2 contains another ethernet module with 2 ports. 1142 entPhysicalDescr.12 == "Acme 10Base-T Module Model 4" 1143 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 1144 entPhysicalContainedIn.12 = 5 1145 entPhysicalClass.12 == module(9) 1146 entPhysicalParentRelPos.12 == 1 1148 entPhysicalDescr.13 == "802.3 AUI Port 1" 1149 entPhysicalVendorType.13 == acmeProducts.portTypes.11 1150 entPhysicalContainedIn.13 == 12 1151 entPhysicalClass.13 == port(10) 1152 entPhysicalParentRelPos.13 == 1 1154 entPhysicalDescr.14 == "10Base-T Port 2" 1155 entPhysicalVendorType.14 == acmeProducts.portTypes.10 1156 entPhysicalContainedIn.14 == 12 1157 entPhysicalClass.14 == port(10) 1158 entPhysicalParentRelPos.14 == 2 1160 Logical entities -- entLogicalTable 1161 Repeater 1--comprised of any ports attached to backplane 1 1163 Draft Entity MIB January 22, 1996 1165 entLogicalDescr.1 == "repeater1" 1166 entLogicalType.1 == snmpDot3RptrMgt 1167 entLogicalCommunity.1 "public-repeater1" 1168 entLogicalTAddress.1 == 124.125.126.127:161 1169 entLogicalTDomain.1 == snmpUDPDomain 1171 Repeater 2--comprised of any ports attached to backplane 2: 1172 entLogicalDescr.2 == "repeater2" 1173 entLogicalType.2 == snmpDot3RptrMgt 1174 entLogicalCommunity.2 == "public-repeater2" 1175 entLogicalTAddress.2 == 124.125.126.127:161 1176 entLogicalTDomain.2 == snmpUDPDomain 1178 Logical to Physical Mappings -- entLPMappingTable: 1180 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 1181 entLPPhysicalIndex.1.2 == 2 1182 entLPPhysicalIndex.1.8 == 8 1183 entLPPhysicalIndex.1.9 == 9 1184 entLPPhysicalIndex.1.13 == 13 1186 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 1187 entLPPhysicalIndex.2.3 == 3 1188 entLPPhysicalIndex.2.10 == 10 1189 entLPPhysicalIndex.2.11 == 11 1190 entLPPhysicalIndex.2.14 == 14 1192 Logical to Physical to Alias Mappings -- entAliasMappingTable: 1193 repeater1 uses slot 1-ports 1 & 2, slot 2-port 1 1194 entAliasIdentifier.1.8.1 == rptrPortGroupIndex.1.1 1195 entAliasIdentifier.1.9.1 == rptrPortGroupIndex.1.2 1196 entAliasIdentifier.1.13.1 == rptrPortGroupIndex.2.1 1198 repeater2 uses slot 1-ports 3 & 4, slot 2-port 2 1199 entAliasIdentifier.2.10.1 == rptrPortGroupIndex.1.3 1200 entAliasIdentifier.2.11.1 == rptrPortGroupIndex.1.4 1201 entAliasIdentifier.2.14.1 == rptrPortGroupIndex.2.2 1203 Physical Containment Tree -- entPhysicalContainsTable 1205 chassis has two backplanes and three containers: 1206 entPhysicalChildIndex.1.2 = 2 1207 entPhysicalChildIndex.1.3 = 3 1208 entPhysicalChildIndex.1.4 = 4 1209 entPhysicalChildIndex.1.5 = 5 1211 Draft Entity MIB January 22, 1996 1213 entPhysicalChildIndex.1.6 = 6 1215 container 1 has a module: 1216 entPhysicalChildIndex.4.7 = 7 1218 container 2 has a module 1219 entPhysicalChildIndex.5.12 = 12 1220 -- container 3 is empty 1222 module 1 has some ports: 1223 entPhysicalChildIndex.7.8 = 8 1224 entPhysicalChildIndex.7.9 = 9 1225 entPhysicalChildIndex.7.10 = 10 1226 entPhysicalChildIndex.7.11 = 11 1228 module 2 has some ports: 1229 entPhysicalChildIndex.12.13 = 13 1230 entPhysicalChildIndex.12.14 = 14 1232 Draft Entity MIB January 22, 1996 1234 6. Acknowledgements 1236 This document was produced by the IETF Entity MIB Working Group. 1238 Draft Entity MIB January 22, 1996 1240 7. References 1242 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1243 of Management Information for version 2 of the Simple Network 1244 Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes 1245 LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1246 University, April 1993. 1248 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 1249 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1250 RFC 1213, Hughes LAN Systems, Performance Systems International, 1251 March 1991. 1253 [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 1254 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, 1255 Trusted Information Systems, Hughes LAN Systems, April 1993. 1257 [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1258 Operations for version 2 of the Simple Network Management Protocol 1259 (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover 1260 Beach Consulting, Inc., Carnegie Mellon University, April 1993. 1262 [5] McCloghrie, K., and J. Galvin, "Party MIB for Version 2 of the 1263 Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN 1264 Systems, Trusted Information Systems, April 1993. 1266 [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1267 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1268 International, MIT Laboratory for Computer Science, May 1990. 1270 [7] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 1271 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 1273 [8] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 1274 Mappings for version 2 of the Simple Network Management Protocol 1275 (SNMPv2)", RFC 1449, SNMP Research, Inc., Hughes LAN Systems, Dover 1276 Beach Consulting, Inc., Carnegie Mellon University, April 1993. 1278 Draft Entity MIB January 22, 1996 1280 8. Security Considerations 1282 Security issues are not discussed in this memo. 1284 9. Authors' Addresses 1286 Keith McCloghrie 1287 cisco Systems, Inc. 1288 170 West Tasman Drive 1289 San Jose, CA 95134 1290 Phone: 408-526-5260 1291 Email: kzm@cisco.com 1293 Andy Bierman 1294 Bierman Consulting 1295 1200 Sagamore Lane 1296 Ventura, CA 93001 1297 Phone: 805-648-2028 1298 Email: abierman@west.net 1300 Draft Entity MIB January 22, 1996 1302 Table of Contents 1304 1 Introduction .................................................... 2 1305 2 The SNMPv1 Network Management Framework ......................... 3 1306 2.1 Object Definitions ............................................ 3 1307 3 Overview ........................................................ 4 1308 3.1 Terms ......................................................... 4 1309 3.2 Relationship to Community Strings ............................. 6 1310 3.3 Relationship to Proxy Mechanisms .............................. 6 1311 3.4 Relationship to a Chassis MIB ................................. 6 1312 3.5 Relationship to the Interfaces MIB ............................ 7 1313 3.6 Relationship to the Other MIBs ................................ 7 1314 3.7 Re-Configuration of Entities .................................. 7 1315 3.8 MIB Structure ................................................. 7 1316 3.9 Multiple Agents ............................................... 8 1317 4 Definitions ..................................................... 9 1318 5 Usage Examples .................................................. 25 1319 5.1 Router/Bridge ................................................. 25 1320 5.2 Repeaters ..................................................... 28 1321 6 Acknowledgements ................................................ 33 1322 7 References ...................................................... 34 1323 8 Security Considerations ......................................... 35 1324 9 Authors' Addresses .............................................. 35