idnits 2.17.1 draft-ietf-ptopomib-mib-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 Introduction 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.) ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1291 has weird spacing: '...imed to perta...' -- 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 (16 November 1998) is 9290 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 section? 'RFC2271' on line 1418 looks like a reference -- Missing reference section? 'RFC1155' on line 1330 looks like a reference -- Missing reference section? 'RFC1212' on line 1341 looks like a reference -- Missing reference section? 'RFC1215' on line 1345 looks like a reference -- Missing reference section? 'RFC1902' on line 1365 looks like a reference -- Missing reference section? 'RFC1903' on line 1372 looks like a reference -- Missing reference section? 'RFC1904' on line 1379 looks like a reference -- Missing reference section? 'RFC1157' on line 1335 looks like a reference -- Missing reference section? 'RFC1901' on line 1359 looks like a reference -- Missing reference section? 'RFC1906' on line 1393 looks like a reference -- Missing reference section? 'RFC2272' on line 1424 looks like a reference -- Missing reference section? 'RFC2274' on line 1435 looks like a reference -- Missing reference section? 'RFC1905' on line 1386 looks like a reference -- Missing reference section? 'RFC2273' on line 1430 looks like a reference -- Missing reference section? 'RFC2275' on line 1440 looks like a reference -- Missing reference section? 'RFC2233' on line 1414 looks like a reference -- Missing reference section? 'RFC2037' on line 1404 looks like a reference -- Missing reference section? 'RFC2021' on line 1400 looks like a reference -- Missing reference section? 'ENTITY-MIB' on line 1321 looks like a reference -- Missing reference section? 'RFC1493' on line 1349 looks like a reference -- Missing reference section? 'RFC2108' on line 1408 looks like a reference -- Missing reference section? 'RFC1700' on line 1355 looks like a reference -- Missing reference section? 'PDP' on line 1325 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PTOPOMIB Working Group Andy Bierman 3 Internet Draft Cisco Systems, Inc. 4 Ken Jones 5 Bay Networks 6 16 November 1998 8 Physical Topology MIB 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet- Drafts Shadow 26 Directories on ftp.ietf.org, nic.nordu.net, venera.isi.edu, or 27 munnari.oz.au. 29 Distribution of this document is unlimited. Please send comments to the 30 PTOPOMIB Working Group, . 32 1. Copyright Notice 34 Copyright (C) The Internet Society (1998). All Rights Reserved. 36 2. Abstract 38 This memo defines an experimental portion of the Management Information 39 Base (MIB) for use with network management protocols in the Internet 40 community. In particular, it describes managed objects used for 41 managing physical topology identification and discovery. 43 3. Table of Contents 45 1 Copyright Notice ................................................ 1 46 2 Abstract ........................................................ 1 47 3 Table of Contents ............................................... 2 48 4 The SNMP Network Management Framework ........................... 2 49 5 Overview ........................................................ 3 50 5.1 Terms ......................................................... 4 51 5.2 Design Goals .................................................. 5 52 6 Topology Framework .............................................. 6 53 6.1 Devices and Topology Agents ................................... 7 54 6.2 Topology Mechanisms ........................................... 7 55 6.3 Future Considerations ......................................... 8 56 7 Physical Topology MIB ........................................... 8 57 7.1 Persistent Identifiers ........................................ 8 58 7.2 Relationship to Entity MIB .................................... 9 59 7.3 Relationship to Interfaces MIB ................................ 9 60 7.4 Relationship to RMON-2 MIB .................................... 9 61 7.5 Relationship to Bridge MIB .................................... 10 62 7.6 Relationship to Repeater MIB .................................. 10 63 7.7 MIB Structure ................................................. 10 64 7.7.1 ptopoData Group ............................................. 10 65 7.7.2 ptopoGeneral Group .......................................... 10 66 7.7.3 ptopoConfig Group ........................................... 11 67 7.8 Physical Topology MIB Definitions ............................. 11 68 8 Intellectual Property ........................................... 29 69 9 Acknowledgements ................................................ 30 70 10 References ..................................................... 30 71 11 Security Considerations ........................................ 33 72 12 Authors' Addresses ............................................. 33 73 13 Full Copyright Statement ....................................... 34 75 4. The SNMP Network Management Framework 77 The SNMP Management Framework presently consists of five major 78 components: 80 o An overall architecture, described in RFC 2271 [RFC2271]. 82 o Mechanisms for describing and naming objects and events for the 83 purpose of management. The first version of this Structure of 84 Management Information (SMI) is called SMIv1 and described in RFC 85 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The 86 second version, called SMIv2, is described in RFC 1902 [RFC1902], 87 RFC 1903 [RFC1903] and RFC 1904 [RFC1904]. 89 o Message protocols for transferring management information. The 90 first version of the SNMP message protocol is called SNMPv1 and 91 described in RFC 1157 [RFC1157]. A second version of the SNMP 92 message protocol, which is not an Internet standards track 93 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and 94 RFC 1906 [RFC1906]. The third version of the message protocol is 95 called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2272 96 [RFC2272] and RFC 2274 [RFC2274]. 98 o Protocol operations for accessing management information. The first 99 set of protocol operations and associated PDU formats is described 100 in RFC 1157 [RFC1157]. A second set of protocol operations and 101 associated PDU formats is described in RFC 1905 [RFC1905]. 103 o A set of fundamental applications described in RFC 2273 [RFC2273] 104 and the view-based access control mechanism described in RFC 2275 105 [RFC2275]. 107 Managed objects are accessed via a virtual information store, termed the 108 Management Information Base or MIB. Objects in the MIB are defined 109 using the mechanisms defined in the SMI. 111 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 112 conforming to the SMIv1 can be produced through the appropriate 113 translations. The resulting translated MIB must be semantically 114 equivalent, except where objects or events are omitted because no 115 information in SMIv2 will be converted into textual descriptions in 116 SMIv1 during the translation process. However, this loss of machine 117 readable information is not considered to change the semantics of the 118 MIB. 120 5. Overview 122 There is a need for a standardized means of representing the physical 123 network connections pertaining to a given management domain. The 124 Physical Topology MIB (PTOPO-MIB) provides a standard way to identify 125 connections between network ports and to discover network addresses of 126 SNMP agents containing management information associated with each port. 128 A topology mechanism is used to discover the information required by the 129 PTOPO-MIB. There is a need for a standardized topology mechanism to 130 increase the likelihood of multi-vendor interoperability of such 131 physical topology management information. The PTOPO-MIB does not, 132 however, specify or restrict the discovery mechanism(s) used for an 133 implementation of the PTOPO-MIB. Topology mechanisms exist for certain 134 media types (such as FDDI) and proprietary mechanisms exist for other 135 media such as shared media Ethernet, switched Ethernet, and Token Ring. 136 Rather than specifying mechanisms for each type of technology, the 137 PTOPO-MIB allows co-existence of multiple topology mechanisms. The 138 required objects of the PTOPO-MIB define the core requirements for any 139 topology mechanism. 141 The scope of the physical topology (PTOPO) mechanism is the 142 identification of connections between two network ports. Network 143 addresses of SNMP agents containing management information associated 144 with each port can also be identified. 146 5.1. Terms 148 Some terms are used throughout this document: 150 Physical Topology 151 Physical topology represents the topology model for layer 1 of the 152 OSI stack - the physical layer. Physical topology consists of 153 identifying the devices on the network and how they are physically 154 interconnected. By definition of this document, physical topology 155 does not imply a physical relationship between ports on the same 156 device. Other means exist for determining these relationships 157 (e.g., Entity MIB). exist for determining these relationships Note 158 that physical topology is independent of logical topology, which 159 associates ports based on higher layer attributes, such as network 160 layer address. 162 Chassis 163 A chassis is a physical component which contains other physical 164 components. It is identified by an entPhysicalEntry with an 165 entPhysicalClass value of 'chassis(3)' and an 166 entPhysicalContainedIn value of zero. A chassis identifier 167 consists of a globally unique DisplayString. 169 Local Chassis 170 The particular chassis containing the SNMP agent implementing the 171 PTOPO MIB. 173 Port 174 A port is a physical component which can be connected to another 175 port through some medium. It is identified by an entPhysicalEntry 176 with an entPhysicalClass value of 'port(10)'. A port identifier 177 consists of a DisplayString which must be unique within the context 178 of the chassis which contains the port. 180 Connection Endpoint 181 A connection endpoint consists of a physical port, which is 182 contained within a single physical chassis. 184 Connection Endpoint Identifier 185 A connection endpoint is identified by a globally unique chassis 186 identifier and a port identifier unique within the associated 187 chassis. 189 Connection 190 A connection consists of two physical ports, and the attached 191 physical medium, configured for the purpose of transferring network 192 traffic between the ports. A connection is identified by its 193 endpoint identifiers. 195 Non-local Connection 196 A connection for which neither endpoint is located on the local 197 chassis. 199 Cloud 200 A cloud identifies a portion of the topology for which insufficient 201 information is known to completely infer the interconnection of 202 devices that make up that portion of the topology. 204 5.2. Design Goals 206 Several factors influenced the design of this physical topology 207 function: 209 - Simplicity 210 The physical topology discovery function should be as simple as 211 possible, exposing only the information needed to identify 212 connection endpoints and the SNMP agent(s) associated with each 213 connection endpoint. 215 - Completeness 216 At least one standard discovery protocol capable of supporting the 217 standard physical topology MIB must be defined. Multi-vendor 218 interoperability will not be achievable unless a simple and 219 extensible discovery protocol is available. However, the PTOPO MIB 220 should not specify or restrict the topology discovery mechanisms an 221 agent can use. 223 - No Functional Overlap 224 Existing standard MIBs should be utilized whenever possible. 225 Physical topology information is tightly coupled to functionality 226 found in the Interfaces MIB [RFC2233] and Entity MIB [RFC2037]. 227 New physical topology MIB objects should not duplicate these MIBs. 229 - Identifier Stability 230 Connection endpoint identifiers must be persistent (i.e. stable 231 across device reboots). Dynamic primary key objects like ifIndex 232 and entPhysicalIndex are not suitable for table indices in a 233 physical topology MIB that is replicated and distributed throughout 234 a managed system. 236 - Identifier Flexibility 237 Persistent string-based component identifiers should be supported 238 from many sources. Chassis identifiers may be found in the Entity 239 MIB, and port identifiers may be found in the Interfaces MIB or 240 Entity MIB. 242 - Partial Topology Support 243 Physical topology data for remote components may only be partially 244 available to an agent. An enumerated INTEGER hierarchy of 245 component identifier types allows for incomplete physical 246 connection identifier information to be substituted with secondary 247 information such as unicast source MAC address or network address 248 associated with a particular port. A PTOPO Agent maintains 249 information derived from the 'best' source of information for each 250 connection. If a 'better' identifier source is detected, the PTOPO 251 entries are updated accordingly. It is an implementation specific 252 matter whether a PTOPO agent replaces 'old' entries or retains 253 them, however an agent must remove information known to be 254 incorrect. 256 - Low Polling Impact 257 Physical topology polling should be minimized through techniques 258 such as TimeFiltered data tables (from RMON-2 [RFC2021]), and 259 last-change notifications. 261 6. Topology Framework 263 This section describes the physical topology framework in detail. 265 6.1. Devices and Topology Agents 267 The network devices, along with their physical connectivity, make up the 268 physical topology. Some of these devices (but maybe not all) provide 269 management agents that report their local physical topology information 270 to a manager via the physical topology MIB. 272 These devices include communication infrastructure devices, such as 273 hubs, switches, and routers, as well as 'leaf' devices such as 274 workstations, printers, and servers. Generally, user data passes 275 through infrastructure devices while leaf devices are sources and sinks 276 of data. Both types of devices may implement the physical topology MIB, 277 although implementation within leaf devices is much less critical. 279 Each managed device collects physical topology information from the 280 network, based on the topology mechanism(s) it is configured to use. 281 The data represents this agent's local view of the physical network. 282 Part of the topology data collected must include the identification of 283 other local agents which may contain additional topology information. 284 The definition of 'local' varies based on the topology mechanism or 285 mechanisms being used. 287 6.2. Topology Mechanisms 289 A topology mechanism is a means, possibly requiring some sort of 290 protocol, by which devices determine topology information. The 291 {topology mechanism must provide sufficient information to populate the 292 MIB described later in this document.} 294 Topology mechanisms can be active or passive. Active mechanisms require 295 a device to send and receive topology protocol packets. These packets 296 provide the device ID of the source of the packet and may also indicate 297 out which port the packet was transmitted. When receiving these 298 packets, devices typically are required to identify on which port that 299 packet was received. 301 Passive mechanisms take advantage of data on the network to populate the 302 topology MIB. By maintaining a list of device identifiers seen on each 303 port of all devices in a network, it is possible to populate the PTOPO- 304 MIB. 306 Many instances of a particular topology mechanism may be in use on a 307 given network, and many different mechanisms may be employed. In some 308 cases, multiple mechanisms may overlap across part of the physical 309 topology with individual ports supporting more than one topology 310 mechanism. In general, this simply allows the port to collect more 311 robust topology information. Agents may need to be configured so that 312 they know which mechanism(s) are in use on any given portion of the 313 network. 315 Most topology mechanisms need to be bounded to a subset of the network 316 to contain their impact on the network and limit the size of topology 317 tables maintained by the agent. Topology mechanisms are often naturally 318 bounded by the media on which they run (e.g. FDDI topology mechanism) or 319 by routers in the network that intentionally block the mechanism from 320 crossing into other parts of the network. 322 6.3. Future Considerations 324 While the framework presented here is focused on physical topology, it 325 may well be that the topology mechanisms and MIB described could be 326 extended to include logical topology information as well. That is not a 327 focus of this memo. 329 7. Physical Topology MIB 331 This section describes and defines the Physical Topology MIB. 333 7.1. Persistent Identifiers 335 The PTOPO MIB utilizes non-volatile identifiers to distinguish 336 individual chassis and port components. These identifiers are 337 associated with external objects in order to relate topology information 338 to the existing managed objects. 340 In particular, an object from the Entity MIB or Interfaces MIB can be 341 used as the 'reference-point' for a connection component identifier. 343 The Physical Topology MIB uses two identifier types pertaining to the 344 PTOPO MIB: 346 - globally unique chassis identifiers. 348 - port identifiers; unique only within the chassis which contains the 349 port. 351 Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes 352 in length, This supports flexible naming conventions and constrains the 353 non-volatile storage requirements for an agent. 355 7.2. Relationship to Entity MIB 357 The Entity MIB [RFC2037] allows the physical component inventory and 358 hierarchy to be identified. However, this MIB does not provide 359 persistent component identifiers, which are required for the PTOPO MIB. 360 Therefore, version 2 of the Entity MIB [ENTITY-MIB] is required to 361 support that feature. Specifically, the entPhysicalAlias object is 362 utilized as a persistent chassis identifier. 364 For agents implementing the PTOPO MIB, this new object must be used to 365 represent the chassis identifier. Port identifiers can be based on the 366 entPhysicalAlias object associated with the port, but only if the port 367 is not represented as an interface in the ifXTable. 369 Implementation of the entPhysicalGroup [RFC2037] and the 370 entPhysicalAlias object [ENTITY-MIB] are mandatory for SNMP agents which 371 implement the PTOPO MIB. No other objects must be implemented from 372 these MIBs to support the physical topology function. 374 7.3. Relationship to Interfaces MIB 376 The PTOPO MIB requires a persistent identifier for each port. The 377 Interfaces MIB [RFC2233] provides a standard mechanism for managing 378 network interfaces. Unfortunately, not all ports which may be 379 represented in the PTOPO MIB are also represented in the Interfaces MIB 380 (e.g., repeater ports). 382 For agents which implement the PTOPO MIB, for each port also represented 383 in the Interfaces MIB, the agent must use the associated ifAlias value 384 for the port identifier. For each port not represented in the 385 Interfaces MIB, the associated entPhysicalAlias value must be used for 386 the port identifier. Note that the PTOPO MIB requires only minimal 387 support from the Interfaces MIB. Specifically, the 388 'ifGeneralInformationGroup' level of conformance must be provided for 389 each port also identified in the PTOPO MIB. The agent may choose to 390 support these objects with read-only access, as specified in the 391 conformance section of the Interfaces MIB. 393 7.4. Relationship to RMON-2 MIB 395 The RMON-2 MIB [RFC2021] contains address mapping information which can 396 be integrated with physical topology information. The physical ports 397 identified in a physical topology MIB can be related to the MAC and 398 network layer addresses found in the addressMapTable. 400 7.5. Relationship to Bridge MIB 402 The Bridge MIB [RFC1493] contains information which may relate to 403 physical ports represented in the ptopoConnTable. Entries in the 404 dot1dBasePortTable and dot1dStpPortTable can by related to physical 405 ports represented in the PTOPO MIB. Also, bridge port MAC addresses may 406 be used as chassis and port identifiers in some situations. 408 7.6. Relationship to Repeater MIB 410 The Repeater MIB [RFC2108] contains information which may relate to 411 physical ports represented in the PTOPO MIB. Entries in the 412 rptrPortTable and rptrMonitorPortTable can by related to physical ports 413 represented in the ptopoConnTable. Entries in the rptrInfoTable and 414 rptrMonTable can be related to repeater backplanes possibly represented 415 in the ptopoConnTable. 417 7.7. MIB Structure 419 The PTOPO MIB contains three MIB object groups: 421 - ptopoData 422 Exposes physical topology data learned from discovery protocols 423 and/or manual configuration. 425 - ptopoGeneral 426 Contains general information regarding PTOPO MIB status. 428 - ptopoConfig 429 Contains configuration variables for the PTOPO MIB agent function. 431 7.7.1. ptopoData Group 433 This group contains a single table to identity physical topology data. 435 The ptopoConnTable contains information about the connections learned or 436 configured on behalf of the PTOPO MIB SNMP Agent. 438 7.7.2. ptopoGeneral Group 440 This group contains some scalar objects to report the status of the 441 PTOPO MIB information currently known to the SNMP Agent. The global last 442 change time, and table add and delete counters allow an NMS to set 443 threshold alarms to trigger PTOPO polling. 445 7.7.3. ptopoConfig Group 447 This group contains tables to configure the behavior of the physical 448 topology function. The transmission of ptopoLastChange traps can be 449 configured using the ptopoConfigTrapInterval scalar MIB object. 451 7.8. Physical Topology MIB Definitions 453 PTOPO-MIB DEFINITIONS ::= BEGIN 455 IMPORTS 456 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32 457 FROM SNMPv2-SMI 458 TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue 459 FROM SNMPv2-TC 460 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 461 FROM SNMPv2-CONF 462 TimeFilter 463 FROM RMON2-MIB 464 PhysicalIndex 465 FROM ENTITY-MIB; 467 ptopoMIB MODULE-IDENTITY 468 LAST-UPDATED "9801260000Z" 469 ORGANIZATION "IETF; PTOPOMIB Working Group" 470 CONTACT-INFO 471 "PTOPOMIB WG Discussion: 472 ptopo@3com.com 473 Subscription: 474 majordomo@3com.com 475 msg body: [un]subscribe ptopomib 477 Andy Bierman 478 Cisco Systems Inc. 479 170 West Tasman Drive 480 San Jose, CA 95134 481 408-527-3711 482 abierman@cisco.com 484 Kendall S. Jones 485 Bay Networks 486 4401 Great America Parkway 487 Santa Clara, CA 95134 488 408-495-7356 489 kjones@baynetworks.com" 491 DESCRIPTION 492 "The MIB module for physical topology information." 493 ::= { experimental xx } 495 ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } 497 -- MIB groups 498 ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } 499 ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } 500 ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } 502 -- textual conventions 504 -- 505 -- IANAAddrFamily TC copied from 506 -- draft-ietf-disman-framework-00.txt 507 -- Eventually, it will be included from a general TC module 508 -- 509 IANAAddrFamily ::= TEXTUAL-CONVENTION 510 STATUS current 511 DESCRIPTION 512 "An address family. Values are defined in Assigned Numbers, 513 RFC1700. Note that not all these values make sense in all 514 contexts where this type is used in this MIB, but they are 515 included for completeness." 516 REFERENCE 517 "Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS" 518 SYNTAX INTEGER { 519 other(0), 520 ipV4(1), 521 ipV6(2), 522 nsap(3), 523 hdlc(4), 524 bbn1822(5), 525 ieee802(6), 526 e163(7), 527 e164(8), 528 f69(9), 529 x121(10), 530 ipx(11), 531 appleTalk(12), 532 decnetIV(13), 533 banyanVines(14), 534 e164WithNsap(15) 536 } 538 PtopoGenAddr ::= TEXTUAL-CONVENTION 539 STATUS current 540 DESCRIPTION 541 "The value of an address." 542 SYNTAX OCTET STRING (SIZE (0..20)) 544 PtopoChassisIdType ::= TEXTUAL-CONVENTION 545 STATUS current 546 DESCRIPTION 547 "This TC describes the source of a chassis identifier. 549 The enumeration 'chasIdEntPhysicalAlias(1)' represents a 550 chassis identifier based on the value of entPhysicalAlias 551 for a chassis component (i.e., an entPhysicalClass value of 552 'chassis(3)'). 554 The enumeration 'chasIdIfAlias(2)' represents a chassis 555 identifier based on the value of ifAlias for an interface on 556 the containing chassis. 558 The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a 559 chassis identifier based on the value of entPhysicalAlias 560 for a port or backplane component (i.e., entPhysicalClass 561 value of 'port(10)' or 'backplane(4)'), within the 562 containing chassis. 564 The enumeration 'chasIdMacAddress(4)' represents a chassis 565 identifier based on the value of a unicast source MAC 566 address (encoded in network byte order and IEEE 802.3 567 canonical bit order), of a port on the containing chassis. 569 The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis 570 identifier based on a network address, associated with a 571 particular chassis. The encoded address is actually composed 572 of two fields. The first field is a single octet, 573 representing the IANAAddrFamily for the specific address 574 type, and the second field is the PtopoGenAddr address 575 value." 576 SYNTAX INTEGER { 577 chasIdEntPhysicalAlias(1), 578 chasIdIfAlias(2), 579 chasIdPortEntPhysicalAlias(3), 580 chasIdMacAddress(4), 581 chasIdPtopoGenAddr(5) 582 } 584 PtopoChassisId ::= TEXTUAL-CONVENTION 585 STATUS current 586 DESCRIPTION 587 "This TC describes the format of a chassis identifier 588 string. Objects of this type are always used with an 589 associated PtopoChassisIdType object, which identifies the 590 format of the particular PtopoChassisId object instance. 592 If the associated PtopoChassisIdType object has a value of 593 'chasIdEntPhysicalAlias(1)', then the octet string 594 identifies a particular instance of the entPhysicalAlias 595 object for a chassis component (i.e., an entPhysicalClass 596 value of 'chassis(3)'). 598 If the associated PtopoChassisIdType object has a value of 599 'chasIdIfAlias(2)', then the octet string identifies a 600 particular instance of the ifAlias object for an interface 601 on the containing chassis. 603 If the associated PtopoChassisIdType object has a value of 604 'chasIdPortEntPhysicalAlias(3)', then the octet string 605 identifies a particular instance of the entPhysicalAlias 606 object for a port or backplane component within the 607 containing chassis. 609 If the associated PtopoChassisIdType object has a value of 610 'chasIdMacAddress(4)', then this string identifies a 611 particular unicast source MAC address (encoded in network 612 byte order and IEEE 802.3 canonical bit order), of a port on 613 the containing chassis. 615 If the associated PtopoChassisIdType object has a value of 616 'chasIdPtopoGenAddr(5)', then this string identifies a 617 particular network address, encoded in network byte order, 618 associated with one or more ports on the containing chassis. 619 The first octet contains the IANAAddrFamily enumeration 620 value for the specific address type, and octets 2 through N 621 contain the PtopoGenAddr address value in network byte 622 order." 623 SYNTAX OCTET STRING (SIZE (1..32)) 625 PtopoPortIdType ::= TEXTUAL-CONVENTION 626 STATUS current 627 DESCRIPTION 628 "This TC describes the source of a particular type of port 629 identifier used in the PTOPO MIB. 631 The enumeration 'portIdIfAlias(1)' represents a port 632 identifier based on the ifAlias MIB object. 634 The enumeration 'portIdPortEntPhysicalAlias(2)' represents a 635 port identifier based on the value of entPhysicalAlias for a 636 port or backplane component (i.e., entPhysicalClass value of 637 'port(10)' or 'backplane(4)'), within the containing 638 chassis. 640 The enumeration 'portIdMacAddr(3)' represents a port 641 identifier based on a unicast source MAC address, which has 642 been detected by the agent and associated with a particular 643 port. 645 The enumeration 'portIdPtopoGenAddr(4)' represents a port 646 identifier based on a network address, detected by the agent 647 and associated with a particular port." 648 SYNTAX INTEGER { 649 portIdIfAlias(1), 650 portIdEntPhysicalAlias(2), 651 portIdMacAddr(3), 652 portIdPtopoGenAddr(4) 653 } 655 PtopoPortId ::= TEXTUAL-CONVENTION 656 STATUS current 657 DESCRIPTION 658 "This TC describes the format of a port identifier string. 659 Objects of this type are always used with an associated 660 PtopoPortIdType object, which identifies the format of the 661 particular PtopoPortId object instance. 663 If the associated PtopoPortIdType object has a value of 664 'portIdIfAlias(1)', then the octet string identifies a 665 particular instance of the ifAlias object. 667 If the associated PtopoPortIdType object has a value of 668 'portIdEntPhysicalAlias(2)', then the octet string 669 identifies a particular instance of the entPhysicalAlias 670 object for a port component (i.e., entPhysicalClass value of 671 'port(10)'). 673 If the associated PtopoPortIdType object has a value of 674 'portIdMacAddr(3)', then this string identifies a particular 675 unicast source MAC address associated with the port. 677 If the associated PtopoPortIdType object has a value of 678 'portIdPtopoGenAddr(4)', then this string identifies a 679 network address associated with the port. The first octet 680 contains the IANAAddrFamily enumeration value for the 681 specific address type, and octets 2 through N contain the 682 PtopoGenAddr address value in network byte order." 683 SYNTAX OCTET STRING (SIZE (1..32)) 685 PtopoAddrSeenState ::= TEXTUAL-CONVENTION 686 STATUS current 687 DESCRIPTION 688 "This TC describes the state of address detection for a 689 particular type of port identifier used in the PTOPO MIB. 691 The enumeration 'not-used(1)' represents an entry for which 692 the particular MIB object is not applicable to the remote 693 connection endpoint, 695 The enumeration 'unknown(2)' represents an entry for which 696 the particular address collection state is not known. 698 The enumeration 'one-addr(3)' represents an entry for which 699 exactly one source address (of the type indicated by the 700 particular MIB object), has been detected. 702 The enumeration 'multi-addr(4)' represents an entry for 703 which more than one source address (of the type indicated by 704 the particular MIB object), has been detected. 706 An agent is expected to set the initial state of the 707 PtopoAddrSeenState to 'not-used(1)' or 'unknown(2)'. 709 Note that the PTOPO MIB does not restrict or specify the 710 means in which the PtopoAddrSeenState is known to an agent. 711 In particular, an agent may detect this information through 712 configuration data, or some means other than directly 713 monitoring all port traffic." 714 SYNTAX INTEGER { 715 not-used(1), 716 unknown(2), 717 one-addr(3), 718 multi-addr(4) 719 } 721 -- *********************************************************** 722 -- 723 -- P T O P O D A T A G R O U P 724 -- 725 -- *********************************************************** 727 -- Connection Table 729 ptopoConnTable OBJECT-TYPE 730 SYNTAX SEQUENCE OF PtopoConnEntry 731 MAX-ACCESS not-accessible 732 STATUS current 733 DESCRIPTION 734 "This table contains one or more rows per physical network 735 connection known to this agent. The agent may wish to 736 ensure that only one ptopoConnEntry is present for each 737 local port, or it may choose to maintain multiple 738 ptopoConnEntries for the same local port. 740 Entries based on lower numbered identifier types are 741 preferred over higher numbered identifier types, i.e., lower 742 values of the ptopoConnRemoteChassisType and 743 ptopoConnRemotePortType objects." 744 ::= { ptopoData 1 } 746 ptopoConnEntry OBJECT-TYPE 747 SYNTAX PtopoConnEntry 748 MAX-ACCESS not-accessible 749 STATUS current 750 DESCRIPTION 751 "Information about a particular physical network connection. 752 Entries may be created and deleted in this table, either 753 manually or by the agent, if a physical topology discovery 754 process is active." 755 INDEX { 756 ptopoConnTimeMark, 757 ptopoConnLocalChassis, 758 ptopoConnLocalPort, 759 ptopoConnIndex 761 } 762 ::= { ptopoConnTable 1 } 764 PtopoConnEntry ::= SEQUENCE { 765 ptopoConnTimeMark TimeFilter, 766 ptopoConnLocalChassis PhysicalIndex, 767 ptopoConnLocalPort PhysicalIndex, 768 ptopoConnIndex Integer32, 769 ptopoConnRemoteChassisType PtopoChassisIdType, 770 ptopoConnRemoteChassis PtopoChassisId, 771 ptopoConnRemotePortType PtopoPortIdType, 772 ptopoConnRemotePort PtopoPortId, 773 ptopoConnDiscAlgorithm AutonomousType, 774 ptopoConnAgentNetAddrType IANAAddrFamily, 775 ptopoConnAgentNetAddr PtopoGenAddr, 776 ptopoConnMultiMacSASeen PtopoAddrSeenState, 777 ptopoConnMultiNetSASeen PtopoAddrSeenState, 778 ptopoConnIsStatic TruthValue, 779 ptopoConnLastVerifyTime TimeStamp, 780 ptopoConnRowStatus RowStatus 781 } 783 ptopoConnTimeMark OBJECT-TYPE 784 SYNTAX TimeFilter 785 MAX-ACCESS not-accessible 786 STATUS current 787 DESCRIPTION 788 "A TimeFilter for this entry. See the TimeFilter textual 789 convention in RFC 2021 to see how this works." 790 ::= { ptopoConnEntry 1 } 792 ptopoConnLocalChassis OBJECT-TYPE 793 SYNTAX PhysicalIndex 794 MAX-ACCESS not-accessible 795 STATUS current 796 DESCRIPTION 797 "The entPhysicalIndex value used to identify the chassis 798 component associated with the local connection endpoint." 799 ::= { ptopoConnEntry 2 } 801 ptopoConnLocalPort OBJECT-TYPE 802 SYNTAX PhysicalIndex 803 MAX-ACCESS not-accessible 804 STATUS current 805 DESCRIPTION 806 "The entPhysicalIndex value used to identify the port 807 component associated with the local connection endpoint." 808 ::= { ptopoConnEntry 3 } 810 ptopoConnIndex OBJECT-TYPE 811 SYNTAX Integer32 (1..2147483647) 812 MAX-ACCESS not-accessible 813 STATUS current 814 DESCRIPTION 815 "This object represents an arbitrary local integer value 816 used by this agent to identify a particular connection 817 instance, unique only for the indicated local connection 818 endpoint. 820 A particular ptopoConnIndex value may be reused in the event 821 an entry is aged out and later re-learned with the same (or 822 different) remote chassis and port identifiers. 824 An agent is encouraged to assign monotonically increasing 825 index values to new entries, starting with one, after each 826 reboot. It is considered unlikely that the ptopoConnIndex 827 will wrap between reboots." 828 ::= { ptopoConnEntry 4 } 830 ptopoConnRemoteChassisType OBJECT-TYPE 831 SYNTAX PtopoChassisIdType 832 MAX-ACCESS read-create 833 STATUS current 834 DESCRIPTION 835 "The type of encoding used to identify the chassis 836 associated with the remote connection endpoint. 838 This object may not be modified if the associated 839 ptopoConnRowStatus object has a value of active(1)." 840 ::= { ptopoConnEntry 5 } 842 ptopoConnRemoteChassis OBJECT-TYPE 843 SYNTAX PtopoChassisId 844 MAX-ACCESS read-create 845 STATUS current 846 DESCRIPTION 847 "The string value used to identify the chassis component 848 associated with the remote connection endpoint. 850 This object may not be modified if the associated 851 ptopoConnRowStatus object has a value of active(1)." 852 ::= { ptopoConnEntry 6 } 854 ptopoConnRemotePortType OBJECT-TYPE 855 SYNTAX PtopoPortIdType 856 MAX-ACCESS read-create 857 STATUS current 858 DESCRIPTION 859 "The type of port identifier encoding used in the associated 860 'ptopoConnRemotePort' object. 862 This object may not be modified if the associated 863 ptopoConnRowStatus object has a value of active(1)." 864 ::= { ptopoConnEntry 7 } 866 ptopoConnRemotePort OBJECT-TYPE 867 SYNTAX PtopoPortId 868 MAX-ACCESS read-create 869 STATUS current 870 DESCRIPTION 871 "The string value used to identify the port component 872 associated with the remote connection endpoint. 874 This object may not be modified if the associated 875 ptopoConnRowStatus object has a value of active(1)." 876 ::= { ptopoConnEntry 8 } 878 ptopoConnDiscAlgorithm OBJECT-TYPE 879 SYNTAX AutonomousType 880 MAX-ACCESS read-only 881 STATUS current 882 DESCRIPTION 883 "An indication of the algorithm used to discover the 884 information contained in this conceptual row. 886 A value of ptopoDiscoveryPDP indicates this entry was 887 configured using the PTOPO Discovery Protocol. [PDP] 889 A value of ptopoDiscoveryLocal indicates this entry was 890 configured by the local agent, without use of a discovery 891 protocol. 893 A value of { 0 0 } indicates this entry was created manually 894 by an NMS via the associated RowStatus object. " 895 ::= { ptopoConnEntry 9 } 897 ptopoConnAgentNetAddrType OBJECT-TYPE 898 SYNTAX IANAAddrFamily 899 MAX-ACCESS read-create 900 STATUS current 901 DESCRIPTION 902 "This network address type of the associated 903 ptopoConnNetAddr object, unless that object contains a zero 904 length string. In such a case, an NMS application should 905 ignore any returned value for this object. 907 This object may not be modified if the associated 908 ptopoConnRowStatus object has a value of active(1)." 909 ::= { ptopoConnEntry 10 } 911 ptopoConnAgentNetAddr OBJECT-TYPE 912 SYNTAX PtopoGenAddr 913 MAX-ACCESS read-create 914 STATUS current 915 DESCRIPTION 916 "This object identifies a network address which may be used 917 to reach an SNMP agent entity containing information for the 918 chassis and port components represented by the associated 919 'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects. 920 If no such address is known, then this object shall contain 921 an empty string. 923 This object may not be modified if the associated 924 ptopoConnRowStatus object has a value of active(1)." 925 ::= { ptopoConnEntry 11 } 927 ptopoConnMultiMacSASeen OBJECT-TYPE 928 SYNTAX PtopoAddrSeenState 929 MAX-ACCESS read-only 930 STATUS current 931 DESCRIPTION 932 "This object indicates if multiple unicast source MAC 933 addresses have been detected by the agent from the remote 934 connection endpoint, since the creation of this entry. 936 If this entry has an associated ptopoConnRemoteChassisType 937 and/or ptopoConnRemotePortType value other than 938 'portIdMacAddr(3)', then the value 'not-used(1)' is 939 returned. 941 Otherwise, one of the following conditions must be true: 943 If the agent has not yet detected any unicast source MAC 944 addresses from the remote port, then the value 'unknown(2)' 945 is returned. 947 If the agent has detected exactly one unicast source MAC 948 address from the remote port, then the value 'one-addr(3)' 949 is returned. 951 If the agent has detected more than one unicast source MAC 952 address from the remote port, then the value 'multi-addr(4)' 953 is returned." 954 ::= { ptopoConnEntry 12 } 956 ptopoConnMultiNetSASeen OBJECT-TYPE 957 SYNTAX PtopoAddrSeenState 958 MAX-ACCESS read-only 959 STATUS current 960 DESCRIPTION 961 "This object indicates if multiple network layer source 962 addresses have been detected by the agent from the remote 963 connection endpoint, since the creation of this entry. 965 If this entry has an associated ptopoConnRemoteChassisType 966 or ptopoConnRemotePortType value other than 967 'portIdGenAddr(4)' then the value 'not-used(1)' is returned. 969 Otherwise, one of the following conditions must be true: 971 If the agent has not yet detected any network source 972 addresses of the appropriate type from the remote port, then 973 the value 'unknown(2)' is returned. 975 If the agent has detected exactly one network source address 976 of the appropriate type from the remote port, then the value 977 'one-addr(3)' is returned. 979 If the agent has detected more than one network source 980 address (of the same appropriate type) from the remote port, 981 this the value 'multi-addr(4)' is returned." 982 ::= { ptopoConnEntry 13 } 984 ptopoConnIsStatic OBJECT-TYPE 985 SYNTAX TruthValue 986 MAX-ACCESS read-create 987 STATUS current 988 DESCRIPTION 989 "This object identifies static ptopoConnEntries. If this 990 object has the value 'true(1)', then this entry is not 991 subject to any age-out mechanisms implemented by the agent. 993 If this object has the value 'false(2)', then this entry is 994 subject to all age-out mechanisms implemented by the agent. 996 This object may not be modified if the associated 997 ptopoConnRowStatus object has a value of active(1)." 998 DEFVAL { false } 999 ::= { ptopoConnEntry 14 } 1001 ptopoConnLastVerifyTime OBJECT-TYPE 1002 SYNTAX TimeStamp 1003 MAX-ACCESS read-only 1004 STATUS current 1005 DESCRIPTION 1006 "If the associated value of ptopoConnIsStatic is equal to 1007 'false(2)', then this object contains the value of sysUpTime 1008 at the time the conceptual row was last verified by the 1009 agent, e.g., via reception of a topology protocol message, 1010 pertaining to the associated remote chassis and port. 1012 If the associated value of ptopoConnIsStatic is equal to 1013 'true(1)', then this object shall contain the value of 1014 sysUpTime at the time this entry was last activated (i.e., 1015 ptopoConnRowStatus set to 'active(1)')." 1016 ::= { ptopoConnEntry 15 } 1018 ptopoConnRowStatus OBJECT-TYPE 1019 SYNTAX RowStatus 1020 MAX-ACCESS read-create 1021 STATUS current 1022 DESCRIPTION 1023 "The status of this conceptual row." 1024 ::= { ptopoConnEntry 16 } 1026 -- *********************************************************** 1027 -- 1028 -- P T O P O G E N E R A L G R O U P 1029 -- 1030 -- *********************************************************** 1032 -- last change time stamp for the whole MIB 1033 ptopoLastChangeTime OBJECT-TYPE 1034 SYNTAX TimeStamp 1035 MAX-ACCESS read-only 1036 STATUS current 1037 DESCRIPTION 1038 "The value of sysUpTime at the time a conceptual row is 1039 created, modified, or deleted in the ptopoConnTable. 1041 An NMS can use this object to reduce polling of the 1042 ptopoData group objects." 1043 ::= { ptopoGeneral 1 } 1045 ptopoConnTabInserts OBJECT-TYPE 1046 SYNTAX Counter32 1047 MAX-ACCESS read-only 1048 STATUS current 1049 DESCRIPTION 1050 "The number of times an entry has been inserted into the 1051 ptopoConnTable." 1052 ::= { ptopoGeneral 2 } 1054 ptopoConnTabDeletes OBJECT-TYPE 1055 SYNTAX Counter32 1056 MAX-ACCESS read-only 1057 STATUS current 1058 DESCRIPTION 1059 "The number of times an entry has been deleted from the 1060 ptopoConnTable." 1061 ::= { ptopoGeneral 3 } 1063 ptopoConnTabDrops OBJECT-TYPE 1064 SYNTAX Counter32 1065 MAX-ACCESS read-only 1066 STATUS current 1067 DESCRIPTION 1068 "The number of times an entry would have been added to the 1069 ptopoConnTable, (e.g., via information learned from a 1070 topology protocol), but was not because of insufficient 1071 resources." 1072 ::= { ptopoGeneral 4 } 1074 ptopoConnTabAgeouts OBJECT-TYPE 1075 SYNTAX Counter32 1076 MAX-ACCESS read-only 1077 STATUS current 1078 DESCRIPTION 1079 "The number of times an entry has been deleted from the 1080 ptopoConnTable because the information timeliness interval 1081 for that entry has expired." 1082 ::= { ptopoGeneral 5 } 1084 -- *********************************************************** 1085 -- 1086 -- P T O P O C O N F I G G R O U P 1087 -- 1088 -- *********************************************************** 1090 ptopoConfigTrapInterval OBJECT-TYPE 1091 SYNTAX Integer32 (0 | 5..3600) 1092 UNITS "seconds" 1093 MAX-ACCESS read-write 1094 STATUS current 1095 DESCRIPTION 1096 "This object controls the transmission of PTOPO traps. 1098 If this object has a value of zero, then no 1099 ptopoConfigChange notifications will be transmitted by the 1100 agent. 1102 If this object has a non-zero value, then the agent must not 1103 generate more than one ptopoConfigChange trap-event in the 1104 indicated period, where a 'trap-event' is the transmission 1105 of a single trap (or inform) PDU to a list of trap 1106 destinations. If additional configuration changes occur 1107 within the indicated throttling period, then these trap- 1108 events must be suppressed by the agent. An NMS should 1109 periodically check the value of ptopoLastChangeTime to 1110 detect any missed ptopoConfigChange trap-events, e.g. due to 1111 throttling or transmission loss. 1113 If notification transmission is enabled, the suggested 1114 default throttling period is 60 seconds, but transmission 1115 should be disabled by default. 1117 If the agent is capable of storing non-volatile 1118 configuration, then the value of this object must be 1119 restored after a re-initialization of the management 1120 system." 1121 DEFVAL { 0 } 1122 ::= { ptopoConfig 1 } 1124 ptopoConfigMaxHoldTime OBJECT-TYPE 1125 SYNTAX Integer32 (1..2147483647) 1126 UNITS "seconds" 1127 MAX-ACCESS read-write 1128 STATUS current 1129 DESCRIPTION 1130 "This object specifies the desired time interval for which 1131 an agent will maintain dynamic ptopoConnEntries. 1133 After the specified number of seconds since the last time an 1134 entry was verified, in the absence of new verification 1135 (e.g., receipt of a topology protocol message), the agent 1136 shall remove the entry. Note that entries may not always be 1137 removed immediately, but may possibly be removed at periodic 1138 garbage collection intervals. 1140 This object only affects dynamic ptopoConnEntries, i.e. for 1141 which ptopoConnIsStatic equals 'false(2)'. Static entries 1142 are not aged out. 1144 Note that dynamic ptopoConnEntries may also be removed by 1145 the agent due to the expired timeliness of learned topology 1146 information (e.g., timeliness interval for a remote port 1147 expires). The actual age-out interval for a given entry is 1148 defined by the following formula: 1150 age-out-time = 1151 min(ptopoConfigMaxHoldTime, ) 1153 where is determined by the 1154 discovery algorithm, and may be different for each entry. 1155 For entries discovered with PDP, this is the particular 1156 'time-to-live' value from the most recent PDP message 1157 associated with the entry." 1158 DEFVAL { 300 } 1159 ::= { ptopoConfig 2 } 1161 -- PTOPO MIB Trap Definitions 1162 ptopoMIBTraps OBJECT IDENTIFIER ::= { ptopoMIB 2 } 1163 ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= { ptopoMIBTraps 0 } 1165 ptopoConfigChange NOTIFICATION-TYPE 1166 OBJECTS { 1167 ptopoConnTabInserts, 1168 ptopoConnTabDeletes, 1169 ptopoConnTabDrops, 1170 ptopoConnTabAgeouts 1171 } 1172 STATUS current 1173 DESCRIPTION 1174 "A ptopoConfigChange trap is sent when the value of 1175 ptopoLastChangeTime changes. It can be utilized by an NMS to 1176 trigger physical topology table maintenance polls. 1178 Note that transmission of ptopoConfigChange notifications 1179 are throttled by the agent, as specified by the 1180 'ptopoConfigTrapInterval' object." 1181 ::= { ptopoMIBTrapPrefix 1 } 1183 -- PTOPO Registration Points 1185 ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 } 1187 -- values used with ptopoConnDiscAlgorithm object 1188 ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 } 1190 ptopoDiscoveryPDP OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 } 1191 ptopoDiscoveryLocal OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 2 } 1193 -- conformance information 1194 ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 } 1196 ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 } 1197 ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 } 1199 -- compliance statements 1201 ptopoCompliance MODULE-COMPLIANCE 1202 STATUS current 1203 DESCRIPTION 1204 "The compliance statement for SNMP entities which implement 1205 the PTOPO MIB." 1206 MODULE -- this module 1207 MANDATORY-GROUPS { 1208 ptopoDataGroup, 1209 ptopoGeneralGroup, 1210 ptopoConfigGroup, 1211 ptopoNotificationsGroup 1212 } 1213 ::= { ptopoCompliances 1 } 1215 -- MIB groupings 1217 ptopoDataGroup OBJECT-GROUP 1218 OBJECTS { 1219 ptopoConnRemoteChassisType, 1220 ptopoConnRemoteChassis, 1221 ptopoConnRemotePortType, 1222 ptopoConnRemotePort, 1223 ptopoConnDiscAlgorithm, 1224 ptopoConnAgentNetAddrType, 1225 ptopoConnAgentNetAddr, 1226 ptopoConnMultiMacSASeen, 1227 ptopoConnMultiNetSASeen, 1228 ptopoConnIsStatic, 1229 ptopoConnLastVerifyTime, 1230 ptopoConnRowStatus 1231 } 1232 STATUS current 1233 DESCRIPTION 1234 "The collection of objects which are used to represent 1235 physical topology information for which a single agent 1236 provides management information. 1238 This group is mandatory for all implementations of the PTOPO 1239 MIB." 1240 ::= { ptopoGroups 1 } 1242 ptopoGeneralGroup OBJECT-GROUP 1243 OBJECTS { 1244 ptopoLastChangeTime, 1245 ptopoConnTabInserts, 1246 ptopoConnTabDeletes, 1247 ptopoConnTabDrops, 1248 ptopoConnTabAgeouts 1249 } 1250 STATUS current 1251 DESCRIPTION 1252 "The collection of objects which are used to report the 1253 general status of the PTOPO MIB implementation. 1255 This group is mandatory for all agents which implement the 1256 PTOPO MIB." 1257 ::= { ptopoGroups 2 } 1259 ptopoConfigGroup OBJECT-GROUP 1260 OBJECTS { 1261 ptopoConfigTrapInterval, 1262 ptopoConfigMaxHoldTime 1263 } 1264 STATUS current 1265 DESCRIPTION 1266 "The collection of objects which are used to configure the 1267 PTOPO MIB implementation behavior. 1269 This group is mandatory for agents which implement the PTOPO 1270 MIB." 1271 ::= { ptopoGroups 3 } 1273 ptopoNotificationsGroup NOTIFICATION-GROUP 1274 NOTIFICATIONS { 1275 ptopoConfigChange 1276 } 1277 STATUS current 1278 DESCRIPTION 1279 "The collection of notifications used to indicate PTOPO MIB 1280 data consistency and general status information. 1282 This group is mandatory for agents which implement the PTOPO 1283 MIB." 1284 ::= { ptopoGroups 4 } 1286 END 1288 8. Intellectual Property 1290 The IETF takes no position regarding the validity or scope of any 1291 intellectual property or other rights that might be claimed to pertain 1292 to the implementation or use of the technology described in this 1293 document or the extent to which any license under such rights might or 1294 might not be available; neither does it represent that it has made any 1295 effort to identify any such rights. Information on the IETF's 1296 procedures with respect to rights in standards-track and standards- 1297 related documentation can be found in BCP-11. Copies of claims of 1298 rights made available for publication and any assurances of licenses to 1299 be made available, or the result of an attempt made to obtain a general 1300 license or permission for the use of such proprietary rights by 1301 implementors or users of this specification can be obtained from the 1302 IETF Secretariat." 1304 The IETF invites any interested party to bring to its attention any 1305 copyrights, patents or patent applications, or other proprietary rights 1306 which may cover technology that may be required to practice this 1307 standard. Please address the information to the IETF Executive 1308 Director. 1310 The IETF has been notified of intellectual property rights claimed in 1311 regard to some or all of the specification contained in this document. 1312 For more information consult the online list of claimed rights. 1314 9. Acknowledgements 1316 The PTOPO Discovery Protocol is a product of the IETF PTOPOMIB Working 1317 Group. 1319 10. References 1321 [ENTITY-MIB] 1322 McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2 (Version 1323 2)", draft-ietf-entmib-v2-01.txt, Cisco Systems, November 1998. 1325 [PDP] 1326 Bierman, A., and K. McCloghrie, "Physical Topology Discovery 1327 Protocol and MIB", draft-ietf-ptopomib-pdp-03.txt, Cisco Systems, 1328 November 1998. 1330 [RFC1155] 1331 Rose, M., and K. McCloghrie, "Structure and Identification of 1332 Management Information for TCP/IP-based Internets", RFC 1155, 1333 Performance Systems International, Hughes LAN Systems, May 1990. 1335 [RFC1157] 1336 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1337 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1338 International, Performance Systems International, MIT Laboratory 1339 for Computer Science, May 1990. 1341 [RFC1212] 1342 Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1343 Performance Systems International, Hughes LAN Systems, March 1991. 1345 [RFC1215] 1346 M. Rose, "A Convention for Defining Traps for use with the SNMP", 1347 RFC 1215, Performance Systems International, March 1991. 1349 [RFC1493] 1350 Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, 1351 "Definitions of Managed Objects for Bridges", RFC 1493, Cisco 1352 Systems, Inc., Digital Equipment Corporation, Hughes LAN Systems, 1353 Inc., July 1993. 1355 [RFC1700] 1356 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1357 USC/Information Sciences Institute, October 1994. 1359 [RFC1901] 1360 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1361 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 1362 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 1363 Inc., International Network Services, January 1996. 1365 [RFC1902] 1366 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1367 Waldbusser, "Structure of Management Information for version 2 of 1368 the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP 1369 Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1370 International Network Services, January 1996. 1372 [RFC1903] 1373 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1374 Waldbusser, "Textual Conventions for version 2 of the Simple 1375 Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, 1376 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1377 International Network Services, January 1996. 1379 [RFC1904] 1380 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1381 Waldbusser, "Conformance Statements for version 2 of the Simple 1382 Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, 1383 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1384 International Network Services, January 1996. 1386 [RFC1905] 1387 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1388 Waldbusser, "Protocol Operations for Version 2 of the Simple 1389 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 1390 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1391 International Network Services, January 1996. 1393 [RFC1906] 1394 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1395 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 1396 Management Protocol (SNMPv2)"", RFC 1906, SNMP Research, Inc., 1397 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1398 Network Services, January 1996. 1400 [RFC2021] 1401 S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 2021, 1402 International Network Services, January 1997. 1404 [RFC2037] 1405 McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037, 1406 Cisco Systems, October 1996. 1408 [RFC2108] 1409 de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, 1410 "Definitions of Managed Objects for IEEE 802.3 Repeater Devices 1411 using SMIv2", RFC 2108, 3Com Corporation, Madge Networks (Israel) 1412 Ltd., Coloma Communications, Cisco Systems Inc., February 1997. 1414 [RFC2233] 1415 McCloghrie, K., and F. Kastenholtz, "The Interfaces Group MIB using 1416 SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. 1418 [RFC2271] 1419 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1420 Describing SNMP Management Frameworks", RFC 2271, Cabletron 1421 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1422 January 1998. 1424 [RFC2272] 1425 Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1426 Processing and Dispatching for the Simple Network Management 1427 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 1428 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 1430 [RFC2273] 1431 Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1432 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 1433 Systems, January 1998. 1435 [RFC2274] 1436 Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1437 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1438 2274, IBM T. J. Watson Research, January 1998. 1440 [RFC2275] 1441 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1442 Control Model (VACM) for the Simple Network Management Protocol 1443 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 1444 Cisco Systems, Inc., January 1998. 1446 11. Security Considerations 1448 This MIB exposes information about the physical connectivity for a 1449 particular portion of a network. A network administrator may wish to 1450 restrict SNMP access to such information, but such agent security 1451 configuration is beyond the scope of this document. 1453 A network administrator may also wish to inhibit transmission of any 1454 ptopoConfigChange notification by setting the ptopoConfigTrapInterval 1455 object to zero. 1457 12. Authors' Addresses 1459 Andy Bierman 1460 Cisco Systems 1461 170 West Tasman Drive 1462 San Jose, CA USA 95134 1463 Phone: +1 408-527-3711 1464 Email: abierman@cisco.com 1466 Kendall S. Jones 1467 Bay Networks 1468 4401 Great America Parkway 1469 Santa Clara, CA USA 95134 1470 Phone: +1 408-495-7356 1471 Email: kjones@baynetworks.com 1473 13. Full Copyright Statement 1475 Copyright (C) The Internet Society (1998). All Rights Reserved. 1477 This document and translations of it may be copied and furnished to 1478 others, and derivative works that comment on or otherwise explain it or 1479 assist in its implementation may be prepared, copied, published and 1480 distributed, in whole or in part, without restriction of any kind, 1481 provided that the above copyright notice and this paragraph are included 1482 on all such copies and derivative works. However, this document itself 1483 may not be modified in any way, such as by removing the copyright notice 1484 or references to the Internet Society or other Internet organizations, 1485 except as needed for the purpose of developing Internet standards in 1486 which case the procedures for copyrights defined in the Internet 1487 Standards process must be followed, or as required to translate it into 1488 languages other than English. 1490 The limited permissions granted above are perpetual and will not be 1491 revoked by the Internet Society or its successors or assigns. 1493 This document and the information contained herein is provided on an "AS 1494 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1495 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1496 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1497 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1498 FITNESS FOR A PARTICULAR PURPOSE."