idnits 2.17.1 draft-ietf-ptopomib-mib-00.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 5 characters in excess of 72. 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 (30 July 1997) is 9766 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) == Outdated reference: A later version (-01) exists of draft-bierman-entmib-compid-00 -- Possible downref: Normative reference to a draft: ref. 'ENTITY-EXT' ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Obsolete normative reference: RFC 1573 (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2021 (Obsoleted by RFC 4502) ** Obsolete normative reference: RFC 2037 (Obsoleted by RFC 2737) Summary: 20 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 3 Physical Topology MIB 5 30 July 1997 7 Andy Bierman 8 Cisco Systems 9 abierman@cisco.com 11 Kendall S. Jones 12 Bay Networks 13 kjones@baynetworks.com 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 1. Introduction 34 This memo defines an experimental portion of the Management Information 35 Base (MIB) for use with network management protocols in the Internet 36 community. In particular, it describes managed objects used for 37 managing physical topology identification and discovery. 39 Draft Physical Topology MIB July 1997 41 2. The SNMP Network Management Framework 43 The SNMP Network Management Framework presently consists of three major 44 components. They are: 46 o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for 47 describing and naming objects for the purpose of management. 49 o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed 50 objects for the Internet suite of protocols. 52 o the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the 53 protocol for accessing managed information. 55 Textual conventions are defined in RFC 1903 [RFC1903], and conformance 56 statements are defined in RFC 1904 [RFC1904]. 58 The Framework permits new objects to be defined for the purpose of 59 experimentation and evaluation. 61 This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A 62 semantically identical MIB conforming to the SNMPv1 SMI can be produced 63 through the appropriate translation. ,lp 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 3. Overview 78 There is a need for a standardized means of representing the physical 79 network connections pertaining to a given management domain. A 80 standardized discovery mechanism is also required to increase the 81 likelihood of multi-vendor interoperability of such physical topology 82 management information. 84 The scope of the physical topology (PTOPO) mechanism is the 85 identification of connections between two network ports. Network 86 Draft Physical Topology MIB July 1997 88 addresses of SNMP agents containing management information associated 89 with each port can also be identified. 91 3.1. Background and Concepts 93 The need to understand the physical relationships between devices in a 94 network has always been an important aspect of network management. With 95 the increasing complexity of multi-segment and multi-media hubs and 96 switching devices, and management applications that want to identify hot 97 spots in the network, isolate complex faults (such as configuration 98 problems) to the physical port, and manage virtual networks (VLANs), the 99 need for accurate, timely, and system wide physical topology is becoming 100 more and more critical to maintaining a mission critical network. 102 Most of today's management platforms do a good job at discovering the 103 logical topology at the network layer but do not help much in 104 understanding the actual physical interconnection. This is due to a 105 lack of standard topology mechanisms at the physical layer to collect 106 the physical topology information as well as a standard MIB to return 107 topology information to the management workstation. 109 Standard topology mechanisms exist for certain media types (such as 110 FDDI) and proprietary mechanisms exist for other media such as shared 111 media Ethernet, switched Ethernet, and Token Ring. While standardizing 112 these or other mechanisms for each of these technologies could be a 113 painstaking task, standardizing a common MIB and a topology framework 114 that allows co-existence of multiple topology mechanisms to populate 115 these MIBs can go a long way toward achieving the goal of providing 116 network-wide physical topology information at the network management 117 workstation. The topology framework should specify the core 118 requirements for topology mechanisms in order to provide the data 119 necessary to populate the common topology MIB. 121 These requirements form a set of guidelines to direct the eventual 122 standardization of a set of topology mechanisms for the various 123 communication media. In the meantime, the common MIB will allow 124 creation of physical topology databases which will allow applications to 125 provide value added services on top of this rich set of data. 127 3.2. Terms 129 Some terms are used throughout this document: 131 Physical Topology 132 Physical topology represents the topology model for layer 1 of the 134 Draft Physical Topology MIB July 1997 136 OSI stack - the physical layer. Physical topology consists of 137 identifying the devices on the network and how they are physically 138 interconnected. By definition of this document, physical topology 139 does not imply a physical relationship between ports on the same 140 device. Other means exist for determining these relationships 141 (e.g., Entity MIB). 143 Logical Topology 144 Logical topology indicates how devices are related based on some 145 system level attribute. Often this is based on the OSI 146 communication layer. For instance, network layer topology, or 147 layer 3 topology, uses network layer address hierarchies to 148 construct a topological relationship. Management platforms 149 typically present Layer-3-based topology. This is done by 150 'discovering' the IP addresses on a network and then grouping these 151 logically by the subnet portion of the address. Other logical 152 views of topology include layer-2 based views based on VLAN 153 membership, and higher layer views such as workgroup membership. 154 Most higher-layer topology views use network address or user name 155 to represent members of the topology space. 157 Chassis 158 A chassis is a physical component which contains other physical 159 components. It is identified by an entPhysicalEntry with an 160 entPhysicalClass value of 'chassis(3)' and an 161 entPhysicalContainedIn value of zero. A chassis identifier 162 consists of a globally unique DisplayString. 164 Local Chassis 165 The particular chassis containing the SNMP agent implementing the 166 PTOPO MIB. 168 Port 169 A port is a physical component which can be connected to another 170 port through some medium. It is identified by an entPhysicalEntry 171 with an entPhysicalClass value of 'port(10)'. A port identifier 172 consists of a DisplayString which must be unique within the context 173 of the chassis which contains the port. 175 Connection Endpoint 176 A connection endpoint consists of a physical port, which is 177 contained within a single physical chassis. 179 Connection Endpoint Identifier 180 A connection endpoint is identified by a globally unique chassis 182 Draft Physical Topology MIB July 1997 184 identifier and a port identifier unique within the associated 185 chassis. 187 Connection 188 A connection consists of two physical ports, and the attached 189 physical medium, configured for the purpose of transferring network 190 traffic between the ports. A connection is identified by its 191 endpoint identifiers. 193 Non-local Connection 194 A connection for which neither endpoint is located on the local 195 chassis. 197 Cloud 198 A cloud identifies a portion of the topology for which insufficient 199 information is known to completely infer the interconnection of 200 devices that make up that portion of the topology. 202 3.3. Functionality Goals 204 While the framework presented here is focused on physical topology, it 205 may well be that the topology mechanisms and MIB described could be 206 extended to include logical topology information as well. That is not a 207 focus of this memo at this time, although some consideration may be 208 given to the framework itself and some notes may be included within this 209 memo. They will be clearly identified as work for further study. 211 The following goals can be described for the physical topology 212 framework. 214 - Develop a common MIB that represents the physical topology 215 information available to any one agent in the network. The MIB 216 should provide enough topology information to allow a management 217 workstation to navigate across agents to build a complete physical 218 topology for an arbitrarily large network. 220 - Provide a set of requirements for topology mechanisms that can 221 populate the agent MIBs. These requirements should allow for many 222 different standard and non-standard topology mechanisms to be used 223 within a given network, with clear rules describing how these 224 mechanisms should interact. 226 - Specify, where appropriate, topology mechanisms for specific media 227 types. Where standard or industry-accepted mechanisms exist, 229 Draft Physical Topology MIB July 1997 231 indicate how these mechanisms can be used to populate the topology 232 MIBs. 234 - Provide a description of the management station procedures to 235 navigate among topology agents and gather topology information. 237 3.4. Design Goals 239 Several factors influenced the design of this physical topology 240 function: 242 - Simplicity 243 The physical topology discovery function should be as simple as 244 possible, exposing only the information needed to identify 245 connection endpoints and the SNMP agent(s) associated with each 246 connection endpoint. 248 - Completeness 249 At least one standard discovery protocol capable of supporting the 250 standard physical topology MIB must be defined. Multi-vendor 251 interoperability will not be achievable unless a simple and 252 extensible discovery protocol is available. 254 - No Functional Overlap 255 Existing standard MIBs should be utilized whenever possible. 256 Physical topology information is tightly coupled to functionality 257 found in the Interfaces MIB [RFC1573] and Entity MIB [RFC2037]. 258 New physical topology MIB objects should not duplicate these MIBs. 260 - Identifier Stability 261 Connection endpoint identifiers must be persistent (i.e. stable 262 across device reboots). Dynamic primary key objects like ifIndex 263 and entPhysicalIndex are not suitable for table indices in a 264 physical topology MIB that is replicated and distributed throughout 265 a managed system. 267 - Identifier Flexibility 268 Persistent string-based component identifiers should be supported 269 from many sources. Chassis identifiers may be found in the Entity 270 MIB, and port identifiers may be found in the Interfaces MIB or 271 Entity MIB. 273 - Partial Topology Support 274 Physical topology data for remote components may only be partially 275 available to an agent. An enumerated INTEGER hierarchy of 277 Draft Physical Topology MIB July 1997 279 component identifier types allows for incomplete physical 280 connection identifier information to be substituted with secondary 281 information such as unicast source MAC address or network address 282 associated with a particular port. A PTOPO Agent maintains 283 information derived from the 'best' source of information for each 284 connection. If a 'better' identifier source is detected, the PTOPO 285 entries are updated accordingly. 287 - Low Polling Impact 288 Physical topology polling should be minimized through techniques 289 such as TimeFiltered data tables (from RMON-2 [RFC2021]), and 290 last-change notifications. 292 - Agent Location Neutrality 293 The MIB should allow a single agent to represent information about 294 non-local connections and connections terminating on the local 295 chassis with the same MIB objects. 297 4. Topology Framework 299 This section describes the physical topology framework in detail. 301 4.1. Framework Overview 303 Several components make up the framework for physical topology. 305 Devices 306 The network devices, along with their physical connectivity, make 307 up the physical topology. Some of these devices (but maybe not all) 308 provide management agents that report their local physical topology 309 information to a manager via the physical topology MIB. (Note that 310 implementation of the PTOPO MIB is required for entities which also 311 implement PDP.) 313 These devices include communication infrastructure devices, such as 314 hubs, switches, and routers, as well as 'leaf' devices such as 315 workstations, printers, and servers. Generally, user data passes 316 through infrastructure devices while leaf devices are sources and 317 sinks of data. Both types of devices may implement the physical 318 topology MIB, although implementation within leaf devices is much 319 less critical. 321 Draft Physical Topology MIB July 1997 323 Topology Mechanisms 324 A topology mechanism allows the management agents to collect the 325 information required to populate the topology MIB. Many instances 326 of a particular topology mechanism may be in use on a given 327 network, and many different mechanisms may be employed. In some 328 cases, multiple mechanisms may overlap across part of the physical 329 topology. Agents may need to be configured so that they know which 330 mechanism(s) are in use on any given portion of the network. Most 331 topology mechanisms need to be bounded to a subset of the network 332 to contain their impact on the network and allow the manager to 333 collect topology information for a limited subset of devices. 335 Most topology mechanisms are naturally bounded by the media on 336 which they run (e.g. FDDI topology mechanism) or by routers in the 337 network that intentionally block these mechanisms from crossing 338 into other parts of the network. 340 Local Topology Data and the Local Topology MIB 341 Each managed device collects physical topology information from the 342 network, based on the topology mechanisms it is configured to use. 343 The data represents this agent's view of the physical network and 344 may or may not provide enough data to understand the local physical 345 topology surrounding this agent. It may be necessary to gather 346 local topology data from a number of agents in order to completely 347 understand the local physical topology. Part of the local topology 348 data collected must include the identification of other local 349 agents which may contain additional topology information. The 350 definition of 'local' varies based on the topology mechanism or 351 mechanisms being used. 353 Manager Process 354 A manager is responsible for querying management agents to obtain 355 their local topology information and their knowledge of additional 356 local agents. The manager might need to query some or all local 357 agents to build an accurate view of the physical network. 359 4.1.1. Topology Mechanisms 361 A topology mechanism is a means, possibly requiring some sort of 362 protocol, by which devices determine topology information. The formal 363 requirement is that the mechanism should provide sufficient information 364 such that a manager can accurately determine the physical topology of a 365 set of devices by querying all of those devices for their local view of 366 the topology. In other words, the mechanism may not be robust enough to 367 allow the manager to accurately determine any part of the network by 368 Draft Physical Topology MIB July 1997 370 querying a single agent - rather it may need to query all agents to 371 understand the topology. 373 Topology mechanisms can be active or passive. Active mechanisms require 374 a device to send and receive topology protocol packets. These packets 375 provide the device ID of the source of the packet and may also indicate 376 out which port the packet was transmitted. When receiving these 377 packets, devices typically are required to identify on which port that 378 packet was received. 380 Passive mechanisms take advantage of data on the network to populate the 381 topology MIB. By maintaining a list of device identifiers seen on each 382 port of all devices in a network, it is possible to construct an 383 accurate physical topology of the network. 385 A device can act as a boundary device or an intermediate point of a 386 topology mechanism. If it is a boundary device, it will prevent active 387 topology mechanisms from passing through to other ports on that device. 388 Routers are often boundary devices for active topology mechanisms. 389 Boundary devices serve a critical role in containing topology mechanisms 390 within a set of devices. This limits the size of topology tables 391 maintained by the agent, reduces calculations required by managers, and 392 prevents proliferating topology protocols across the network. 394 It is possible to have ports that support more than one topology 395 mechanism. In general this simply allows the port to collect more 396 robust topology information which should allow the manager to create 397 more accurate physical topologies. If the set of devices that support 398 each mechanism has only minimal overlap, the manager may need to work 399 with the union of the two sets which could increase the processing 400 requirement substantially. 402 4.1.2. Manager Process 404 A manager uses the following process to determine the physical topology 405 of a portion of the network using a common topology mechanism. Limiting 406 the manager process to those devices using a common mechanism is not 407 required, but it does contain the effort and allows the topology to be 408 built piece by piece in a methodical way. The process described assumes 409 that a single topology mechanism is in use across the set of devices 410 over which physical topology is being determined. Manager processing 411 for overlapping topology mechanisms is described subsequently. 413 - a manager first identifies a managed device on the network to begin 414 the physical topology collection process 416 Draft Physical Topology MIB July 1997 418 - the manager chooses a port to begin the topology determination and 419 obtains the topology mechanism and instance for that port 421 - for each port on the device which use the same instance of this 422 topology mechanism, the manager obtains the topology data for that 423 port and any downstream agent identities. 425 - the manager then queries all downstream agents identified by this 426 device and repeats the previous step. 428 - the manager continues walking through the topology until it has no 429 other new agents identified and has collected topology data from 430 all agents. 432 - the manager then performs topology calculations as required based 433 on topology data returned to determine the actual physical topology 434 of this collection of devices. 436 - once this portion of the network has been mapped, the manager 437 should identify other ports on devices that are running a different 438 instance of the topology mechanism or a different topology 439 mechanism altogether and repeat the process to map that topology. 441 - following this iterative procedure, the physical topology of an 442 arbitrarily large network can be calculated. 444 5. Physical Topology MIB 446 This section describes and defines the Physical Topology MIB. 448 5.1. Persistent Identifiers 450 The PTOPO MIB utilizes non-volatile identifiers to distinguish 451 individual chassis and port components. These identifiers are 452 associated with external objects in order to relate topology information 453 to the existing managed objects. 455 In particular, an object from the Entity MIB or Interfaces MIB can be 456 used as the 'reference-point' for a connection component identifier. 458 The Physical Topology MIB uses two identifier types pertaining to the 459 PTOPO MIB: 461 Draft Physical Topology MIB July 1997 463 - globally unique chassis identifiers. 465 - port identifiers; unique only within the chassis which contains the 466 port. 468 Identifiers are stored as OCTET STRINGs, which are limited to 48 469 bytes in length, This supports flexible naming conventions and 470 constrains the non-volatile storage requirements for an agent. 472 5.2. Relationship to Entity MIB 474 The Entity MIB [RFC2037] allows the physical component inventory and 475 hierarchy to be identified. However, the Entity MIB does not provide 476 persistent component identifiers, which are required for the PTOPO MIB. 477 Therefore, an extension to the Entity MIB is defined [ENTITY-EXT] to 478 provide that feature. The new table augments the entPhysicalTable, and 479 adds a read-write 'alias' identifier, similar to the ifAlias MIB object 480 for interfaces. 482 For agents implementing the PTOPO MIB, this new object must be used to 483 represent the chassis identifier. Port identifiers can be based on the 484 entPhysicalAlias object associated with the port, but only if the port 485 is not represented as an interface in the ifXTable. 487 Implementation of the entPhysicalGroup and entPhysicalXGroup is 488 mandatory for SNMP agents which implement the PTOPO MIB. 490 5.3. Relationship to Interfaces MIB 492 The PTOPO MIB requires a persistent identifier for each port. The 493 Interfaces MIB [RFC1573] provides a standard mechanism for managing 494 network interfaces. Unfortunately, not all ports which may be 495 represented in the PTOPO MIB are also represented in the Interfaces MIB 496 (e.g., repeater ports). 498 For agents which implement the PTOPO MIB, for each port represented in 499 the Interfaces MIB, the agent must use the associated ifAlias value for 500 the port identifier. For each port not represented in the Interfaces 501 MIB, the associated entPhysicalAlias value must be used for the port 502 identifier. 504 5.4. Relationship to RMON-2 MIB 506 The RMON-2 MIB [RFC2021] contains address mapping information which can 507 be integrated with physical topology information. The physical ports 508 Draft Physical Topology MIB July 1997 510 identified in a physical topology MIB can be related to the MAC and 511 network layer addresses found in the addressMapTable. 513 5.5. MIB Structure 515 The PTOPO MIB contains three MIB object groups: 517 - ptopoData 518 Exposes physical topology data learned from discovery protocols 519 and/or manual configuration. 521 - ptopoGeneral 522 Contains general information regarding PTOPO MIB status. 524 - ptopoConfig 525 Contains configuration variables for the PTOPO MIB agent function. 527 5.5.1. ptopoData Group 529 This group contains a single table to identity physical topology data. 531 The ptopoConnTable contains information about the connections learned or 532 configured on behalf of the PTOPO MIB SNMP Agent. 534 5.5.2. ptopoGeneral Group 536 This group contains some scalar objects to report the status of the 537 PTOPO MIB information currently known to the SNMP Agent. The global last 538 change time, and table add and delete counters allow an NMS to set 539 threshold alarms to trigger PTOPO polling. 541 5.5.3. ptopoConfig Group 543 This group contains tables to configure the behavior of the physical 544 topology function. The transmission of ptopoLastChange traps can be 545 configured using the ptopoConfigTrapsEnabled scalar MIB object. 547 5.6. Physical Topology MIB Definitions 549 PTOPO-MIB DEFINITIONS ::= BEGIN 551 IMPORTS 552 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32 553 FROM SNMPv2-SMI 554 TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue 556 Draft Physical Topology MIB July 1997 558 FROM SNMPv2-TC 559 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 560 FROM SNMPv2-CONF 561 TimeFilter 562 FROM RMON2-MIB 563 PhysicalIndex 564 FROM ENTITY-MIB; 566 ptopoMIB MODULE-IDENTITY 567 LAST-UPDATED "9707300000Z" 568 ORGANIZATION "IETF PTOPOMIB Working Group" 569 CONTACT-INFO 570 "Andy Bierman 571 Cisco Systems Inc. 572 170 West Tasman Drive 573 San Jose, CA 95134 574 408-527-3711 575 abierman@cisco.com" 576 DESCRIPTION 577 "The MIB module for physical topology information." 578 ::= { experimental xx } 580 ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } 582 -- MIB groups 583 ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } 584 ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } 585 ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } 587 -- textual conventions 589 -- 590 -- IANAAddrFamily and GenAddr TCs copied from 591 -- draft-ietf-disman-framework-00.txt 592 -- Eventually, they will be included from a general TC module 593 -- 594 IANAAddrFamily ::= TEXTUAL-CONVENTION 595 STATUS current 596 DESCRIPTION 597 "An address family. Values are defined in Assigned Numbers, 598 RFC1700. Note that not all these values make sense in all 599 contexts where this type is used in this MIB, but they are 600 included for completeness." 601 REFERENCE 603 Draft Physical Topology MIB July 1997 605 "Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS" 606 SYNTAX INTEGER { 607 other(0), 608 ipV4(1), 609 ipV6(2), 610 nsap(3), 611 hdlc(4), 612 bbn1822(5), 613 ieee802(6), 614 e163(7), 615 e164(8), 616 f69(9), 617 x121(10), 618 ipx(11), 619 appleTalk(12), 620 decnetIV(13), 621 banyanVines(14), 622 e164WithNsap(15) 623 } 625 PtopoGenAddr ::= TEXTUAL-CONVENTION 626 STATUS current 627 DESCRIPTION 628 "The value of an address." 629 -- SYNTAX OCTET STRING (SIZE (0..60)) 630 SYNTAX OCTET STRING (SIZE (0..20)) 632 PtopoChassisIdType ::= TEXTUAL-CONVENTION 633 STATUS current 634 DESCRIPTION 635 "This TC describes the source of a chassis identifier. 637 The enumeration 'chasIdEntPhysicalAlias(1)' represents a 638 chassis identifier based on the value of entPhysicalAlias 639 for a chassis component (i.e., an entPhysicalClass value of 640 'chassis(3)'). 642 The enumeration 'chasIdIfAlias(2)' represents a chassis 643 identifier based on the value of ifAlias for an interface on 644 the containing chassis. 646 The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a 647 chassis identifier based on the value of entPhysicalAlias 648 for a port component (i.e., entPhysicalClass value of 649 'port(10)'), on the containing chassis. 651 Draft Physical Topology MIB July 1997 653 The enumeration 'chasIdMacAddress(4)' represents a chassis 654 identifier based on the value of a unicast source MAC 655 address (encoded in network byte order and IEEE 802.3 656 canonical bit order), of a port on the containing chassis. 658 The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis 659 identifier based on a network address, associated with a 660 particular chassis. The encoded address is actually composed 661 of two fields. The first field is a single octet, 662 representing the IANAAddrFamily for the specific address 663 type, and the second field is the PtopoGenAddr address 664 value." 665 SYNTAX INTEGER { 666 chasIdEntPhysicalAlias(1), 667 chasIdIfAlias(2), 668 chasIdPortEntPhysicalAlias(3), 669 chasIdMacAddress(4), 670 chasIdPtopoGenAddr(5) 671 } 673 PtopoChassisId ::= TEXTUAL-CONVENTION 674 STATUS current 675 DESCRIPTION 676 "This TC describes the format of a chassis identifier 677 string. Objects of this type are always used with an 678 associated PtopoChassisIdType object, which identifies the 679 format of the particular PtopoChassisId object instance. 681 If the associated PtopoChassisIdType object has a value of 682 'chasIdEntPhysicalAlias(1)', then the octet string 683 identifies a particular instance of the entPhysicalAlias 684 object for a chassis component (i.e., an entPhysicalClass 685 value of 'chassis(3)'). 687 If the associated PtopoChassisIdType object has a value of 688 'chasIdIfAlias(2)', then the octet string identifies a 689 particular instance of the ifAlias object for an interface 690 on the containing chassis. 692 If the associated PtopoChassisIdType object has a value of 693 'chasIdPortEntPhysicalAlias(3)', then the octet string 694 identifies a particular instance of the entPhysicalAlias 695 object for a port component (i.e., entPhysicalClass value of 696 'port(10)') on the containing chassis. 698 Draft Physical Topology MIB July 1997 700 If the associated PtopoChassisIdType object has a value of 701 'chasIdMacAddress(4)', then this string identifies a 702 particular unicast source MAC address (encoded in network 703 byte order and IEEE 802.3 canonical bit order), of a port on 704 the containing chassis. 706 If the associated PtopoChassisIdType object has a value of 707 'chasIdPtopoGenAddr(5)', then this string identifies a 708 particular network address, encoded in network byte order, 709 associated with one or more ports on the containing chassis. 710 The first octet contains the IANAAddrFamily enumeration 711 value for the specific address type, and octets 2 through N 712 contain the PtopoGenAddr address value in network byte 713 order." 714 SYNTAX OCTET STRING (SIZE (1..48)) 716 PtopoPortIdType ::= TEXTUAL-CONVENTION 717 STATUS current 718 DESCRIPTION 719 "This TC describes the source of a particular type of port 720 identifier used in the PTOPO MIB. 722 The enumeration 'portIdIfAlias(1)' represents a port 723 identifier based on the ifAlias MIB object. 725 The enumeration 'portIdEntPhysicalAlias(2)' represents a 726 port identifier based on the entPhysicalAlias MIB object. 728 The enumeration 'portIdMacAddress(3)' represents a port 729 identifier based on a unicast source MAC address, which has 730 been detected by the agent and associated with a particular 731 port. 733 The enumeration 'portIdPtopoGenAddr(4)' represents a port 734 identifier based on a network address, detected by the agent 735 and associated with a particular port." 736 SYNTAX INTEGER { 737 portIdIfAlias(1), 738 portIdEntPhysicalAlias(2), 739 portIdMacAddress(3), 740 portIdPtopoGenAddr(4) 741 } 743 PtopoPortId ::= TEXTUAL-CONVENTION 744 STATUS current 746 Draft Physical Topology MIB July 1997 748 DESCRIPTION 749 "This TC describes the format of a port identifier string. 750 Objects of this type are always used with an associated 751 PtopoPortIdType object, which identifies the format of the 752 particular PtopoPortId object instance. 754 If the associated PtopoPortIdType object has a value of 755 'portIdIfAlias(1)', then the octet string identifies a 756 particular instance of the ifAlias object. 758 If the associated PtopoPortIdType object has a value of 759 'portIdEntPhysicalAlias(2)', then the octet string 760 identifies a particular instance of the entPhysicalAlias 761 object for a port component (i.e., entPhysicalClass value of 762 'port(10)'). 764 If the associated PtopoPortIdType object has a value of 765 'portIdMacAddress(3)', then this string identifies a 766 particular unicast source MAC address associated with the 767 port. 769 If the associated PtopoPortIdType object has a value of 770 'portIdPtopoGenAddr(4)', then this string identifies a 771 network address associated with the port. The first octet 772 contains the IANAAddrFamily enumeration value for the 773 specific address type, and octets 2 through N contain the 774 PtopoGenAddr address value in network byte order." 775 SYNTAX OCTET STRING (SIZE (1..48)) 777 -- *********************************************************** 778 -- 779 -- P T O P O D A T A G R O U P 780 -- 781 -- *********************************************************** 783 -- Connection Table 785 ptopoConnTable OBJECT-TYPE 786 SYNTAX SEQUENCE OF PtopoConnEntry 787 MAX-ACCESS not-accessible 788 STATUS current 789 DESCRIPTION 790 "This table contains one row per physical network connection 791 known to this agent. The agent must ensure that duplicate 793 Draft Physical Topology MIB July 1997 795 connections are not present in the table at any time. This 796 can occur if the order of the endpoint identifiers is 797 arbitrarily reversed. 799 An agent must also insure that a particular chassis or port 800 is not identified by more than one identifier type. An agent 801 must use the lowest numbered identifier type 802 (PtopoChassisIdType or PtopoPortIdType) for a given 803 component (ptopoConnChassis2 or ptopoConnPort2). 805 Entries based on higher numbered identifier types must be 806 removed from the table, and replaced with a lower numbered 807 identifier type, whenever possible. 809 Note that the index ordering (i.e. A to B or B to A) is an 810 implementation-specific matter which endpoint identifier is 811 associated with { ptopoConnChassis1, ptopoConnPort1 }." 812 ::= { ptopoData 1 } 814 ptopoConnEntry OBJECT-TYPE 815 SYNTAX PtopoConnEntry 816 MAX-ACCESS not-accessible 817 STATUS current 818 DESCRIPTION 819 "Information about a particular physical network connection. 820 Entries may be created and deleted in this table, either 821 manually or by the agent, if a physical topology discovery 822 process is active." 823 INDEX { 824 ptopoConnTimeMark, 825 ptopoConnChassis1, 826 ptopoConnPort1, 827 ptopoConnChassis2Type, 828 ptopoConnChassis2, 829 ptopoConnPort2Type, 830 ptopoConnPort2 831 } 832 ::= { ptopoConnTable 1 } 834 PtopoConnEntry ::= SEQUENCE { 835 ptopoConnTimeMark TimeFilter, 836 ptopoConnChassis1 PhysicalIndex, 837 ptopoConnPort1 PhysicalIndex, 838 ptopoConnChassis2Type PtopoChassisIdType, 839 ptopoConnChassis2 PtopoChassisId, 841 Draft Physical Topology MIB July 1997 843 ptopoConnPort2Type PtopoPortIdType, 844 ptopoConnPort2 PtopoPortId, 845 ptopoConnDiscAlgorithm AutonomousType, 846 ptopoConnNetAddrType IANAAddrFamily, 847 ptopoConnNetAddr PtopoGenAddr, 848 ptopoConnMultiMacSASeen TruthValue, 849 ptopoConnRowStatus RowStatus 850 } 852 ptopoConnTimeMark OBJECT-TYPE 853 SYNTAX TimeFilter 854 MAX-ACCESS not-accessible 855 STATUS current 856 DESCRIPTION 857 "A TimeFilter for this entry. See the TimeFilter textual 858 convention in RFC 2021 to see how this works." 859 ::= { ptopoConnEntry 1 } 861 ptopoConnChassis1 OBJECT-TYPE 862 SYNTAX PhysicalIndex 863 MAX-ACCESS not-accessible 864 STATUS current 865 DESCRIPTION 866 "The entPhysicalIndex value used to identify the chassis 867 component associated with the first connection endpoint." 868 ::= { ptopoConnEntry 2 } 870 ptopoConnPort1 OBJECT-TYPE 871 SYNTAX PhysicalIndex 872 MAX-ACCESS not-accessible 873 STATUS current 874 DESCRIPTION 875 "The entPhysicalIndex value used to identify the port 876 component associated with the first connection endpoint." 877 ::= { ptopoConnEntry 3 } 879 ptopoConnChassis2Type OBJECT-TYPE 880 SYNTAX PtopoChassisIdType 881 MAX-ACCESS not-accessible 882 STATUS current 883 DESCRIPTION 884 "The type of encoding used to identify the chassis 885 associated with the second connection endpoint." 886 ::= { ptopoConnEntry 4 } 888 Draft Physical Topology MIB July 1997 890 ptopoConnChassis2 OBJECT-TYPE 891 SYNTAX PtopoChassisId 892 MAX-ACCESS not-accessible 893 STATUS current 894 DESCRIPTION 895 "The string value used to identify the chassis component 896 associated with the second connection endpoint." 897 ::= { ptopoConnEntry 5 } 899 ptopoConnPort2Type OBJECT-TYPE 900 SYNTAX PtopoPortIdType 901 MAX-ACCESS not-accessible 902 STATUS current 903 DESCRIPTION 904 "The type of encoding used to identify the port associated 905 with the second connection endpoint." 906 ::= { ptopoConnEntry 6 } 908 ptopoConnPort2 OBJECT-TYPE 909 SYNTAX PtopoPortId 910 MAX-ACCESS not-accessible 911 STATUS current 912 DESCRIPTION 913 "The string value used to identify the port component 914 associated with the second connection endpoint." 915 ::= { ptopoConnEntry 7 } 917 ptopoConnDiscAlgorithm OBJECT-TYPE 918 SYNTAX AutonomousType 919 MAX-ACCESS read-create 920 STATUS current 921 DESCRIPTION 922 "An indication of the algorithm used to discover the 923 information contained in this conceptual row. 925 A value of ptopoDiscoveryPDP indicates this entry was 926 configured using the PTOPO Discovery Protocol. 928 A value of ptopoDiscoveryLocal indicates this entry was 929 configured by the local agent, without use of a discovery 930 protocol. 932 A value of { 0 0 } indicates this entry was created manually 933 by an NMS via the associated RowStatus object. 935 Draft Physical Topology MIB July 1997 937 This object may not be modified if the associated 938 ptopoConnRowStatus object has a value of active(1)." 939 ::= { ptopoConnEntry 8 } 941 ptopoConnNetAddrType OBJECT-TYPE 942 SYNTAX IANAAddrFamily 943 MAX-ACCESS read-create 944 STATUS current 945 DESCRIPTION 946 "This network address type of the associated 947 ptopoConnNetAddr object, unless that object contains a zero 948 length string. In such a case, this object shall contain 949 the value 'other(0)'. 951 This object may not be modified if the associated 952 ptopoConnRowStatus object has a value of active(1)." 953 ::= { ptopoConnEntry 9 } 955 ptopoConnNetAddr OBJECT-TYPE 956 SYNTAX PtopoGenAddr 957 MAX-ACCESS read-create 958 STATUS current 959 DESCRIPTION 960 "This object identifies a network address which may be used 961 to reach an SNMP agent entity containing information for the 962 chassis and port components represented by the associated 963 'ptopoConnChassis2' and 'ptopoConnPort2' objects. If no such 964 address is known, then this object shall contain an empty 965 string. 967 This object may not be modified if the associated 968 ptopoConnRowStatus object has a value of active(1)." 969 ::= { ptopoConnEntry 10 } 971 ptopoConnMultiMacSASeen OBJECT-TYPE 972 SYNTAX TruthValue 973 MAX-ACCESS read-only 974 STATUS current 975 DESCRIPTION 976 "This object indicates if multiple unicast source MAC 977 addresses have been detected by the agent on the port 978 identified by the associated instance of the 979 'ptopoConnPort2' object. 981 If the agent has detected multiple unicast source MAC 983 Draft Physical Topology MIB July 1997 985 addresses on the indicated port, then this object contains 986 the value 'true(1)'. 988 If the agent has detected only a single unicast source MAC 989 address on the indicated port, or the agent does not know, 990 then this object contains the value 'false(2)'." 991 ::= { ptopoConnEntry 11 } 993 ptopoConnRowStatus OBJECT-TYPE 994 SYNTAX RowStatus 995 MAX-ACCESS read-create 996 STATUS current 997 DESCRIPTION 998 "The status of this conceptual row." 999 ::= { ptopoConnEntry 12 } 1001 -- *********************************************************** 1002 -- 1003 -- P T O P O G E N E R A L G R O U P 1004 -- 1005 -- *********************************************************** 1007 -- last change time stamp for the whole MIB 1009 ptopoLastChangeTime OBJECT-TYPE 1010 SYNTAX TimeStamp 1011 MAX-ACCESS read-only 1012 STATUS current 1013 DESCRIPTION 1014 "The value of sysUpTime at the time a conceptual row is 1015 created, modified, or deleted in the ptopoConnTable. 1017 An NMS can use this object to reduce polling of the 1018 ptopoData group objects." 1019 ::= { ptopoGeneral 1 } 1021 ptopoConnTabInserts OBJECT-TYPE 1022 SYNTAX Counter32 1023 MAX-ACCESS read-only 1024 STATUS current 1025 DESCRIPTION 1026 "The number of times an entry has been inserted into the 1027 ptopoConnTable." 1028 ::= { ptopoGeneral 2 } 1030 Draft Physical Topology MIB July 1997 1032 ptopoConnTabDeletes OBJECT-TYPE 1033 SYNTAX Counter32 1034 MAX-ACCESS read-only 1035 STATUS current 1036 DESCRIPTION 1037 "The number of times an entry has been deleted from the 1038 ptopoConnTable." 1039 ::= { ptopoGeneral 3 } 1041 -- *********************************************************** 1042 -- 1043 -- P T O P O C O N F I G G R O U P 1044 -- 1045 -- *********************************************************** 1047 ptopoConfigTrapsEnabled OBJECT-TYPE 1048 SYNTAX TruthValue 1049 MAX-ACCESS read-write 1050 STATUS current 1051 DESCRIPTION 1052 "This object controls the transmission of PTOPO 1053 notifications. 1055 If the agent is capable of storing non-volatile 1056 configuration, then the value of this object must be 1057 restored after a re-initialization of the management 1058 system." 1059 DEFVAL { true } 1060 ::= { ptopoConfig 1 } 1062 -- PTOPO MIB Trap Definitions 1063 ptopoMIBTraps OBJECT IDENTIFIER ::= { ptopoMIB 2 } 1064 ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 } 1066 ptopoConfigChange NOTIFICATION-TYPE 1067 OBJECTS { ptopoConnTabInserts, ptopoConnTabDeletes } 1068 STATUS current 1069 DESCRIPTION 1070 "A ptopoConfigChange trap is sent when the value of 1071 ptopoLastChangeTime changes. It can be utilized by an NMS to 1072 trigger physical topology table maintenance polls. 1074 An agent must not generate more than one ptopoConfigChange 1076 Draft Physical Topology MIB July 1997 1078 'trap-event' in a five second period, where a 'trap-event' 1079 is the transmission of a single trap PDU to a list of trap 1080 destinations. If additional configuration changes occur 1081 within the five second 'throttling' period, then these 1082 trap-events should be suppressed by the agent. An NMS should 1083 periodically check the value of ptopoLastChangeTime to 1084 detect any missed ptopoConfigChange trap-events, e.g. due to 1085 throttling or transmission loss." 1086 ::= { ptopoMIBTrapPrefix 1 } 1088 -- PTOPO Registration Points 1090 ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 } 1092 -- values used with ptopoConnDiscAlgorithm object 1093 ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 } 1094 ptopoDiscoveryPDP OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 } 1095 ptopoDiscoveryLocal OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 2 } 1097 -- conformance information 1098 ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 } 1100 ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 } 1101 ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 } 1103 -- compliance statements 1105 ptopoCompliance MODULE-COMPLIANCE 1106 STATUS current 1107 DESCRIPTION 1108 "The compliance statement for SNMP entities which implement 1109 the PTOPO MIB." 1110 MODULE -- this module 1111 MANDATORY-GROUPS { 1112 ptopoDataGroup, 1113 ptopoGeneralGroup, 1114 ptopoConfigGroup, 1115 ptopoNotificationsGroup 1116 } 1117 ::= { ptopoCompliances 1 } 1119 -- MIB groupings 1120 Draft Physical Topology MIB July 1997 1122 ptopoDatagroup OBJECT-GROUP 1123 OBJECTS { 1124 ptopoConnDiscAlgorithm, 1125 ptopoConnNetAddrType, 1126 ptopoConnNetAddr, 1127 ptopoConnMultiMacSASeen, 1128 ptopoConnRowStatus 1129 } 1130 STATUS current 1131 DESCRIPTION 1132 "The collection of objects which are used to represent 1133 physical topology information for which a single agent 1134 provides management information. 1136 This group is mandatory for all implementations of the PTOPO 1137 MIB." 1138 ::= { ptopoGroups 1 } 1140 ptopoGeneralGroup OBJECT-GROUP 1141 OBJECTS { 1142 ptopoLastChangeTime, 1143 ptopoConnTabInserts, 1144 ptopoConnTabDeletes 1145 } 1146 STATUS current 1147 DESCRIPTION 1148 "The collection of objects which are used to report the 1149 general status of the PTOPO MIB implementation. 1151 This group is mandatory for all agents which implement the 1152 PTOPO MIB." 1153 ::= { ptopoGroups 2 } 1155 ptopoConfigGroup OBJECT-GROUP 1156 OBJECTS { 1157 ptopoConfigTrapsEnabled 1158 } 1159 STATUS current 1160 DESCRIPTION 1161 "The collection of objects which are used to configure the 1162 PTOPO MIB implementation behavior. 1164 This group is mandatory for agents which implement the PTOPO 1165 MIB." 1166 ::= { ptopoGroups 3 } 1168 Draft Physical Topology MIB July 1997 1170 ptopoNotificationsGroup NOTIFICATION-GROUP 1171 NOTIFICATIONS { 1172 ptopoConfigChange 1173 } 1174 STATUS current 1175 DESCRIPTION 1176 "The collection of notifications used to indicate PTOPO MIB 1177 data consistency and general status information. 1179 This group is mandatory for agents which implement the PTOPO 1180 MIB." 1181 ::= { ptopoGroups 4 } 1183 END 1184 Draft Physical Topology MIB July 1997 1186 6. References 1188 [ENTITY-EXT] 1189 Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent 1190 Component Identification", draft-bierman-entmib-compid-00.txt, 1191 Cisco Systems, July 1997. 1193 [RFC1157] 1194 Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1195 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1196 International, MIT Laboratory for Computer Science, May 1990. 1198 [RFC1213] 1199 McCloghrie, K., and M. Rose, Editors, "Management Information Base 1200 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1201 RFC 1213, Hughes LAN Systems, Performance Systems International, 1202 March 1991. 1204 [RFC1573] 1205 McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 1206 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 1208 [RFC1700] 1209 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1210 USC/Information Sciences Institute, October 1994. 1212 [RFC1902] 1213 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1214 S. Waldbusser, "Structure of Management Information for version 2 1215 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1216 January 1996. 1218 [RFC1903] 1219 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1220 S. Waldbusser, "Textual Conventions for version 2 of the Simple 1221 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1223 [RFC1904] 1224 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1225 S. Waldbusser, "Conformance Statements for version 2 of the Simple 1226 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1228 [RFC1905] 1229 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1230 S. Waldbusser, "Protocol Operations for version 2 of the Simple 1232 Draft Physical Topology MIB July 1997 1234 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1236 [RFC2021] 1237 S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021, 1238 International Network Services, January 1997. 1240 [RFC2037] 1241 McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, 1242 Cisco Systems, October 1996. 1244 Draft Physical Topology MIB July 1997 1246 7. Security Considerations 1248 Security issues are not discussed in this memo. 1250 8. Authors' Addresses 1252 Andy Bierman 1253 Cisco Systems 1254 170 West Tasman Drive 1255 San Jose, CA 95134 1256 Phone: 408-527-3711 1257 Email: abierman@cisco.com 1259 Kendall S. Jones 1260 Bay Networks 1261 4401 Great America Parkway 1262 Santa Clara, CA 95134 1263 Phone: 408-495-7356 1264 Email: kjones@baynetworks.com 1266 Draft Physical Topology MIB July 1997 1268 Table of Contents 1270 1 Introduction .................................................... 1 1271 2 The SNMP Network Management Framework ........................... 2 1272 2.1 Object Definitions ............................................ 2 1273 3 Overview ........................................................ 2 1274 3.1 Background and Concepts ....................................... 3 1275 3.2 Terms ......................................................... 3 1276 3.3 Functionality Goals ........................................... 5 1277 3.4 Design Goals .................................................. 6 1278 4 Topology Framework .............................................. 7 1279 4.1 Framework Overview ............................................ 7 1280 4.1.1 Topology Mechanisms ......................................... 8 1281 4.1.2 Manager Process ............................................. 9 1282 5 Physical Topology MIB ........................................... 10 1283 5.1 Persistent Identifiers ........................................ 10 1284 5.2 Relationship to Entity MIB .................................... 11 1285 5.3 Relationship to Interfaces MIB ................................ 11 1286 5.4 Relationship to RMON-2 MIB .................................... 11 1287 5.5 MIB Structure ................................................. 12 1288 5.5.1 ptopoData Group ............................................. 12 1289 5.5.2 ptopoGeneral Group .......................................... 12 1290 5.5.3 ptopoConfig Group ........................................... 12 1291 5.6 Physical Topology MIB Definitions ............................. 12 1292 6 References ...................................................... 27 1293 7 Security Considerations ......................................... 29 1294 8 Authors' Addresses .............................................. 29