idnits 2.17.1 draft-ietf-entmib-entmib-01.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 3 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: ---------------------------------------------------------------------------- -- 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 14, 1996) is 10329 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: '5' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1157, 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) Summary: 17 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft Entity MIB January 14, 1996 4 5 Entity MIB 7 14 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 14, 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 SNMP agent. 43 Draft Entity MIB January 14, 1996 45 2. The SNMPv2 Network Management Framework 47 The SNMPv2 Network Management Framework consists of four 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 o RFC 1445 [3] which defines the administrative and other 57 architectural aspects of the framework. 59 o RFC 1448 [4] which defines the protocol used for network access to 60 managed objects. 62 The Framework permits new objects to be defined for the purpose of 63 experimentation and evaluation. 65 2.1. Object Definitions 67 Managed objects are accessed via a virtual information store, termed the 68 Management Information Base or MIB. Objects in the MIB are defined 69 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 70 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 71 an administratively assigned name. The object type together with an 72 object instance serves to uniquely identify a specific instantiation of 73 the object. For human convenience, we often use a textual string, 74 termed the descriptor, to refer to the object type. 76 Draft Entity MIB January 14, 1996 78 3. Overview 80 There is a need for a standardized way of representing a single agent 81 which supports multiple instances of one MIB. This is already true for 82 at least 3 standard MIBs, and is likely to become true for more and more 83 MIBs as time passes. For example: 85 - multiple instances of a bridge supported within a single device 86 having a single agent; 88 - multiple repeaters supported by a single agent; 90 - multiple OSPF backbone areas, each one operating as part of its own 91 Autonomous System, and each identified by the same area-id (e.g., 92 0.0.0.0), supported inside a single router with one agent. 94 The fact that it is a single agent in each of these cases implies there 95 is some relationship which binds all of these entities together. 96 Effectively, there is some "overall" physical entity which houses the 97 sum of the things managed by that one agent, i.e., there are multiple 98 "logical" entities within a single physical entity. Sometimes, the 99 overall physical entity contains multiple (smaller) physical entities 100 and each logical entity is associated with a particular such physical 101 entity. Sometimes, the overall physical entity is a "compound" of 102 multiple physical entities (e.g., a stack of stackable hubs). 104 What is needed is a way to determine exactly what logical entities are 105 managed by the agent (either by SNMPv1 or SNMPv2), and thereby to be 106 able to communicate with the agent about a particular logical entity. 107 When different logical entities are associated with different physical 108 entities within the overall physical entity, it is also useful to be 109 able to use this information to distinguish between logical entities. 111 In these situations, there is no need for varbinds for multiple logical 112 entities to be referenced in the same SNMP message (although that might 113 be useful in the future). Rather, it is sufficient, and in some 114 situations preferable, to have the context/community in the message 115 identify the logical entity to which the varbinds apply. 117 3.1. Terms 119 Some new terms are used throughout this document: 121 Draft Entity MIB January 14, 1996 123 - Naming Scope 124 A "naming scope" represents the set of information that may be 125 potentially accessed through a single SNMP operation. All instances 126 within the naming scope share the same unique identifier space. For 127 SNMPv1, a naming scope is identified by the value of the associated 128 'entLogicalCommunity' instance. 130 - Logical Entity 131 A managed system contains one or more logical entities, each 132 represented by at most one instantiation of each of a particular 133 set of MIB objects. A set of management functions is associated 134 with each logical entity. Examples of logical entities include 135 routers, bridges, print-servers, etc. 137 - Physical Entity 138 A "physical entity" or "physical component" represents an 139 identifiable physical resource within a managed system. Zero or 140 more logical entities may utilize a physical resource at any given 141 time. It is an implementation-specific manner as to which physical 142 components are represented by an agent in the EntPhysicalTable. 143 Typically, physical resources (e.g. communications ports, 144 backplanes, sensors, daughter-cards, power supplies, the overall 145 chassis) which can be managed via functions associated with one or 146 more logical entities are included in the MIB. 148 - Containment Tree 149 Each physical component may optionally be modeled as 'contained' 150 within another physical component. A "containment-tree" is the 151 conceptual sequence of entPhysicalIndex values which uniquely 152 specifies the exact physical location of a physical component 153 within the managed system. It is generated by 'following and 154 recording' each 'entPhysicalContainedIn' instance until a value of 155 zero (indicating no further containment) is found. 157 It is suggested that physical containment-trees retain their 158 identity across reboots. Specifically, two identical hardware 159 configurations should produce the same set of containment-trees for 160 every corresponding entry in the entPhysicalTable (i.e. the same 161 set of entPhysicalEntries with the same entPhysicalIndex values, 163 [ed. want to say anything about container/containee guidelines 164 here?] 166 Draft Entity MIB January 14, 1996 168 3.2. Relationship to Community Strings 170 For SNMPv1, distinguishing between different logical entities is one 171 (but not the only) purpose of the community string [6]. This is 172 accommodated by representing each community string as a logical entity. 174 Note that different logical entities may 'share' the same naming scope 175 (and therefore the same values of entLogicalCommunity). In such a case, 176 individual logical entities can be identified by examining the 177 sysORTable within the same naming scope. 179 3.3. Relationship to Proxy Mechanisms 181 The Entity MIB is designed to allow functional component discovery. The 182 administrative relationships between different logical entities are not 183 visible in any Entity MIB tables. 185 The management of administrative framework functions is not an explicit 186 goal of the Entity MIB WG at this time. This new area of functionality 187 may be revisited after some operational experience with the Entity MIB 188 is gained. 190 3.4. Relationship to a Chassis MIB 192 Some readers may recall that a previous IETF working group attempted to 193 define a Chassis MIB. No consensus was reached by that working group, 194 possibly because its scope was too broad. As such, it is not the 195 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 196 the scope of this MIB to contain all the information which might be 197 necessary to manage a "chassis". On the other hand, the entities 198 represented by an implementation of this MIB might well be contained in 199 a chassis. 201 3.5. Relationship to the Interfaces MIB 203 The Entity MIB contains a mapping table identifying physical components 204 that have 'external values' (e.g. ifIndex) associated with them within a 205 given naming scope. This table can be used to identify the physical 206 location of each interface in the ifTable. Since ifIndex values in 207 different contexts are not related to one another, the interface to 208 physical component associations are relative to a specific logical 209 entity within the agent. 211 Draft Entity MIB January 14, 1996 213 [ed. say anything about entAliasMappingTable and ifIndex renumbering?] 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 row is indexed by an arbitrary, small integer, and contains a 246 description and type of the physical entity. It also optionally 247 contains the index number of another row in the same table indicating a 248 containment relationship between the two. 250 The entLogicalTable contains one row per logical entity. Each row is 251 indexed by an arbitrary, small integer and contains a name, description, 252 and type of the logical entity. It also contains information to allow 253 Draft Entity MIB January 14, 1996 255 SNMPv2 and/or SNMPv1 access to the MIB information for the logical 256 entity. 258 The entLPMappingTable contains mappings between entLogicalIndex values 259 (logical entities) and entPhysicalIndex values (the physical components 260 supporting that entity). A logical entity can map to more than one 261 physical component, and more than one logical entity can map to (share) 262 the same physical component. 264 The entAliasMappingTable contains mappings between entPhysicalIndex, 265 entLogicalIndex pairs and 'alias' object identifier values. This allows 266 resources managed with other MIBs (e.g. repeater ports, bridge ports, 267 physical and logical interfaces) to be identified in the physical entity 268 hierarchy. Note that each alias identifier is only relevant in a 269 particular naming scope. 271 The entPhysicalContainsTable contains simple mappings between 272 'entPhysicalContainsIn' values for each container/containee relationship 273 in the managed system. The indexing of this table allows an NMS to 274 quickly discover the 'entPhysicalIndex' values for all children of a 275 given physical entity. 277 3.9. Multiple Agents 279 Even though a primary motivation for this MIB is to represent the 280 multiple logical entities supported by a single agent, it is also 281 possible to use it to represent multiple logical entities supported by 282 multiple agents (in the same "overall" physical entity). Indeed, it is 283 implicit in the SNMP architecture, that the number of agents is 284 transparent to a network management station. 286 Draft Entity MIB January 14, 1996 288 4. Definitions 290 ENTITY-MIB DEFINITIONS ::= BEGIN 292 IMPORTS 293 MODULE-IDENTITY, OBJECT-TYPE, experimental, 294 IpAddress 295 FROM SNMPv2-SMI 296 DisplayString, AutonomousType, TruthValue 297 FROM SNMPv2-TC 298 Context 299 FROM SNMPv2-PARTY-MIB 300 MODULE-COMPLIANCE, OBJECT-GROUP 301 FROM SNMPv2-CONF; 303 entityMIB MODULE-IDENTITY 304 LAST-UPDATED "9601020000Z" 305 ORGANIZATION "IETF ENTMIB Working Group" 306 CONTACT-INFO 307 " Keith McCloghrie 308 Cisco Systems Inc. 309 170 West Tasman Drive 310 San Jose, CA 95134 311 408-526-5260 312 kzm@cisco.com 314 Andy Bierman 315 Bierman Consulting 316 1200 Sagamore Lane 317 Ventura, CA 93001 318 805-648-2028 319 abierman@west.net" 320 DESCRIPTION 321 "The MIB module for representing multiple logical 322 entities supported by a single SNMP agent." 323 ::= { experimental xx } 325 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 326 Draft Entity MIB January 14, 1996 328 -- The Physical Entity Table 330 entPhysicalTable OBJECT-TYPE 331 SYNTAX SEQUENCE OF EntPhysicalEntry 332 MAX-ACCESS not-accessible 333 STATUS current 334 DESCRIPTION 335 "This table contains one row per physical entity. There is 336 always at least one row for an 'overall' physical entity." 337 ::= { entityMIBObjects 1 } 339 entPhysicalEntry OBJECT-TYPE 340 SYNTAX EntPhysicalEntry 341 MAX-ACCESS not-accessible 342 STATUS current 343 DESCRIPTION 344 "Information about a particular physical entity. An agent 345 is expected to represent physical components in as much 346 detail as possible. If more than one agent within a chassis 347 implements the Entity MIB, the information retrieved from 348 each agent must be consistent, but not necessarily 349 identical." 350 INDEX { entPhysicalIndex } 351 ::= { entPhysicalTable 1 } 353 EntPhysicalEntry ::= SEQUENCE { 354 entPhysicalIndex INTEGER, 355 entPhysicalDescr DisplayString, 356 entPhysicalVendorType AutonomousType, 357 entPhysicalContainedIn INTEGER, 358 entPhysicalClass 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 entPhysicalDescr OBJECT-TYPE 373 Draft Entity MIB January 14, 1996 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 the 394 entPhysicalClass object should be used to indicate the 395 general type 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 14, 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), 430 port(10) 431 -- some others here that I forgot? 432 } 433 MAX-ACCESS read-only 434 STATUS current 435 DESCRIPTION 436 "An indication of the general hardware type of the physical 437 entity. 439 An agent should set this object to the standard enumeration 440 value which most accurately indicates the general class of 441 the physical entity, or the primary class if there is more 442 than one. 444 If no appropriate standard registration identifier exists 445 for this physical entity, then the value 'other(1)' is 446 returned. If the value is unknown by this agent, then the 447 value 'unknown(2)' is returned." 448 ::= { entPhysicalEntry 5 } 450 Draft Entity MIB January 14, 1996 452 -- The Logical Entity Table 453 entLogicalTable OBJECT-TYPE 454 SYNTAX SEQUENCE OF EntLogicalEntry 455 MAX-ACCESS not-accessible 456 STATUS current 457 DESCRIPTION 458 "This table contains one row per logical entity." 459 ::= { entityMIBObjects 2 } 461 entLogicalEntry OBJECT-TYPE 462 SYNTAX EntLogicalEntry 463 MAX-ACCESS not-accessible 464 STATUS current 465 DESCRIPTION 466 "Information about a particular logical entity. Entities 467 may be managed by this agent or other SNMP agents (possibly) 468 in the same chassis." 469 INDEX { entLogicalIndex } 470 ::= { entLogicalTable 1 } 472 EntLogicalEntry ::= SEQUENCE { 473 entLogicalIndex INTEGER, 474 entLogicalDescr DisplayString, 475 entLogicalType AutonomousType, 476 entLogicalCommunity OCTET STRING, 477 entLogicalIpAddress IpAddress 478 } 480 entLogicalIndex OBJECT-TYPE 481 SYNTAX INTEGER (1..2147483647) 482 MAX-ACCESS not-accessible 483 STATUS current 484 DESCRIPTION 485 "The value of this object uniquely identifies the logical 486 entity. The value is a small positive integer; index values 487 for different logical entities are are not necessarily 488 contiguous." 489 ::= { entLogicalEntry 1 } 491 Draft Entity MIB January 14, 1996 493 entLogicalDescr OBJECT-TYPE 494 SYNTAX DisplayString 495 MAX-ACCESS read-only 496 STATUS current 497 DESCRIPTION 498 "A textual description of logical entity." 499 ::= { entLogicalEntry 2 } 501 entLogicalType OBJECT-TYPE 502 SYNTAX AutonomousType 503 MAX-ACCESS read-only 504 STATUS current 505 DESCRIPTION 506 "An indication of the type of logical entity. This will 507 typically be the OBJECT IDENTIFIER name of the node in the 508 SMI's naming hierarchy which represents the major MIB 509 module, or the majority of the MIB modules, supported by the 510 logical entity. For example: 511 a logical entity of a regular host/router -> mib-2 512 a logical entity of a 802.1d bridge -> dot1dBridge 513 a logical entity of a 802.3 repeater -> 514 snmpDot3RptrMgmt" 515 ::= { entLogicalEntry 3 } 517 entLogicalCommunity OBJECT-TYPE 518 SYNTAX OCTET STRING 519 MAX-ACCESS read-only 520 STATUS current 521 DESCRIPTION 522 "A SNMPv1 community-string which can be used to access 523 detailed management information for this logical entity. 524 The agent should allow read access with this community 525 string (to an appropriate subset of all managed objects) and 526 may also choose to return a community string based on the 527 privileges of the request used to read this object (e.g. 528 only return a string having read-write privileges when 529 accessed with read-write privileges). 531 A conformant SNMP agent may wish to conserve naming scopes 532 by representing multiple logical entities in a single 'main' 533 naming scope. This is possible when the logical entities 534 represented by the same value of entLogicalCommunity have no 535 object instances in common. For example, 'bridge1' and 536 'repeater1' may be part of the main naming scope, but two 537 additional community strings are needed to represent 539 Draft Entity MIB January 14, 1996 541 'bridge2' and 'repeater2'. 543 Logical entities 'bridge1' and 'repeater1' would be 544 represented by sysOREntries associated with the 'main' 545 naming scope. 547 For agents not accessible via SNMPv1, the value of this 548 object is the empty-string." 549 ::= { entLogicalEntry 4 } 551 entLogicalIpAddress OBJECT-TYPE 552 SYNTAX IpAddress 553 MAX-ACCESS read-only 554 STATUS current 555 DESCRIPTION 556 "The IP-address of the SNMPv1 agent from which detailed 557 management information for this logical entity can be 558 obtained. For agents not accessible via SNMPv1, the value 559 of this object is 0.0.0.0." 560 ::= { entLogicalEntry 5 } 562 Draft Entity MIB January 14, 1996 564 -- entLPMappingTable: for each entity index, there are N 565 -- rows, each representing a physical component 566 -- that is associated with the indicated entity 567 -- 568 -- entity to component table 569 entLPMappingTable OBJECT-TYPE 570 SYNTAX SEQUENCE OF EntLPMappingEntry 571 MAX-ACCESS not-accessible 572 STATUS current 573 DESCRIPTION 574 "This table contains zero or more rows of logical entity to 575 physical equipment associations." 576 ::= { entityMIBObjects 3 } 578 entLPMappingEntry OBJECT-TYPE 579 SYNTAX EntLPMappingEntry 580 MAX-ACCESS not-accessible 581 STATUS current 582 DESCRIPTION 583 "Information about a particular logical entity to physical 584 equipment binding." 585 INDEX { entLogicalIndex, entLPPhysicalIndex } 586 ::= { entLPMappingTable 1 } 588 EntLPMappingEntry ::= SEQUENCE { 589 entLPPhysicalIndex INTEGER 590 } 592 entLPPhysicalIndex OBJECT-TYPE 593 SYNTAX INTEGER (1..2147483647) 594 MAX-ACCESS read-only 595 STATUS current 596 DESCRIPTION 597 "The value of this object identifies a particular 598 entPhysicalEntry associated with the indicated 599 entLogicalEntity." 600 ::= { entLPMappingEntry 1 } 602 Draft Entity MIB January 14, 1996 604 -- logical entity/component to alias table 605 entAliasMappingTable OBJECT-TYPE 606 SYNTAX SEQUENCE OF EntAliasMappingEntry 607 MAX-ACCESS not-accessible 608 STATUS current 609 DESCRIPTION 610 "This table contains zero or more rows of logical entity, 611 and physical component to external identifier associations." 612 ::= { entityMIBObjects 4 } 614 entAliasMappingEntry OBJECT-TYPE 615 SYNTAX EntAliasMappingEntry 616 MAX-ACCESS not-accessible 617 STATUS current 618 DESCRIPTION 619 "Information about a particular physical equipment, logical 620 entity to external identifier binding. Note that the same 621 physical component-logical entity pair may have an arbitrary 622 number of external identifier (alias) bindings." 623 INDEX { entLogicalIndex, entPhysicalIndex, entAliasMappingIndex } 624 ::= { entAliasMappingTable 1 } 626 EntAliasMappingEntry ::= SEQUENCE { 627 entAliasMappingIndex INTEGER, 628 entAliasIdentifier OBJECT IDENTIFIER 629 } 631 entAliasMappingIndex OBJECT-TYPE 632 SYNTAX INTEGER (1..2147483647) 633 MAX-ACCESS not-accessible 634 STATUS current 635 DESCRIPTION 636 "The value of this object uniquely identifies the particular 637 binding for a specific logical entity on a particular 638 physical component. The value is a small positive integer; 639 index values for different entAlias mappings are not 640 necessarily contiguous." 641 ::= { entAliasMappingEntry 1 } 643 entAliasIdentifier OBJECT-TYPE 644 SYNTAX OBJECT IDENTIFIER 645 MAX-ACCESS read-only 646 STATUS current 647 DESCRIPTION 648 "The value of this object identifies a particular MIB 650 Draft Entity MIB January 14, 1996 652 instance associated with the indicated entPhysicalEntry and 653 entLogicalEntry pair. 655 For example, suppose a physical port was represented by 656 entPhysicalEntry.3, and entLogicalEntry.1 existed for a 657 repeater, entLogicalEntry.2 existed for a bridge, and the 658 bridge port was also represented in the ifTable. Then there 659 might be three associated instances of entAliasIdentifier: 660 entAliasIdentifier.3.1.1 == rptrPortGroupIndex.5.2 661 entAliasIdentifier.3.2.1 == dot1dBasePort.2 662 entAliasIdentifier.3.2.2 == ifIndex.2 " 663 ::= { entAliasMappingEntry 2 } 665 Draft Entity MIB January 14, 1996 667 -- physical mapping table 668 entPhysicalContainsTable OBJECT-TYPE 669 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 670 MAX-ACCESS not-accessible 671 STATUS current 672 DESCRIPTION 673 "A table which exposes the container/containee relationships 674 between physical entities." 675 ::= { entityMIBObjects 5 } 677 entPhysicalContainsEntry OBJECT-TYPE 678 SYNTAX EntPhysicalContainsEntry 679 MAX-ACCESS not-accessible 680 STATUS current 681 DESCRIPTION 682 "A single container/containee relationship." 683 INDEX { entPhysicalIndex, entPhysicalChildIndex } 684 ::= { entPhysicalContainsTable 1 } 686 EntPhysicalContainsEntry ::= SEQUENCE { 687 entPhysicalChildIndex INTEGER 688 } 690 entPhysicalChildIndex OBJECT-TYPE 691 SYNTAX INTEGER (1..2147483647) 692 MAX-ACCESS read-only 693 STATUS current 694 DESCRIPTION 695 "The value of entPhysicalIndex for the contained physical 696 entity." 697 ::= { entPhysicalContainsEntry 1 } 699 Draft Entity MIB January 14, 1996 701 -- last change timestamp for the whole MIB 702 entLastConfigChangeTime OBJECT-TYPE 703 SYNTAX Timestamp 704 MAX-ACCESS read-only 705 STATUS current 706 DESCRIPTION 707 "The value of sysUpTime at the time any of these events 708 occur: 709 * a conceptual row is created or deleted in any of these tables: 710 - entPhysicalTable 711 - entLogicalTable 712 - entLPMappingTable 713 - entAliasMappingTable 714 - entPhysicalContainsTable 716 * any instance in the following list of objects changes value: 717 - entPhysicalDescr 718 - entPhysicalVendorType 719 - entPhysicalContainedIn 720 - entPhysicalClass 721 - entLogicalDescr 722 - entLogicalType 723 - entLogicalCommunity 724 - entLogicalIpAddress 725 - entAliasIdentifier 726 " 727 ::= { entityMIBObjects 6 } 729 Draft Entity MIB January 14, 1996 731 -- Entity MIB Trap Definitions 732 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 734 entConfigChange NOTIFICATION-TYPE 735 OBJECTS { 736 entLastChangeTime 737 } 738 STATUS current 739 DESCRIPTION 740 "An entConfigChange trap is sent when the value of 741 entLastConfigChangeTime changes. It can be utilized by an 742 NMS to trigger logical/physical entity table maintenance 743 polls. This trap is throttled by the agent. 745 The value of entLastChangeTime at the time the config- 746 change-event is generated by the agent is encoded at the 747 only var-bind in the trap. 749 An agent must take care not to generate more than one 750 entLastChangeTime 'trap-event' in a five second period (a 751 'trap-event' is the transmission of a single trap PDU to a 752 list of trap receivers). If additional configuration 753 changes occur within the five second 'throttling' period, 754 then the agent should discard all but the most recent trap- 755 event (if any), rather than queueing them and generating 756 trap-events (one every five seconds) in sequence. " 757 ::= { entityMIBTraps 1 } 759 Draft Entity MIB January 14, 1996 761 -- conformance information 762 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 764 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 765 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 767 -- compliance statements 769 entityCompliance MODULE-COMPLIANCE 770 STATUS current 771 DESCRIPTION 772 "The compliance statement for SNMPv2 entities 773 which implement the Entity MIB." 774 MODULE -- this module 775 MANDATORY-GROUPS { entityGroup } 776 ::= { entityCompliances 1 } 778 -- units of conformance 780 entityGroup OBJECT-GROUP 781 OBJECTS { entPhysicalDescr, 782 entPhysicalVendorType, 783 entPhysicalContainedIn, 784 entPhysicalClass, 785 entLogicalDescr, 786 entLogicalType, 787 entLogicalCommunity, 788 entLogicalIpAddress, 789 entLPPhysicalIndex, 790 entAliasIdentifier, 791 entPhysicalChildIndex, 792 entLastChangeTime, 793 entConfigChange -- separate conformance group needed for trap?? 794 } 795 STATUS current 796 DESCRIPTION 797 "The collection of objects which are used to 798 represent the multiple logical entities, 799 physical components, interfaces, and port 800 alias identifiers for which a single agent 801 provides MIB information." 802 ::= { entityGroups 1 } 804 END 805 Draft Entity MIB January 14, 1996 807 5. Usage Examples 809 5.1. Router/Bridge 811 A bi-lingual (SNMPv1 and SNMPv2) router containing two slots. Each slot 812 contains a 3 port router/bridge module. Each port is represented in the 813 ifTable. There are two logical instances of OSPF running and two 814 logical bridges: 816 Physical entities -- entPhysicalTable: 817 1 Field-replaceable physical chassis: 818 entPhysicalDescr.1 == "Acme Chassis Model 100" 819 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 820 entPhysicalContainedIn.1 == 0 821 entPhysicalClass.1 == chassis(3) 823 2 slots within the chassis: 824 entPhysicalDescr.2 == "Acme Router Chassis Slot 1" 825 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 826 entPhysicalContainedIn.2 == 1 827 entPhysicalClass.2 == container(5) 829 entPhysicalDescr.3 == "Acme Router Chassis Slot 2" 830 entPhysicalVendorType.3 == acmeProducts.slotTypes.1 831 entPhysicalContainedIn.3 == 1 832 entPhysicalClass.3 == container(5) 834 2 Field-replaceable modules: 835 Slot 1 contains a module with 3 ports: 836 entPhysicalDescr.4 == "Acme Router Module Model 10" 837 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 838 entPhysicalContainedIn.4 == 2 839 entPhysicalClass.4 == module(9) 841 entPhysicalDescr.5 == "Acme Router Ethernet Port 1" 842 entPhysicalVendorType.5 == acmeProducts.portTypes.2 843 entPhysicalContainedIn.5 == 4 844 entPhysicalClass.5 == port(10) 846 entPhysicalDescr.6 == "Acme Router Ethernet Port 2" 847 entPhysicalVendorType.6 == acmeProducts.portTypes.2 848 entPhysicalContainedIn.6 == 4 849 entPhysicalClass.6 == port(10) 851 entPhysicalDescr.7 == "Acme Router Fddi Port 3" 853 Draft Entity MIB January 14, 1996 855 entPhysicalVendorType.7 == acmeProducts.portTypes.3 856 entPhysicalContainedIn.7 == 4 857 entPhysicalClass.7 == port(10) 859 Slot 2 contains another 3-port module: 860 entPhysicalDescr.8 == "Acme Router Module Model 11" 861 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 862 entPhysicalContainedIn.8 == 3 863 entPhysicalClass.8 == module(9) 865 entPhysicalDescr.9 == "Acme Router Fddi Port 1" 866 entPhysicalVendorType.9 == acmeProducts.portTypes.3 867 entPhysicalContainedIn.9 == 8 868 entPhysicalClass.9 == port(10) 870 entPhysicalDescr.10 == "Acme Router Ethernet Port 2" 871 entPhysicalVendorType.10 == acmeProducts.portTypes.2 872 entPhysicalContainedIn.10 == 8 873 entPhysicalClass.10 == port(10) 875 entPhysicalDescr.11 == "Acme Router Ethernet Port 3" 876 entPhysicalVendorType.11 == acmeProducts.portTypes.2 877 entPhysicalContainedIn.11 == 8 878 entPhysicalClass.11 == port(10) 880 Logical entities -- entLogicalTable 881 2 OSPF instances: 882 entLogicalDescr.1 == "ospf-1" 883 entLogicalType.1 == ospf 884 entLogicalCommunity.1 == "public-ospf1" 885 entLogicalIpAddress.1 == 124.125.126.127 887 entLogicalDescr.2 == "ospf-2" 888 entLogicalType.2 == ospf 889 entLogicalCommunity.2 == "public-ospf2" 890 entLogicalIpAddress.2 == 124.125.126.127 892 2 logical bridges: 893 entLogicalDescr.3 == "bridge1" 894 entLogicalType.3 == dod1dBridge 895 entLogicalCommunity.3 == "public-bridge1" 896 entLogicalIpAddress.3 == 124.125.126.127 898 entLogicalDescr.4 == "bridge2" 899 entLogicalType.4 == dod1dBridge 901 Draft Entity MIB January 14, 1996 903 entLogicalCommunity.4 == "public-bridge2" 904 entLogicalIpAddress.4 == 124.125.126.127 906 Logical to Physical Mappings: 907 1st OSPF instance: uses module 1-port 1 908 entLPPhysicalIndex.1.5 == 5 910 2nd OSPF instance: uses module 2-port 1 911 entLPPhysicalIndex.2.9 == 9 913 1st bridge group: uses module 1, all ports 914 entLPPhysicalIndex.3.5 == 5 915 entLPPhysicalIndex.3.6 == 6 916 entLPPhysicalIndex.3.7 == 7 918 2nd bridge group: uses module 2, all ports 919 entLPPhysicalIndex.4.9 == 9 920 entLPPhysicalIndex.4.10 == 10 921 entLPPhysicalIndex.4.11 == 11 923 Logical to Physical to Alias Mappings -- entAliasMappingTable: 924 Bridge 1 uses Ports 1..3 on Slot 1 925 entAliasIdentifier.3.5.1 == dot1dBasePort.1 926 entAliasIdentifier.3.5.2 == ifIndex.1 927 entAliasIdentifier.3.6.1 == dot1dBasePort.2 928 entAliasIdentifier.3.6.2 == ifIndex.2 929 entAliasIdentifier.3.7.1 == dot1dBasePort.3 930 entAliasIdentifier.3.7.2 == ifIndex.3 932 Bridge 2 uses Ports 1..3 on Slot 2; uses same Bridge MIB and ifIndex 933 values as Bridge 1, but in a different context, and representing 934 different physical ports: 935 entAliasIdentifier.4.9.1 == dot1dBasePort.1 936 entAliasIdentifier.4.9.2 == ifIndex.1 937 entAliasIdentifier.4.10.1 == dot1dBasePort.2 938 entAliasIdentifier.4.10.2 == ifIndex.2 939 entAliasIdentifier.4.11.1 == dot1dBasePort.3 940 entAliasIdentifier.4.11.2 == ifIndex.3 942 Physical Containment Tree -- entPhysicalContainsTable 943 chassis has two containers: 944 entPhysicalChildIndex.1.2 = 2 945 entPhysicalChildIndex.1.3 = 3 947 container 1 has a module: 949 Draft Entity MIB January 14, 1996 951 entPhysicalChildIndex.2.4 = 4 953 container 2 has a module 954 entPhysicalChildIndex.3.8 = 8 956 module 1 has some ports: 957 entPhysicalChildIndex.4.5 = 5 958 entPhysicalChildIndex.4.6 = 6 959 entPhysicalChildIndex.4.7 = 7 961 module 2 has some ports: 962 entPhysicalChildIndex.8.9 = 9 963 entPhysicalChildIndex.8.10 = 10 964 entPhysicalChildIndex.1.11 = 11 966 5.2. Repeaters 968 An SNMPv1 only, 3-slot Hub with 2 backplane ethernet segments. Slot 969 three is empty, and the remaining slots contain ethernet repeater 970 modules. 972 Physical entities -- entPhysicalTable: 973 1 Field-replaceable physical chassis: 974 entPhysicalDescr.1 == "Acme Repeater Chassis Model 110" 975 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 976 entPhysicalContainedIn.1 == 0 977 entPhysicalClass.1 == chassis(3) 979 2 Chassis Ethernet Backplanes: 980 entPhysicalDescr.2 == "Ethernet Backplane 1" 981 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 982 entPhysicalContainedIn.2 == 1 983 entPhysicalClass.2 == backplane(4) 985 entPhysicalDescr.3 == "Ethernet Backplane 2" 986 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 987 entPhysicalContainedIn.3 == 1 988 entPhysicalClass.3 == backplane(4) 990 3 slots within the chassis: 991 entPhysicalDescr.4 == "Acme Hub Slot 1" 992 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 993 entPhysicalContainedIn.4 == 1 994 entPhysicalClass.4 == container(5) 996 Draft Entity MIB January 14, 1996 998 entPhysicalDescr.5 == "Acme Hub Slot 2" 999 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 1000 entPhysicalContainedIn.5 == 1 1001 entPhysicalClass.5 == container(5) 1003 entPhysicalDescr.6 == "Acme Hub Slot 3" 1004 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 1005 entPhysicalContainedIn.6 == 1 1006 entPhysicalClass.6 == container(5) 1008 Slot 1 contains a plug-in module with 4 10-BaseT ports: 1009 entPhysicalDescr.7 == "10Base-T Module Model 14" 1010 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 1011 entPhysicalContainedIn.7 == 4 1012 entPhysicalClass.7 == module(9) 1014 entPhysicalDescr.8 == "10Base-T Port 1" 1015 entPhysicalVendorType.8 == acmeProducts.portTypes.10 1016 entPhysicalContainedIn.8 == 7 1017 entPhysicalClass.8 == port(10) 1019 entPhysicalDescr.9 == "10Base-T Port 2" 1020 entPhysicalVendorType.9 == acmeProducts.portTypes.10 1021 entPhysicalContainedIn.9 == 7 1022 entPhysicalClass.9 == port(10) 1024 entPhysicalDescr.10 == "10Base-T Port 3" 1025 entPhysicalVendorType.10 == acmeProducts.portTypes.10 1026 entPhysicalContainedIn.10 == 7 1027 entPhysicalClass.10 == port(10) 1029 entPhysicalDescr.11 == "10Base-T Port 4" 1030 entPhysicalVendorType.11 == acmeProducts.portTypes.10 1031 entPhysicalContainedIn.11 == 7 1032 entPhysicalClass.11 == port(10) 1034 Slot 2 contains another ethernet module with 2 ports. 1035 entPhysicalDescr.12 == "Acme 10Base-T Module Model 4" 1036 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 1037 entPhysicalContainedIn.12 = 5 1038 entPhysicalClass.12 == module(9) 1040 entPhysicalDescr.13 == "802.3 AUI Port 1" 1041 entPhysicalVendorType.13 == acmeProducts.portTypes.11 1042 entPhysicalContainedIn.13 == 12 1044 Draft Entity MIB January 14, 1996 1046 entPhysicalClass.13 == port(10) 1048 entPhysicalDescr.14 == "10Base-T Port 2" 1049 entPhysicalVendorType.14 == acmeProducts.portTypes.10 1050 entPhysicalContainedIn.14 == 12 1051 entPhysicalClass.14 == port(10) 1053 Logical entities -- entLogicalTable 1054 Repeater 1--comprised of any ports attached to backplane 1 1055 entLogicalDescr.1 == "repeater1" 1056 entLogicalType.1 == snmpDot3RptrMgt 1057 entLogicalCommunity.1 "public-repeater1" 1058 entLogicalIpAddress.1 124.125.126.128 1060 Repeater 2--comprised of any ports attached to backplane 2: 1061 entLogicalDescr.2 == "repeater2" 1062 entLogicalType.2 == snmpDot3RptrMgt 1063 entLogicalCommunity.2 == "public-repeater2" 1064 entLogicalIpAddress.2 == 124.125.126.128 1066 Logical to Physical Mappings -- entLPMappingTable: 1068 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 1069 entLPPhysicalIndex.1.2 == 2 1070 entLPPhysicalIndex.1.8 == 8 1071 entLPPhysicalIndex.1.9 == 9 1072 entLPPhysicalIndex.1.13 == 13 1074 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 1075 entLPPhysicalIndex.2.3 == 3 1076 entLPPhysicalIndex.2.10 == 10 1077 entLPPhysicalIndex.2.11 == 11 1078 entLPPhysicalIndex.2.14 == 14 1080 Logical to Physical to Alias Mappings -- entAliasMappingTable: 1081 repeater1 uses slot 1-ports 1 & 2, slot 2-port 1 1082 entAliasIdentifier.1.8.1 == rptrPortGroupIndex.1.1 1083 entAliasIdentifier.1.9.1 == rptrPortGroupIndex.1.2 1084 entAliasIdentifier.1.13.1 == rptrPortGroupIndex.2.1 1086 repeater2 uses slot 1-ports 3 & 4, slot 2-port 2 1087 entAliasIdentifier.2.10.1 == rptrPortGroupIndex.1.3 1088 entAliasIdentifier.2.11.1 == rptrPortGroupIndex.1.4 1089 entAliasIdentifier.2.14.1 == rptrPortGroupIndex.2.2 1091 Draft Entity MIB January 14, 1996 1093 Physical Containment Tree -- entPhysicalContainsTable 1095 chassis has two backplanes and three containers: 1096 entPhysicalChildIndex.1.2 = 2 1097 entPhysicalChildIndex.1.3 = 3 1098 entPhysicalChildIndex.1.4 = 4 1099 entPhysicalChildIndex.1.5 = 5 1100 entPhysicalChildIndex.1.6 = 6 1102 container 1 has a module: 1103 entPhysicalChildIndex.4.7 = 7 1105 container 2 has a module 1106 entPhysicalChildIndex.5.12 = 12 1107 -- container 3 is empty 1109 module 1 has some ports: 1110 entPhysicalChildIndex.7.8 = 8 1111 entPhysicalChildIndex.7.9 = 9 1112 entPhysicalChildIndex.7.10 = 10 1113 entPhysicalChildIndex.7.11 = 11 1115 module 2 has some ports: 1116 entPhysicalChildIndex.12.13 = 13 1117 entPhysicalChildIndex.12.14 = 14 1119 Draft Entity MIB January 14, 1996 1121 6. Acknowledgements 1123 This document was produced by the IETF Entity MIB Working Group. 1125 Draft Entity MIB January 14, 1996 1127 7. References 1129 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1130 of Management Information for version 2 of the Simple Network 1131 Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes 1132 LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1133 University, April 1993. 1135 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 1136 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1137 RFC 1213, Hughes LAN Systems, Performance Systems International, 1138 March 1991. 1140 [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 1141 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, 1142 Trusted Information Systems, Hughes LAN Systems, April 1993. 1144 [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1145 Operations for version 2 of the Simple Network Management Protocol 1146 (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover 1147 Beach Consulting, Inc., Carnegie Mellon University, April 1993. 1149 [5] McCloghrie, K., and J. Galvin, "Party MIB for Version 2 of the 1150 Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN 1151 Systems, Trusted Information Systems, April 1993. 1153 [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1154 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1155 International, MIT Laboratory for Computer Science, May 1990. 1157 [7] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 1158 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 1160 Draft Entity MIB January 14, 1996 1162 8. Security Considerations 1164 Security issues are not discussed in this memo. 1166 9. Authors' Addresses 1168 Keith McCloghrie 1169 cisco Systems, Inc. 1170 170 West Tasman Drive 1171 San Jose, CA 95134 1172 Phone: 408-526-5260 1173 Email: kzm@cisco.com 1175 Andy Bierman 1176 Bierman Consulting 1177 1200 Sagamore Lane 1178 Ventura, CA 93001 1179 Phone: 805-648-2028 1180 Email: abierman@west.net 1182 Draft Entity MIB January 14, 1996 1184 Table of Contents 1186 1 Introduction .................................................... 2 1187 2 The SNMPv2 Network Management Framework ......................... 3 1188 2.1 Object Definitions ............................................ 3 1189 3 Overview ........................................................ 4 1190 3.1 Terms ......................................................... 4 1191 3.2 Relationship to Community Strings ............................. 6 1192 3.3 Relationship to Proxy Mechanisms .............................. 6 1193 3.4 Relationship to a Chassis MIB ................................. 6 1194 3.5 Relationship to the Interfaces MIB ............................ 6 1195 3.6 Relationship to the Other MIBs ................................ 7 1196 3.7 Re-Configuration of Entities .................................. 7 1197 3.8 MIB Structure ................................................. 7 1198 3.9 Multiple Agents ............................................... 8 1199 4 Definitions ..................................................... 9 1200 5 Usage Examples .................................................. 23 1201 5.1 Router/Bridge ................................................. 23 1202 5.2 Repeaters ..................................................... 26 1203 6 Acknowledgements ................................................ 30 1204 7 References ...................................................... 31 1205 8 Security Considerations ......................................... 32 1206 9 Authors' Addresses .............................................. 32