idnits 2.17.1 draft-ietf-ptopomib-mib-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 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 (17 September 1997) is 9717 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 1493 (Obsoleted by RFC 4188) ** 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: 21 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft Physical Topology MIB September 1997 4 5 Physical Topology MIB 7 17 September 1997 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 September 1997 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. 86 Draft Physical Topology MIB September 1997 88 The scope of the physical topology (PTOPO) mechanism is the 89 identification of connections between two network ports. Network 90 addresses of SNMP agents containing management information associated 91 with each port can also be identified. 93 3.1. Background and Concepts 95 The need to understand the physical relationships between devices in a 96 network has always been an important aspect of network management. With 97 the increasing complexity of multi-segment and multi-media hubs and 98 switching devices, and management applications that want to identify hot 99 spots in the network, isolate complex faults (such as configuration 100 problems) to the physical port, and manage virtual networks (VLANs), the 101 need for accurate, timely, and system wide physical topology is becoming 102 more and more critical to maintaining a mission critical network. 104 Most of today's management platforms do a good job at discovering the 105 logical topology at the network layer but do not help much in 106 understanding the actual physical interconnection. This is due to a 107 lack of standard topology mechanisms at the physical layer to collect 108 the physical topology information as well as a standard MIB to return 109 topology information to the management workstation. 111 Standard topology mechanisms exist for certain media types (such as 112 FDDI) and proprietary mechanisms exist for other media such as shared 113 media Ethernet, switched Ethernet, and Token Ring. While standardizing 114 these or other mechanisms for each of these technologies could be a 115 painstaking task, standardizing a common MIB and a topology framework 116 that allows co-existence of multiple topology mechanisms to populate 117 these MIBs can go a long way toward achieving the goal of providing 118 network-wide physical topology information at the network management 119 workstation. The topology framework should specify the core 120 requirements for topology mechanisms in order to provide the data 121 necessary to populate the common topology MIB. 123 These requirements form a set of guidelines to direct the eventual 124 standardization of a set of topology mechanisms for the various 125 communication media. In the meantime, the common MIB will allow 126 creation of physical topology databases which will allow applications to 127 provide value added services on top of this rich set of data. 129 Draft Physical Topology MIB September 1997 131 3.2. Terms 133 Some terms are used throughout this document: 135 Physical Topology 136 Physical topology represents the topology model for layer 1 of the 137 OSI stack - the physical layer. Physical topology consists of 138 identifying the devices on the network and how they are physically 139 interconnected. By definition of this document, physical topology 140 does not imply a physical relationship between ports on the same 141 device. Other means exist for determining these relationships 142 (e.g., Entity MIB). 144 Logical Topology 145 Logical topology indicates how devices are related based on some 146 system level attribute. Often this is based on the OSI 147 communication layer. For instance, network layer topology, or 148 layer 3 topology, uses network layer address hierarchies to 149 construct a topological relationship. Management platforms 150 typically present Layer-3-based topology. This is done by 151 'discovering' the IP addresses on a network and then grouping these 152 logically by the subnet portion of the address. Other logical 153 views of topology include layer-2 based views based on VLAN 154 membership, and higher layer views such as workgroup membership. 155 Most higher-layer topology views use network address or user name 156 to represent members of the topology space. 158 Chassis 159 A chassis is a physical component which contains other physical 160 components. It is identified by an entPhysicalEntry with an 161 entPhysicalClass value of 'chassis(3)' and an 162 entPhysicalContainedIn value of zero. A chassis identifier 163 consists of a globally unique DisplayString. 165 Local Chassis 166 The particular chassis containing the SNMP agent implementing the 167 PTOPO MIB. 169 Port 170 A port is a physical component which can be connected to another 171 port through some medium. It is identified by an entPhysicalEntry 172 with an entPhysicalClass value of 'port(10)'. A port identifier 173 consists of a DisplayString which must be unique within the context 174 of the chassis which contains the port. 176 Draft Physical Topology MIB September 1997 178 Connection Endpoint 179 A connection endpoint consists of a physical port, which is 180 contained within a single physical chassis. 182 Connection Endpoint Identifier 183 A connection endpoint is identified by a globally unique chassis 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 224 Draft Physical Topology MIB September 1997 226 within a given network, with clear rules describing how these 227 mechanisms should interact. 229 - Specify, where appropriate, topology mechanisms for specific media 230 types. Where standard or industry-accepted mechanisms exist, 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 272 Draft Physical Topology MIB September 1997 274 Entity MIB. 276 - Partial Topology Support 277 Physical topology data for remote components may only be partially 278 available to an agent. An enumerated INTEGER hierarchy of 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 318 Draft Physical Topology MIB September 1997 320 sinks of data. Both types of devices may implement the physical 321 topology MIB, although implementation within leaf devices is much 322 less critical. 324 Topology Mechanisms 325 A topology mechanism allows the management agents to collect the 326 information required to populate the topology MIB. Many instances 327 of a particular topology mechanism may be in use on a given 328 network, and many different mechanisms may be employed. In some 329 cases, multiple mechanisms may overlap across part of the physical 330 topology. Agents may need to be configured so that they know which 331 mechanism(s) are in use on any given portion of the network. Most 332 topology mechanisms need to be bounded to a subset of the network 333 to contain their impact on the network and allow the manager to 334 collect topology information for a limited subset of devices. 336 Most topology mechanisms are naturally bounded by the media on 337 which they run (e.g. FDDI topology mechanism) or by routers in the 338 network that intentionally block these mechanisms from crossing 339 into other parts of the network. 341 Local Topology Data and the Local Topology MIB 342 Each managed device collects physical topology information from the 343 network, based on the topology mechanisms it is configured to use. 344 The data represents this agent's view of the physical network and 345 may or may not provide enough data to understand the local physical 346 topology surrounding this agent. It may be necessary to gather 347 local topology data from a number of agents in order to completely 348 understand the local physical topology. Part of the local topology 349 data collected must include the identification of other local 350 agents which may contain additional topology information. The 351 definition of 'local' varies based on the topology mechanism or 352 mechanisms being used. 354 Manager Process 355 A manager is responsible for querying management agents to obtain 356 their local topology information and their knowledge of additional 357 local agents. The manager might need to query some or all local 358 agents to build an accurate view of the physical network. 360 4.1.1. Topology Mechanisms 362 A topology mechanism is a means, possibly requiring some sort of 363 protocol, by which devices determine topology information. The formal 364 requirement is that the mechanism should provide sufficient information 365 Draft Physical Topology MIB September 1997 367 such that a manager can accurately determine the physical topology of a 368 set of devices by querying all of those devices for their local view of 369 the topology. In other words, the mechanism may not be robust enough to 370 allow the manager to accurately determine any part of the network by 371 querying a single agent - rather it may need to query all agents to 372 understand the topology. 374 Topology mechanisms can be active or passive. Active mechanisms require 375 a device to send and receive topology protocol packets. These packets 376 provide the device ID of the source of the packet and may also indicate 377 out which port the packet was transmitted. When receiving these 378 packets, devices typically are required to identify on which port that 379 packet was received. 381 Passive mechanisms take advantage of data on the network to populate the 382 topology MIB. By maintaining a list of device identifiers seen on each 383 port of all devices in a network, it is possible to construct an 384 accurate physical topology of the network. 386 A device can act as a boundary device or an intermediate point of a 387 topology mechanism. If it is a boundary device, it will prevent active 388 topology mechanisms from passing through to other ports on that device. 389 Routers are often boundary devices for active topology mechanisms. 390 Boundary devices serve a critical role in containing topology mechanisms 391 within a set of devices. This limits the size of topology tables 392 maintained by the agent, reduces calculations required by managers, and 393 prevents proliferating topology protocols across the network. 395 It is possible to have ports that support more than one topology 396 mechanism. In general this simply allows the port to collect more 397 robust topology information which should allow the manager to create 398 more accurate physical topologies. If the set of devices that support 399 each mechanism has only minimal overlap, the manager may need to work 400 with the union of the two sets which could increase the processing 401 requirement substantially. 403 4.1.2. Manager Process 405 A manager uses the following process to determine the physical topology 406 of a portion of the network using a common topology mechanism. Limiting 407 the manager process to those devices using a common mechanism is not 408 required, but it does contain the effort and allows the topology to be 409 built piece by piece in a methodical way. The process described assumes 410 that a single topology mechanism is in use across the set of devices 411 over which physical topology is being determined. Manager processing 412 Draft Physical Topology MIB September 1997 414 for overlapping topology mechanisms is described subsequently. 416 - a manager first identifies a managed device on the network to begin 417 the physical topology collection process 419 - the manager chooses a port to begin the topology determination and 420 obtains the topology mechanism and instance for that port 422 - for each port on the device which use the same instance of this 423 topology mechanism, the manager obtains the topology data for that 424 port and any downstream agent identities. 426 - the manager then queries all downstream agents identified by this 427 device and repeats the previous step. 429 - the manager continues walking through the topology until it has no 430 other new agents identified and has collected topology data from 431 all agents. 433 - the manager then performs topology calculations as required based 434 on topology data returned to determine the actual physical topology 435 of this collection of devices. 437 - once this portion of the network has been mapped, the manager 438 should identify other ports on devices that are running a different 439 instance of the topology mechanism or a different topology 440 mechanism altogether and repeat the process to map that topology. 442 - following this iterative procedure, the physical topology of an 443 arbitrarily large network can be calculated. 445 5. Physical Topology MIB 447 This section describes and defines the Physical Topology MIB. 449 5.1. Persistent Identifiers 451 The PTOPO MIB utilizes non-volatile identifiers to distinguish 452 individual chassis and port components. These identifiers are 453 associated with external objects in order to relate topology information 454 to the existing managed objects. 456 In particular, an object from the Entity MIB or Interfaces MIB can be 457 used as the 'reference-point' for a connection component identifier. 459 Draft Physical Topology MIB September 1997 461 The Physical Topology MIB uses two identifier types pertaining to the 462 PTOPO MIB: 464 - globally unique chassis identifiers. 466 - port identifiers; unique only within the chassis which contains the 467 port. 469 Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes 470 in length, This supports flexible naming conventions and constrains the 471 non-volatile storage requirements for an agent. 473 5.2. Relationship to Entity MIB 475 The Entity MIB [RFC2037] allows the physical component inventory and 476 hierarchy to be identified. However, the Entity MIB does not provide 477 persistent component identifiers, which are required for the PTOPO MIB. 478 Therefore, an extension to the Entity MIB is defined [ENTITY-EXT] to 479 provide that feature. The new table augments the entPhysicalTable, and 480 adds a read-write 'alias' identifier, similar to the ifAlias MIB object 481 for interfaces. 483 For agents implementing the PTOPO MIB, this new object must be used to 484 represent the chassis identifier. Port identifiers can be based on the 485 entPhysicalAlias object associated with the port, but only if the port 486 is not represented as an interface in the ifXTable. 488 Implementation of the entPhysicalGroup and entPhysicalXGroup is 489 mandatory for SNMP agents which implement the PTOPO MIB. 491 5.3. Relationship to Interfaces MIB 493 The PTOPO MIB requires a persistent identifier for each port. The 494 Interfaces MIB [RFC1573] provides a standard mechanism for managing 495 network interfaces. Unfortunately, not all ports which may be 496 represented in the PTOPO MIB are also represented in the Interfaces MIB 497 (e.g., repeater ports). 499 For agents which implement the PTOPO MIB, for each port represented in 500 the Interfaces MIB, the agent must use the associated ifAlias value for 501 the port identifier. For each port not represented in the Interfaces 502 MIB, the associated entPhysicalAlias value must be used for the port 503 identifier. 505 Draft Physical Topology MIB September 1997 507 5.4. Relationship to RMON-2 MIB 509 The RMON-2 MIB [RFC2021] contains address mapping information which can 510 be integrated with physical topology information. The physical ports 511 identified in a physical topology MIB can be related to the MAC and 512 network layer addresses found in the addressMapTable. 514 5.5. Relationship to Bridge MIB 516 The Bridge MIB [RFC1493] contains information which may relate to 517 physical ports represented in the ptopoConnTable. Entries in the 518 dot1dBasePortTable and dot1dStpPortTable can by related to physical 519 ports represented in the PTOPO MIB. Also, bridge port MAC addresses may 520 be used as chassis and port identifiers in some situations. 522 5.6. Relationship to Repeater MIB 524 The Repeater MIB [RFC2108] contains information which may relate to 525 physical ports represented in the PTOPO MIB. Entries in the 526 rptrPortTable and rptrMonitorPortTable can by related to physical ports 527 represented in the ptopoConnTable. Entries in the rptrInfoTable and 528 rptrMonTable can be related to repeater backplanes possibly represented 529 in the ptopoConnTable. 531 5.7. MIB Structure 533 The PTOPO MIB contains three MIB object groups: 535 - ptopoData 536 Exposes physical topology data learned from discovery protocols 537 and/or manual configuration. 539 - ptopoGeneral 540 Contains general information regarding PTOPO MIB status. 542 - ptopoConfig 543 Contains configuration variables for the PTOPO MIB agent function. 545 5.7.1. ptopoData Group 547 This group contains a single table to identity physical topology data. 549 The ptopoConnTable contains information about the connections learned or 550 configured on behalf of the PTOPO MIB SNMP Agent. 552 Draft Physical Topology MIB September 1997 554 5.7.2. ptopoGeneral Group 556 This group contains some scalar objects to report the status of the 557 PTOPO MIB information currently known to the SNMP Agent. The global last 558 change time, and table add and delete counters allow an NMS to set 559 threshold alarms to trigger PTOPO polling. 561 5.7.3. ptopoConfig Group 563 This group contains tables to configure the behavior of the physical 564 topology function. The transmission of ptopoLastChange traps can be 565 configured using the ptopoConfigTrapsEnabled scalar MIB object. 567 5.8. Physical Topology MIB Definitions 569 PTOPO-MIB DEFINITIONS ::= BEGIN 571 IMPORTS 572 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32 573 FROM SNMPv2-SMI 574 TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue 575 FROM SNMPv2-TC 576 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 577 FROM SNMPv2-CONF 578 TimeFilter 579 FROM RMON2-MIB 580 PhysicalIndex 581 FROM ENTITY-MIB; 583 ptopoMIB MODULE-IDENTITY 584 LAST-UPDATED "9709090000Z" 585 ORGANIZATION "IETF; PTOPOMIB Working Group" 586 CONTACT-INFO 587 "PTOPOMIB WG Discussion: 588 ptopo@3com.com 589 Subscription: 590 majordomo@3com.com 591 msg body: [un]subscribe ptopomib 593 Andy Bierman 594 Cisco Systems Inc. 595 170 West Tasman Drive 596 San Jose, CA 95134 597 408-527-3711 598 abierman@cisco.com 600 Draft Physical Topology MIB September 1997 602 Kendall S. Jones 603 Bay Networks 604 4401 Great America Parkway 605 Santa Clara, CA 95134 606 408-495-7356 607 kjones@baynetworks.com" 608 DESCRIPTION 609 "The MIB module for physical topology information." 610 ::= { experimental xx } 612 ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } 614 -- MIB groups 615 ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } 616 ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } 617 ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } 619 -- textual conventions 621 -- 622 -- IANAAddrFamily TC copied from 623 -- draft-ietf-disman-framework-00.txt 624 -- Eventually, it will be included from a general TC module 625 -- 626 IANAAddrFamily ::= TEXTUAL-CONVENTION 627 STATUS current 628 DESCRIPTION 629 "An address family. Values are defined in Assigned Numbers, 630 RFC1700. Note that not all these values make sense in all 631 contexts where this type is used in this MIB, but they are 632 included for completeness." 633 REFERENCE 634 "Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS" 635 SYNTAX INTEGER { 636 other(0), 637 ipV4(1), 638 ipV6(2), 639 nsap(3), 640 hdlc(4), 641 bbn1822(5), 642 ieee802(6), 643 e163(7), 644 e164(8), 645 f69(9), 647 Draft Physical Topology MIB September 1997 649 x121(10), 650 ipx(11), 651 appleTalk(12), 652 decnetIV(13), 653 banyanVines(14), 654 e164WithNsap(15) 655 } 657 PtopoGenAddr ::= TEXTUAL-CONVENTION 658 STATUS current 659 DESCRIPTION 660 "The value of an address." 661 SYNTAX OCTET STRING (SIZE (0..20)) 663 PtopoChassisIdType ::= TEXTUAL-CONVENTION 664 STATUS current 665 DESCRIPTION 666 "This TC describes the source of a chassis identifier. 668 The enumeration 'chasIdEntPhysicalAlias(1)' represents a 669 chassis identifier based on the value of entPhysicalAlias 670 for a chassis component (i.e., an entPhysicalClass value of 671 'chassis(3)'). 673 The enumeration 'chasIdIfAlias(2)' represents a chassis 674 identifier based on the value of ifAlias for an interface on 675 the containing chassis. 677 The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a 678 chassis identifier based on the value of entPhysicalAlias 679 for a port or backplane component (i.e., entPhysicalClass 680 value of 'port(10)' or 'backplane(4)'), within the 681 containing chassis. 683 The enumeration 'chasIdMacAddress(4)' represents a chassis 684 identifier based on the value of a unicast source MAC 685 address (encoded in network byte order and IEEE 802.3 686 canonical bit order), of a port on the containing chassis. 688 The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis 689 identifier based on a network address, associated with a 690 particular chassis. The encoded address is actually composed 691 of two fields. The first field is a single octet, 692 representing the IANAAddrFamily for the specific address 693 type, and the second field is the PtopoGenAddr address 695 Draft Physical Topology MIB September 1997 697 value." 698 SYNTAX INTEGER { 699 chasIdEntPhysicalAlias(1), 700 chasIdIfAlias(2), 701 chasIdPortEntPhysicalAlias(3), 702 chasIdMacAddress(4), 703 chasIdPtopoGenAddr(5) 704 } 706 PtopoChassisId ::= TEXTUAL-CONVENTION 707 STATUS current 708 DESCRIPTION 709 "This TC describes the format of a chassis identifier 710 string. Objects of this type are always used with an 711 associated PtopoChassisIdType object, which identifies the 712 format of the particular PtopoChassisId object instance. 714 If the associated PtopoChassisIdType object has a value of 715 'chasIdEntPhysicalAlias(1)', then the octet string 716 identifies a particular instance of the entPhysicalAlias 717 object for a chassis component (i.e., an entPhysicalClass 718 value of 'chassis(3)'). 720 If the associated PtopoChassisIdType object has a value of 721 'chasIdIfAlias(2)', then the octet string identifies a 722 particular instance of the ifAlias object for an interface 723 on the containing chassis. 725 If the associated PtopoChassisIdType object has a value of 726 'chasIdPortEntPhysicalAlias(3)', then the octet string 727 identifies a particular instance of the entPhysicalAlias 728 object for a port or backplane component within the 729 containing chassis. 731 If the associated PtopoChassisIdType object has a value of 732 'chasIdMacAddress(4)', then this string identifies a 733 particular unicast source MAC address (encoded in network 734 byte order and IEEE 802.3 canonical bit order), of a port on 735 the containing chassis. 737 If the associated PtopoChassisIdType object has a value of 738 'chasIdPtopoGenAddr(5)', then this string identifies a 739 particular network address, encoded in network byte order, 740 associated with one or more ports on the containing chassis. 741 The first octet contains the IANAAddrFamily enumeration 743 Draft Physical Topology MIB September 1997 745 value for the specific address type, and octets 2 through N 746 contain the PtopoGenAddr address value in network byte 747 order." 748 SYNTAX OCTET STRING (SIZE (1..32)) 750 PtopoPortIdType ::= TEXTUAL-CONVENTION 751 STATUS current 752 DESCRIPTION 753 "This TC describes the source of a particular type of port 754 identifier used in the PTOPO MIB. 756 The enumeration 'portIdIfAlias(1)' represents a port 757 identifier based on the ifAlias MIB object. 759 The enumeration 'portIdPortEntPhysicalAlias(2)' represents a 760 port identifier based on the value of entPhysicalAlias for a 761 port or backplane component (i.e., entPhysicalClass value of 762 'port(10)' or 'backplane(4)'), within the containing 763 chassis. 765 The enumeration 'portIdMacAddr(3)' represents a port 766 identifier based on a unicast source MAC address, which has 767 been detected by the agent and associated with a particular 768 port. 770 The enumeration 'portIdPtopoGenAddr(4)' represents a port 771 identifier based on a network address, detected by the agent 772 and associated with a particular port." 773 SYNTAX INTEGER { 774 portIdIfAlias(1), 775 portIdEntPhysicalAlias(2), 776 portIdMacAddr(3), 777 portIdPtopoGenAddr(4) 778 } 780 PtopoPortId ::= TEXTUAL-CONVENTION 781 STATUS current 782 DESCRIPTION 783 "This TC describes the format of a port identifier string. 784 Objects of this type are always used with an associated 785 PtopoPortIdType object, which identifies the format of the 786 particular PtopoPortId object instance. 788 If the associated PtopoPortIdType object has a value of 789 'portIdIfAlias(1)', then the octet string identifies a 791 Draft Physical Topology MIB September 1997 793 particular instance of the ifAlias object. 795 If the associated PtopoPortIdType object has a value of 796 'portIdEntPhysicalAlias(2)', then the octet string 797 identifies a particular instance of the entPhysicalAlias 798 object for a port component (i.e., entPhysicalClass value of 799 'port(10)'). 801 If the associated PtopoPortIdType object has a value of 802 'portIdMacAddr(3)', then this string identifies a particular 803 unicast source MAC address associated with the port. 805 If the associated PtopoPortIdType object has a value of 806 'portIdPtopoGenAddr(4)', then this string identifies a 807 network address associated with the port. The first octet 808 contains the IANAAddrFamily enumeration value for the 809 specific address type, and octets 2 through N contain the 810 PtopoGenAddr address value in network byte order." 811 SYNTAX OCTET STRING (SIZE (1..32)) 813 PtopoAddrSeenState ::= TEXTUAL-CONVENTION 814 STATUS current 815 DESCRIPTION 816 "This TC describes the state of address detection for a 817 particular type of port identifier used in the PTOPO MIB. 819 The enumeration 'not-used(1)' represents an entry for which 820 the particular MIB object is not applicable to the remote 821 connection endpoint, e.g. ptopoConnRemotePortType equals 822 'portIdIfAlias(1)'. 824 The enumeration 'unknown(2)' represents an entry for which 825 the particular address collection state is not known. 827 The enumeration 'one-addr(3)' represents an entry for which 828 exactly one source address (of the type indicated by the 829 particular MIB object), has been detected. 831 The enumeration 'multi-addr(4)' represents an entry for 832 which more than one source address (of the type indicated by 833 the particular MIB object), has been detected." 834 SYNTAX INTEGER { 835 not-used(1), 836 unknown(2), 838 Draft Physical Topology MIB September 1997 840 one-addr(3), 841 multi-addr(4) 842 } 844 -- *********************************************************** 845 -- 846 -- P T O P O D A T A G R O U P 847 -- 848 -- *********************************************************** 850 -- Connection Table 852 ptopoConnTable OBJECT-TYPE 853 SYNTAX SEQUENCE OF PtopoConnEntry 854 MAX-ACCESS not-accessible 855 STATUS current 856 DESCRIPTION 857 "This table contains one row per physical network connection 858 known to this agent. The agent may wish to ensure that only 859 one ptopoConnEntry is present for each local port, or it may 860 choose to maintain multiple ptopoConnEntries for the same 861 local port. 863 Entries based on lower numbered identifier types are 864 preferred over higher numbered identifier types, i.e., lower 865 values of the ptopoConnRemoteChassisType and 866 ptopoConnRemotePortType objects." 867 ::= { ptopoData 1 } 869 ptopoConnEntry OBJECT-TYPE 870 SYNTAX PtopoConnEntry 871 MAX-ACCESS not-accessible 872 STATUS current 873 DESCRIPTION 874 "Information about a particular physical network connection. 875 Entries may be created and deleted in this table, either 876 manually or by the agent, if a physical topology discovery 877 process is active." 878 INDEX { 879 ptopoConnTimeMark, 880 ptopoConnLocalChassis, 881 ptopoConnLocalPort, 882 ptopoConnIndex 883 } 885 Draft Physical Topology MIB September 1997 887 ::= { ptopoConnTable 1 } 889 PtopoConnEntry ::= SEQUENCE { 890 ptopoConnTimeMark TimeFilter, 891 ptopoConnLocalChassis PhysicalIndex, 892 ptopoConnLocalPort PhysicalIndex, 893 ptopoConnIndex Integer32, 894 ptopoConnRemoteChassisType PtopoChassisIdType, 895 ptopoConnRemoteChassis PtopoChassisId, 896 ptopoConnRemotePortType PtopoPortIdType, 897 ptopoConnRemotePort PtopoPortId, 898 ptopoConnDiscAlgorithm AutonomousType, 899 ptopoConnAgentNetAddrType IANAAddrFamily, 900 ptopoConnAgentNetAddr PtopoGenAddr, 901 ptopoConnMultiMacSASeen PtopoAddrSeenState, 902 ptopoConnMultiNetSASeen PtopoAddrSeenState, 903 ptopoConnIsStatic TruthValue, 904 ptopoConnLastVerifyTime TimeStamp, 905 ptopoConnRowStatus RowStatus 906 } 908 ptopoConnTimeMark OBJECT-TYPE 909 SYNTAX TimeFilter 910 MAX-ACCESS not-accessible 911 STATUS current 912 DESCRIPTION 913 "A TimeFilter for this entry. See the TimeFilter textual 914 convention in RFC 2021 to see how this works." 915 ::= { ptopoConnEntry 1 } 917 ptopoConnLocalChassis OBJECT-TYPE 918 SYNTAX PhysicalIndex 919 MAX-ACCESS not-accessible 920 STATUS current 921 DESCRIPTION 922 "The entPhysicalIndex value used to identify the chassis 923 component associated with the local connection endpoint." 924 ::= { ptopoConnEntry 2 } 926 ptopoConnLocalPort OBJECT-TYPE 927 SYNTAX PhysicalIndex 928 MAX-ACCESS not-accessible 929 STATUS current 930 DESCRIPTION 931 "The entPhysicalIndex value used to identify the port 933 Draft Physical Topology MIB September 1997 935 component associated with the local connection endpoint." 936 ::= { ptopoConnEntry 3 } 938 ptopoConnIndex OBJECT-TYPE 939 SYNTAX Integer32 (1..2147483647) 940 MAX-ACCESS not-accessible 941 STATUS current 942 DESCRIPTION 943 "This object represents an arbitrary local integer value 944 used by this agent to identify a particular connection 945 instance, unique only for the indicated local connection 946 endpoint. 948 [ed. WG must decide on index re-use issue; Only one of the 949 following two paragraphs will remain.] 951 A particular ptopoConnIndex value may be reused in the event 952 an entry is aged out and later re-learned with the same 953 remote chassis and port identifiers. 955 [ed. - OR] 957 A particular ptopoConnIndex value may only be used once for 958 a given (ptopoConnLocalChassis, ptopoConnLocalPort) pair, 959 since the last reinitialization of the PTOPO agent." 960 ::= { ptopoConnEntry 4 } 962 ptopoConnRemoteChassisType OBJECT-TYPE 963 SYNTAX PtopoChassisIdType 964 MAX-ACCESS read-create 965 STATUS current 966 DESCRIPTION 967 "The type of encoding used to identify the chassis 968 associated with the remote connection endpoint. 970 This object may not be modified if the associated 971 ptopoConnRowStatus object has a value of active(1)." 972 ::= { ptopoConnEntry 5 } 974 ptopoConnRemoteChassis OBJECT-TYPE 975 SYNTAX PtopoChassisId 976 MAX-ACCESS read-create 977 STATUS current 978 DESCRIPTION 979 "The string value used to identify the chassis component 981 Draft Physical Topology MIB September 1997 983 associated with the remote connection endpoint. 985 This object may not be modified if the associated 986 ptopoConnRowStatus object has a value of active(1)." 987 ::= { ptopoConnEntry 6 } 989 ptopoConnRemotePortType OBJECT-TYPE 990 SYNTAX PtopoPortIdType 991 MAX-ACCESS read-create 992 STATUS current 993 DESCRIPTION 994 "The type of port identifier encoding used in the associated 995 'ptopoConnRemotePort' object. 997 This object may not be modified if the associated 998 ptopoConnRowStatus object has a value of active(1)." 999 ::= { ptopoConnEntry 7 } 1001 ptopoConnRemotePort OBJECT-TYPE 1002 SYNTAX PtopoPortId 1003 MAX-ACCESS read-create 1004 STATUS current 1005 DESCRIPTION 1006 "The string value used to identify the port component 1007 associated with the remote connection endpoint. 1009 This object may not be modified if the associated 1010 ptopoConnRowStatus object has a value of active(1)." 1011 ::= { ptopoConnEntry 8 } 1013 ptopoConnDiscAlgorithm OBJECT-TYPE 1014 SYNTAX AutonomousType 1015 MAX-ACCESS read-only 1016 STATUS current 1017 DESCRIPTION 1018 "An indication of the algorithm used to discover the 1019 information contained in this conceptual row. 1021 A value of ptopoDiscoveryPDP indicates this entry was 1022 configured using the PTOPO Discovery Protocol. 1024 A value of ptopoDiscoveryLocal indicates this entry was 1025 configured by the local agent, without use of a discovery 1026 protocol. 1028 Draft Physical Topology MIB September 1997 1030 A value of { 0 0 } indicates this entry was created manually 1031 by an NMS via the associated RowStatus object. " 1032 ::= { ptopoConnEntry 9 } 1034 ptopoConnAgentNetAddrType OBJECT-TYPE 1035 SYNTAX IANAAddrFamily 1036 MAX-ACCESS read-create 1037 STATUS current 1038 DESCRIPTION 1039 "This network address type of the associated 1040 ptopoConnNetAddr object, unless that object contains a zero 1041 length string. In such a case, an NMS application should 1042 ignore any returned value for this object. 1044 This object may not be modified if the associated 1045 ptopoConnRowStatus object has a value of active(1)." 1046 ::= { ptopoConnEntry 10 } 1048 ptopoConnAgentNetAddr OBJECT-TYPE 1049 SYNTAX PtopoGenAddr 1050 MAX-ACCESS read-create 1051 STATUS current 1052 DESCRIPTION 1053 "This object identifies a network address which may be used 1054 to reach an SNMP agent entity containing information for the 1055 chassis and port components represented by the associated 1056 'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects. 1057 If no such address is known, then this object shall contain 1058 an empty string. 1060 This object may not be modified if the associated 1061 ptopoConnRowStatus object has a value of active(1)." 1062 ::= { ptopoConnEntry 11 } 1064 ptopoConnMultiMacSASeen OBJECT-TYPE 1065 SYNTAX PtopoAddrSeenState 1066 MAX-ACCESS read-only 1067 STATUS current 1068 DESCRIPTION 1069 "This object indicates if multiple unicast source MAC 1070 addresses have been detected by the agent from the remote 1071 connection endpoint, since the creation of this entry. 1073 If this entry has an associated ptopoConnRemoteChassisType 1074 and/or ptopoConnRemotePortType value other than 1076 Draft Physical Topology MIB September 1997 1078 'portIdMacAddr(3)', then the value 'not-used(1)' is 1079 returned. 1081 Otherwise, one of the following conditions must be true: 1083 If the agent has not yet detected any unicast source MAC 1084 addresses from the remote port, then the value 'unknown(2)' 1085 is returned. 1087 If the agent has detected exactly one unicast source MAC 1088 address from the remote port, then the value 'one-addr(3)' 1089 is returned. 1091 If the agent has detected more than one unicast source MAC 1092 address from the remote port, then the value 'multi-addr(4)' 1093 is returned." 1094 ::= { ptopoConnEntry 12 } 1096 ptopoConnMultiNetSASeen OBJECT-TYPE 1097 SYNTAX PtopoAddrSeenState 1098 MAX-ACCESS read-only 1099 STATUS current 1100 DESCRIPTION 1101 "This object indicates if multiple network layer source 1102 addresses have been detected by the agent from the remote 1103 connection endpoint, since the creation of this entry. 1105 If this entry has an associated ptopoConnRemoteChassisType 1106 or ptopoConnRemotePortType value other than 1107 'portIdGenAddr(4)' then the value 'not-used(1)' is returned. 1109 Otherwise, one of the following conditions must be true: 1111 If the agent has not yet detected any network source 1112 addresses of the appropriate type from the remote port, then 1113 the value 'unknown(2)' is returned. 1115 If the agent has detected exactly one network source address 1116 of the appropriate type from the remote port, then the value 1117 'one-addr(3)' is returned. 1119 If the agent has detected more than one network source 1120 address (of the same appropriate type) from the remote port, 1121 this the value 'multi-addr(4)' is returned." 1122 ::= { ptopoConnEntry 13 } 1124 Draft Physical Topology MIB September 1997 1126 ptopoConnIsStatic OBJECT-TYPE 1127 SYNTAX TruthValue 1128 MAX-ACCESS read-create 1129 STATUS current 1130 DESCRIPTION 1131 "This object identifies static ptopoConnEntries. If this 1132 object has the value 'true(1)', then this entry is not 1133 subject to any age-out mechanisms implemented by the agent. 1135 If this object has the value 'false(2)', then this entry is 1136 subject to all age-out mechanisms implemented by the agent. 1138 This object may not be modified if the associated 1139 ptopoConnRowStatus object has a value of active(1)." 1140 DEFVAL { false } 1141 ::= { ptopoConnEntry 14 } 1143 ptopoConnLastVerifyTime OBJECT-TYPE 1144 SYNTAX TimeStamp 1145 MAX-ACCESS read-only 1146 STATUS current 1147 DESCRIPTION 1148 "If the associated value of ptopoConnIsStatic is equal to 1149 'false(2)', then this object contains the value of sysUpTime 1150 at the time the conceptual row was last verified by the 1151 agent, e.g. via reception of a PDP message pertaining to the 1152 associated remote chassis and port. 1154 If the associated value of ptopoConnIsStatic is equal to 1155 'true(1)', then this object shall contain the value of 1156 sysUpTime at the time this entry was last activated (i.e., 1157 ptopoConnRowStatus set to 'active(1)')." 1158 ::= { ptopoConnEntry 15 } 1160 ptopoConnRowStatus OBJECT-TYPE 1161 SYNTAX RowStatus 1162 MAX-ACCESS read-create 1163 STATUS current 1164 DESCRIPTION 1165 "The status of this conceptual row." 1166 ::= { ptopoConnEntry 16 } 1168 -- *********************************************************** 1169 -- 1170 Draft Physical Topology MIB September 1997 1172 -- P T O P O G E N E R A L G R O U P 1173 -- 1174 -- *********************************************************** 1176 -- last change time stamp for the whole MIB 1178 ptopoLastChangeTime OBJECT-TYPE 1179 SYNTAX TimeStamp 1180 MAX-ACCESS read-only 1181 STATUS current 1182 DESCRIPTION 1183 "The value of sysUpTime at the time a conceptual row is 1184 created, modified, or deleted in the ptopoConnTable. 1186 An NMS can use this object to reduce polling of the 1187 ptopoData group objects." 1188 ::= { ptopoGeneral 1 } 1190 ptopoConnTabInserts OBJECT-TYPE 1191 SYNTAX Counter32 1192 MAX-ACCESS read-only 1193 STATUS current 1194 DESCRIPTION 1195 "The number of times an entry has been inserted into the 1196 ptopoConnTable." 1197 ::= { ptopoGeneral 2 } 1199 ptopoConnTabDeletes OBJECT-TYPE 1200 SYNTAX Counter32 1201 MAX-ACCESS read-only 1202 STATUS current 1203 DESCRIPTION 1204 "The number of times an entry has been deleted from the 1205 ptopoConnTable." 1206 ::= { ptopoGeneral 3 } 1208 ptopoConnTabDrops OBJECT-TYPE 1209 SYNTAX Counter32 1210 MAX-ACCESS read-only 1211 STATUS current 1212 DESCRIPTION 1213 "The number of times an entry would have been added to the 1214 ptopoConnTable, (e.g., via information learned from PDP), 1215 but was not because of insufficient resources." 1217 Draft Physical Topology MIB September 1997 1219 ::= { ptopoGeneral 4 } 1221 ptopoConnTabReplaces OBJECT-TYPE 1222 SYNTAX Counter32 1223 MAX-ACCESS read-only 1224 STATUS current 1225 DESCRIPTION 1226 "The number of times an entry for a particular connection 1227 has been replaced with an entry for the same local port, but 1228 different values for any of the following objects: 1229 - ptopoConnRemoteChassisType 1230 - ptopoConnRemoteChassis 1231 - ptopoConnRemotePortType 1232 - ptopoConnRemotePort" 1233 ::= { ptopoGeneral 5 } 1235 ptopoConnTabAgeouts OBJECT-TYPE 1236 SYNTAX Counter32 1237 MAX-ACCESS read-only 1238 STATUS current 1239 DESCRIPTION 1240 "The number of times an entry has been deleted from the 1241 ptopoConnTable because the information timeliness interval 1242 for that entry has expired." 1243 ::= { ptopoGeneral 6 } 1245 -- *********************************************************** 1246 -- 1247 -- P T O P O C O N F I G G R O U P 1248 -- 1249 -- *********************************************************** 1251 ptopoConfigTrapsEnabled OBJECT-TYPE 1252 SYNTAX TruthValue 1253 MAX-ACCESS read-write 1254 STATUS current 1255 DESCRIPTION 1256 "This object controls the transmission of PTOPO traps. 1258 If the agent is capable of storing non-volatile 1259 configuration, then the value of this object must be 1260 restored after a re-initialization of the management 1261 system." 1263 Draft Physical Topology MIB September 1997 1265 DEFVAL { false } 1266 ::= { ptopoConfig 1 } 1268 ptopoConfigMaxHoldTime OBJECT-TYPE 1269 SYNTAX Integer32 (1..2147483647) 1270 UNITS "seconds" 1271 MAX-ACCESS read-write 1272 STATUS current 1273 DESCRIPTION 1274 "This object specifies the desired time interval for which 1275 an agent will maintain dynamic ptopoConnEntries. 1277 After the specified number of seconds since the last time an 1278 entry was verified, in the absence of new verification 1279 (e.g., receipt of a PDP message), the agent shall remove the 1280 entry. Note that entries may not always be removed 1281 immediately, but may possibly be removed at periodic garbage 1282 collection intervals. 1284 This object only affects dynamic ptopoConnEntries, i.e. for 1285 which ptopoConnIsStatic equals 'false(2)'. Static entries 1286 are not aged out. 1288 Note that dynamic ptopoConnEntries may also be removed by 1289 the agent due to the expired timeliness of learned topology 1290 information (e.g., timeliness interval for a remote port 1291 expires). The actual age-out interval for a given entry is 1292 defined by the following formula: 1294 age-out-time = 1295 min(ptopoConfigMaxHoldTime, ) 1297 where is determined by the 1298 discovery algorithm, and may be different for each entry. 1299 For entries discovered with PDP, this is the particular 1300 'time-to-live' value from the most recent PDP message 1301 associated with the entry." 1302 DEFVAL { 300 } 1303 ::= { ptopoConfig 2 } 1305 -- PTOPO MIB Trap Definitions 1306 ptopoMIBTraps OBJECT IDENTIFIER ::= { ptopoMIB 2 } 1307 ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 } 1308 Draft Physical Topology MIB September 1997 1310 ptopoConfigChange NOTIFICATION-TYPE 1311 OBJECTS { 1312 ptopoConnTabInserts, 1313 ptopoConnTabDeletes, 1314 ptopoConnTabDrops, 1315 ptopoConnTabReplaces, 1316 ptopoConnTabAgeouts 1317 } 1318 STATUS current 1319 DESCRIPTION 1320 "A ptopoConfigChange trap is sent when the value of 1321 ptopoLastChangeTime changes. It can be utilized by an NMS to 1322 trigger physical topology table maintenance polls. 1324 An agent must not generate more than one ptopoConfigChange 1325 trap-event in a five second period, where a 'trap-event' is 1326 the transmission of a single trap PDU to a list of trap 1327 destinations. If additional configuration changes occur 1328 within the five second throttling period, then these trap- 1329 events should be suppressed by the agent. An NMS should 1330 periodically check the value of ptopoLastChangeTime to 1331 detect any missed ptopoConfigChange trap-events, e.g. due to 1332 throttling or transmission loss." 1333 ::= { ptopoMIBTrapPrefix 1 } 1335 -- PTOPO Registration Points 1337 ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 } 1339 -- values used with ptopoConnDiscAlgorithm object 1340 ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 } 1341 ptopoDiscoveryPDP OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 } 1342 ptopoDiscoveryLocal OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 2 } 1344 -- conformance information 1345 ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 } 1347 ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 } 1348 ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 } 1350 -- compliance statements 1351 Draft Physical Topology MIB September 1997 1353 ptopoCompliance MODULE-COMPLIANCE 1354 STATUS current 1355 DESCRIPTION 1356 "The compliance statement for SNMP entities which implement 1357 the PTOPO MIB." 1358 MODULE -- this module 1359 MANDATORY-GROUPS { 1360 ptopoDataGroup, 1361 ptopoGeneralGroup, 1362 ptopoConfigGroup, 1363 ptopoNotificationsGroup 1364 } 1365 ::= { ptopoCompliances 1 } 1367 -- MIB groupings 1369 ptopoDataGroup OBJECT-GROUP 1370 OBJECTS { 1371 ptopoConnRemoteChassisType, 1372 ptopoConnRemoteChassis, 1373 ptopoConnRemotePortType, 1374 ptopoConnRemotePort, 1375 ptopoConnDiscAlgorithm, 1376 ptopoConnAgentNetAddrType, 1377 ptopoConnAgentNetAddr, 1378 ptopoConnMultiMacSASeen, 1379 ptopoConnMultiNetSASeen, 1380 ptopoConnIsStatic, 1381 ptopoConnLastVerifyTime, 1382 ptopoConnRowStatus 1383 } 1384 STATUS current 1385 DESCRIPTION 1386 "The collection of objects which are used to represent 1387 physical topology information for which a single agent 1388 provides management information. 1390 This group is mandatory for all implementations of the PTOPO 1391 MIB." 1392 ::= { ptopoGroups 1 } 1394 ptopoGeneralGroup OBJECT-GROUP 1395 OBJECTS { 1396 ptopoLastChangeTime, 1397 ptopoConnTabInserts, 1399 Draft Physical Topology MIB September 1997 1401 ptopoConnTabDeletes, 1402 ptopoConnTabDrops, 1403 ptopoConnTabReplaces, 1404 ptopoConnTabAgeouts 1405 } 1406 STATUS current 1407 DESCRIPTION 1408 "The collection of objects which are used to report the 1409 general status of the PTOPO MIB implementation. 1411 This group is mandatory for all agents which implement the 1412 PTOPO MIB." 1413 ::= { ptopoGroups 2 } 1415 ptopoConfigGroup OBJECT-GROUP 1416 OBJECTS { 1417 ptopoConfigTrapsEnabled, 1418 ptopoConfigMaxHoldTime 1419 } 1420 STATUS current 1421 DESCRIPTION 1422 "The collection of objects which are used to configure the 1423 PTOPO MIB implementation behavior. 1425 This group is mandatory for agents which implement the PTOPO 1426 MIB." 1427 ::= { ptopoGroups 3 } 1429 ptopoNotificationsGroup NOTIFICATION-GROUP 1430 NOTIFICATIONS { 1431 ptopoConfigChange 1432 } 1433 STATUS current 1434 DESCRIPTION 1435 "The collection of notifications used to indicate PTOPO MIB 1436 data consistency and general status information. 1438 This group is mandatory for agents which implement the PTOPO 1439 MIB." 1440 ::= { ptopoGroups 4 } 1442 END 1443 Draft Physical Topology MIB September 1997 1445 6. References 1447 [ENTITY-EXT] 1448 Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent 1449 Component Identification", draft-bierman-entmib-compid-00.txt, 1450 Cisco Systems, July 1997. 1452 [RFC1157] 1453 Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 1454 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1455 International, MIT Laboratory for Computer Science, May 1990. 1457 [RFC1213] 1458 McCloghrie, K., and M. Rose, Editors, "Management Information Base 1459 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1460 RFC 1213, Hughes LAN Systems, Performance Systems International, 1461 March 1991. 1463 [RFC1493] 1464 E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie, "Definitions 1465 of Managed Objects for Bridges", RFC 1493, Cisco Systems, Inc., 1466 Digital Equipment Corporation, Hughes LAN Systems, Inc., July 1993. 1468 [RFC1573] 1469 McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 1470 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 1472 [RFC1700] 1473 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1474 USC/Information Sciences Institute, October 1994. 1476 [RFC1902] 1477 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1478 S. Waldbusser, "Structure of Management Information for version 2 1479 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 1480 January 1996. 1482 [RFC1903] 1483 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1484 S. Waldbusser, "Textual Conventions for version 2 of the Simple 1485 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1487 [RFC1904] 1488 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1489 S. Waldbusser, "Conformance Statements for version 2 of the Simple 1491 Draft Physical Topology MIB September 1997 1493 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1495 [RFC1905] 1496 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1497 S. Waldbusser, "Protocol Operations for version 2 of the Simple 1498 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1500 [RFC2021] 1501 S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021, 1502 International Network Services, January 1997. 1504 [RFC2037] 1505 McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, 1506 Cisco Systems, October 1996. 1508 [RFC2108] 1509 K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, "Definitions 1510 of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", 1511 RFC 2108, 3Com Corporation, Madge Networks (Israel) Ltd., Coloma 1512 Communications, Cisco Systems Inc., February 1997. 1514 Draft Physical Topology MIB September 1997 1516 7. Security Considerations 1518 This MIB exposes information about the physical connectivity for a 1519 particular portion of a network. A network administrator may wish to 1520 restrict SNMP access to such information, but such agent security 1521 configuration is beyond the scope of this document. 1523 A network administrator may also wish to inhibit transmission of any 1524 ptopoConfigChange traps by setting the ptopoConfigTrapsEnabled object to 1525 'false(2)'. 1527 8. Authors' Addresses 1529 Andy Bierman 1530 Cisco Systems 1531 170 West Tasman Drive 1532 San Jose, CA 95134 1533 Phone: 408-527-3711 1534 Email: abierman@cisco.com 1536 Kendall S. Jones 1537 Bay Networks 1538 4401 Great America Parkway 1539 Santa Clara, CA 95134 1540 Phone: 408-495-7356 1541 Email: kjones@baynetworks.com 1543 Draft Physical Topology MIB September 1997 1545 Table of Contents 1547 1 Introduction .................................................... 1 1548 2 The SNMP Network Management Framework ........................... 2 1549 2.1 Object Definitions ............................................ 2 1550 3 Overview ........................................................ 2 1551 3.1 Background and Concepts ....................................... 3 1552 3.2 Terms ......................................................... 4 1553 3.3 Functionality Goals ........................................... 5 1554 3.4 Design Goals .................................................. 6 1555 4 Topology Framework .............................................. 7 1556 4.1 Framework Overview ............................................ 7 1557 4.1.1 Topology Mechanisms ......................................... 8 1558 4.1.2 Manager Process ............................................. 9 1559 5 Physical Topology MIB ........................................... 10 1560 5.1 Persistent Identifiers ........................................ 10 1561 5.2 Relationship to Entity MIB .................................... 11 1562 5.3 Relationship to Interfaces MIB ................................ 11 1563 5.4 Relationship to RMON-2 MIB .................................... 12 1564 5.5 Relationship to Bridge MIB .................................... 12 1565 5.6 Relationship to Repeater MIB .................................. 12 1566 5.7 MIB Structure ................................................. 12 1567 5.7.1 ptopoData Group ............................................. 12 1568 5.7.2 ptopoGeneral Group .......................................... 13 1569 5.7.3 ptopoConfig Group ........................................... 13 1570 5.8 Physical Topology MIB Definitions ............................. 13 1571 6 References ...................................................... 32 1572 7 Security Considerations ......................................... 34 1573 8 Authors' Addresses .............................................. 34