idnits 2.17.1 draft-ietf-ptopomib-mib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-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 (March 1998) is 9538 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) == Missing Reference: 'RFC1573' is mentioned on line 260, but not defined ** Obsolete undefined reference: RFC 1573 (Obsoleted by RFC 2233) == 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 1493 (Obsoleted by RFC 4188) ** 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) ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) Summary: 22 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft Physical Topology MIB March 1998 4 5 Physical Topology MIB 7 2 March 1998 9 Andy Bierman 10 Cisco Systems 11 abierman@cisco.com 13 Kendall S. Jones 14 Bay Networks 15 kjones@baynetworks.com 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 1. Introduction 36 This memo defines an experimental portion of the Management Information 37 Base (MIB) for use with network management protocols in the Internet 38 community. In particular, it describes managed objects used for 39 managing physical topology identification and discovery. 41 Draft Physical Topology MIB March 1998 43 2. The SNMP Network Management Framework 45 The SNMP Network Management Framework presently consists of three major 46 components. They are: 48 o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for 49 describing and naming objects for the purpose of management. 51 o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed 52 objects for the Internet suite of protocols. 54 o the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the 55 protocol for accessing managed information. 57 Textual conventions are defined in RFC 1903 [RFC1903], and conformance 58 statements are defined in RFC 1904 [RFC1904]. 60 The Framework permits new objects to be defined for the purpose of 61 experimentation and evaluation. 63 This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A 64 semantically identical MIB conforming to the SNMPv1 SMI can be produced 65 through the appropriate translation. 67 2.1. Object Definitions 69 Managed objects are accessed via a virtual information store, termed the 70 Management Information Base or MIB. Objects in the MIB are defined 71 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 72 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 73 an administratively assigned name. The object type together with an 74 object instance serves to uniquely identify a specific instantiation of 75 the object. For human convenience, we often use a textual string, 76 termed the descriptor, to refer to the object type. 78 3. Overview 80 There is a need for a standardized means of representing the physical 81 network connections pertaining to a given management domain. A 82 standardized discovery mechanism is also required to increase the 83 likelihood of multi-vendor interoperability of such physical topology 84 management information, although the PTOPO MIB does not specify or 85 restrict the discovery mechanisms required for implementation. 87 Draft Physical Topology MIB March 1998 89 The scope of the physical topology (PTOPO) mechanism is the 90 identification of connections between two network ports. Network 91 addresses of SNMP agents containing management information associated 92 with each port can also be identified. 94 3.1. Background and Concepts 96 The need to understand the physical relationships between devices in a 97 network has always been an important aspect of network management. With 98 the increasing complexity of multi-segment and multi-media hubs and 99 switching devices, and management applications that want to identify hot 100 spots in the network, isolate complex faults (such as configuration 101 problems) to the physical port, and manage virtual networks (VLANs), the 102 need for accurate, timely, and system wide physical topology is becoming 103 more and more critical to maintaining a mission critical network. 105 Most of today's management platforms do a good job at discovering the 106 logical topology at the network layer but do not help much in 107 understanding the actual physical interconnection. This is due to a 108 lack of standard topology mechanisms at the physical layer to collect 109 the physical topology information as well as a standard MIB to return 110 topology information to the management workstation. 112 Standard topology mechanisms exist for certain media types (such as 113 FDDI) and proprietary mechanisms exist for other media such as shared 114 media Ethernet, switched Ethernet, and Token Ring. While standardizing 115 these or other mechanisms for each of these technologies could be a 116 painstaking task, standardizing a common MIB and a topology framework 117 that allows co-existence of multiple topology mechanisms to populate 118 these MIBs can go a long way toward achieving the goal of providing 119 network-wide physical topology information at the network management 120 workstation. The topology framework should specify the core 121 requirements for topology mechanisms in order to provide the data 122 necessary to populate the common topology MIB. 124 These requirements form a set of guidelines to direct the eventual 125 standardization of a set of topology mechanisms for the various 126 communication media. In the meantime, the common MIB will allow 127 creation of physical topology databases which will allow applications to 128 provide value added services on top of this rich set of data. 130 Draft Physical Topology MIB March 1998 132 3.2. Terms 134 Some terms are used throughout this document: 136 Physical Topology 137 Physical topology represents the topology model for layer 1 of the 138 OSI stack - the physical layer. Physical topology consists of 139 identifying the devices on the network and how they are physically 140 interconnected. By definition of this document, physical topology 141 does not imply a physical relationship between ports on the same 142 device. Other means exist for determining these relationships 143 (e.g., Entity MIB). 145 Logical Topology 146 Logical topology indicates how devices are related based on some 147 system level attribute. Often this is based on the OSI 148 communication layer. For instance, network layer topology, or 149 layer 3 topology, uses network layer address hierarchies to 150 construct a topological relationship. Management platforms 151 typically present Layer-3-based topology. This is done by 152 'discovering' the IP addresses on a network and then grouping these 153 logically by the subnet portion of the address. Other logical 154 views of topology include layer-2 based views based on VLAN 155 membership, and higher layer views such as workgroup membership. 156 Most higher-layer topology views use network address or user name 157 to represent members of the topology space. 159 Chassis 160 A chassis is a physical component which contains other physical 161 components. It is identified by an entPhysicalEntry with an 162 entPhysicalClass value of 'chassis(3)' and an 163 entPhysicalContainedIn value of zero. A chassis identifier 164 consists of a globally unique DisplayString. 166 Local Chassis 167 The particular chassis containing the SNMP agent implementing the 168 PTOPO MIB. 170 Port 171 A port is a physical component which can be connected to another 172 port through some medium. It is identified by an entPhysicalEntry 173 with an entPhysicalClass value of 'port(10)'. A port identifier 174 consists of a DisplayString which must be unique within the context 175 of the chassis which contains the port. 177 Draft Physical Topology MIB March 1998 179 Connection Endpoint 180 A connection endpoint consists of a physical port, which is 181 contained within a single physical chassis. 183 Connection Endpoint Identifier 184 A connection endpoint is identified by a globally unique chassis 185 identifier and a port identifier unique within the associated 186 chassis. 188 Connection 189 A connection consists of two physical ports, and the attached 190 physical medium, configured for the purpose of transferring network 191 traffic between the ports. A connection is identified by its 192 endpoint identifiers. 194 Non-local Connection 195 A connection for which neither endpoint is located on the local 196 chassis. 198 Cloud 199 A cloud identifies a portion of the topology for which insufficient 200 information is known to completely infer the interconnection of 201 devices that make up that portion of the topology. 203 3.3. Functionality Goals 205 While the framework presented here is focused on physical topology, it 206 may well be that the topology mechanisms and MIB described could be 207 extended to include logical topology information as well. That is not a 208 focus of this memo at this time, although some consideration may be 209 given to the framework itself and some notes may be included within this 210 memo. They will be clearly identified as work for further study. 212 The following goals can be described for the physical topology 213 framework. 215 - Develop a common MIB that represents the physical topology 216 information available to any one agent in the network. The MIB 217 should provide enough topology information to allow a management 218 workstation to navigate across agents to build a complete physical 219 topology for an arbitrarily large network. 221 - Provide a set of requirements for topology mechanisms that can 222 populate the agent MIBs. These requirements should allow for many 223 different standard and non-standard topology mechanisms to be used 225 Draft Physical Topology MIB March 1998 227 within a given network, with clear rules describing how these 228 mechanisms should interact. 230 - Specify, where appropriate, topology mechanisms for specific media 231 types. Where standard or industry-accepted mechanisms exist, 232 indicate how these mechanisms can be used to populate the topology 233 MIBs. 235 - Provide a description of the management station procedures to 236 navigate among topology agents and gather topology information. 238 3.4. Design Goals 240 Several factors influenced the design of this physical topology 241 function: 243 - Simplicity 244 The physical topology discovery function should be as simple as 245 possible, exposing only the information needed to identify 246 connection endpoints and the SNMP agent(s) associated with each 247 connection endpoint. 249 - Completeness 250 At least one standard discovery protocol capable of supporting the 251 standard physical topology MIB must be defined. Multi-vendor 252 interoperability will not be achievable unless a simple and 253 extensible discovery protocol is available. However, the PTOPO MIB 254 should not specify or restrict the topology discovery mechanisms an 255 agent can use. 257 - No Functional Overlap 258 Existing standard MIBs should be utilized whenever possible. 259 Physical topology information is tightly coupled to functionality 260 found in the Interfaces MIB [RFC1573] and Entity MIB [RFC2037]. 261 New physical topology MIB objects should not duplicate these MIBs. 263 - Identifier Stability 264 Connection endpoint identifiers must be persistent (i.e. stable 265 across device reboots). Dynamic primary key objects like ifIndex 266 and entPhysicalIndex are not suitable for table indices in a 267 physical topology MIB that is replicated and distributed throughout 268 a managed system. 270 - Identifier Flexibility 271 Persistent string-based component identifiers should be supported 273 Draft Physical Topology MIB March 1998 275 from many sources. Chassis identifiers may be found in the Entity 276 MIB, and port identifiers may be found in the Interfaces MIB or 277 Entity MIB. 279 - Partial Topology Support 280 Physical topology data for remote components may only be partially 281 available to an agent. An enumerated INTEGER hierarchy of 282 component identifier types allows for incomplete physical 283 connection identifier information to be substituted with secondary 284 information such as unicast source MAC address or network address 285 associated with a particular port. A PTOPO Agent maintains 286 information derived from the 'best' source of information for each 287 connection. If a 'better' identifier source is detected, the PTOPO 288 entries are updated accordingly. It is an implementation specific 289 matter whether a PTOPO agent replaces 'old' entries or retains 290 them, however an agent must remove information known to be 291 incorrect. 293 - Low Polling Impact 294 Physical topology polling should be minimized through techniques 295 such as TimeFiltered data tables (from RMON-2 [RFC2021]), and 296 last-change notifications. 298 4. Topology Framework 300 This section describes the physical topology framework in detail. 302 4.1. Framework Overview 304 Several components make up the framework for physical topology. 306 Devices 307 The network devices, along with their physical connectivity, make 308 up the physical topology. Some of these devices (but maybe not all) 309 provide management agents that report their local physical topology 310 information to a manager via the physical topology MIB. 312 These devices include communication infrastructure devices, such as 313 hubs, switches, and routers, as well as 'leaf' devices such as 314 workstations, printers, and servers. Generally, user data passes 315 through infrastructure devices while leaf devices are sources and 316 sinks of data. Both types of devices may implement the physical 317 topology MIB, although implementation within leaf devices is much 319 Draft Physical Topology MIB March 1998 321 less critical. 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 Draft Physical Topology MIB March 1998 368 the topology. In other words, the mechanism may not be robust enough to 369 allow the manager to accurately determine any part of the network by 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 Draft Physical Topology MIB March 1998 415 - a manager first identifies a managed device on the network to begin 416 the physical topology collection process 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 Draft Physical Topology MIB March 1998 461 PTOPO MIB: 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 32 bytes 469 in length, This supports flexible naming conventions and constrains the 470 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. No other 489 groups must be implemented from this MIB to support the physical 490 topology function. 492 5.3. Relationship to Interfaces MIB 494 The PTOPO MIB requires a persistent identifier for each port. The 495 Interfaces MIB [RFC2233] provides a standard mechanism for managing 496 network interfaces. Unfortunately, not all ports which may be 497 represented in the PTOPO MIB are also represented in the Interfaces MIB 498 (e.g., repeater ports). 500 For agents which implement the PTOPO MIB, for each port also represented 501 in the Interfaces MIB, the agent must use the associated ifAlias value 502 for the port identifier. For each port not represented in the 503 Interfaces MIB, the associated entPhysicalAlias value must be used for 504 the port identifier. Note that the PTOPO MIB requires only minimal 505 support from the Interfaces MIB. Specifically, the 506 Draft Physical Topology MIB March 1998 508 'ifGeneralInformationGroup' level of conformance must be provided for 509 each port also identified in the PTOPO MIB. The agent may choose to 510 support these objects with read-only access, as specified in the 511 conformance section of the Interfaces MIB. 513 5.4. Relationship to RMON-2 MIB 515 The RMON-2 MIB [RFC2021] contains address mapping information which can 516 be integrated with physical topology information. The physical ports 517 identified in a physical topology MIB can be related to the MAC and 518 network layer addresses found in the addressMapTable. 520 5.5. Relationship to Bridge MIB 522 The Bridge MIB [RFC1493] contains information which may relate to 523 physical ports represented in the ptopoConnTable. Entries in the 524 dot1dBasePortTable and dot1dStpPortTable can by related to physical 525 ports represented in the PTOPO MIB. Also, bridge port MAC addresses may 526 be used as chassis and port identifiers in some situations. 528 5.6. Relationship to Repeater MIB 530 The Repeater MIB [RFC2108] contains information which may relate to 531 physical ports represented in the PTOPO MIB. Entries in the 532 rptrPortTable and rptrMonitorPortTable can by related to physical ports 533 represented in the ptopoConnTable. Entries in the rptrInfoTable and 534 rptrMonTable can be related to repeater backplanes possibly represented 535 in the ptopoConnTable. 537 5.7. MIB Structure 539 The PTOPO MIB contains three MIB object groups: 541 - ptopoData 542 Exposes physical topology data learned from discovery protocols 543 and/or manual configuration. 545 - ptopoGeneral 546 Contains general information regarding PTOPO MIB status. 548 - ptopoConfig 549 Contains configuration variables for the PTOPO MIB agent function. 551 Draft Physical Topology MIB March 1998 553 5.7.1. ptopoData Group 555 This group contains a single table to identity physical topology data. 557 The ptopoConnTable contains information about the connections learned or 558 configured on behalf of the PTOPO MIB SNMP Agent. 560 5.7.2. ptopoGeneral Group 562 This group contains some scalar objects to report the status of the 563 PTOPO MIB information currently known to the SNMP Agent. The global last 564 change time, and table add and delete counters allow an NMS to set 565 threshold alarms to trigger PTOPO polling. 567 5.7.3. ptopoConfig Group 569 This group contains tables to configure the behavior of the physical 570 topology function. The transmission of ptopoLastChange traps can be 571 configured using the ptopoConfigTrapInterval scalar MIB object. 573 5.8. Physical Topology MIB Definitions 575 PTOPO-MIB DEFINITIONS ::= BEGIN 577 IMPORTS 578 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32 579 FROM SNMPv2-SMI 580 TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue 581 FROM SNMPv2-TC 582 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 583 FROM SNMPv2-CONF 584 TimeFilter 585 FROM RMON2-MIB 586 PhysicalIndex 587 FROM ENTITY-MIB; 589 ptopoMIB MODULE-IDENTITY 590 LAST-UPDATED "9801260000Z" 591 ORGANIZATION "IETF; PTOPOMIB Working Group" 592 CONTACT-INFO 593 "PTOPOMIB WG Discussion: 594 ptopo@3com.com 595 Subscription: 596 majordomo@3com.com 597 msg body: [un]subscribe ptopomib 599 Draft Physical Topology MIB March 1998 601 Andy Bierman 602 Cisco Systems Inc. 603 170 West Tasman Drive 604 San Jose, CA 95134 605 408-527-3711 606 abierman@cisco.com 608 Kendall S. Jones 609 Bay Networks 610 4401 Great America Parkway 611 Santa Clara, CA 95134 612 408-495-7356 613 kjones@baynetworks.com" 614 DESCRIPTION 615 "The MIB module for physical topology information." 616 ::= { experimental xx } 618 ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } 620 -- MIB groups 621 ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } 622 ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } 623 ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } 625 -- textual conventions 627 -- 628 -- IANAAddrFamily TC copied from 629 -- draft-ietf-disman-framework-00.txt 630 -- Eventually, it will be included from a general TC module 631 -- 632 IANAAddrFamily ::= TEXTUAL-CONVENTION 633 STATUS current 634 DESCRIPTION 635 "An address family. Values are defined in Assigned Numbers, 636 RFC1700. Note that not all these values make sense in all 637 contexts where this type is used in this MIB, but they are 638 included for completeness." 639 REFERENCE 640 "Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS" 641 SYNTAX INTEGER { 642 other(0), 643 ipV4(1), 645 Draft Physical Topology MIB March 1998 647 ipV6(2), 648 nsap(3), 649 hdlc(4), 650 bbn1822(5), 651 ieee802(6), 652 e163(7), 653 e164(8), 654 f69(9), 655 x121(10), 656 ipx(11), 657 appleTalk(12), 658 decnetIV(13), 659 banyanVines(14), 660 e164WithNsap(15) 661 } 663 PtopoGenAddr ::= TEXTUAL-CONVENTION 664 STATUS current 665 DESCRIPTION 666 "The value of an address." 667 SYNTAX OCTET STRING (SIZE (0..20)) 669 PtopoChassisIdType ::= TEXTUAL-CONVENTION 670 STATUS current 671 DESCRIPTION 672 "This TC describes the source of a chassis identifier. 674 The enumeration 'chasIdEntPhysicalAlias(1)' represents a 675 chassis identifier based on the value of entPhysicalAlias 676 for a chassis component (i.e., an entPhysicalClass value of 677 'chassis(3)'). 679 The enumeration 'chasIdIfAlias(2)' represents a chassis 680 identifier based on the value of ifAlias for an interface on 681 the containing chassis. 683 The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a 684 chassis identifier based on the value of entPhysicalAlias 685 for a port or backplane component (i.e., entPhysicalClass 686 value of 'port(10)' or 'backplane(4)'), within the 687 containing chassis. 689 The enumeration 'chasIdMacAddress(4)' represents a chassis 690 identifier based on the value of a unicast source MAC 691 address (encoded in network byte order and IEEE 802.3 693 Draft Physical Topology MIB March 1998 695 canonical bit order), of a port on the containing chassis. 697 The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis 698 identifier based on a network address, associated with a 699 particular chassis. The encoded address is actually composed 700 of two fields. The first field is a single octet, 701 representing the IANAAddrFamily for the specific address 702 type, and the second field is the PtopoGenAddr address 703 value." 704 SYNTAX INTEGER { 705 chasIdEntPhysicalAlias(1), 706 chasIdIfAlias(2), 707 chasIdPortEntPhysicalAlias(3), 708 chasIdMacAddress(4), 709 chasIdPtopoGenAddr(5) 710 } 712 PtopoChassisId ::= TEXTUAL-CONVENTION 713 STATUS current 714 DESCRIPTION 715 "This TC describes the format of a chassis identifier 716 string. Objects of this type are always used with an 717 associated PtopoChassisIdType object, which identifies the 718 format of the particular PtopoChassisId object instance. 720 If the associated PtopoChassisIdType object has a value of 721 'chasIdEntPhysicalAlias(1)', then the octet string 722 identifies a particular instance of the entPhysicalAlias 723 object for a chassis component (i.e., an entPhysicalClass 724 value of 'chassis(3)'). 726 If the associated PtopoChassisIdType object has a value of 727 'chasIdIfAlias(2)', then the octet string identifies a 728 particular instance of the ifAlias object for an interface 729 on the containing chassis. 731 If the associated PtopoChassisIdType object has a value of 732 'chasIdPortEntPhysicalAlias(3)', then the octet string 733 identifies a particular instance of the entPhysicalAlias 734 object for a port or backplane component within the 735 containing chassis. 737 If the associated PtopoChassisIdType object has a value of 738 'chasIdMacAddress(4)', then this string identifies a 739 particular unicast source MAC address (encoded in network 741 Draft Physical Topology MIB March 1998 743 byte order and IEEE 802.3 canonical bit order), of a port on 744 the containing chassis. 746 If the associated PtopoChassisIdType object has a value of 747 'chasIdPtopoGenAddr(5)', then this string identifies a 748 particular network address, encoded in network byte order, 749 associated with one or more ports on the containing chassis. 750 The first octet contains the IANAAddrFamily enumeration 751 value for the specific address type, and octets 2 through N 752 contain the PtopoGenAddr address value in network byte 753 order." 754 SYNTAX OCTET STRING (SIZE (1..32)) 756 PtopoPortIdType ::= TEXTUAL-CONVENTION 757 STATUS current 758 DESCRIPTION 759 "This TC describes the source of a particular type of port 760 identifier used in the PTOPO MIB. 762 The enumeration 'portIdIfAlias(1)' represents a port 763 identifier based on the ifAlias MIB object. 765 The enumeration 'portIdPortEntPhysicalAlias(2)' represents a 766 port identifier based on the value of entPhysicalAlias for a 767 port or backplane component (i.e., entPhysicalClass value of 768 'port(10)' or 'backplane(4)'), within the containing 769 chassis. 771 The enumeration 'portIdMacAddr(3)' represents a port 772 identifier based on a unicast source MAC address, which has 773 been detected by the agent and associated with a particular 774 port. 776 The enumeration 'portIdPtopoGenAddr(4)' represents a port 777 identifier based on a network address, detected by the agent 778 and associated with a particular port." 779 SYNTAX INTEGER { 780 portIdIfAlias(1), 781 portIdEntPhysicalAlias(2), 782 portIdMacAddr(3), 783 portIdPtopoGenAddr(4) 784 } 786 PtopoPortId ::= TEXTUAL-CONVENTION 787 STATUS current 789 Draft Physical Topology MIB March 1998 791 DESCRIPTION 792 "This TC describes the format of a port identifier string. 793 Objects of this type are always used with an associated 794 PtopoPortIdType object, which identifies the format of the 795 particular PtopoPortId object instance. 797 If the associated PtopoPortIdType object has a value of 798 'portIdIfAlias(1)', then the octet string identifies a 799 particular instance of the ifAlias object. 801 If the associated PtopoPortIdType object has a value of 802 'portIdEntPhysicalAlias(2)', then the octet string 803 identifies a particular instance of the entPhysicalAlias 804 object for a port component (i.e., entPhysicalClass value of 805 'port(10)'). 807 If the associated PtopoPortIdType object has a value of 808 'portIdMacAddr(3)', then this string identifies a particular 809 unicast source MAC address associated with the port. 811 If the associated PtopoPortIdType object has a value of 812 'portIdPtopoGenAddr(4)', then this string identifies a 813 network address associated with the port. The first octet 814 contains the IANAAddrFamily enumeration value for the 815 specific address type, and octets 2 through N contain the 816 PtopoGenAddr address value in network byte order." 817 SYNTAX OCTET STRING (SIZE (1..32)) 819 PtopoAddrSeenState ::= TEXTUAL-CONVENTION 820 STATUS current 821 DESCRIPTION 822 "This TC describes the state of address detection for a 823 particular type of port identifier used in the PTOPO MIB. 825 The enumeration 'not-used(1)' represents an entry for which 826 the particular MIB object is not applicable to the remote 827 connection endpoint, 829 The enumeration 'unknown(2)' represents an entry for which 830 the particular address collection state is not known. 832 The enumeration 'one-addr(3)' represents an entry for which 833 exactly one source address (of the type indicated by the 834 particular MIB object), has been detected. 836 Draft Physical Topology MIB March 1998 838 The enumeration 'multi-addr(4)' represents an entry for 839 which more than one source address (of the type indicated by 840 the particular MIB object), has been detected. 842 An agent is expected to set the initial state of the 843 PtopoAddrSeenState to 'not-used(1)' or 'unknown(2)'. 845 Note that the PTOPO MIB does not restrict or specify the 846 means in which the PtopoAddrSeenState is known to an agent. 847 In particular, an agent may detect this information through 848 configuration data, or some means other than directly 849 monitoring all port traffic." 850 SYNTAX INTEGER { 851 not-used(1), 852 unknown(2), 853 one-addr(3), 854 multi-addr(4) 855 } 857 -- *********************************************************** 858 -- 859 -- P T O P O D A T A G R O U P 860 -- 861 -- *********************************************************** 863 -- Connection Table 865 ptopoConnTable OBJECT-TYPE 866 SYNTAX SEQUENCE OF PtopoConnEntry 867 MAX-ACCESS not-accessible 868 STATUS current 869 DESCRIPTION 870 "This table contains one or more rows per physical network 871 connection known to this agent. The agent may wish to 872 ensure that only one ptopoConnEntry is present for each 873 local port, or it may choose to maintain multiple 874 ptopoConnEntries for the same local port. 876 Entries based on lower numbered identifier types are 877 preferred over higher numbered identifier types, i.e., lower 878 values of the ptopoConnRemoteChassisType and 879 ptopoConnRemotePortType objects." 880 ::= { ptopoData 1 } 882 ptopoConnEntry OBJECT-TYPE 883 Draft Physical Topology MIB March 1998 885 SYNTAX PtopoConnEntry 886 MAX-ACCESS not-accessible 887 STATUS current 888 DESCRIPTION 889 "Information about a particular physical network connection. 890 Entries may be created and deleted in this table, either 891 manually or by the agent, if a physical topology discovery 892 process is active." 893 INDEX { 894 ptopoConnTimeMark, 895 ptopoConnLocalChassis, 896 ptopoConnLocalPort, 897 ptopoConnIndex 898 } 899 ::= { ptopoConnTable 1 } 901 PtopoConnEntry ::= SEQUENCE { 902 ptopoConnTimeMark TimeFilter, 903 ptopoConnLocalChassis PhysicalIndex, 904 ptopoConnLocalPort PhysicalIndex, 905 ptopoConnIndex Integer32, 906 ptopoConnRemoteChassisType PtopoChassisIdType, 907 ptopoConnRemoteChassis PtopoChassisId, 908 ptopoConnRemotePortType PtopoPortIdType, 909 ptopoConnRemotePort PtopoPortId, 910 ptopoConnDiscAlgorithm AutonomousType, 911 ptopoConnAgentNetAddrType IANAAddrFamily, 912 ptopoConnAgentNetAddr PtopoGenAddr, 913 ptopoConnMultiMacSASeen PtopoAddrSeenState, 914 ptopoConnMultiNetSASeen PtopoAddrSeenState, 915 ptopoConnIsStatic TruthValue, 916 ptopoConnLastVerifyTime TimeStamp, 917 ptopoConnRowStatus RowStatus 918 } 920 ptopoConnTimeMark OBJECT-TYPE 921 SYNTAX TimeFilter 922 MAX-ACCESS not-accessible 923 STATUS current 924 DESCRIPTION 925 "A TimeFilter for this entry. See the TimeFilter textual 926 convention in RFC 2021 to see how this works." 927 ::= { ptopoConnEntry 1 } 929 ptopoConnLocalChassis OBJECT-TYPE 930 Draft Physical Topology MIB March 1998 932 SYNTAX PhysicalIndex 933 MAX-ACCESS not-accessible 934 STATUS current 935 DESCRIPTION 936 "The entPhysicalIndex value used to identify the chassis 937 component associated with the local connection endpoint." 938 ::= { ptopoConnEntry 2 } 940 ptopoConnLocalPort OBJECT-TYPE 941 SYNTAX PhysicalIndex 942 MAX-ACCESS not-accessible 943 STATUS current 944 DESCRIPTION 945 "The entPhysicalIndex value used to identify the port 946 component associated with the local connection endpoint." 947 ::= { ptopoConnEntry 3 } 949 ptopoConnIndex OBJECT-TYPE 950 SYNTAX Integer32 (1..2147483647) 951 MAX-ACCESS not-accessible 952 STATUS current 953 DESCRIPTION 954 "This object represents an arbitrary local integer value 955 used by this agent to identify a particular connection 956 instance, unique only for the indicated local connection 957 endpoint. 959 A particular ptopoConnIndex value may be reused in the event 960 an entry is aged out and later re-learned with the same (or 961 different) remote chassis and port identifiers. 963 An agent is encouraged to assign monotonically increasing 964 index values to new entries, starting with one, after each 965 reboot. It is considered unlikely that the ptopoConnIndex 966 will wrap between reboots." 967 ::= { ptopoConnEntry 4 } 969 ptopoConnRemoteChassisType OBJECT-TYPE 970 SYNTAX PtopoChassisIdType 971 MAX-ACCESS read-create 972 STATUS current 973 DESCRIPTION 974 "The type of encoding used to identify the chassis 975 associated with the remote connection endpoint. 977 Draft Physical Topology MIB March 1998 979 This object may not be modified if the associated 980 ptopoConnRowStatus object has a value of active(1)." 981 ::= { ptopoConnEntry 5 } 983 ptopoConnRemoteChassis OBJECT-TYPE 984 SYNTAX PtopoChassisId 985 MAX-ACCESS read-create 986 STATUS current 987 DESCRIPTION 988 "The string value used to identify the chassis component 989 associated with the remote connection endpoint. 991 This object may not be modified if the associated 992 ptopoConnRowStatus object has a value of active(1)." 993 ::= { ptopoConnEntry 6 } 995 ptopoConnRemotePortType OBJECT-TYPE 996 SYNTAX PtopoPortIdType 997 MAX-ACCESS read-create 998 STATUS current 999 DESCRIPTION 1000 "The type of port identifier encoding used in the associated 1001 'ptopoConnRemotePort' object. 1003 This object may not be modified if the associated 1004 ptopoConnRowStatus object has a value of active(1)." 1005 ::= { ptopoConnEntry 7 } 1007 ptopoConnRemotePort OBJECT-TYPE 1008 SYNTAX PtopoPortId 1009 MAX-ACCESS read-create 1010 STATUS current 1011 DESCRIPTION 1012 "The string value used to identify the port component 1013 associated with the remote connection endpoint. 1015 This object may not be modified if the associated 1016 ptopoConnRowStatus object has a value of active(1)." 1017 ::= { ptopoConnEntry 8 } 1019 ptopoConnDiscAlgorithm OBJECT-TYPE 1020 SYNTAX AutonomousType 1021 MAX-ACCESS read-only 1022 STATUS current 1023 DESCRIPTION 1025 Draft Physical Topology MIB March 1998 1027 "An indication of the algorithm used to discover the 1028 information contained in this conceptual row. 1030 A value of ptopoDiscoveryPDP indicates this entry was 1031 configured using the PTOPO Discovery Protocol. 1033 A value of ptopoDiscoveryLocal indicates this entry was 1034 configured by the local agent, without use of a discovery 1035 protocol. 1037 A value of { 0 0 } indicates this entry was created manually 1038 by an NMS via the associated RowStatus object. " 1039 ::= { ptopoConnEntry 9 } 1041 ptopoConnAgentNetAddrType OBJECT-TYPE 1042 SYNTAX IANAAddrFamily 1043 MAX-ACCESS read-create 1044 STATUS current 1045 DESCRIPTION 1046 "This network address type of the associated 1047 ptopoConnNetAddr object, unless that object contains a zero 1048 length string. In such a case, an NMS application should 1049 ignore any returned value for this object. 1051 This object may not be modified if the associated 1052 ptopoConnRowStatus object has a value of active(1)." 1053 ::= { ptopoConnEntry 10 } 1055 ptopoConnAgentNetAddr OBJECT-TYPE 1056 SYNTAX PtopoGenAddr 1057 MAX-ACCESS read-create 1058 STATUS current 1059 DESCRIPTION 1060 "This object identifies a network address which may be used 1061 to reach an SNMP agent entity containing information for the 1062 chassis and port components represented by the associated 1063 'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects. 1064 If no such address is known, then this object shall contain 1065 an empty string. 1067 This object may not be modified if the associated 1068 ptopoConnRowStatus object has a value of active(1)." 1069 ::= { ptopoConnEntry 11 } 1071 ptopoConnMultiMacSASeen OBJECT-TYPE 1072 Draft Physical Topology MIB March 1998 1074 SYNTAX PtopoAddrSeenState 1075 MAX-ACCESS read-only 1076 STATUS current 1077 DESCRIPTION 1078 "This object indicates if multiple unicast source MAC 1079 addresses have been detected by the agent from the remote 1080 connection endpoint, since the creation of this entry. 1082 If this entry has an associated ptopoConnRemoteChassisType 1083 and/or ptopoConnRemotePortType value other than 1084 'portIdMacAddr(3)', then the value 'not-used(1)' is 1085 returned. 1087 Otherwise, one of the following conditions must be true: 1089 If the agent has not yet detected any unicast source MAC 1090 addresses from the remote port, then the value 'unknown(2)' 1091 is returned. 1093 If the agent has detected exactly one unicast source MAC 1094 address from the remote port, then the value 'one-addr(3)' 1095 is returned. 1097 If the agent has detected more than one unicast source MAC 1098 address from the remote port, then the value 'multi-addr(4)' 1099 is returned." 1100 ::= { ptopoConnEntry 12 } 1102 ptopoConnMultiNetSASeen OBJECT-TYPE 1103 SYNTAX PtopoAddrSeenState 1104 MAX-ACCESS read-only 1105 STATUS current 1106 DESCRIPTION 1107 "This object indicates if multiple network layer source 1108 addresses have been detected by the agent from the remote 1109 connection endpoint, since the creation of this entry. 1111 If this entry has an associated ptopoConnRemoteChassisType 1112 or ptopoConnRemotePortType value other than 1113 'portIdGenAddr(4)' then the value 'not-used(1)' is returned. 1115 Otherwise, one of the following conditions must be true: 1117 If the agent has not yet detected any network source 1118 addresses of the appropriate type from the remote port, then 1120 Draft Physical Topology MIB March 1998 1122 the value 'unknown(2)' is returned. 1124 If the agent has detected exactly one network source address 1125 of the appropriate type from the remote port, then the value 1126 'one-addr(3)' is returned. 1128 If the agent has detected more than one network source 1129 address (of the same appropriate type) from the remote port, 1130 this the value 'multi-addr(4)' is returned." 1131 ::= { ptopoConnEntry 13 } 1133 ptopoConnIsStatic OBJECT-TYPE 1134 SYNTAX TruthValue 1135 MAX-ACCESS read-create 1136 STATUS current 1137 DESCRIPTION 1138 "This object identifies static ptopoConnEntries. If this 1139 object has the value 'true(1)', then this entry is not 1140 subject to any age-out mechanisms implemented by the agent. 1142 If this object has the value 'false(2)', then this entry is 1143 subject to all age-out mechanisms implemented by the agent. 1145 This object may not be modified if the associated 1146 ptopoConnRowStatus object has a value of active(1)." 1147 DEFVAL { false } 1148 ::= { ptopoConnEntry 14 } 1150 ptopoConnLastVerifyTime OBJECT-TYPE 1151 SYNTAX TimeStamp 1152 MAX-ACCESS read-only 1153 STATUS current 1154 DESCRIPTION 1155 "If the associated value of ptopoConnIsStatic is equal to 1156 'false(2)', then this object contains the value of sysUpTime 1157 at the time the conceptual row was last verified by the 1158 agent, e.g., via reception of a topology protocol message, 1159 pertaining to the associated remote chassis and port. 1161 If the associated value of ptopoConnIsStatic is equal to 1162 'true(1)', then this object shall contain the value of 1163 sysUpTime at the time this entry was last activated (i.e., 1164 ptopoConnRowStatus set to 'active(1)')." 1165 ::= { ptopoConnEntry 15 } 1167 Draft Physical Topology MIB March 1998 1169 ptopoConnRowStatus OBJECT-TYPE 1170 SYNTAX RowStatus 1171 MAX-ACCESS read-create 1172 STATUS current 1173 DESCRIPTION 1174 "The status of this conceptual row." 1175 ::= { ptopoConnEntry 16 } 1177 -- *********************************************************** 1178 -- 1179 -- P T O P O G E N E R A L G R O U P 1180 -- 1181 -- *********************************************************** 1183 -- last change time stamp for the whole MIB 1185 ptopoLastChangeTime OBJECT-TYPE 1186 SYNTAX TimeStamp 1187 MAX-ACCESS read-only 1188 STATUS current 1189 DESCRIPTION 1190 "The value of sysUpTime at the time a conceptual row is 1191 created, modified, or deleted in the ptopoConnTable. 1193 An NMS can use this object to reduce polling of the 1194 ptopoData group objects." 1195 ::= { ptopoGeneral 1 } 1197 ptopoConnTabInserts OBJECT-TYPE 1198 SYNTAX Counter32 1199 MAX-ACCESS read-only 1200 STATUS current 1201 DESCRIPTION 1202 "The number of times an entry has been inserted into the 1203 ptopoConnTable." 1204 ::= { ptopoGeneral 2 } 1206 ptopoConnTabDeletes OBJECT-TYPE 1207 SYNTAX Counter32 1208 MAX-ACCESS read-only 1209 STATUS current 1210 DESCRIPTION 1211 "The number of times an entry has been deleted from the 1212 ptopoConnTable." 1213 ::= { ptopoGeneral 3 } 1215 Draft Physical Topology MIB March 1998 1217 ptopoConnTabDrops OBJECT-TYPE 1218 SYNTAX Counter32 1219 MAX-ACCESS read-only 1220 STATUS current 1221 DESCRIPTION 1222 "The number of times an entry would have been added to the 1223 ptopoConnTable, (e.g., via information learned from a 1224 topology protocol), but was not because of insufficient 1225 resources." 1226 ::= { ptopoGeneral 4 } 1228 ptopoConnTabAgeouts OBJECT-TYPE 1229 SYNTAX Counter32 1230 MAX-ACCESS read-only 1231 STATUS current 1232 DESCRIPTION 1233 "The number of times an entry has been deleted from the 1234 ptopoConnTable because the information timeliness interval 1235 for that entry has expired." 1236 ::= { ptopoGeneral 5 } 1238 -- *********************************************************** 1239 -- 1240 -- P T O P O C O N F I G G R O U P 1241 -- 1242 -- *********************************************************** 1244 ptopoConfigTrapInterval OBJECT-TYPE 1245 SYNTAX Integer32 (0 | 5..3600) 1246 UNITS "seconds" 1247 MAX-ACCESS read-write 1248 STATUS current 1249 DESCRIPTION 1250 "This object controls the transmission of PTOPO traps. 1252 If this object has a value of zero, then no 1253 ptopoConfigChange notifications will be transmitted by the 1254 agent. 1256 If this object has a non-zero value, then the agent must not 1257 generate more than one ptopoConfigChange trap-event in the 1258 indicated period, where a 'trap-event' is the transmission 1259 of a single trap (or inform) PDU to a list of trap 1260 destinations. If additional configuration changes occur 1261 within the indicated throttling period, then these trap- 1263 Draft Physical Topology MIB March 1998 1265 events must be suppressed by the agent. An NMS should 1266 periodically check the value of ptopoLastChangeTime to 1267 detect any missed ptopoConfigChange trap-events, e.g. due to 1268 throttling or transmission loss. 1270 If notification transmission is enabled, the suggested 1271 default throttling period is 60 seconds, but transmission 1272 should be disabled by default. 1274 If the agent is capable of storing non-volatile 1275 configuration, then the value of this object must be 1276 restored after a re-initialization of the management 1277 system." 1278 DEFVAL { 0 } 1279 ::= { ptopoConfig 1 } 1281 ptopoConfigMaxHoldTime OBJECT-TYPE 1282 SYNTAX Integer32 (1..2147483647) 1283 UNITS "seconds" 1284 MAX-ACCESS read-write 1285 STATUS current 1286 DESCRIPTION 1287 "This object specifies the desired time interval for which 1288 an agent will maintain dynamic ptopoConnEntries. 1290 After the specified number of seconds since the last time an 1291 entry was verified, in the absence of new verification 1292 (e.g., receipt of a topology protocol message), the agent 1293 shall remove the entry. Note that entries may not always be 1294 removed immediately, but may possibly be removed at periodic 1295 garbage collection intervals. 1297 This object only affects dynamic ptopoConnEntries, i.e. for 1298 which ptopoConnIsStatic equals 'false(2)'. Static entries 1299 are not aged out. 1301 Note that dynamic ptopoConnEntries may also be removed by 1302 the agent due to the expired timeliness of learned topology 1303 information (e.g., timeliness interval for a remote port 1304 expires). The actual age-out interval for a given entry is 1305 defined by the following formula: 1307 age-out-time = 1308 min(ptopoConfigMaxHoldTime, ) 1310 Draft Physical Topology MIB March 1998 1312 where is determined by the 1313 discovery algorithm, and may be different for each entry. 1314 For entries discovered with PDP, this is the particular 1315 'time-to-live' value from the most recent PDP message 1316 associated with the entry." 1317 DEFVAL { 300 } 1318 ::= { ptopoConfig 2 } 1320 -- PTOPO MIB Trap Definitions 1321 ptopoMIBTraps OBJECT IDENTIFIER ::= { ptopoMIB 2 } 1322 ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 } 1324 ptopoConfigChange NOTIFICATION-TYPE 1325 OBJECTS { 1326 ptopoConnTabInserts, 1327 ptopoConnTabDeletes, 1328 ptopoConnTabDrops, 1329 ptopoConnTabAgeouts 1330 } 1331 STATUS current 1332 DESCRIPTION 1333 "A ptopoConfigChange trap is sent when the value of 1334 ptopoLastChangeTime changes. It can be utilized by an NMS to 1335 trigger physical topology table maintenance polls. 1337 Note that transmission of ptopoConfigChange notifications 1338 are throttled by the agent, as specified by the 1339 'ptopoConfigTrapInterval' object." 1340 ::= { ptopoMIBTrapPrefix 1 } 1342 -- PTOPO Registration Points 1344 ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 } 1346 -- values used with ptopoConnDiscAlgorithm object 1347 ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 } 1349 ptopoDiscoveryPDP OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 } 1350 ptopoDiscoveryLocal OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 2 } 1352 -- conformance information 1353 Draft Physical Topology MIB March 1998 1355 ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 } 1357 ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 } 1358 ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 } 1360 -- compliance statements 1362 ptopoCompliance MODULE-COMPLIANCE 1363 STATUS current 1364 DESCRIPTION 1365 "The compliance statement for SNMP entities which implement 1366 the PTOPO MIB." 1367 MODULE -- this module 1368 MANDATORY-GROUPS { 1369 ptopoDataGroup, 1370 ptopoGeneralGroup, 1371 ptopoConfigGroup, 1372 ptopoNotificationsGroup 1373 } 1374 ::= { ptopoCompliances 1 } 1376 -- MIB groupings 1378 ptopoDataGroup OBJECT-GROUP 1379 OBJECTS { 1380 ptopoConnRemoteChassisType, 1381 ptopoConnRemoteChassis, 1382 ptopoConnRemotePortType, 1383 ptopoConnRemotePort, 1384 ptopoConnDiscAlgorithm, 1385 ptopoConnAgentNetAddrType, 1386 ptopoConnAgentNetAddr, 1387 ptopoConnMultiMacSASeen, 1388 ptopoConnMultiNetSASeen, 1389 ptopoConnIsStatic, 1390 ptopoConnLastVerifyTime, 1391 ptopoConnRowStatus 1392 } 1393 STATUS current 1394 DESCRIPTION 1395 "The collection of objects which are used to represent 1396 physical topology information for which a single agent 1397 provides management information. 1399 This group is mandatory for all implementations of the PTOPO 1401 Draft Physical Topology MIB March 1998 1403 MIB." 1404 ::= { ptopoGroups 1 } 1406 ptopoGeneralGroup OBJECT-GROUP 1407 OBJECTS { 1408 ptopoLastChangeTime, 1409 ptopoConnTabInserts, 1410 ptopoConnTabDeletes, 1411 ptopoConnTabDrops, 1412 ptopoConnTabAgeouts 1413 } 1414 STATUS current 1415 DESCRIPTION 1416 "The collection of objects which are used to report the 1417 general status of the PTOPO MIB implementation. 1419 This group is mandatory for all agents which implement the 1420 PTOPO MIB." 1421 ::= { ptopoGroups 2 } 1423 ptopoConfigGroup OBJECT-GROUP 1424 OBJECTS { 1425 ptopoConfigTrapInterval, 1426 ptopoConfigMaxHoldTime 1427 } 1428 STATUS current 1429 DESCRIPTION 1430 "The collection of objects which are used to configure the 1431 PTOPO MIB implementation behavior. 1433 This group is mandatory for agents which implement the PTOPO 1434 MIB." 1435 ::= { ptopoGroups 3 } 1437 ptopoNotificationsGroup NOTIFICATION-GROUP 1438 NOTIFICATIONS { 1439 ptopoConfigChange 1440 } 1441 STATUS current 1442 DESCRIPTION 1443 "The collection of notifications used to indicate PTOPO MIB 1444 data consistency and general status information. 1446 This group is mandatory for agents which implement the PTOPO 1448 Draft Physical Topology MIB March 1998 1450 MIB." 1451 ::= { ptopoGroups 4 } 1453 END 1454 Draft Physical Topology MIB March 1998 1456 6. References 1458 [ENTITY-EXT] 1459 Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent 1460 Component Identification", draft-bierman-entmib-compid-00.txt, 1461 Cisco Systems, July 1997. 1463 [RFC1157] 1464 Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1465 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1466 International, MIT Laboratory for Computer Science, May 1990. 1468 [RFC1213] 1469 McCloghrie, K., and M. Rose, Editors, "Management Information Base 1470 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1471 RFC 1213, Hughes LAN Systems, Performance Systems International, 1472 March 1991. 1474 [RFC1493] 1475 E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie, "Definitions 1476 of Managed Objects for Bridges", RFC 1493, Cisco Systems, Inc., 1477 Digital Equipment Corporation, Hughes LAN Systems, Inc., July 1993. 1479 [RFC1700] 1480 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1481 USC/Information Sciences Institute, October 1994. 1483 [RFC1902] 1484 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1485 S. Waldbusser, "Structure of Management Information for version 2 1486 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1487 January 1996. 1489 [RFC1903] 1490 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1491 S. Waldbusser, "Textual Conventions for version 2 of the Simple 1492 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1494 [RFC1904] 1495 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1496 S. Waldbusser, "Conformance Statements for version 2 of the Simple 1497 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1499 [RFC1905] 1500 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1502 Draft Physical Topology MIB March 1998 1504 S. Waldbusser, "Protocol Operations for version 2 of the Simple 1505 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1507 [RFC2021] 1508 S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021, 1509 International Network Services, January 1997. 1511 [RFC2037] 1512 McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, 1513 Cisco Systems, October 1996. 1515 [RFC2108] 1516 K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, "Definitions 1517 of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", 1518 RFC 2108, 3Com Corporation, Madge Networks (Israel) Ltd., Coloma 1519 Communications, Cisco Systems Inc., February 1997. 1521 [RFC2233] 1522 McCloghrie, K., and Kastenholtz, F., "The Interfaces Group MIB 1523 using SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. 1525 Draft Physical Topology MIB March 1998 1527 7. Security Considerations 1529 This MIB exposes information about the physical connectivity for a 1530 particular portion of a network. A network administrator may wish to 1531 restrict SNMP access to such information, but such agent security 1532 configuration is beyond the scope of this document. 1534 A network administrator may also wish to inhibit transmission of any 1535 ptopoConfigChange notification by setting the ptopoConfigTrapInterval 1536 object to zero. 1538 8. Authors' Addresses 1540 Andy Bierman 1541 Cisco Systems 1542 170 West Tasman Drive 1543 San Jose, CA 95134 1544 Phone: 408-527-3711 1545 Email: abierman@cisco.com 1547 Kendall S. Jones 1548 Bay Networks 1549 4401 Great America Parkway 1550 Santa Clara, CA 95134 1551 Phone: 408-495-7356 1552 Email: kjones@baynetworks.com 1554 Draft Physical Topology MIB March 1998 1556 Table of Contents 1558 1 Introduction .................................................... 1 1559 2 The SNMP Network Management Framework ........................... 2 1560 2.1 Object Definitions ............................................ 2 1561 3 Overview ........................................................ 2 1562 3.1 Background and Concepts ....................................... 3 1563 3.2 Terms ......................................................... 4 1564 3.3 Functionality Goals ........................................... 5 1565 3.4 Design Goals .................................................. 6 1566 4 Topology Framework .............................................. 7 1567 4.1 Framework Overview ............................................ 7 1568 4.1.1 Topology Mechanisms ......................................... 8 1569 4.1.2 Manager Process ............................................. 9 1570 5 Physical Topology MIB ........................................... 10 1571 5.1 Persistent Identifiers ........................................ 10 1572 5.2 Relationship to Entity MIB .................................... 11 1573 5.3 Relationship to Interfaces MIB ................................ 11 1574 5.4 Relationship to RMON-2 MIB .................................... 12 1575 5.5 Relationship to Bridge MIB .................................... 12 1576 5.6 Relationship to Repeater MIB .................................. 12 1577 5.7 MIB Structure ................................................. 12 1578 5.7.1 ptopoData Group ............................................. 13 1579 5.7.2 ptopoGeneral Group .......................................... 13 1580 5.7.3 ptopoConfig Group ........................................... 13 1581 5.8 Physical Topology MIB Definitions ............................. 13 1582 6 References ...................................................... 33 1583 7 Security Considerations ......................................... 35 1584 8 Authors' Addresses .............................................. 35